Übersicht über EJB-3.0- und EJB-3.1-Anwendungsbindungen

Eine auf einem Anwendungsserver installierte Anwendung kann erst gestartet werden, wenn alle in der Anwendung definierten EJB-Referenzen (Enterprise JavaBeans) und Ressourcenreferenzen an die tatsächlichen, im Anwendungsserver definierten Artefakte (Enterprise-Beans oder Ressourcen) gebunden sind.

Seit Version 8.0 steht eine erweiterte Unterstützung von Bindungen im EJB-Container zur Verfügung. Der EJB-Container ordnet auf der Basis von Anwendungsname, Modulname und Komponentenname Standard-JNDI-Bindungen für EJB-3.x-Geschäftsschnittstellen zu. Es ist nicht erforderlich, explizit JNDI-Bindungsnamen für jede Schnittstelle oder jedes EJB-Home in einem EJB-3.0-Modul bzw. für Sichten ohne Schnittstellen in einem EJB-3.1-Modul zu definieren.

Wenn Sie Bindungen definieren, geben Sie für die referenzierbaren und referenzierten Artefakte JNDI-Namen (Java™ Naming and Directory Interface) in einer Anwendung an. Die für Artefakte angegebenen jndiName-Werte müssen qualifizierte Lookup-Namen sein.

In EJB-3.x-Modulen ist es nicht erforderlich, JNDI-Bindungsnamen für jede Schnittstelle oder für jedes EJB-Home bzw. für Sichten ohne Schnittstellen in Ihren Enterprise-Beans manuell zuzuordnen. Wenn Sie keine Bindungen explizit zuordnen, ordnet der EJB-Container Standardbindungen zu.

Namespaces für Standard-EJB-JNDI-Bindungen

Der Anwendungsserver kann Standard-EJB-Bindungen sowohl in die Sätze mit klassischen Namespaces als auch in die Sätze mit java:[scope]-Namespaces stellen.

Der Satz mit klassischen Namespaces besteht aus den JNDI-Namespaces "ejblocal:" und "Global". Die klassischen Namespaces beinhalten eine WebSphere-Erweiterung und sie wurden in den Versionen vor Application Server Version 8.0 verwendet.

Der Satz mit java:[scope]-Namespaces besteht aus den Namespaces "java:global", "java:app" und "java:module". Die java:[scope]-Namespaces werden durch die Spezifikation Java EE 6 definiert und in WebSphere Application Server Version 8 bereitgestellt. Sie werden zusätzlich zu den klassischen Namespaces hinzugefügt.

Details zu klassischen Namespaces

Für EJB 3.x stellt das Produkt zwei getrennte Namespaces für EJB-Schnittstellen zur Verfügung, je nachdem, ob es sich um eine lokale oder eine ferne Schnittstelle handelt. Diese Vorgehensweise gilt auch für EJB-Home-Schnittstellen und Sichten ohne Schnittstellen, die als ein besonderer Typ von Schnittstellen betrachtet werden können. Es gibt folgende klassische Namespaces:
  • JVM-bezogener Namespace "ejblocal:"
  • globaler JNDI-Namespace

Lokale EJB-Schnittstellen und EJB-Home-Schnittstellen und Sichten ohne Schnittstellen müssen immer an einen klassischen JVM-Namespace "ejblocal:" gebunden werden. Sie sind nur innerhalb desselben Anwendungsserverprozesses zugänglich.

Im Gegensatz dazu müssen ferne EJB-Schnittstellen und EJB-Home-Schnittstellen immer in den globalen WebSphere-JNDI-Namespace gebunden werden, weil sie von überall aus zugänglich sind, auch von anderen Serverprozessen und anderen fernen Clients aus. Lokale Schnittstellen und Sichten ohne Schnittstellen können ebenso wenig an den klassischen globalen JNDI-Namespace gebunden werden, wie ferne Schnittstellen an den klassischen JVM-Namespace "ejblocal:" gebunden werden können.

Der klassische Namespace "ejblocal:" und der klassische globale JNDI-Namespace sind vollkommen getrennte und verschiedene Namespaces. Beispielsweise entspricht eine lokale EJB-Schnittstelle oder eine Sicht ohne Schnittstellen, die an "ejblocal:AccountHome" gebunden ist, in keiner Weise einer fernen Schnittstelle, die an "AccountHome" im klassischen globalen Namespace gebunden ist. Diese Unterscheidung hilft die Trennung zwischen Ihren Referenzen auf lokale und ferne Schnittstellen aufrechtzuerhalten. Die Verwendung eines lokalen JVM-Namespace ermöglicht es Ihren Anwendungen außerdem, lokale EJB-Schnittstellen und Sichten ohne Schnittstellen von jeder Position im JVM-Serverprozess aus direkt zu suchen oder zu referenzieren, auch über die Grenzen von Java EE-Anwendungen (Java Platform, Enterprise Edition) hinweg.

Zuordnung von klassischen JNDI-Standardbindungen für EJB-Geschäftsschnittstellen mit Anwendungs-, Modul- und Komponentennamen im EJB-3.x-Container

Der EJB-Container ordnet auf der Basis von Anwendungsname, Modulname und Komponentenname klassische Standard-JNDI-Bindungen für EJB-3.x-Geschäftsschnittstellen zu. Daher ist es wichtig zu wissen, wie diese Namen definiert werden. Jeder dieser Namen ist eine Zeichenfolge.

Java EE-Anwendungen sind in einem Standardformat gepackt, das als EAR-Datei (Enterprise Application Archive) bezeichnet wird. EAR ist das Format einer gepackten Datei, ähnlich dem Dateiformat .zip oder .tar, und kann als solches als eine Sammlung von logischen Verzeichnissen und Dateien verstanden werden, die in einer einzigen physischen Datei gepackt sind. In einer EAR-Datei sind ein oder mehrere Java EE-Moduldateien enthalten, die Folgendes enthalten können:
  • JAR-Dateien (Java Application Archive) für EJB-Module, Java EE-Anwendungsclientmodule und Dienstprogrammklassenmodule
  • WAR-Dateien (Web Application Archive) für Webmodule
  • andere technologiespezifische Module, z. B. RAR-Dateien (Resource Application Archive) und andere Arten von Modulen
In jeder Moduldatei sind normalerweise eine oder mehrere Java EE-Komponenten enthalten. Beispiele für Java EE-Komponenten sind Enterprise-Beans, Servlets und Hauptklassen des Anwendungsclients.

Weil Java EE-Module in Java EE-Anwendungsarchiven und Java EE-Komponenten wiederum in Java EE-Modulen gepackt sind, kann der "Verschachtelungspfad" jeder Komponente dazu verwendet werden, jede Komponente innerhalb eines Java EE-Anwendungsarchivs entsprechend ihrem Anwendungsnamen, Modulnamen und Komponentennamen eindeutig zu identifizieren.

In klassischen Bindungen verwendeter Anwendungsname

Der Name einer Anwendung wird durch Folgendes definiert (in der Reihenfolge ihrer Priorität angegeben):
  • den Wert des Anwendungsnamens, der bei der Installation der Anwendung im Produkt in der Administrationskonsole des Produkts oder im Parameter appname im Befehlszeilenscriptingtool wsadmin angegeben wird.
  • den Wert des Parameters <display-name> im Implementierungsdeskriptor META-INF/application.xml für die Anwendung.
  • den EAR-Dateinamen ohne Dateisuffix .ear. Beispielsweise hätte eine Anwendungs-EAR-Datei mit dem Namen CustomerServiceApp.ear den Anwendungsnamen "CustomerServiceApp".
Die Spezifikation Java EE 6 stellt für EJB JNDI-Lookup-Namen mit dem allgemeinen Format java:global[/Anwendungsname]/Modulname/Bean-Name bereit. Die Komponente Anwendungsname des Lookup-Namens wird als optional angezeigt, weil sie nicht auf Beans, die in eigenständigen Modulen implementiert sind, anwendbar ist. Nur Beans, die in EAR-Dateien (.ear) gepackt sind, enthalten die Komponente Anwendungsname im Lookup-Namen "java:global". Die Regeln, die den Wert für Anwendungsname bestimmen, unterscheiden sich von den Regeln, die zuvor für Anwendungsnamen beschrieben wurden. Der Wert für Anwendungsname in der oben genannten Lookup-Namensschablone "java:global" wird durch Folgendes definiert (geordnet nach Priorität):
  • den Wert des Parameters <application-name> im Implementierungsdeskriptor application.xml für die Anwendung.
  • den EAR-Dateinamen ohne Dateisuffix .ear. Beispielsweise hätte eine Anwendungs-EAR-Datei mit dem Namen CustomerServiceApp.ear den Anwendungsnamen "CustomerServiceApp". Wenn die Anwendung ein eigenständiges Modul ist, enthält der Lookup-Name "java:global" keine Anwendungskomponente.
Der Wert für Anwendungsname ist auch der Zeichenfolgewert, der unter dem Namen "java:app/AppName" gemäß der Spezifikation Java EE 6 gebunden wird.

In klassischen Bindungen verwendeter Modulname

Der Name eines Moduls wird als URI (Uniform Resource Identifier) der Moduldatei relativ zum Stammverzeichnis der EAR-Datei, in der es enthalten ist, definiert. Anders ausgedrückt, der Modulname ist der Dateiname des Moduls relativ zum Stammverzeichnis der EAR-Datei einschließlich aller Unterverzeichnisse, in denen die Moduldatei verschachtelt ist. Diese Namenskonvention ist auch gültig, wenn der logische Modulname mit dem Element "module-name" im Implementierungsdeskriptor explizit angegeben wird.

Im folgenden Beispiel enthält die Anwendung "CustomerServiceApp" drei Module mit den Namen AccountProcessing.jar, Utility/FinanceUtils.jar und AppPresentation.war:
CustomerServiceApp.ear:AccountProcessing.jar
com/mycompany/AccountProcessingServiceBean.class AccountProcessingService.class
Utility/FinanceUtils.jar META-INF/ejb-jar.xml
com/mycompany/InterestCalculatorServiceBean.class InterestCalculatorService.class
AppPresentation.war META-INF/web.xml  
Die Spezifikation Java EE 6 stellt für EJB JNDI-Lookup-Namen mit dem allgemeinen Format java:global[/Anwendungsname]/Modulname/Bean-Name bereit. Die Komponente Anwendungsname des Lookup-Namens wird als optional angezeigt, weil sie nicht auf Beans, die in eigenständigen Modulen implementiert sind, anwendbar ist. Nur Beans, die in EAR-Dateien (.ear) gepackt sind, enthalten die Komponente Anwendungsname im Lookup-Namen "java:global". Eine andere Variante des JNDI-Lookup-Namens, die den Modulnamen enthält, ist "java:app/Modulname/Bean-Name". Der Wert für Modulname ist nicht der Modul-URI. Der Wert für Modulname in den Lookup-Namensschablonen "java:global" und "java:app" wird durch Folgendes definiert (geordnet nach Priorität):
  • Der Wert des Parameters <module-name> im Implementierungsdeskriptor ejb-jar.xml oder web.xml für das Modul.
  • den Modul-URI, jedoch ohne das Suffix .jar oder .war. Beispiel: Ein Modul mit dem URI CustomerService.jar oder CustomerService.war hat den Modulnamen "CustomerService".
Der Wert für Modulname ist auch der Zeichenfolgewert, der unter dem Namen "java:module/Modulname" gemäß der Spezifikation Java EE 6 gebunden wird. Dies gilt ebenfalls für Clientmodule. Für Clientmodule befindet sich der Parameter <module-name> in der Implementierungsdeskriptordatei application-client.xml.

In klassischen Bindungen verwendeter Name der EJB-Komponente

Der Name einer EJB-Komponente wird durch den folgenden Wert definiert (in der Reihenfolge ihrer Priorität angegeben):
  • den Wert des Tags "ejb-name", der der Bean im Implementierungsdeskriptor ejb-jar.xml zugeordnet ist, falls vorhanden.
  • den Wert des Parameters "name", falls vorhanden, in der Annotation "@Stateless" oder "@Stateful", die der Bean zugeordnet ist.
  • den Namen der Bean-Implementierungsklasse ohne Qualifikationsmerkmal auf Paketebene.

Klassische Standardbindungen für EJB-Geschäftsschnittstellen, Home-Schnittstellen und Sichten ohne Schnittstellen

Es ist nicht erforderlich, explizit JNDI-Bindungsnamen für jede Schnittstelle oder jedes EJB-Home in einem EJB-3.x-Modul bzw. für Sichten ohne Schnittstellen in einem EJB-3.1-Modul zu definieren. Wenn Sie keine Bindungen explizit zuordnen, ordnet der EJB-Container des Produkts klassische Standardbindungen zu, indem er die hier beschriebenen Regeln anwendet. Dieses Verhalten weicht ab von der EJB-Unterstützung im Produkt, die vor der Spezifikation EJB 3.0 zur Anwendung kam.

