Enterprise JavaBeans mit fernen Schnittstellen in Liberty verwenden
Sie können für den Fernzugriff auf EJB-Methoden (Enterprise JavaBeans) ferne Schnittstellen verwenden, wenn die EJB von einer anderen Java Virtual Machine (JVM) oder einer anderen Anwendung innerhalb derselben JVM gehostet wird. WebSphere® Application Server implementiert ferne EJB-Schnittstellen mithilfe von RMI-IIOP-Technologien. Sie können die Unterstützung für den EJB-Fernzugriff mit dem Feature ejbRemote-3.2 aktivieren.
Informationen zu diesem Vorgang
Wenn Sie einen Liberty-Server für die Ausführung einer Anwendung mit aktivierter Unterstützung für ferne EJBs konfigurieren möchten, müssen Sie das Feature ejbRemote-3.2 definieren.
Beachten Sie bei der Verwendung ferner EJB-Schnittstellen die folgenden Aspekte:
- Benennung
Namespace java: verwenden
Die EJB-Spezifikation setzt voraus, dass die fernen Schnittstellen an den Namespace java: gebunden werden, z. B.:java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface java:app/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface java:module/ExampleBean!com.ibm.example.ExampleRemoteInterface
EJB-Komponenten werden anders als in WebSphere Application Server Traditional nicht an den JNDI-Standardnamespace (Java Naming and Directory Interface) gebunden, daher dürfen @EJB-Lookups und Bindungen in Dateien des Typs ibm-*-bnd.xml diesen Namespace nicht verwenden. Diese Lookups müssen java:-Namen für EJB-Komponenten in demselben Server und corbaname:-URLs für EJB-Komponenten auf einem anderen Server verwenden.
- corbaname:-URLs verwendenSchnittstellen werden in ähnlichen Kontexten wie den Schnittstellen, die im Namespace java:global verwendet werden, auch an den ORB-CosNaming-Namensservice gebunden. Für den Zugriff auf diese Schnittstellen kann JNDI mit corbaname:-URLs verwendet werden, z. B.:
corbaname::test.ibm.com:2809#ejb/global/ExampleApp/ExampleModule/ExampleHomeBean!com.ibm.example.ExampleEJBHome corbaname:rir:#ejb/global/ExampleApp/ExampleModule/ExampleHomeBean!com.ibm.example.ExampleEJBHome
Im Server wird im rir:-Format der URL der lokale Namensservice verwendet. Im Client wird der ferne Standardnamensservice oder der konfigurierte ferne Namensservice verwendet.
- corbaname:-URLs mit Escapezeichen versehen
Entsprechend der OMG-Spezifikation (Object Management Group) für Namensservices müssen einige Zeichen in corbaname:-URLs mit einem Escapezeichen versehen werden. Liberty versucht festzustellen, ob eine vom java:global-Namespace abgeleitete corbaname:-URL mit Escapezeichen versehen werden muss, und setzt die Escapezeichen dann automatisch. Es ist nicht in jedem Fall möglich, Escapezeichen zu setzen. Wenn ein Name beispielsweise einen einzelnen Punkt (.) und keine ungültigen Zeichen enthält, ist ein automatisches Setzen von Escapezeichen nicht möglich. Damit ein Name auf eine bestimmte Weise interpretiert wird, müssen die Ecapezeichen in der URL wie in der OMG-Spezifikation für Namensservice beschrieben manuell gesetzt werden.
Angenommen, eine Enterprise-Bean hat den folgenden java:global-Namen:
Im einfachen Format der corbaname:-URL können Escapezeichen nicht automatisch gesetzt werden, weil es eine andere, aber gültige Position darstellt. Deshalb funktioniert die folgende URL nicht wie erwartet:java:global/TestApp/TestModule/TestBean!test.TestRemoteInterface
Stattdessen müssen in dieser URL die Escapezeichen wie folgt manuell gesetzt werden:corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test.TestRemoteInterface
corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test%5c.TestRemoteInterface
Die Syntax für corbaname:-URLs mit Escapezeichen ist ausführlich in der OMG-Spezifikation für Namensservices beschrieben.
- JNDI-Namen über das Programm verwendenAlle URLs und JNDI-Namen in diesen Beispielen können programmgesteuert über einen InitialContext gesucht werden. Wenn Sie einen java:-Namen suchen, kann das entsprechende Objekt direkt in den erwarteten Typ umgesetzt werden, z. B.:
Wenn Sie Objekte jedoch mit corbaname:-URLs abrufen, muss die RMI-Umsetzung, auch Narrowing genannt, verwendet werden, z. B.:Object found = new InitialContext().lookup("java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface"); ExampleRemoteInterface bean = (ExampleRemoteInterface) found;
Object found = new InitialContext().lookup("corbaname:rir:#ejb/global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface"); ExampleRemoteInterface bean = (ExampleRemoteInterface)PortableRemoteObject.narrow(found, ExampleRemoteInterface.class);
- Interoperabilität
- Alle Produkte, die das Protokoll IIOP unterstützen, können Enterprise-Beans aufrufen, die das EJB 2.x-Fernprogrammiermodell mit EJBHome und EJBObject verwenden, sofern es in ein EJB-JAR-Modul mit einem Implementierungsdeskriptor der Version 2.0 gepackt ist. Die Datei WLP-INSTALLATIONSVERZEICHNIS/clients/ejbRemotePortable.jar muss in den Klassenpfad des fernen Clients eingeschlossen werden. Diese Datei enthält die Systemwertklassen, die für die Kommunikation mit einem Liberty-Server erforderlich sind. Diese Datei ist nicht erforderlich, wenn Sie über Fernzugriff auf EJB-Komponenten über WebSphere Application Server Liberty oder WebSphere Application Server Traditional zugreifen. EJB-Komponenten, die das EJB 3-Fernprogrammiermodell von Liberty verwenden, können über Fernzugriff von WebSphere Application Server-Prozessen aufgerufen werden. Liberty stellt keinen Thin Client bereit, um EJB-Komponenten über einen eigenständigen Java-Prozess zu starten. Liberty stellt auch keine Workload-Management- und Failoverfunktionen für ferne EJB-Komponenten bereit. Dies gilt auch für das Starten von EJB-Komponenten, die von WebSphere Application Server Traditional gehostet werden.
- Stubklassen
- Ein Client muss Stubklassen enthalten, wenn Sie
eine von WebSphere Application Server gehostete ferne EJB starten.
Wenn der Client eine WebSphere Application
Server-Instanz ist, kann das Produkt die richtigen Stubklassen in einigen Fällen automatisch generieren:
- Wenn eine Clientanwendung eine ferne EJB startet, die sich in derselben Anwendung befindet, generiert Liberty automatisch Stubklassen.
- Wenn die Ziel-EJB in einer separaten Anwendung ausgeführt wird und das EJB 2.x-Fernprogrammiermodell mit EJBHome und EJBObject verwendet, muss der Client Stubklassen in den Klassenpfad aufnehmen. Wenn die EJB von WebSphere Application Server Traditional gehostet wird, können Sie die EJB-Client-JAR-Datei aus der Anwendung aus der EAR-Datei kopieren, nachdem sie vom Befehl ejbdeploy verarbeitet wurde. Wenn die EJB von WebSphere Application Server Liberty gehostet wird, müssen Sie das im Java SDK enthaltene Programm rmic verwenden, um die Stubklassen für die Ziel-EJB zu generieren. Anschließend müssen Sie die Stubklassen in den Client aufnehmen.
- Wenn die Ziel-EJB in einer separaten Anwendung ausgeführt wird und das EJB 3.x-Fernprogrammiermodell verwendet, generiert der Clientprozess von WebSphere Application Server Liberty oder WebSphere Application Server Traditional die Stubklassen automatisch. EJB-Komponenten, die das EJB 3-Fernprogrammiermodell von Liberty Profile verwenden, können nur über Fernzugriff von WebSphere Application Server- oder WebSphere Application Client-Prozessen aufgerufen werden.
- Transaktionsweitergabe
- Liberty bietet keine Unterstützung für die Weitergabe abgehender oder eingehender Transaktionen. Außderm setzt die EJB-Spezifikation voraus, dass ein Produkt, selbst wenn es die Weitergabe abgehender Transaktionen unterstützt, trotzdem einen Nulltransaktionskontext senden muss. Dieser Kontext muss von EJB-Komponenten, die die Transaktionsattribute Required (Standard), Mandatory und Supports verwenden, zurückgewiesen werden. Ein Client mit einer aktiven globalen Transaktion kann keine EJB mit Standardtransaktionsattributen starten, wenn sich der Client oder Server in Liberty befindet. Der Client kann die EJB starten, wenn die EJB auf die Verwendung des Transaktionsattributs RequiresNew oder NotSupported umgestellt wird. Die von der EJB ausgeführten transaktionsorientierten Arbeitsvorgänge werden nicht im Rahmen der Transaktionen des Clients festgeschrieben.
- Asynchrone Methoden
- Eine ferne EJB-Schnittstelle kann asynchrone Methoden
mit dem Rückgabewert Future verwenden.
Der Server gibt ein Future-Objekt an den Client zurück, das zum Abrufen des Werts verwendet wird.
Ferne asynchrone Methoden werden nicht empfohlen, weil die Akkumulation von
nicht eingeforderten Ergebnissen den Speicher ausschöpfen kann. Um dieses Problem zu entschärfen, verfallen die Serverergebnisse,
wenn sie der Client nicht innerhalb von 24 Stunden abruft bzw. wenn die maximale Anzahl nicht beanspruchter Ergebnisse 1000 übersteigt.
Diese Werte können in der Datei server.xml angepasst werden, z. B.:
<ejbContainer> <async maxUnclaimedRemoteResults="10"unclaimedRemoteResultTimeout="10m"/> </ejbContainer>