Der EJB-Container führt in jeder Enterprise-Bean zwei klassische Standardbindungen für jede Schnittstelle aus (Geschäftsschnittstelle, ferne Home-Schnittstelle oder lokale Home-Schnittstelle). Diese zwei klassischen Bindungen werden hier als kurze und lange Bindung der Sichten mit bzw. ohne Schnittstellen bezeichnet. Die kurze Bindung verwendet lediglich den mit dem Paket qualifizierten Java-Klassennamen der Sicht mit bzw. ohne Schnittstellen, während die lange Bindung die Komponenten-ID der Enterprise-Bean als zusätzliches Qualifikationsmerkmal vor dem mit dem Paket qualifizierten Klassennamen der Sicht mit bzw. ohne Schnittstellen verwendet, wobei zwischen Komponenten-ID und Klassenname der Sicht mit bzw. ohne Schnittstellen ein Hash oder Nummernzeichen (#) eingefügt wird. Sie können sich den Unterschied zwischen den beiden Formen so vorstellen wie den Unterschied zwischen dem kurzen TCP/IP-Hostnamen (nur Maschinenname) und dem langen Hostnamen (Maschinenname mit vorangestelltem Domänennamen).

Die kurze und die lange klassische Bindung für eine Sicht mit bzw. ohne Schnittstellen können wie folgt lauten: com.mycompany.AccountService versus AccountApp/module1.jar/ServiceBean#com.mycompany.AccountService.

Standardmäßig wird die Komponenten-ID für klassische EJB-Standardbindungen aus Anwendungsname, Modulname und Komponentenname der Enterprise-Bean gebildet. Sie können aber stattdessen auch eine beliebige andere Zeichenfolge zuordnen. Wenn Sie eine eigene Zeichenfolge als Komponenten-ID definieren, können Sie eine Namenskonvention festlegen, in der die Bindungen im Langformat einen gemeinsamen benutzerdefinierten Teil, darüber hinaus aber auch einen vom System definierten Teil enthalten, der auf dem Namen der entsprechenden Klasse der Sicht mit bzw. ohne Schnittstellen basiert. Dadurch ist es auch möglich, die Standard-EJB-Bindungsnamen unabhängig davon zu machen, wie die Enterprise-Beans innerhalb der Anwendungsmodulhierarchie gepackt wurden. Die Vorgehensweise zum Überschreiben der Standardkomponenten-ID einer Enterprise-Bean wird im Abschnitt "Benutzerdefinierte Bindungen für EJB-Geschäftsschnittstellen, Home-Schnittstellen und Sichten ohne Schnittstellen" in diesem Artikel beschrieben.

Wie weiter oben im Abschnitt über den klassischen lokalen JVM-Namespace und den klassischen globalen JNDI-Namespace erwähnt, müssen alle lokalen Schnittstellen und Home-Schnittstellen an den klassischen Namespace "ejblocal:" gebunden werden, der nur innerhalb desselben Serverprozesses (JVM) zugänglich ist, während ferne Schnittstellen und Home-Schnittstellen an den klassischen globalen Namespace gebunden werden müssen, der von jeder Position innerhalb der WebSphere-Produktzelle aus zugänglich ist. Wie zu erwarten wäre, befolgt der EJB-Container diese Regeln für Standardbindungen.

Darüber hinaus verwenden lange Standardbindungen für ferne Schnittstellen die bewährten Verfahren für Java EE, indem sie unter einem ejb-Kontextnamen gruppiert werden. Standardmäßig werden ferne EJB-Home- und -Geschäftsschnittstellen im Stammelement des Namenskontextes des Anwendungsservers gebunden. Allerdings wird der Stammkontext des Anwendungsservers nicht nur zum Binden von EJB-Schnittstellen verwendet. Damit dieser Kontext nicht zu stark belegt wird, empfiehlt es sich, EJB-bezogene Bindungen in einem gemeinsamen "ejb"-Subkontext zu gruppieren, anstatt sie direkt in den Stammkontext des Servers zu stellen. Dieser Vorgehensweise liegt eine ähnliche Überlegung zu Grunde wie die, Unterverzeichnisse auf einem Plattendatenträger zu erstellen, anstatt alle Dateien im Stammverzeichnis zu speichern.

Die kurzen Standardbindungen für ferne Schnittstellen werden nicht an den ejb-Kontext gebunden. Die kurzen Standardbindungen sind im Stammelement des Serverstammkontextes enthalten. Obwohl es ein bewährtes Verfahren ist, alle EJB-bezogenen Bindungen unter einem ejb-Kontext zu gruppieren, gibt es andere Überlegungen. Dazu gehört Folgendes:
  • Die kurzen Standardbindungen bieten eine einfache, direkte Zugriffsmöglichkeit auf eine EJB-Schnittstelle. Indem sie direkt in den Serverstammkontext gestellt und lediglich über den Schnittstellennamen oder den Schnittstellennamen mit vorangestelltem "ejblocal:" referenziert werden, erfüllen sie dieses Ziel der Einfachheit.
  • Indem die langen Standardbindungen in den ejb-Kontext oder, im Fall einer lokalen Schnittstelle, in den Kontext von "ejblocal:" gestellt wurden, blieben diese Bindungen gleichzeitig außerhalb des Stammkontextes des Servers, sodasss die Belegung des Stammkontextes so gering gehalten wurde, dass die kurzen Bindungen dort gespeichert werden konnten.
  • Diese Vorgehensweise bietet eine übergreifende Kompatibilität mit anderen Java EE-Anwendungsservern, die ähnliche Namenskonventionen verwenden.

Zusammenfassend kann man festhalten, dass alle lokalen Standardbindungen, sowohl im Kurz- als auch im Langformat, in den klassischen Server-/JVM-Namespace "ejblocal:" gestellt werden, während ferne Standardbindungen im Kurzformat in den Serverstammkontext des klassischen globalen Namespace und im Langformat in den Kontext "<Serverstammkontext>/ejb" (direkt unterhalb des Stammkontextes des Servers) gestellt werden. Daher sind die einzigen Standardbindungen, die im globalen Stammkontext des Servers enthalten sind, die kurzen Bindungen für ferne Schnittstellen. Auf diese Weise wird eine Ausgewogenheit hergestellt zwischen dem Anspruch, ein einfaches, portables Verwendungsmodell bereitzustellen und der Anforderung, den globalen Stammkontext des Servers von einer Überbelegung freizuhalten.

Standardbindungsmuster

Die Muster für jeden Typ Standardbindungen sind unten in der Tabelle aufgeführt. In diesen Mustern stellen die in eckige Klammern gesetzten Zeichenfolgen in <Kursivschrift> einen Wert dar. Beispiel: , <mit_dem_Paket.qualifizierte.Schnittstelle> kann den Wert"com.mycompany.AccountService" und <Komponenten-ID> den Wert "AccountApp/module1.jar/ServiceBean" haben.

Tabelle 1. Standardbindungsmuster. Standardbindungsmuster
Bindungsmuster Beschreibung
ejblocal:<mit_dem_Paket.qualifizierte.Schnittstelle> Kurzes Format für lokale Schnittstellen, Home-Schnittstellen und Sichten ohne Schnittstellen
<mit_dem_Paket.qualifizierte.Schnittstelle> Kurzes Format für ferne Schnittstellen und Home-Schnittstellen
ejblocal:<Komponenten-ID>#<mit_dem_Paket.qualifizierte.Schnittstelle> Langes Format für lokale Schnittstellen, Home-Schnittstellen und Sichten ohne Schnittstellen
ejb/<Komponenten-ID>#<mit_dem_Paket.qualifizierte.Schnittstelle> Langes Format für ferne Schnittstellen und Home-Schnittstellen

Die Komponenten-ID wird standardmäßig in <Anwendungsname>/<Modul-JAR-Name>/<EJB-Name> aufgelöst, sofern sie nicht wie im nächsten Abschnitt, "Konflikte in kurzen Standardbindungsnamen bei Implementierung derselben Schnittstelle durch mehrere Enterprise-Beans", beschrieben, in der Bindungsdatei des EJB-Moduls mit dem Attribut "component-id" überschrieben wird. Die Variable <Modul-JAR-Name> entspricht, wenn sie nicht durch die Bindungsdatei des EJB-Moduls überschrieben wird, dem physischen Moduldateinamen in der EAR-Datei einschließlich Erweiterung, z. B. .jar, .ear, .war, gemäß der Beschreibung im vorherigen Abschnitt "Modulname". Dies trifft auch zu, wenn im Implementierungsdeskriptor ein logischer Modulname angegeben ist.

Konflikte in kurzen Standardbindungsnamen bei Implementierung derselben Schnittstelle durch mehrere Enterprise-Beans

Wenn mehrere Enterprise-Beans, die im Anwendungsserver ausgeführt werden, eine bestimmte Sicht mit bzw. ohne Schnittstellen implementieren, dann wird der kurze Standardbindungsname mehrdeutig, weil sich der Kurzname auf alle Enterprise JavaBeans beziehen kann, die die Sicht mit bzw. ohne Schnittstellen implementieren. Zur Vermeidung dieser Situation müssen Sie entweder, wie im nächsten Abschnitt beschrieben, explizit eine Bindung für jede EJB-Bean definieren, die die betreffende Sicht mit bzw. ohne Schnittstelle implementiert, oder die kurzen Standardbindungen für Anwendungen inaktivieren, die diese Enterprise JavaBeans enthalten, indem Sie im WebSphere-Produkt eine angepasste JVM-Eigenschaft mit dem Namen "com.ibm.websphere.ejbcontainer.disableShortDefaultBindings" definieren. Weitere Informationen zur Definition der angepassten JVM-Eigenschaft finden Sie im Artikel "Angepasste Eigenschaften für Java Virtual Machine".

Damit Sie diese angepasste JVM-Eigenschaft verwenden können, legen Sie als Eigenschaftsnamen com.ibm.websphere.ejbcontainer.disableShortFormBinding fest und geben Sie als Eigenschaftswert entweder einen Stern (*) als Platzhalterzeichen an, um Standardbindungen im Kurzformat für alle Anwendungen im Server zu inaktivieren, oder geben Sie eine durch Doppelpunkte begrenzte Folge von Java EE-Anwendungsnamen an, für die die kurzen Standardbindungen inaktiviert werden sollen, z. B. PayablesApp:InventoryApp:AccountServicesApp.

Auswirkungen der expliziten Zuordnung von klassischen Standardbindungen

Wenn Sie eine Bindungsdefinition einer Schnittstelle, einem Home oder einer Sicht ohne Schnittstellen explizit zuordnen, werden keine kurzen oder langen klassischen Standardbindungen für diese Sicht mit bzw. ohne Schnittstellen erstellt.
Unterstützte Konfigurationen Unterstützte Konfigurationen: Dies gilt nur für die Schnittstellen bzw. die Sichten ohne Schnittstellen, denen Sie eine explizite Bindung zuordnen. Andere Instanzen in dieser Enterprise-Bean, die nicht über explizit zugeordnete Bindungen verfügen, werden unter Verwendung von klassischen Standardbindungsnamen gebunden.sptcfg

java:[scope]-Namespaces

Die Namespaces "java:global", "java:app" und "java:module" werden durch die Spezifikation Java EE 6 eingeführt. Sie stellen ein Verfahren für das Binden und Suchen von Ressourcen bereit, das anwendungsserverübergreifend portiert werden kann.

Der Server erstellt für jede EJB-Schnittstelle, einschließlich der Sicht ohne Schnittstelle, immer eine Standardbindung mit langem Format und stellt sie in die Namespaces "java:global", "java:app" und "java:module". Eine Bindung mit kurzem Format wird auch erstellt und in die Namespaces "java:global", "java:app" und "java:module" gestellt, falls die Bean einschließlich der Sicht ohne Schnittstelle nur eine Schnittstelle bereitstellt. Die Standardbindungen werden nur für Session-Beans erstellt. Sie werden nicht für Entity-Beans oder nachrichtengesteuerte Beans (Message driven Beans, MDB) erstellt.

Die Bindungen im Langformat und im Kurzformat enthalten beide den Anwendungsnamen, den Modulnamen und den Namen der Bean-Komponente. Der Anwendungsname wird standardmäßig mit dem Basisnamen der EAR-Datei (ohne Erweiterung) angegeben. Der Anwendungsname kann mit dem Element "application-name" in der Datei "application.xml" überschrieben werden. Der Modulname wird standardmäßig mit dem Pfadnamen des Moduls angegeben, zwar ohne die Erweiterung, doch mit allen Verzeichnisnamen. Der Modulname kann mit dem Element "module-name" in der Datei "ejb-jar.xml" oder "web.xml" überschrieben werden. Der Name der Bean-Komponente wird standardmäßig mit dem nicht qualifizierten Namen der Bean-Klasse angegeben. Der Name der Bean-Komponente kann mit dem Attribut "name" in der Annotation der EJB-Komponente oder mit dem Element "ejb-name" in der Datei "ejb-jar.xml" überschrieben werden.

Das Bindungsmuster im Langformat ist java:global/<Anwendungsname>/<Modulname>/<Name der Bean-Komponente>!<vollständig qualifizierter Schnittstellenname>.

Das Bindungsmuster im Kurzformat ist java:global/<Anwendungsname>/<Modulname>/<Name der Bean-Komponente>.

Beispielsweise stellt die Bean-Komponente MyBeanComponent nur die Schnittstelle "com.foo.MyBeanComponentLocalInterface" bereit und ist im Modul myModule.jar in der Datei myApp.ear enthalten. In den java:[scope]-Bindungen werden die folgenden Namespaces erstellt:
  • java:global/myApp/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
  • java:global/myApp/myModule/MyBeanComponent
  • java:app/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
  • java:app/myModule/MyBeanComponent
  • java:module/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
  • java:module/MyBeanComponent
Die Bean "MyBeanComponent" kann mit einem der folgenden Verfahren von den java:[scope]-Namespaces abgerufen werden:
  • Attribut "lookup" in der Annotation @EJB verwenden. Beispiel:
    @EJB(lookup="java:global/myApp/myModule/MyBeanComponent")
  • Element "lookup-name" in der Datei ejb-jar.xml verwenden. Beispiel:
    <lookup-name>java:global/myApp/myModule/MyBeanComponent!com.ibm.MyBeanComponentLocalInterfaces</lookup-name>
  • Suche nach dem Objekt "InitialContext" durchführen. Beispiel:
    initialContext.lookup("java:global/myApp/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterfaces")

Zusätzlich zu den vom Anwendungsserver erstellten Standardbindungen kann der Benutzer Referenzen in den Namespaces "java:global", "java:app" und "java:module" definieren. Referenzen, die in den Namespaces "java:global", "java:app" und "java:module" definiert sind, werden nicht in den Namespace "component" gestellt. Referenzen, die in den Namespaces "java:global", "java:app" und "java:module" definiert sind, müssen in diesen Namespaces gesucht oder aus den Namespaces injiziert werden. Es besteht nicht die Möglichkeit, sie im Namespace "component" zu suchen oder aus diesem Namespace zu injizieren.

Eine Bean-Komponente kann den Namespace "java:module" verwenden, um eine Referenz zu deklarieren, die von einer Komponente, die in demselben Modul enthalten ist, genutzt werden kann. Sie kann den Namespace "java:app" verwenden, um eine Referenz zu deklarieren, die von einer Komponente, die in einem anderen Modul innerhalb derselben Anwendung enthalten ist, genutzt werden kann. Sie kann den Namespace "java:global" verwenden, um eine Referenz zu deklarieren, die von einer Komponente, die in einer anderen Anwendung enthalten ist, genutzt werden kann.

Zwischen gleichnamigen Referenzen in den Namespaces "java:global", "java:app" und "java:module" können Konflikte auftreten, so wie zwischen gleichnamigen Referenzen im Namespace "component". Eine Referenz, die sich auf den Namespace "java:app" für eine Anwendung bezieht, steht mit einer Referenz gleichen Namens, die sich auf den Namespace "java:app" für eine andere Anwendung bezieht, nicht in Konflikt. Analog dazu steht eine Referenz, die sich auf den Namespace "java:module" für ein Modul bezieht, mit einer Referenz desselben Namens, die sich auf den Namespace "java:module" für ein anderes Modul bezieht, nicht in Konflikt.

Eine Referenz kann mit Annotationen im java:global-Namespace deklariert werden. Beispiel:
@EJB(name="java:global/env/myBean")
Eine Referenz kann in der Datei ejb-jar.xml deklariert werden. Beispiel:
<resource-ref>
    <res-ref-name>java:global/env/myDataSource</res-ref-name>
    ....
</resource-ref>         

Weitere Informationen zu den java:[scope]-Namespaces finden Sie im Abschnitt 5.2.2 der Spezifikation Java EE 6 und im Abschnitt 4.4 der Spezifikation Enterprise JavaBeans 3.1.

Benutzerdefinierte Bindungen für EJB-Geschäftsschnittstellen, Home-Schnittstellen und Sichten ohne Schnittstellen

In den Fällen, in denen anstelle der Standardbindungen des Produkts Bindungspositionen manuell zugeordnet werden sollen, können Sie die Bindungsdatei des EJB-Moduls verwenden, um bestimmten Schnittstellen, Home-Schnittstellen und Sichten ohne Schnittstellen eigene Bindungspositionen zuzuordnen. Sie können diese Datei auch dazu verwenden, den Teil der Standardbindung, der die Komponenten-ID enthält, in einer oder mehreren Enterprise-Beans im Modul zu überschreiben. Das Überschreiben der Komponenten-ID stellt einen Mittelweg dar zwischen der Verwendung von Bindungen, die vollständig standardisiert sind, und der vollständigen Angabe des Bindungsnamens für jede Schnittstelle oder Sicht ohne Schnittstellen.

Wenn Sie Informationen zu benutzerdefinierten Bindungen für Module der EJB Version 3.x angeben möchten, speichern Sie eine Datei mit dem Namen "ibm-ejb-jar-bnd.xml" im Verzeichnis "META-INF" für die EJB-JAR-Datei. Für diese Datei wird das Suffix "XML" verwendet. Beachten Sie außerdem, dass dem Namen die Zeichenfolge "ejblocal:" vorangestellt werden muss, falls eine klassische Bindung für eine lokale Schnittstelle oder eine Sicht ohne Schnittstellen definiert wird, damit diese an den klassischen JVM-Namespace "ejblocal:" gebunden wird.

Die Datei ibm-ejb-jar-bnd.xml wird für Module der EJB Version 3.0 und spätere Module verwendet, die im Produkt ausgeführt werden, während die Datei ibm-ejb-jar.bnd.xmi für Module vor EJB 3.0 und für Webmodule verwendet wird. Das Format der Bindungsdatei in ibm-ejb-jar.bnd.xml unterscheidet sich von dem früheren XMI-Dateiformat. Dies hat folgende Gründe:
  • Bindungen und Erweiterungen, die im XMI-Dateiformat deklariert werden, benötigen eine entsprechende Implementierungsdeskriptordatei mit dem Namen ejb-jar.xml, in der explizit auf eindeutige ID-Nummern verwiesen wird, die den Elementen in dieser Datei zugeordnet sind. Dieses System funktioniert für Module von EJB 3.0 oder höher nicht mehr, da in diesen Module der Implementierungsdeskriptor ejb-jar.xml keine Voraussetzung mehr ist.
  • Das XMI-Dateiformat war so gestaltet, dass es nur von Entwicklungstools und Systemmanagementfunktionen des Produkts editiert werden konnte. Es war Teil der internen Produktimplementierung und die Dateistruktur wurde niemals extern dokumentiert. Daher war es für Entwickler unmöglich, mit einer vom Produkt unterstützten Methode Bindungsdateien manuell zu editieren oder diese als Teil eines von WebSphere unabhängigen Erstellungsprozesses zu erstellen.
  • Anstatt codierte ID-Nummern im Implementierungsdeskriptor ejb-jar.xml zu referenzieren, verweist die XML-basierte Bindungsdatei auf die EJB-Komponenten über ihren EJB-Namen. Jeder EJB-Komponente in einem Modul wird ein eindeutiger EJB-Name zugesichert, entweder durch Standardzuordnung oder durch explizite Zuordnung seitens des Entwicklers. Bei diesem Verhalten werden eindeutige Zielbindungen und -erweiterungen bereitgestellt.
  • Die neuen Bindungsdateien sind XML-basiert und es wird eine XSD-Datei (XML Schema Definition) bereitgestellt, um die Struktur extern zu dokumentieren. Diese .xsd-Dateien können von vielen gebräuchlichen XML-Dateieditoren zur Unterstützung bei der Syntaxprüfung und für Funktionen zur Codefertigstellung verwendet werden. Folglich sind Entwickler jetzt in der Lage, die Bindungs- und Erweiterungsdateien unabhängig von der Infrastruktur des Anwendungsservers zu erzeugen und zu editieren.
Die folgende Tabelle listet die Elemente von ibm-ejb-jar-bnd.xml auf sowie die Attribute, die für die Zuordnung von Bindungen zu EJB-Schnittstellen und EJB-Home-Schnittstellen für EJB-3.x-Module und Sichten ohne Schnittstellen für EJB-3.1-Module verwendet werden.
Tabelle 2. Elemente und Attribute in der Datei ibm-ejb-jar-bnd.xml. Elemente und Attribute in der Datei ibm-ejb-jar-bnd.xml
Element oder Attribut Verwendung Beispiel Kommentare
<session> Deklariert eine Gruppe von Bindungszuordnungen für eine Session-Bean. <session name="AccountServiceBean"/> Erfordert ein Namensattribut und mindestens eines der folgenden Attribute: Attribut "simple-binding-name", Attribut "local-home-binding-name", Attribut "remote-home-binding-name" oder Element "<interface>".
name Ein Attribut, das den EJB-Namen (ejb-name) der Enterprise-Bean angibt, für die eines der Elemente "<session>", "<message-driven>" oder "<entity>" oder ein anderes Element gilt. <session name="AccountServiceBean"/> Der Namenswert ist der im Element "<ejb-name>" in der Implementierungsdeskriptordatei "ejb-jar.xml" deklarierte Name, das Attribut "name" der Annotation "@Stateful", "@Stateless", "@Singleton" oder "@MessageDriven" oder der Standardwert des nicht qualifizierten Klassennamens der EJB-Implementierungsklasse mit der Annotation "@Session" oder "@MessageDriven" (falls im XML-Implementierungsdeskriptor kein Wert für "<ejb-name>" und in der Annotation kein Parameter "name" deklariert ist).
component-id Ein Attribut, das den Standardwert der Komponenten-ID für eine Enterprise-Bean überschreibt. Die klassischen Standardbindungen im Langformat für diese Enterprise-Bean verwendet die angegebene Komponenten-ID anstelle von <Anwendungsname>/<Modul-JAR-Name>/<Bean-Name>.
<session name="AccountServiceBean"
component-id="Dept549/AccountProcessor"/>

Das Ergebnis des oben aufgeführten Beispiels ist eine Bean mit dem EJB-Namen (ejb-name) "AccountServiceBean". Ihre lokalen Standardschnittstellen im Langformat sind unter ejblocal:Department549/AccountProcessor#<package.qualified.interface> und ihre fernen Standardschnittstellen im Langformat unter ejb/Department549/AccountProcessor#<package.qualified.interface> gebunden.

Dieses Attribut kann allein verwendet werden oder zusammen mit dem Element "<interface>", dem Attribut "local-home-binding-name" oder dem Attribut "remote-home-binding-name". Schnittstellen, denen keine expliziten Bindungen zugeordnet sind, erhalten klassische Standardbindungen, die unter Verwendung des benutzerdefinierten Werts der Komponenten-ID ausgeführt werden. Schnittstellen, denen explizite Bindungen zugeordnet wurden, werden unter Verwendung dieser Werte gebunden.

Weil das Attribut "simple-binding-name" für alle definierten Schnittstellen in einer bestimmten Enterprise-Bean gelten soll (wobei keine Schnittstelle Standardbindungen verwenden soll), ist die Verwendung einer Komponenten-ID (component-id) zusammen mit dem Attribut "simple-binding-name" in der Regel nicht sinnvoll.

simple-binding-name Ein einfacher Mechanismus für die Zuordnung von Schnittstellenbindungen für Enterprise JavaBeans, die folgende Schnittstellen implementieren:
  • ein einzelne EJB-3.x-Geschäftsschnittstelle oder
  • eine Komponentenschnittstelle (lokal und/oder fern) vor EJB 3.0 mit einem begleitenden EJB-Home.
Der Wert des Attributs wird als Bindungsposition der Geschäftsschnittstelle der Enterprise-Bean verwendet oder als Bindungsposition der lokalen und/oder der fernen Home-Schnittstelle der Enterprise JavaBeans. Die Bindung wird für eine lokale Schnittstelle oder ein lokales Home in den klassischen Namespace "ejblocal:" gestellt und für eine ferne Schnittstelle oder ein fernes Home in den Anwendungsserver-Stammkontext des klassischen globalen JNDI-Namespace.
<session name="AccountServiceBean"
simple-binding-name="ejb/AccountService"/>
Das Ergebnis des oben aufgeführten Beispiels ist eine Bean mit dem EJB-Namen (ejb-name) "AccountServiceBean". Ihre lokale Geschäfts- oder Home-Schnittstelle, falls vorhanden, wird unter "ejblocal:ejb/AccountService" im klassischen lokalen JVM-EJB-Namespace und ihre ferne Geschäfts- oder Home-Schnittstelle, falls vorhanden, wird unter "ejb/AccountService" im Stammkontext des Anwendungsservers des klassischen globalen JNDI-Namespace gebunden.
Wichtig: Wichtig:
Der genaue Wert des Attributs, einschließlich des Subkontextnamens "ejb" in diesem speziellen Beispiel, wird auch verwendet, wenn die Schnittstelle eine lokale Schnittstelle ist, die an den Namespace "ejblocal:" gebunden ist. Wenn benutzerdefinierte Bindungen angegeben werden, wird der durch das Attribut festgelegte exakte Name verwendet.
Dieses Attribut darf nicht zusammen mit den Attributen "local-home-binding-name" und "remote-home-binding-name" oder zusammen mit dem Element "<interface>" verwendet werden. Darüber hinaus sollte es nicht in Beans verwendet werden, die mehrere Geschäftsschnittstellen implementieren - in diesem Fall sollte stattdessen das Element "<interface>" verwendet werden.

Wird dieses Attribut in einer Enterprise-Bean verwendet, die mehrere Geschäftsschnittstellen oder eine Kombination aus Geschäftsschnittstelle und lokaler/ferner Komponentenschnittstelle mit Home implementiert, wird die Mehrdeutigkeit der resultierenden Bindungen dadurch aufgehoben, dass ein Hash oder Nummernzeichen (#) gefolgt von dem mit dem Paket qualifizierten Klassennamen jeder Schnittstelle und/oder jeder Home-Schnittstelle in der Enterprise-Bean an den Attributwert angehängt wird. Diese Situation kann jedoch vermieden werden, wenn das Element "<interface>" anstelle von "simple-binding-name" verwendet wird, um für jede Geschäftsschnittstelle eine Bindung zu definieren.

Wichtig: Wichtig:
Wenn das Element "simple-binding-name" in einer Bean definiert wird, die mehrere Geschäftsschnittstellen implementiert, ist dies nicht derselbe Vorgang wie das Überschreiben der Standard-Komponenten-ID für eine Bean mithilfe des Attributs "<component-id>". Standardbindungen für ferne Schnittstellen, die mit einer Komponenten-ID (component-id) definiert wurden, werden weiterhin unter dem ejb-Kontext gruppiert (wie alle Standardbindungen für ferne Schnittstellen), während Bindungen für ferne Schnittstellen, deren Mehrdeutigkeit (die das Ergebnis einer falschen Verwendung von "simple-binding-name" in einer Bean mit mehreren Schnittstellen ist) vom EJB-Container aufgehoben wurde, nicht unter dem ejb-Kontext gruppiert werden.
Außerdem wird der mit dem Paket qualifizierte Klassenname für klassische Standardbindungen im langen Format immer aufgenommen, während dies bei Verwendung von "simple-binding-name" nur im Fall von Fehlerbedingungen durch Auflösen von Mehrdeutigkeit geschieht. Es wird jedoch empfohlen, sich bei der Erstellung des Bindungsnamens nicht darauf zu verlassen, dass er durch Auflösen der Mehrdeutigkeit erstellt wird, da sich dieser Mechanismus ändern kann, wenn die Bean geändert wird, um mehr oder weniger Schnittstellen zu implementieren.
local-home-binding-name Ein Attribut zur Angabe der Bindungsposition der lokalen Home-Schnittstelle einer Enterprise-Bean.
<session name="AccountServiceBean"
 local-home-binding-name="ejblocal:AccountService"/>
Dieses Attribut darf nicht zusammen mit dem Attribut "simple-binding-name" verwendet werden. Weil lokale Home-Schnittstellen immer an den klassischen JVM-Namespace gebunden werden müssen, muss der Wert mit dem Präfix "ejblocal:" beginnen.
remote-home-binding-name Ein Attribut zur Angabe der Bindungsposition der fernen Home-Schnittstelle einer Enterprise-Bean.
<session name="AccountServiceBean"
 remote-home-binding-name=
 "ejb/services/AccountService"/>
Dieses Attribut darf nicht zusammen mit dem Attribut "simple-binding-name" verwendet werden. Der Wert darf nicht mit dem klassischen Präfix "ejblocal:" beginnen, weil ferne Home-Schnittstellen nicht an den klassischen Namespace "ejblocal:" gebunden werden können.
<interface> Ein Unterelement des Elements "<session>", das einer bestimmten EJB-Geschäftsschnittstelle oder einer Sicht ohne Schnittstellen eine Bindung zuordnet. Anders als bei den Attributen "simple-binding-name", "local-home-binding-name" und "remote-home-binding-name" müssen sowohl der Parameter "binding-name" als auch der Parameter "class" angegeben werden. (Diese Unterscheidung ist tatsächlich der Grund dafür, dass ein separates XML-Element statt eines Attributs erforderlich ist.) Der Parameter "class" gibt den mit dem Paket qualifizierten Namen der Geschäftsschnittstellenklasse bzw. der Klasse der Sicht ohne Schnittstellen an, die gebunden werden soll.
<interface class="com.ejbs.InventoryService" 
binding-name="ejb/Inventory"/> 
(deklariert als Unterelement in einem Element <session>)
Dieses Attribut darf nicht zusammen mit dem Attribut "simple-binding-name" verwendet werden. Weil lokale Schnittstellen und Sichten ohne Schnittstellen immer an den klassischen JVM-Namespace gebunden werden müssen, muss der Wert für "binding-name" mit dem Präfix "ejblocal:" beginnen, wenn dieses Element auf eine lokale Schnittstelle oder eine Sicht ohne Schnittstellen angewendet wird.
binding-name Ein Attribut zur Angabe der Bindungsposition einer Geschäftsschnittstelle, die mit dem Element "<interface>" gebunden wird.
<interface class="com.ejbs.InventoryService" 
binding-name="ejb/Inventory"/>
(deklariert als Unterelement in einem Element <session>)
Dieses Attribut muss zusammen mit dem Element "<interface>" angegeben werden (und wird nur in diesem Element verwendet). Weil lokale Schnittstellen immer an den JVM-Namespace gebunden werden müssen, muss der Wert für "binding-name" mit dem Präfix "ejblocal:" beginnen, wenn dieses Element auf eine lokale Schnittstelle angewendet wird.

Beispiel 1 für eine Bindungsdatei

Nachfolgend ist eine Basisdatei mit dem Namen "ibm-ejb-jar-bnd.xml" aufgeführt, die nur die Elemente und Attribute enthält, die EJB-Schnittstellen und Sichten ohne Schnittstellen Bindungsnamen zuordnen. Diese Datei überschreibt die Komponenten-ID, die für Standardbindungen in der Enterprise-Bean mit dem Namen S01 verwendet wird, und ordnet einigen Schnittstellen in den Enterprise-Beans, in diesem Modul S02 und S03, explizite Bindungen zu.
<?xml version="1.0" encoding="UTF-8?"> 
<ejb-jar-bnd xmlns=http://websphere.ibm.com/xml/ns/javaee xmlns:xsi="
 http://www.w3.org/2001/XMLSchema-instance "xsi:schemaLocation"=
 http://websphere.ibm.com/xml/ns/javaee 
 http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd "version 1.0">
 <session name="S01" component-id="Department549/AccountProcessors"/>
 <session name="S02" simple-binding-name="ejb/session/S02"/> 
 <session name="S03"> 
  <interface class="com.ejbs.BankAccountService" binding-name="ejblocal:session/BAS"/>
 </session>  
</ejb-jar-bnd>
Die Bindungsdatei führt zu folgendem Ergebnis:
  • Der Session-Bean mit dem EJB-Namen (ejb-name) "S01" wird für alle Schnittstellen und Sichten ohne Schnittstellen in dieser Bean eine benutzerdefinierte Komponenten-ID zugeordnet (Anwendungsname/EJB-JAR-Modulname/Bean-Name). Lokale Schnittstellen und Sichten ohne Schnittstellen in dieser Bean sind unter ejblocal:Department549/AccountProcessors#<package.qualified.interface.name> und ihre fernen Schnittstellen unter ejb/Department549/AccountProcessors#<package.qualified.interface.name> gebunden.
  • Für die Session-Bean mit dem EJB-Namen S02 wird eine einzelne EJB-3.x-Geschäftsschnittstelle oder eine EJB-3.1-Sicht ohne Schnittstellen angenommen. Alternativ dazu könnte sie über eine "Komponenten"-Schnittstelle vor EJB 3.0 mit lokalem Home und/oder fernem Home verfügen. Die Geschäftsschnittstelle oder die Home-Schnittstelle(n) der Komponentenschnittstelle werden unter ejblocal:ejb/session/S02 gebunden, wenn es sich um eine lokale Schnittstelle handelt, oder sie werden unter ejb/session/S02 gebunden, wenn es sich um eine ferne Schnittstelle handelt.

    Falls die Bean S02 über mehrere Geschäftsschnittstellen oder über Geschäftsschnittstelle(n) und Home verfügt, ist ein einfacher Bindungsname (simple-binding-name) mehrdeutig. In diesem Fall wird die Mehrdeutigkeit der Bindungszuordnungen vom Container aufgelöst, indem er an den einfachen Bindungsnamen "ejb/session/S02" für jede Schnittstelle der Bean #<mit_dem_Paket.qualifizierter.Schnittstellenname> anhängt.

  • Die EJB-3.x-Geschäftsschnittstelle oder die EJB-3.1-Sicht ohne Schnittstellen, "com.ejbs.BankAccountService", in der Session-Bean mit dem EJB-Namen S03 wird unter "ejblocal:session/BAS" gebunden.
Sind weitere Geschäftsschnittstellen, Home-Schnittstellen und Sichten ohne Schnittstellen in dieser Bean vorhanden, werden ihnen klassische Standardbindungen zugeordnet. Die Schnittstelle "com.ejbs.BankAccountService" wird als lokale Schnittstelle eingestuft, weil sie in diesem Beispiel dem Namespace "ejblocal:" zugewiesen wurde. Wäre sie keine lokale Schnittstelle, würde dies einen Fehler auslösen.

Im nächsten Abschnitt wird dieses Beispiel näher erläutert. Dabei werden Elemente für das Auflösen der Ziele unterschiedlicher Arten von Referenz- und Injektionseinträgen eingeführt, die entweder im XML-Implementierungsdeskriptor oder über Annotationen deklariert wurden.

Benutzerdefinierte Bindungen zum Auflösen von Referenzen und Injektionszielen

Im vorherigen Abschnitt wurde beschrieben, wie benutzerdefinierte Bindungsnamen für Geschäftsschnittstellen, Home-Schnittstellen und Sichten ohne Schnittstellen zugeordnet werden. In diesem Abschnitt erfahren Sie, wie Verbindungsziele für Referenzen, Injektionsanweisungen und Ziele für nachrichtengesteuerte Beans aufgelöst werden.

Tabelle 3. Elemente und Attribute für die Auflösung von Verbindungszielen für Referenzen und Injektionsziele. Elemente und Attribute für die Auflösung von Verbindungszielen für Referenzen und Injektionsziele
Element oder Attribut Verwendung Beispiel Kommentare
<jca-adapter> Definiert die JCA-1.5.-Adapteraktivierungsspezifikation und eine JNDI-Position als Nachrichtenziel für die Zustellung von Nachrichten an eine nachrichtengesteuerte Bean.
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
destination-binding-name="jms/ServiceQueue"/>
Erfordert die Angabe des Attributs activation-spec-binding-name. Wenn die zugehörige nachrichtengesteuerte Bean ihr Nachrichtenziel nicht über das Element "<message-destination-link>" identifiziert, dann ist das Attribut "destination-binding-name" ebenfalls erforderlich. Kann optional das Attribut "activation-spec-auth-alias" enthalten.
<ejb-ref> Löst das Ziel einer "ejb-ref"-Deklaration auf, die über die Annotation "@EJB" oder über "ejb-ref" im Implementierungsdeskriptor "ejb-jar.xml" deklariert wurde, und stellt dadurch die Verbindung bereit zwischen dem im Komponentennamespace "java:comp/env" deklarierten Namen und dem Namen der Ziel-Enterprise-Bean im klassischen JVM-Namespace "ejblocal:" oder im klassischen globalen JNDI-Namespace.
<ejb-ref name="com.ejbs.BankAccountServiceBean/s02Ref" 
binding-name="ejb/session/S02"/>
Erfordert die Angabe der Attribute "name" und "binding-name".
<message-driven> Deklariert eine Gruppe von Bindungszuordnungen für eine nachrichtengesteuerte Bean (Message-driven Bean).
<message-driven name="EventRecorderBean">
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec" 
destination-binding-name="jms/ServiceQueue"/>
</message-driven>
Erfordert die Angabe des Attributs "name" und des Unterelements "<jca-adapter>".
<message-destination> Ordnet den Namen eines Nachrichtenziels, bei dem es sich um einen logischen Namen handelt, der in einem Implementierungsdeskriptor des Java EE-Moduls definiert wurde, einem bestimmten globalen JNDI-Namen zu, der ein tatsächlicher Name im JNDI-Namespace ist. Die Elemente des Typs "<message-destination-ref>" im Implementierungsdeskriptor des Java EE-Moduls oder die Injektionsanweisungen des Typs "@Resource", die Nachrichtenziele einfügen, können anschließend mit dem Element "<message-destination-line>" dieses Nachrichtenziel ("message-destination") über den logischen Namen des Ziels referenzieren. Auf diese Weise entfällt die Anforderung, für jede definierte "message-destination-ref" in der Bindungsdatei Bindungseinträge des Typs "<message-destination-ref>" anzugeben.
<message-destination name="EventProcessingDestination"
binding-name="jms/ServiceQueue"/>
Erfordert die Angabe der Attribute "name" und "binding-name".
<message-destination-ref> Löst das Ziel einer "message-destination-ref"-Deklaration auf, die über die Annotation "@Resource" oder über "message-destination-ref" im Implementierungsdeskriptor "ejb-jar.xml" deklariert wurde, und stellt dadurch die Verbindung bereit zwischen dem im Komponentennamespace "java:comp/env" deklarierten Namen und dem Namen der Zielressourcenumgebung im globalen JNDI-Namespace.
<message-destination-ref
name="com.ejbs.BankAccountServiceBean/serviceQueue"
binding-name="jms/ServiceQueue"/>
Erfordert die Angabe der Attribute "name" und "binding-name".
<resource-ref> Löst das Ziel einer "resource-ref"-Deklaration auf, die über die Annotation "@Resource" oder über "resource-ref" im Implementierungsdeskriptor "ejb-jar.xml" deklariert wurde, und stellt dadurch die Verbindung bereit zwischen dem im Komponentennamespace "java:comp/env" deklarierten Namen und dem Namen der Zielressource im globalen JNDI-Namespace.
<resource-ref name="com.ejbs.BankAccountServiceBean/dataSource"
binding-name="jdbc/Default"/>
Erfordert die Angabe der Attribute "name" und "binding-name". Kann die Attribute "authentication-alias" oder "custom-login-configuration" enthalten.
<resource-env-ref> Löst das Ziel einer "resource-env-ref"-Deklaration auf, die über die Annotation "@Resource" oder über "resource-env-ref" im Implementierungsdeskriptor "ejb-jar.xml" deklariert wurde, und stellt dadurch die Verbindung bereit zwischen dem im Komponentennamespace "java:comp/env" deklarierten Namen und der Zielressourcenumgebung im globalen JNDI-Namespace.
<resource-env-ref 
name="com.ejbs.BankAccountServiceBean/dataFactory"
binding-name="jdbc/Default"/>
Erfordert die Angabe der Attribute "name" und "binding-name".
<env-entry> Überschreibt einen Umgebungseintrag mit dem angegebenen, im Zeichenfolgeformat dargestellten Wert, oder mit einem Objekt, das mit einem JNDI-Lookup des angegebenen Lookup-Namens, der auf den Standardausgangskontext angewendet wird, aufgerufen werden kann.
<env-entry name="java:module/env/taxYear" value="2010"/>
<env-entry name="java:module/env/taxYear" binding-name="cell/persistent/MyApp/MyModule/taxYear"/
Erfordert das Attribut "name" und das Attribut "value" oder das Attribut "binding-name", jedoch nicht beide.
<data-source> Überschreibt eine Datenquellendefinition, die über die Annotation @DataSourceDefinition, über das Element "data-source" in der Anwendung oder einen Implementierungsdeskriptor für Module mit einer verwalteten Ressource deklariert wird.
<data-source name="java:module/env/myDS" 
binding-name="jdbc/DB2DS"/>
Erfordert die Angabe der Attribute "name" und "binding-name".
name Ein Attribut, das die normalerweise im komponentenspezifischen Namespace "java:comp/env" enthaltene Namensposition angibt, die die "Quellenseite" einer Referenz-/Zielverbindung definiert, wie in "ejb-ref", "resource-ref", "resource-env-ref", "message-destination" oder "message-destination-ref".
<ejb-ref name="com.ejbs.BankAccountServiceBean/goodBye"
binding-name="ejb/session/S02"/>
 
binding-name Ein Attribut, das die im klassischen Namespace "ejblocal:", im klassischen globalen JNDI-Namespace oder im Namespace "java:global" enthaltene Namensposition angibt, die die "Zielseite" einer Referenz-/Zielverbindung definiert, wie in "ejb-ref", "resource-ref", "resource-env-ref", "message-destination" oder "message-destination-ref".
<ejb-ref name="com.ejbs.BankAccountServiceBean/goodBye"
binding-name="ejb/session/S02"/>
 
value Attribut, das den Wert für eine env-entry-Bindung angibt.
<env-entry name="java:module/env/taxYear" value="2010"/>
 
activation-spec-binding-name Ein Attribut, das die JNDI-Position der Aktivierungsspezifikation angibt, die dem JCA-1.5-Adapter zugeordnet ist, der für die Zustellung von Nachrichten in einer nachrichtengesteuerten Bean verwendet werden soll.
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
destination-binding-name="jms/ServiceQueue"/>
Dieser Name muss mit dem Namen einer JCA-1.5-Aktivierungsspezifikation übereinstimmen, die Sie für WebSphere Application Server definieren.
activation-spec-auth-alias Ein optionales Attribut, das den Namen eines J2C-Authentifizierungsalias angibt, der für die Authentifizierung von Verbindungen mit dem JCA-Ressourcenadapter verwendet wird. Ein J2C-Authentifizierungsalias gibt die Benutzer-ID/Kennwort-Kombination an, die für die Authentifizierung einer neuen Verbindung mit dem JCA-Ressourcenadapter verwendet wird.
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
activation-spec-auth-alias="jms/Service47Alias"
destination-binding-name="jms/ServiceQueue"/>
Dieser Name muss mit dem Namen eines J2C-Berechtigungsalias übereinstimmen, den Sie für WebSphere Application Server definieren.
destination-binding-name Ein Attribut, das den JNDI-Namen angibt, den die nachrichtengesteuerte Bean verwendet, um das JMS-Ziel im JNDI-Namespace zu ermitteln.
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
destination-binding-name="jms/ServiceQueue"/>
Dieser Name muss mit dem Namen einer JMS-Warteschlange oder eines JMS-Topics übereinstimmen, das Sie für WebSphere Application Server definieren.
authentication -alias Optionales Unterelement des Bindungselements "<resource-ref>". Falls die Ressourcenreferenz für eine Verbindungsfactory erfolgt, kann eine optionale JAAS-Anmeldekonfiguration angegeben werden, in diesem Fall ein einfacher Authentifizierungsalias.
<resource-ref name="com.ejbs.BankAccountServiceBean/dataSource"
binding-name="jdbc/Default">
<authentication-alias name="defaultAuth"/>
<resource-ref>
Dieser Name muss mit dem Namen eines JAAS-Berechtigungsalias übereinstimmen, den Sie für WebSphere Application Server definieren.
custom-login-configuration Optionales Unterelement des Bindungselements "<resource-ref>". Falls die Ressourcenreferenz für eine Verbindungsfactory erfolgt, kann eine optionale JAAS-Anmeldekonfiguration angegeben werden, in diesem Fall eine Gruppe von Eigenschaften (Name/Wert-Paare).
<resource-ref name="com.ejbs.BankAccountServiceBean/dataSource"
binding-name="jdbc/Default">
<custom-login-configuration-name="customLogin">
<property name="loginParm1" value="ABC123"/>
<property name="loginParm2" value="DEF456"/>
</custom-login-configuration> 
</resource-ref>
Dieser Name muss mit dem Namen einer JAAS-Anmeldekonfiguration übereinstimmen, die Sie für WebSphere Application Server definieren.

Beispiel 2 für eine Bindungsdatei

Nachfolgend ist eine Erweiterung der im Beispiel 1 eingeführten Basisdatei ibm-ejb-jar-bnd.xml dargestellt.
<?xml version="1.0" encoding="UTF-8"?> 
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" "xmlns:xsi"=
"http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee" 
"http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd version" "1.0">
 <session name="S01" component-id="Department549/AccountProcessors"/>
 <session name="S02" simple-binding-name="ejb/session/S02"/>
 <session name="S03">
  <interface class="com.ejbs.BankAccountService"
   binding-name="ejblocal:session/BAS"/>
  <ejb-ref name="com.ejbs.BankAccountServiceBean/goodBye"
   binding-name="ejb/session/S02"/>
  <resource-ref name="com.ejbs.BankAccountServiceBean/dataSource"
   binding-name="jdbc/Default"/>
 </session>
 <message-driven name="MO1">
  <jca-adapter activation-spec-binding-name="jms/InternalProviderSpec"
   destination-binding-name=jms/"ServiceQueue"/>
 </message-driven>
 <session name="S04" simple-binding-name="ejb/session/S04">
  <resource-ref name="ejbs.S04Bean/dataSource"
   binding-name="jdbc/Default">
   <authentication-alias name="defaultlogin"/>
  </resource-ref>
 </session>
 <session name="S05">
  <interface class="com.ejbs.InventoryService" 
   binding-name="ejb/session/S05Inventory"/>
  <resource-ref name="ejbs.S05Bean/dataSource"
   binding-name="jdbc/Default">
   <custom-login-configuration name="customLogin">
    <property name="loginParm1" value="ABC123"/>
    <property name="loginParm2" value="DEF456"/>
   </custom-login-configuration>
  </resource-ref>
 </session>
</ejb-jar-bnd>
Die Bindungsdatei führt zu folgendem Ergebnis:
  1. Die Geschäftsschnittstellen- und Home-Bindungen sowie die Bindungen der Sichten ohne Schnittstellen für die Session-Beans mit den Namen S01, S02 und S03 stimmen mit denen im vorherigen Beispiel überein.
  2. Die Session-Bean mit dem EJB-Namen (ejb-name) S03 enthält jetzt zwei Bindungen für die Auflösung des Referenzziels:
    • Die Bindung "ejb-ref" löst die in "java:comp/env/com.ejbs.BankAccountServiceBean/goodBye" definierte EJB-Referenz in die JNDI-Position "ejb/session/S02" im JNDI-Stammkontext des Anwendungsservers auf. Die EJB-Referenz könnte auch von einer "@EJB"-Injektion in der Klasse "com.ejbs.BankAccountServiceBean" in eine Instanzvariable mit dem Namen "goodBye" definiert worden sein.
      Anmerkung: "ejb/session/S02" ist die JNDI-Position der Session-Bean S02, die ebenfalls in derselben Bindungsdatei definiert ist, was zur Folge hat, dass die Referenz auf die Session-Bean mit dem Nahen S02 verweist.
    • Die Bindung "resource-ref" löst die in "java:comp/env/com.ejbs.BankAccountServiceBean/dataSource" definierte Ressourcenreferenz in die JNDI-Position "jdbc/Default" auf. Die Ressourcenreferenz könnte auch von einer "@Resource"-Injektion in der Klasse "com.ejbs.BankAccountServiceBean" in eine Instanzvariable mit dem Namen "dataSource" definiert worden sein.
  3. Es werden Bindungen für eine nachrichtengesteuerte Bean (Message-Driven Bean, MDB) mit dem EJB-Namen (ejb-name) M01 definiert. Die MDB empfängt Nachrichten von einem in WebSphere Application Server definierten JMS-Ziel mit dem JNDI-Namen "jms/ServiceQueue". Sie verwendet dazu einen JCA-1.5-Adapter, dessen JCA-1.5-Aktivierungsspezifikation in WebSphere Application Server unter dem Namen "jms/InternalProviderSpec" definiert wurde.
  4. Für die Session-Bean mit dem EJB-Namen (ejb-name) S04 ist eine einzelne Geschäftsschnittstelle oder Sicht ohne Schnittstellen vorgesehen, die unter "ejb/session/S04" gebunden ist, wenn es sich um eine ferne Schnittstelle handelt, und unter "ejblocal:ejb/session/S04", wenn es sich um eine lokale Schnittstelle handelt. Sie verfügt über eine "resource-ref" mit dem Namen "java:comp/env/ejbs/S04Bean/dataSource". Dies kann auch die Klasse "ejbs.S04Bean" mit einer Injektion von "@Resource" in eine Variable mit dem Namen "dataSource" sein. Diese "resource-ref" wurde in die JNDI-Position "jdbc/Default" aufgelöst. "resource-ref" bezieht sich auf eine J2C-Verbindung und stellt über einen für WebSphere Application Server definierten einfachen Authentifizierungsalias mit dem Namen defaultlogin eine Verbindung zu dieser Ressource her.
  5. Eine Geschäftsschnittstellenbindung wird für die Schnittstelle mit dem Klassennamen "com.ejbs.InventoryService" definiert, die von der Session-Bean mit dem EJB-Namen S05 implementiert wird. Die Schnittstelle wird als ferne Schnittstelle behandelt, da ihr nicht das Präfix "ejblocal:" vorangestellt ist. Sie wird folglich unter "ejb/session/S05Inventory" an den klassischen globalen Namespace im JNDI-Stammkontext des Servers gebunden. Allen übrigen Geschäftsschnittstellen, die von dieser Bean implementiert werden, werden klassische Standardbindungen zugeordnet. Die Bean verfügt über eine "resource-ref" mit dem Namen "java:comp/env/ejbs.S05Bean/dataSource" (oder eine "@Resource"-Injektion in der Klasse "ejbs.S05Bean" in eine Variable mit dem Namen "dataSource"), die in die JNDI-Position "jdbc/Default" aufgelöst wird. "resource-ref" bezieht sich auf eine J2C-Verbindung und stellt über eine angepasste Anmeldekonfiguration, die zwei Name/Wert-Paare enthält, eine Verbindung zu dieser Ressource her.

Beispiel 3 für eine Bindungsdatei

Dieses Beispiel zeigt, wie EJB-Referenzbindungen definiert und aufgelöst werden, damit JNDI-Suchoperationen (Lookups) in den Anwendungsserverinstanzen innerhalb einer WebSphere Application Server-Zelle ausgeführt werden. Es werden zwei EJB-Beans verwendet: eine aufgerufene Bean, die mit dem Attribut simple-binding-name eine explizite Bindung definiert, und eine aufrufende Bean, die eine "@EJB"-Injektion ausführt und das Element "ejb-ref" in der ihr zugeordneten Bindungsdatei verwendet, um die Referenz so aufzulösen, dass sie auf die aufgerufene Bean zeigt, die in einem anderen Anwendungsserverprozess enthalten ist.

ibm-ejb-jar-bnd.xml (aufgerufene Bean)

<?xml version="1.0" encoding="UTF-8"?> 
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee" 
 "http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd" version="1.0"> 
 <session name="FacadeBean" simple-binding-name="ejb/session/FacadeBean"/> 
</ejb-jar-bnd>
Dieser Inhalt der Bindungsdatei geht davon aus, dass die Session-Bean mit dem EJB-Namen "FacadeBean" eine einzelne Geschäftsschnittstelle implementiert. Folglich kann das Attribut "simple-binding-name" als Alternative zum Unterelement "<interface>" verwendet werden.) In diesem Fall implementiert die FacadeBean eine einzelne ferne Geschäftsschnittstelle, die unter "ejb/session/FacadeBean" im JNDI-Stammkontext des Anwendungsservers gebunden ist, in dem die FacadeBean enthalten ist.

Codefragment (aufrufende Bean)

@EJB(name="ejb/FacadeRemoteRef") 	
FacadeRemote remoteRef; 	
try {
     output = remoteRef.orderStatus(input);
} 
catch (Exception e) {
     		// Ausnahmen behandeln, usw.
} 
Dieses Codefragment führt eine EJB-Ressourceninjektion in die Instanzvariable mit dem Namen "remoteRef" durch, die den Typ "FacadeRemote" hat. Die Injektion überschreibt den Parameter "name", indem Sie den resultierenden "ejb-ref"-Referenznamen als "ejb/FacadeRemoteRef" festlegt. Der Code ruft eine Geschäftsmethode für die mittels Injektion eingefügte Referenz auf.

ibm-ejb-jar-bnd.xml (calling bean)

<?xml version="1.0" encoding="UTF-8"?> 
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee"
 "xmlns:xsi="
 "http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee" 
 "http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd" version="1.0">
 <session name="CallingBean">     
  <ejb-ref name="ejb/FacadeRemoteRef" 
   binding-name="cell/nodes/S35NLA1/servers/S35serverA1/ejb/session/FacadeBean"/>   
 </session> 
</ejb-bnd-jar>  
Schließlich löst diese Bindungsdatei die EJB-Referenz mit dem ejb-ref-Namen ejb/FacadeRemoteRef so auf, dass sie auf den klassischen globalen JNDI-Namen cell/nodes/S35NLA1/servers/S35serverA1/ejb/session/FacadeBean verweist. Dieser klassische globale JNDI-Name stellt eine Schnittstelle dar, die unter "ejb/session/FacadeBean" im Serverstammkontext des Servers "S35serverA1" auf dem Knoten "S35NLA1" in der WebSphere Application Server-Zelle der aufrufenden Bean gebunden wird. Wenn Sie auf eine Position in einer anderen WebSphere Application Server-Zelle zeigen möchten, können Sie anstelle des Standard-JNDI-Namens einen Namen im CORBAName-Stil verwenden.

Anweisungen zum Ändern der Datei ibm-ejb-jar-bnd.xml finden Sie im Artikel zur Aktualisierung von Anwendungsdateien.

Beziehungen zwischen Injektionen und Referenzen

Zwischen Injektionsanweisungen und Referenzdeklarationen besteht eine Eins-zu-eins-Entsprechung - jede Injektion definiert implizit eine Referenz eines bestimmten Typs und umgekehrt kann jede Referenz optional auch eine Injektion definieren. Sie können sich eine Injektionsannotation als den Mechanismus vorstellen, mit dem Referenzen anstatt über den XML-Implementierungsdeskriptor durch Annotationen definiert werden.

Standardmäßig definiert eine Injektion eine Referenz mit einem Namen, der gebildet wird aus dem mit dem Paket qualifizierten Klassennamen der Komponente, die die Injektion ausführt, einem Schrägstrich (/) und dem Namen der Variablen oder Eigenschaft in die die Injektion ausgeführt wird. Beispiel: Eine Injektion, die in der Klasse "com.ejbs.AccountService" in eine Variable oder Eigenschaft mit dem Namen "depositService" ausgeführt wird, hat eine Referenz mit dem Namen "java:comp/env/com.ejbs.AccountService/depositService" zur Folge. Allerdings wird dieser Standardname durch Angabe des optionalen Parameters "name" in der Injektionsanweisung überschrieben, sodass die Referenz entsprechend dem Wert des Parameters "name" benannt wird.

Wenn Sie diese Regel kennen, können Sie leicht verstehen, wie eine Bindungsdatei nicht nur zum Auflösen von Zielen für Referenzen eingesetzt werden kann, die in einem XML-Extensible Markup Language deklariert wurden, sondern auch zum Auflösen von Zielen für Referenzen, die implizit durch eine Annotationsinjektionsanweisung deklariert wurden. Es wird einfach der Wert des Parameters "name" in der Injektionsannotation verwendet oder der Standardreferenzname aus dem Klassennamen und Variablen-/Eigenschaftsnamen, falls kein "name"-Parameter angegeben wurde, so als wäre dies der Name der in einem XML-Implementierungsdeskriptor deklarierten Referenz.

Standardauflösung von EJB-Referenzen und EJB-Injektionen: Die Features EJBLink und AutoLink

Die Features EJBLink und AutoLink sind zwei verschiedene Verfahren, die Referenzen auf EJB-Komponenten auflösen, die in derselben Anwendung und in demselben Anwendungsserverprozess enthalten sind wie die Komponente mit der Referenz. Sowohl EJBLink als auch AutoLink machen es unnötig, die EJB-Referenz explizit mit Bindungsinformationen aufzulösen. Das Feature EJBLink wird durch die EJB-Spezifikation definiert, wohingegen das Feature AutoLink eine Erweiterung von WebSphere Application Server ist.

Die Features EJBLink und AutoLink verwenden verschiedene Suchkritierien zur Lokalisierung der Bean-Zielkomponente. EJBLink sucht mit dem explizit angegebenen Bean-Namen nach der Bean-Zielkomponente. AutoLink sucht mit der von der Bean implementierten Schnittstelle nach der Ziel-Bean-Komponente. Wenn keine expliziten Bindungen bereitgestellt werden, jedoch ein Bean-Name angegeben wird, wird das Feature EJBLink verwendet. Wenn keine expliziten Bindungen und kein Bean-Name bereitgestellt werden, wird das Feature AutoLink verwendet. Die Features EJBLink und AutoLink werden niemals zusammen als Bestandteil desselben Suchprozesses verwendet.

Mit Ausnahme der Suchkriterien sind die Features EJBLink und AutoLink ähnlich strukturiert. Beide Features suchen zuerst ein bestimmtes Modul und suchen dann, falls erforderlich, erneut die anderen Module in derselben Anwendung und in demselben Anwendungsserverprozess. Beide Features setzen voraus, dass die Suchkriterien in genau eine Bean-Komponente aufgelöst werden, und gehen davon aus, dass eine Fehlerbedingung vorliegt, wenn die Suchkriterien in mehrere Bean-Komponenten aufgelöst werden. Es liegt eine Fehlerbedingung vor, weil der Anwendungsserver nicht weiß, welche der Bean-Komponenten verwendet werden muss. In diesem Fall wird die Ausnahmebedingung com.ibm.websphere.ejbcontainer.AmbiguousEJBReferenceException abgesetzt. Diese Ausnahmebedingung wird zur Ausführungszeit ausgelöst, wenn die Komponente mit der Referenz versucht, die Ziel-Bean-Komponente zu lokalisieren.

Das Feature EJBLink unterstützt drei verschiedene Formate.
  • Bei Format 1 wird nur der Name der Bean-Komponente angegeben. Beispiel: MyBean.
  • Bei Format 2 wird der Name der physischen Moduldatei einschließlich Erweiterung, die die Ziel-Bean-Komponente enthält, angegeben, gefolgt vom Zeichen "#" und vom Namen der Bean-Komponente. Beispiel: myModule.jar#MyBean
  • Bei Format 3 wird der logische Name des Moduls angegeben, das die Ziel-Bean-Komponente enthält, gefolgt vom Zeichen "/" und dem Namen der Bean-Komponente. Beispiel: MyModule/MyBean.

Bei Bedarf kann der logische Name des Moduls für ein EJB-JAR-Modul mit dem Element "module-name" im EJB-Implementierungsdeskriptor angegeben werden. Die Angabe für ein WAR-Modul mit EJB-Inhalt erfolgt mit dem Element "module-name" im Web-Implementierungsdeskriptor. Bei einem WAR-Modul mit EJB-Inhalt wird das im EJB-Implementierungsdeskriptor angegebene Element "module-name" ignoriert, stattdessen wird das im Web-Implementierungsdeskriptor angegebene Element "module-name" verarbeitet. Wenn im Implementierungsdeskriptor kein Wert für "module-name" angegeben ist, wird dem Modul standardmäßig ein logischer Name zugeordnet. Der logische Standardmodulname ist der Basisname der Moduldatei ohne Erweiterung. Beispiel: Der Name des logischen Moduls für die Moduldatei "MyModule.jar" lautet standardmäßig "MyModule".

Die Angabe des Namens der physischen Moduldatei wird auch unterstützt, wenn das Modul einen logischen Namen hat. Die Angabe des logischen Namens des Moduls wird auch unterstützt, wenn kein logischer Modulname im Implementierungsdeskriptor konfiguriert ist. In diesem Fall wird der Basisname des Moduls als logischer Name des Moduls verwendet.

Der integrierbare EJB-Container unterstützt alle EJBLink-Formate. Zur Unterstützung des Dateiformats für physische Module lässt der EJB-Container nicht zu, dass mehrere Module mit demselben Basisnamen gestartet werden.

AutoLink ist ein wertsteigerndes Feature von WebSphere Application Server, das die explizite Auflösung von EJB-Referenzzielen in bestimmten Verwendungsszenarien überflüssig macht. In WebSphere Application Server Version 8 wird AutoLink innerhalb der Grenzen jedes WebSphere Application Server-Prozesses implementiert. Der AutoLink-Algorithmus funktioniert wie folgt.

Wenn der EJB-Container eine EJB-Referenz in einem bestimmten EJB-Modul findet, prüft er zunächst, ob Sie das Ziel der Referenz durch Aufnahme eines Eintrags in die Bindungsdatei des Moduls explizit aufgelöst haben. Falls der Container keine explizite Auflösung des Ziels in der Bindungsdatei findet, sucht er im Modul mit der Referenz nach einer Enterprise-Bean, die den Schnittstellentyp oder die Sicht ohne Schnittstellen implementiert, den bzw. die Sie in der Referenz definiert haben.

Falls er genau eine Enterprise-Bean im Modul findet, die die Schnittstelle oder die Sicht ohne Schnittstellen implementiert, verwendet er diese Enterprise-Bean als Ziel für die EJB-Referenz. Falls der Container keine Enterprise-Bean dieses Typs im Modul findet, erweitert er den Suchbereich auf die Anwendung, zu der das Modul gehört, und durchsucht andere Module in dieser Anwendung, die demselben Anwendungsserver zugeordnet sind wie das Modul mit der Referenz. Auch hier gilt, dass wenn der Container in den anderen Modulen der Anwendung, die demselben Server zugeordnet sind wie das Modul mit der Referenz, genau eine Enterprise-Bean findet, die die Zielschnittstelle oder die Sicht ohne Schnittstellen implementiert, er diese Enterprise-Bean als Referenzziel verwendet.

Der Geltungsbereich von AutoLink ist auf die Anwendung begrenzt, in der die EJB-Referenz erscheint, und auf den Anwendungsserver, dem das Modul mit der Referenz zugeordnet ist. Referenzen auf Enterprise-Beans in einer anderen Anwendung, auf Enterprise-Beans in einem Modul, das einem anderen Anwendungsserver zugeordnet ist, oder auf Enterprise-Beans, die in einem Modul enthalten sind, das einem Cluster von WebSphere Application Server zugeordnet ist, müssen über Referenzzielbindungen in der Datei ibm-ejb-jar-bnd.xml des EJB-Moduls oder in der Datei ibm-web-bnd.xmi des Webmoduls explizit aufgelöst werden.

Es ist wichtig darauf hinzuweisen, dass die Funktion AutoLink nur für EJB-Referenzen unterstützt wird, nicht für andere Arten von Referenzen, obwohl sie im EJB-Container, im Web-Container und im Anwendungsclientcontainer unterstützt wird. Da der Geltungsbereich der Funktion AutoLink auf den Server begrenzt ist, dem das Modul mit der Referenz zugeordnet ist, oder, im Fall des Java EE-Client-Containers, auf den Server, für den der Client-Container als JNDI-Bootstrap-Server konfiguriert ist, ist diese Funktion hauptsächlich in Entwicklungsumgebungen und Verwendungsszenarios mit Einzelservern nützlich. Selbst innerhalb dieser aktuellen Begrenzungen kann die Funktion eine wertvolle Hilfe beim Beschleunigen des Entwicklungsprozesses sein, indem sie die explizite Auflösung von EJB-Referenzen unnötig macht.

Auflösung von EJB-Referenzen und Ressourcenreferenzen und Injektionen: Das Feature Lookup

Das Feature Lookup wird durch die Spezifikation EJB 3.1 als Verfahren definiert, das Referenzen auf EJBs oder Ressourcen über einen explizitem JNDI-Namen auflöst. Sie können das Attribut "lookup" in der Annotation "javax.ejb.EJB" oder "javax.annotation.Resource" angeben. Das entsprechende XML-Attribut in der Datei ejb-jar.xml ist <lookup-name> in einem der folgenden Elemente: <ejb-ref>, <ejb-local-ref>, <env-entry>, <resource-ref>, <resource-env-ref> oder <message-destination-ref>. "lookup" oder <lookup-name> ist ein JNDI-Name, der sich auf den Namenskontext von "java:comp/env" bezieht.

In einer EJB-Referenz darf "lookup" oder <lookup-name> nicht mit "beanName" oder <ejb-link> angegeben werden. Die Administrationskonsole zeigt "lookup-name" und "ejb-link" als schreibgeschützt an. Wenn im Anwendungsinstallationsschritt "EJB-Referenzen Beans zuordnen" ein JNDI-Name angegeben wird, wird der Wert für "lookup-name" oder "ejb-link" überschrieben.

In Anwendungen definierte Umgebungseinträge überschreiben

Anwendungen können Umgebungseinträge definieren mit Werten, die für den Komponententest, aber nicht für den Integrationstest oder den Produktionseinsatz geeignet sind. Wenn Sie den Wert eines Umgebungseintrags überschreiben möchten, können Sie das folgende Element zur entsprechenden Bindungsdatei hinzufügen:
<env-entry name="Name" value="Wert"/>
Name steht für den env-entry-Namen gemäß Definition in der Anwendung und Wert ist der Wert, der dem env-entry im Zeichenfolgeformat zugeordnet ist. Die Zeichenfolge für Wert wird gemäß Typ des Umgebungseintrags so geparst, als wäre der Wert mit env-entry-value im Implementierungsdeskriptor angegeben worden. Beispiel:
<env-entry name="java:module/env/taxYear" value="2010"/>
ordnet den env-entry "java:module/env/taxYear" dem Wert "2010" zu.
Alternativ dazu können Sie einen env-entry als Referenz auf ein anderes Objekt konfigurieren, das über JNDI aufgerufen werden kann. Das Objekt, das vom JNDI-Lookup zurückgegeben wird, wird als env-entry-Wert verwendet. Das Element für diese Option hat das folgende Format:
<env-entry name="Name" binding-name="Lookup-Name"/>
Name steht für den env-entry-Namen gemäß Definition in der Anwendung und Lookup-Name ist ein JNDI-Name, der aufgelöst wird, wenn er auf eine Suchfunktion (Lookup) für den Standardausgangskontext angewendet wird. Beispiel:
<env-entry name="java:module/env/taxYear" binding-name="cell/persistent/MyApp/MyModule/taxYear"/>
ordnet den env-entry "java:module/env/taxYear" einem Wert zu, der von einer für "cell/persistent/MyApp/MyModule/taxYear" ausgeführten Suchoperation (Lookup) des Standardausgangskontextes zurückgegeben wird. Für die Erstellung des JNDI-Objekts sind Sie selbst verantwortlich. Die Klasse des gebundenen Objekts muss in Bezug auf den Objekttyp des zugeordneten env-entry zuordnungsfähig sein.

Umgebungseinträge können auf der Anwendungsebene und in EJB-, Web- und Clientmodulen definiert werden. Diese Ebenen entsprechen den Bindungsdateien application-bnd.xml, ejb-jar-bnd.xml, web-app-bnd.xml und application-client-bnd.xml.

Datenquellendefinitionen überschreiben

Mit Java EE 6 können Sie Anwendungen entwickeln, die Datenquellen mit der Annotation @DataSourceDefinition oder dem Implementierungsdeskriptoreintrag <data-source> definieren.

Ihre Anwendungen müssen Ressourcenreferenzen suchen, anstatt Datenquellendefinitionen direkt zu suchen. Wenn Sie eine vorhandene Anwendung installieren möchten, die direkte Lookups für eine Datenquellendefinitionen enthält, und Sie eine andere Datenquellendefinition verwenden möchten, können Sie die Datenquellendefinition mit einer Bindung überschreiben, die in eine verwaltete, von Ihnen erstellte Ressource aufgelöst wird. Erstellen Sie die Bindung, indem Sie das folgende Element zu Ihrer Bindungsdatei hinzufügen:
<data-source name="Name" binding-name="Lookup-Name"/> 
Name steht für den env-entry-Namen gemäß Definition in der Anwendung und Lookup-Name ist ein JNDI-Name, der aufgelöst wird, wenn er auf eine Suchfunktion (Lookup) für den Standardausgangskontext angewendet wird. Beispiel:
<data-source name="java:module/env/myDS" binding-name="jdbc/DB2DS"/>
führt Lookups von "java:module/env/myDS" aus und bewirkt die Auflösung in die mit dem Namen "jdbc/DB2DS" gebundene Datenquelle relativ zum Standardausgangskontext. Die Datenquelle, die unter "jdbc/DB2DS" gebunden ist, kann z. B. über die Administrationskonsole gebunden werden.

Datenquellen können auf der Anwendungsebene und in EJB-, Web- und Clientmodulen definiert werden. Diese Ebenen entsprechen den Bindungsdateien application-bnd.xml, ejb-jar-bnd.xml, web-app-bnd.xml und application-client-bnd.xml.

Namenskonventionen in Clusterumgebungen und Umgebungen mit mehreren Servern

Die klassischen globalen JNDI-Namenskonventionen in den vorherigen Abschnitten gelten in Umgebungen ohne Cluster und für den Fall, dass das gesuchte Ziel innerhalb desselben Clusters liegt wie die Quelle der Suche. Beim Ausführen einer Suchoperation von außerhalb eines Clusters nach einer Bindung, die sich innerhalb eines bestimmten Clusters befindet, muss die Suchzeichenfolge so qualifiziert werden, dass sie den Namen des Clusters angibt, in dem sich das Ziel befindet. Dabei muss folgende Konvention befolgt werden:
cell/clusters/<Clustername>/<Position_der_Namensbindung>   
Beispiel: Folgende Bindungsposition der EJB-Schnittstelle ist im Stammkontext des Anwendungsservers gegeben:
ejb/Department549/AccountProcessors/CheckingAccountReconciler 
Wenn die EJB, die diese Schnittstelle implementiert, einem Anwendungsserver zugeordnet wird, der ein Member eines Clusters mit dem Namen Cluster47 ist, sieht die außerhalb des Clusters eingegebene Suchzeichenfolge wie folgt aus:
cell/clusters/Cluster47/ejb/Department549/AccountProcessors/CheckingAccountReconciler
Wenn eine Suche über mehrere Anwendungsserverprozesse ausgeführt wird, muss die Suchzeichenfolge so qualifiziert werden, dass sie den Namen des Knotens und Servers angibt, in dem sich das Ziel befindet. Dabei muss folgende Konvention befolgt werden:
cell/nodes/<node-name>/servers/<Servername>/<Position_der_Namensbindung> 
Auch in diesem Beispiel ist eine Bindungsposition der EJB-Schnittstelle im Stammkontext des Anwendungsservers gegeben:
ejb/Department549/AccountProcessors/CheckingAccountReconciler 
Wenn die Enterprise-Bean, die diese Schnittstelle implementiert, einem Anwendungsserver mit dem Namen Server47A1 zugeordnet wird, der sich in einem Knoten dem Namen S47NLA1 befindet, sieht die eingegebene serverübergreifende Suchzeichenfolge wie folgt aus:
cell/nodes/S47NLA1/servers/Server47A1/ejb/Department549/AccountProcessors/CheckingAccountReconciler 

Benutzerdefinierte Einstellungen für die EJB-Erweiterung

Für Fälle, in denen Sie Werte für EJB-Erweiterungseinstellungen für WebSphere Application Server angeben möchten, können Sie eine EJB-Modulerweiterungsdatei verwenden, um diese Einstellungen bestimmten EJB-Typen in dem betreffenden Modul zuzuordnen. Die Angaben für die Erweiterungseinstellungen für EJB-3.x-Module können festgelegt werden, indem eine von zwei Dateien oder beide Dateien in das Verzeichnis "META-INF" der EJB-JAR-Datei aufgenommen werden, je nachdem, welcher Erweiterungstyp definiert wird. Die Namen der zwei Dateien sind ibm-ejb-jar-ext.xml und ibm-ejb-jar-ext-pme.xml.

Anmerkung: Das Suffix dieser Dateien lautet "XML" und nicht "XMI" wie in früheren Versionen von WebSphere Application Server.
Die Dateien ibm-ejb-jar-ext.xml und ibm-ejb-jar-ext-pme.xml werden für EJB-3.x-Module verwendet, die in WebSphere Application Server ausgeführt werden, während die Dateien ibm-ejb-jar-ext.xmi und ibm-ejb-jar-ext-pme.xmi für Module vor 3.0 EJB verwendet werden. WebSphere Application Server Version 8.0 verwendet ein neues XML-basiertes Erweiterungsdateiformat anstelle des früheren .xmi-Dateiformats. Dies hat folgende Gründe:
  1. Bindungen und Erweiterungen, die im XMI-Dateiformat deklariert werden, benötigen eine entsprechende Implementierungsdeskriptordatei mit dem Namen ejb-jar.xml, in der explizit auf eindeutige ID-Nummern verwiesen wird, die den Elementen in dieser Datei zugeordnet sind. Dieses System funktioniert für Module von EJB 3.0 oder höher nicht mehr, da in diesen Module der Implementierungsdeskriptor "ejb-jar.xml" keine Voraussetzung mehr ist.
  2. Das XMI-Dateiformat war so gestaltet, dass es nur von WebSphere-Entwicklungstools und -Systemmanagementfunktionen editiert werden konnte. Es war Teil der internen Implementierung von WebSphere, und die Struktur der Datei wurde nie extern dokumentiert. Daher war es für Entwickler unmöglich, auf vom Produkt unterstützte Art und Weise Bindungsdateien manuell zu erstellen bzw. zu editieren oder diese als Teil eines von WebSphere unabhängigen Erstellungsprozesses mit Unterstützung zu erstellen.
  3. Anstatt codierte ID-Nummern in ejb-jar.xml zu referenzieren, verweist das XML-basierte Erweiterungsdateiformat auf die EJB-Komponenten über deren EJB-Namen. Jeder EJB-Komponente in einem Modul wird ein eindeutiger EJB-Name zugesichert, entweder durch Standardzuordnung oder durch explizite Zuordnung durch den Entwickler, sodass Zielbindungen und Erweiterungen eindeutig angegeben werden.
  4. Die neuen Bindungs- und Erweiterungsdateiformate sind XML-basiert und es werden xsd-Dateien (XML Schema Definition) bereitgestellt, um ihre Struktur extern zu dokumentieren. Diese .xsd-Dateien können von vielen gebräuchlichen XML-Dateieditoren zur Unterstützung bei der Syntaxprüfung und für Funktionen zur Codefertigstellung verwendet werden. Folglich sind Entwickler jetzt in der Lage, die Bindungs- und Erweiterungsdateien unabhängig von der Infrastruktur von WebSphere Application Server zu erzeugen und zu editieren, indem Sie einen generischen Editor oder ein Scripterstellungssystem ihrer Wahl verwenden.

In der Datei META-INF/ibm-ejb-jar-ext.xml definierte Erweiterungen

Die folgende Tabelle listet die Erweiterungselemente und Attribute auf, die in die Datei META-INF/ibm-ejb-jar-ext.xml aufgenommen werden müssen. Im nächsten Abschnitt werden die Elemente und Attribute aufgelistet, die in einer separaten Datei, META-INF/ibm-ejb-jar-ext-pme.xml, enthalten sind.
Tabelle 4. Elemente und Attribute der Datei META-INF/ibm-ejb-jar-ext.xml . Elemente und Attribute der Datei META-INF/ibm-ejb-jar-ext.xml
Element oder Attribut Beschreibung Beispiel Verwendungshinweise
<session> Deklariert eine Gruppe von Erweiterungseinstellungen für eine Session-Bean.
<session name="AccountServiceBean"/>
Erfordert die Angabe des Attributs name. Damit es wirksam wird, muss außerdem mindestens ein Unterelement der Definition der Erweiterungseinstellung aufgenommen werden.
<message-driven> Deklariert eine Gruppe von Erweiterungseinstellungen für eine nachrichtengesteuerte Bean (Message-driven Bean).
<message-driven name="EventProcessorBean"/>
Erfordert die Angabe des Attributs name. Damit es wirksam wird, muss außerdem mindestens ein Unterelement der Definition der Erweiterungseinstellung aufgenommen werden.
Tabelle 5. Elemente und Attribute der Datei META-INF/ibm-ejb-jar-ext.xml . Elemente und Attribute in der Datei "META-INF/ibm-ejb-jar-ext.xml"
Element oder Attribut Beschreibung Beispiel Verwendungshinweise
<time-out> Ein Unterelement des Elements "<session>", das optional zur Deklaration der Anzahl Sekunden zwischen Methodenaufrufen verwendet wird, nach deren Ablauf eine Stateful-Session-Bean nicht mehr verfügbar ist.
<session
 name="ShoppingCartBean">
 <time-out value="600"/>
</session>
Erfordert die Angabe des Attributs value, bei dem es sich um eine positive ganze Zahl handelt.
Anmerkung: Gilt nur für Stateful-Session-Beans; darf für Stateless-Beans nicht verwendet werden.

Standardwert des Attributs: 300 (5 Minuten)

<bean-cache> Ein Unterelement des Elements "<session>", mit dem die Bean-Aktivierungs-/-Passivierungseinstellungen für Stateful-Session-Beans deklariert werden.
<session
 name="ShoppingCartBean">
 <bean-cache
  activation-policy="TRANSACTION"/>
</session>
Damit es wirksam wird, muss außerdem das Attribut "activation-policy" aufgenommen werden.
activation-policy Ein Attribut des Elements "<bean-cache>", das die Bedingungen deklariert, unter denen die Bean-Instanz aktiviert und passiviert wird. Gültig für Stateful-Session-Bean. Zulässige Werte und ihre Bedeutungen:
  • TRANSACTION: Dieser Wert legt fest, dass die Bean am Anfang einer Transaktion aktiviert und am Ende einer Transaktion passiviert (und aus dem Cache der aktiven EJB-Instanz entfernt) wird.
  • ONCE: Dieser Wert legt fest, dass die Bean aktiviert wird, wenn sie im Serverprozess zum ersten Mal aufgerufen wird, und dass sie nach Entscheidung des Containers inaktiviert (und aus dem Cache der aktiven EJB-Instanz entfernt) wird, beispielsweise, wenn der Cache voll ist.
  • ACTIVITY_SESSION: Zeigt an, dass die Bean wie folgt Aktivierungen und Passivierungen ausführt:
    1. an einer ActivitySession-Grenze, falls der ActivitySession-Kontext bei der Aktivierung vorhanden ist
    2. an einer Transaktionsgrenze, falls ein Transaktionskontext (aber kein ActivitySession-Kontext bei der Aktivierung vorhanden ist)
    3. an einer Aufrufgrenze
<session
 name="ShoppingCartBean">
 <bean-cache
  activation-policy="ONCE"/>
</session>
Standardwert des Attributs: ONCE für Stateful-Session-Beans.
Tabelle 6. Elemente und Attribute der Datei META-INF/ibm-ejb-jar-ext.xml . Elemente und Attribute in der Datei "META-INF/ibm-ejb-jar-ext.xml"
Element oder Attribut Beschreibung Beispiel Verwendungshinweise
<global-transaction> Ein Unterelement der Elemente "<session>" und "<message-driven>", mit dem das Transaktionszeitlimit (in Sekunden) deklariert werden kann, das in Transaktionen verwendet werden soll, die von diesem speziellen EJB-Typ gestartet wurden. (Hiermit wird die Servereinstellung für das globale Transaktionszeitlimit überschrieben.) Außerdem kann dieses Unterelement deklarieren, ob dieser EJB-Typ den globalen Transaktionskontext, der über WSAT (Web Service Atomic Transactions) empfangen wurde, in der heterogenen Web-Service-Umgebung weitergeben soll.
<session
 name="AccountServiceBean"
 <global-transaction
  <global-transaction
 transaction-time-out="180"
  send-wsat-context="FALSE"/>
</session>
Mindestens eines der Attribute transaction-time-out oder "send-wsat-context" muss angegeben werden.

Standardwert des Attributs: Die Einstellung des Servertranssaktionszeitlimits für transaction-time-out; FALSE für "send-wsat-context"

<local-transaction> Ein Unterelement der Elemente "<session>" und "<message-driven>", das zur Deklaration der Einstellungen für lokale Transaktionen verwendet werden kann. Zulässige Attribute sind "boundary", "resolver" und "unresolved-action". Diese Attribute konfigurieren für die Komponente das Verhalten der LTC-Umgebung des Containers (Local Transaction Containment, lokaler Transaktionseinschluss), die der Container immer dann aufbaut, wenn keine globale Transaktion vorhanden ist. Die Attribute haben folgende Bedeutung:

Boundary

Diese Einstellung gibt die Einschlussgrenzen an, innerhalb derer alle enthaltenen lokalen Transaktionen des Ressourcenmanagers (Resource Manager Local Transactions) ausgeführt werden müssen. Gültige Werte:
  • BEAN_METHOD: Dies ist der Standardwert. Wenn Sie diese Option auswählen, müssen RMLTs innerhalb der Bean-Methode aufgelöst werden, in der sie gestartet wurden.
  • ACTIVITY_SESSION: RMLTs müssen im Geltungsbereich der "ActivitySession", in der sie gestartet wurden, bzw. bei Fehlen eines "ActivitySession"-Kontextes in der Bean-Methode aufgelöst werden, in der sie gestartet wurden.

Resolver

Diese Einstellung gibt die Komponente an, die für das Einleiten und Beenden von RMLTs zuständig ist. Gültige Werte:
  • APPLICATION: Dies ist der Standardwert. Die Anwendung ist für das Starten und Beenden der RMLTs innerhalb der LTC-Grenzen (Local Transaction Containment) zuständig. Alle RMLTs, die am Ende der LTC-Grenzen nicht beendet sind, werden vom Container entsprechend dem Wert des Aktionsattributs "Nicht aufgelöst" bereinigt.
  • CONTAINER_AT_BOUNDARY: Der Container ist für das Starten und Beenden der RMLTs innerhalb der LTC-Grenzen zuständig. Der Container startet eine RMLT bei der erstmaligen Verwendung einer Verbindung im LTC-Geltungsbereich und beendet sie automatisch am Ende des LTC-Geltungsbereichs. Wenn die LTC-Grenze auf ActivitySession gesetzt ist, werden die RMLTs als ActivitySession-Ressourcen registriert und von der ActivitySession ausgeführt. Wenn die LTC-Grenze auf BeanMethod gesetzt ist, werden die RMLTs am Ende der Methode vom Container festgeschrieben.

Unresolved Action

Diese Einstellung gibt die Richtung an, die der Container für die RMLTs vorschreibt, wenn diese am Ende der LTC-Grenze nicht aufgelöst sind und "Resolver" auf "Application" gesetzt ist. Gültige Werte:
  • ROLLBACK: Dies ist der Standardwert. Am Ende der LTC-Grenze weist der Container eine ROLLBACK-Operation für alle nicht aufgelösten RMLTs an.
  • COMMIT: Am Ende der LTC-Grenze weist der Container eine COMMIT-Operation für alle nicht aufgelösten RMLTs an. Der Container weist die COMMIT-Operation für die RMLTs nur an, wenn keine nicht behandelte Ausnahme vorhanden ist. Wird die Anwendungsmethode, die in einem lokalen Transaktionskontext ausgeführt wird, mit einer Ausnahme beendet, werden alle nicht aufgelösten RMLTs vom Container rückgängig gemacht. Dasselbe Verhalten gilt für globale Transaktionen.
<session
 name>="AccountServiceBean">
 <local-transaction boundary="BEAN_METHOD" 
  resolver="APPLICATION" 
  unresolved-action="ROLLBACK"/>
</session>
Mindestens eines der Attribute "boundary", "resolver" oder "unresolved-action" muss angegeben werden.
Standardwert des Attributs:
boundary="BEAN_METHOD"; 
resolver="APPLICATION"; 
unresolved-action=
"ROLLBACK"
Tabelle 7. Elemente und Attribute der Datei META-INF/ibm-ejb-jar-ext.xml . Elemente und Attribute der Datei META-INF/ibm-ejb-jar-ext.xml
Element oder Attribut Beschreibung Beispiel Verwendungshinweise
<method> Ein Unterelement der Elemente "<method-session-attribute>" und "<run-as-mode>", das zur Angabe des Methodennamens, der Methodensignatur oder des Methodentyps verwendet wird, für den bzw. die eine bestimmte Einstellung gelten soll. Zulässige Attribute sind "type", "name" und "params". Jedes Attribut wird wie folgt beschrieben:

type

  • UNSPECIFIED: Die Einstellung gilt für alle Methoden, die mit den Attributen "name" und "params" übereinstimmen, unabhängig vom Schnittstellentyp.
  • REMOTE: Die Einstellung gilt nur für ferne Geschäftsschnittstellen- und ferne Komponentenschnittstellenmethoden, die mit den Attributen "name" und "params" übereinstimmen.
  • LOCAL: Die Einstellung gilt für lokale Geschäftsschnittstellen, lokale Komponentenschnittstellenmethoden und Sichten ohne Schnittstellen mit entsprechendem Attribut "name" und/oder "params".
  • HOME: Die Einstellung gilt nur für ferne Home-Schnittstellenmethoden, die mit den Attributen "name" und "params" übereinstimmen.
  • LOCAL_HOME: Die Einstellung gilt nur für lokale Home-Schnittstellenmethoden, die mit den Attributen "name" und "params" übereinstimmen.
  • SERVICE_ENDPOINT: Die Einstellung gilt nur für Methoden in der JAX-RPC-Serviceendpunktschnittstelle, die mit den Attributen "name" und "params" übereinstimmen.

name

Der Name der Methode, auf die die Einstellung angewendet wird, oder ein Stern (*), wenn die Einstellung auf alle Methoden angewendet werden soll, unabhängig von ihrem Namen.

params

Die Parametersignatur der Methode, auf die die Einstellung angewendet werden soll. Hiermit kann für den Fall, dass mehrere Methoden denselben Namen verwenden, eine bestimmte Methode eindeutig identifiziert werden. Die Parametersignatur ist eine durch Kommas getrennte Liste mit Java-Typen. Primitive Typen werden nur mit ihrem Namen angegeben. Nicht primitive Typen werden mit ihrem vollständig qualifizierten Klassen- oder Schnittstellennamen, einschließlich des Java-Pakets, angegeben, und Feldgruppen von Java-Typen werden durch den Typ des Feldgruppenelements, gefolgt von einem oder mehreren Paaren von eckigen Klammern (z. B. "int[][]"), angegeben.

<session
 /name="AccountServiceBean">
 <method-session-attribute
  type="REQUIRES_NEW">
 <method type="LOCAL" name="debitAccount" 
  params="java.lang.String[], int, 
     com.xyz.CustomerInfo"/>
 </method-session-attribute;>
</session>
 
<run-as-mode> Ein Unterelement der Elemente "<session>" und "<message-driven>", das zur Deklaration der Sicherheitsidentität verwendet werden kann, die eine bestimmte EJB-Methode beim Aufrufen einer anderen Methode verwendet. Die Identität kann so festgelegt werden, dass die Identität des Callers (mode = CALLER_IDENTITY), die Identität des EJB-Servers (mode = SYSTEM_IDENTITY) oder die Identität einer bestimmten Sicherheitsrolle (mode = SPECIFIED_IDENTITY) verwendet wird.
<session
 name="AccountServiceBean">
 <run-as-mode
   mode="SPECIFIED_IDENTITY">
 <specified-identity
   role="admin"/>
 <method type="UNSPECIFIED" 
   name="testRunAsRole"/>
 </run-as-mode>
</session>
Erfordert die Angabe des Attributs "mode" und des Unterelements <method>. Wenn als Modus ("mode") SPECIFIED_IDENTITY angegeben ist, ist auch das Unterelement "<specified-identity" erforderlich.
<start-at-app-start> Ein Unterelement der Elemente "<session>" und "<message-driven>", mit dem der EJB-Container darüber informiert werden kann, dass der angegebene EJB-Typ beim ersten Start der Anwendung initialisiert werden soll und nicht, wenn der EJB-Typ zum ersten Mal von der Anwendung verwendet wird.
<session
 name="AccountServiceBean">
 <start-at-app-startvalue="TRUE"/>
</session>
Erfordert die Angabe des Attributs "value".

Standardwert des Attributs: FALSE (EJB-Typ initialisieren, wenn er zum ersten Mal von der Anwendung verwendet wird) für Beans, die keine nachrichtengesteuerte Beans sind. Immer TRUE für nachrichtengesteuerte Beans.

<resource-ref> Ein Unterelement der Elemente "<session>" und "<message-driven>", das dazu verwendet werden kann, zusätzliche Einstellungen für eine Java EE-Ressourcenreferenz zu deklarieren, beispielsweise die Isolationsstufe, die in Transaktionen verwendet werden soll, die über eine von der Referenz referenzierte Verbindung gesteuert werden. Zu den gültigen Attributen gehört isolation-level. Die Attribute sind wie folgt definiert:
isolation-level
  • TRANSACTION_REPEATABLE_READ: Diese Isolationsstufe untersagt "dirty reads" oder nicht wiederholbare Leseoperationen, aber sie erlaubt Phantomleseoperationen.
  • TRANSACTION_READ_COMMITTED: Diese Isolationsstufe untersagt "dirty reads" und Phantomleseoperationen.
  • TRANSACTION_READ_UNCOMMITTED: Diese Isolationsstufe erlaubt das Lesen nicht festgeschriebener Änderungen (Daten, die von einer anderen, noch nicht abgeschlossenen Transaktion geändert wurden). Außerdem erlaubt sie "dirty reads", nicht wiederholbare Leseoperationen und Phantomleseoperationen.
  • TRANSACTION_SERIALIZABLE: Diese Isolationsstufe verhindert Leseoperationen der folgenden Typen:
    1. "Dirty Reads", d. h. Leseoperationen, bei denen eine Transaktion eine Datenbankzeile liest, die nicht festgeschriebene Änderungen aus einer zweiten Transaktion enthält.
    2. Nicht wiederholbare Leseoperationen, d. h. Leseoperationen, bei denen eine Transaktion eine Zeile liest, eine zweite Transaktion diese Zeile ändert und die erste Transaktion die Zeile erneut liest und einen anderen Wert erhält.
    3. Phantomleseoperationen, bei denen eine Transaktion alle Zeilen liest, die eine SQL-WHERE-Bedingung erfüllen, eine zweite Transaktion eine Zeile einfügt, die ebenfalls die WHERE-Bedingung erfüllt, und die erste Transaktion dieselbe WHERE-Bedingung anwendet und die von der zweiten Transaktion eingefügte Zeile erhält.
  • TRANSACTION_NONE: Diese Isolationsstufe zeigt an, dass dieser Ressourcentyp keine Transaktionen unterstützt.
<session
 name="AccountServiceBean">
 <resource-ref  name="jdbc/Default" 
  isolation-level="TRANSACTION_NONE">
</session>
Erfordert die Angabe des Attributs "name". Damit es wirksam wird, muss außerdem das Attribut "isolation-level" aufgenommen werden.

In der Datei "META-INF/ibm-ejb-jar-ext-pme.xml" definierte Erweiterungen

Die folgende Tabelle listet die Erweiterungselemente und Attribute auf, die in die Datei META-INF/ibm-ejb-jar-ext-pme.xml aufgenommen werden müssen.
Tabelle 8. In META-INF/ibm-ejb-jar-ext-pme.xml definierte Erweiterungen. In der Datei "META-INF/ibm-ejb-jar-ext-pme.xml" definierte Erweiterungen
Element oder Attribut Beschreibung Beispiel Verwendungshinweise
<internationalization> Ein Element, das zur Deklaration der vom EJB-Typ verwendeten Ländereinstellung verwendet wird (Ländereinstellung des Callers oder Ländereinstellung des Servers).
<internationalization>
  <application>
   <ejb name="S01"/>
   <ejb name="S02"/>
  </application>
  <run-as-caller>
   <method type="LOCAL" name="getFoo" params="int">
     <ejb name="C01"/>
   </method>
  </run-as-caller>
  <run-as-server>
   <method type="LOCAL" name="getBar" params="int">
    <ejb name="C02"/>
   </method>
  </run-as-server>
  <run-as-specified name="North American English">
   <locale lang="en" country="US" variant="foo"/>
   <locale lang="en" country="CA" variant="bar" /> 
   <time-zone name="GMT"/> 
   <method type="LOCAL" name="getFoo" params="int"> 
    <ejb name="C03"/>
   </method>
  </run-as-specified>
  <run-as-specified name="North American French"> 
   <locale lang="fr" country="US" variant="foo"/>
   <locale lang="fr" country="US" variant="bar" /> 
   <time-zone name="GMT"  /> 
   <method type="LOCAL" name="getBar" params="int"> 
   <ejb name="C04"/>
   </method>
  </run-as-specified>
</internationalization>
Informationen zu dieser Erweiterung finden Sie in den Beschreibungen der Containerattribut für die Internationalisierung für WebSphere Application Server.

Aufgrund der Komplexität dieser Funktion ist es hilfreich, ein für WebSphere Application Server entworfenes Tool wie Rational Application Developer (RAD) zu verwenden, um die gewünschten Zeilengruppen der Erweiterungsdatei zu erzeugen und die XML-Datei anschließend nach Bedarf zu ändern.

<activity-sessions> Ein Element, das optional die Art des Activity-Session-Managements deklariert, die in einer bestimmten Session-Bean (BEAN oder CONTAINER) verwendet werden soll, und für containergesteuerte Activity Sessions die Art des Activity-Session-Verhaltens, die der Container bereitstellen soll.
<activity-sessions>
 <container-activity-session 
  name="Foo" type="NOT_SUPPORTED">
  <methodtype="HOME" name="findByPrimaryKey" 
    params="int">
   <ejb name="C01"/>
  </method>
 </container-activity-session>
<./activity-sessions>
Informationen zu dieser Erweiterung finden Sie unter "Implementierungsattribute Implementierungsattribute für ActivitySession eines EJB-Moduls definieren".

Aufgrund der Komplexität dieser Funktion ist es hilfreich, ein für WebSphere Application Server entworfenes Tool wie Rational Application Developer zu verwenden.

<app-profiles> Ein Element, das optional Anwendungsprofileinstellungen für eine oder mehrere EJB-Dateien deklariert.
<app-profiles>
 <defined-access-intent-policy name="foo">
  <collection-scope type"SESSION"/>
  <optimistic-read/>
  <read-ahead-hint hint="foo.bar.baz"/>
 </defined-access-intent-policy>
 <run-as-task 
  name="TestEJB1.ejbs.C01LocalHome.createjava.lang.Integer" 
  type="RUN_AS_SPECIFIED_TASK">
  <task name=“/>
  <method type="LOCAL" name="getFoo" params="int">
   <ejb name="C01"/>
  </method>
 </run-as-task>
 <ejb-component-extension ejb="C01"> 
  <task name="SomeTask"/>
 </ejb-component-extension>
</app-profiles>
Aufgrund der Komplexität dieser Funktion ist es hilfreich, ein für WebSphere Application Server entworfenes Tool wie Rational Application Developer (RAD) zu verwenden, um die gewünschten Zeilengruppen der Erweiterungsdatei zu erzeugen und die XML-Datei anschließend nach Bedarf zu ändern.

Traditionelle (XMI-)Bindungen

Vorhandene Module und Anwendungen können weiterhin die im Produkt bereitgestellte traditionelle Bindungsunterstützung verwenden. Daher können die vorhandenen Tools und Assistenten verwendet werden, um Bindungs- und Erweiterungsinformationen für Anwendungen und Module anzugeben. Die Verwendung der traditionellen Unterstützung ist auf die EAR-Dateien und Module beschränkt, die XML-Implementierungsdeskriptoren für J2EE-Version 1.4 verwenden.

EJB-Module, die ein XML-Implementierungsdeskriptor-Schema der Version 3.x verwenden oder keine XML-Implementierungsdeskriptordatei enthalten, müssen entweder Standardbindungen und AutoLink oder benutzerdefinierte XML-Bindungsdateien verwenden.

CMP-Entity-Beans müssen immer in einem Modul mit einem XML-Implementierungsdeskriptorschema der Version 2.1 gepackt werden, damit die vorhandenen Tools verwendet werden können, um Zuordnungen, Bindungen und Erweiterungsunterstützung bereitzustellen.

Benutzerdefinierte XML-Bindungen

Die Standardbindungen für jede Schnittstelle und die AutoLink-Referenzauflösung für jede Referenz können überschrieben werden, indem Bindungen für das EJB-Modul durch Erstellen einer Datei mit dem Namen META-INF/ibm-ejb-jar-bnd.xml festgelegt werden.

Die Schemadateien, die das Format beschreiben, sind im Verzeichnis "<WAS_HOME>/properties/schemas" enthalten. Diese Form der Bindungsspezifikation kann nur für Module verwendet werden, die entweder keinen XML-Implementierungsdeskriptor oder einen EJB-3.x-Implementierungsdeskriptor enthalten.
Anmerkung: Es ist nicht erforderlich, alle Bindungen anzugeben. Jeder Bindungsname oder jede Referenz, die nicht definiert wird, verwendet die Standardbindungen und die AutoLink-Unterstützung.
Bindungen können für die folgenden Beans festgelegt werden:
  • Für Session-Beans mit dem Element "<session>".
  • Für nachrichtengesteuerte Beans mit dem Element "<message-driven>".
Für das Element "<session>" werden nur die folgenden Attribute und Unterelemente unterstützt:
  • Attribut "id"
  • Attribut "name"
  • Attribut "simple-binding-name"
  • Attribut "component-id"
  • Element "ejb-ref"
  • Element "resource-ref" und seine Attribute
  • Element "resource-env-ref" und seine Attribute
  • Element "message-destination-ref" und seine Attribute
  • Element "env-entry"
  • Element "data-source"
Für das Element "<message-driven>" werden nur die folgenden Attribute und Unterelemente unterstützt:
  • Attribut "id"
  • Attribut "name"
  • Attribut "jca-adapter"
  • Element "ejb-ref" und seine Attribute
  • Element "resource-ref" und seine Attribute
  • Element "resource-env-ref" und seine Attribute
  • Element "message-destination-ref" und seine Attribute
  • Element "env-entry"
  • Element "data-source"

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_bindingsejbfp
Dateiname:cejb_bindingsejbfp.html