Übersicht über die Implementierung von EJB 3.0 und EJB 3.1
Machen Sie sich mit dem Implementierungsmodell von Enterprise JavaBeans (EJB) 3.0 und 3.1 einschließlich der JIT-Implementierung (Just-In-Time) vertraut.
Alle Java™ EE-Anwendungsserverprodukte (Java Enterprise Edition) verfügen über eine Art EJB-Implementierungsphase, in der Ihre Anwendung so angepasst wird, dass sie in Ihrer speziellen Anwendungsserverimplementierung ausgeführt wird. Dies wird normalerweise über ein anwendungsserverspezifisches Implementierungstool erreicht, das einen Code generiert, der als Brücke zwischen Ihrer EJB-Schnittstelle und Implementierungscode und der EJB-Containerimplementierung des Anwendungsservers dient. Die Implementierungstools einiger Anwendungsserverprodukte ändern die Bytecodes Ihrer Anwendungsklassen anstatt Code zu generieren, aber das Endergebnis ist ähnlich.
Application Server überbrückt die EJB-Schnittstelle mit seiner Implementierung, indem er Code generiert, der die EJB-Implementierungsklassen kapselt und sie damit mit dem EJB-Container von Application Server verbindet. Auf diese Weise kann der EJB-Container Ihre Enterprise-Beans ausführen und ihnen Services bereitstellen. Wenn in einer oder mehreren Enterprise-Beans ferne Schnittstellen definiert sind, generiert Application Server zusätzlichen Code für die Bereitstellung der fernen Funktion.
Weitere Informationen zum Packen Ihres EJB-Moduls finden Sie im Artikel mit der Übersicht über das Packen von Modulen der EJB Version 3.x.
Tool "EJBDeploy"
In der Vergangenheit wurde die EJB-Implementierung im Produkt Application Server vom Tool "EJBDeploy" durchgeführt, das mit WebSphere Application Server geliefert wird und im Paket mit den Entwicklungstools für WebSphere-Produkte enthalten ist.
Das Tool "EJBDeploy" untersucht die externen Schnittstellen für Ihre Enterprise-Beans, generiert den Wrapper-Code in Form von Dateien mit der Erweiterung ".java", kompiliert den Code anschließend mit dem Compiler "javac", um Dateien mit der Erweiterung ".class" zu erzeugen, die anschließend zusammen mit Ihrem Anwendungscode in das EJB-Modul gepackt werden. Das Tool "EJBDeploy" führt außerdem das Tool "rmic" für ferne EJB-Schnittstellen in der Anwendung aus und erzeugt dabei zusätzliche stub- und tie-Klassendateien, die mit dem RMI-IIOP ORB (Remote Method Invocation over Internet Inter-ORB Protocol (IIOP) Object Request Broker (ORB)) interagieren und dadurch eine Remote-Objekt-Unterstützung bereitstellen.
Gewöhnlich führen Sie das Tool "EJBDeploy" während der Installation der Anwendung in Application Server oder vor der Installation der Anwendung über das Befehlszeilentool oder über ein Entwicklungstool aus.
JIT-Implementierung
Die Unterstützung für EJB 3.0 in Application Server enthält ein neues Feature, die sogenannte JIT-Implementierung.
Mit der JIT-Implementierung generiert der EJB-Container dynamisch die Wrapper-, Stub- und Tie-Klassen im Speicher, wenn die Anwendung ausgeführt wird. Außerdem generieren der Web-Container und der Anwendungs-Client-Container dynamisch die Stubklasse, die für ferne EJB-Aufrufe erforderlich ist.
Dies bedeutet, dass Sie Module der EJB Version 3.0 oder 3.1, Webmodule, die Beans der EJB Version 3.0 oder 3.1 aufrufen, und Clientmodule, die Beans der EJB Version 3.0 oder 3.1 aufrufen, nicht über das Tool "EJBDeploy" verarbeiten müssen, bevor Sie sie in Application Server ausführen.
Tool "createEJBStubs"
In den meisten Fällen kann das JIT-Implementierungsfeature die RMI-IIOP-Stubklassen, die für den Aufruf ferner EJB-Schnittstellen benötigt werden, dynamisch generieren. Es gibt jedoch auch einige Fälle, in denen diese Stubklassen nicht dynamisch generiert werden. Für Clients der EJB Version 3.0 oder 3.1, die nicht in einem für EJB 3.x aktivierten Web-Container, EJB-Container oder Client-Container ausgeführt werden, müssen Sie die Stubklassen mit dem Tool "createEJBStubs" generieren und sicherstellen, dass die generierten Stubs im Klassenpfad der Clientumgebung verfügbar sind. Normalerweise würde dies durch Kopieren der generierten Stubs in die Position, in der die Geschäftsschnittstellenklasse des Clients enthalten ist, erfolgen.
- Reine Java SE-Clients (Java Standard Edition), in denen eine Java SE-JVM (Java Virtual Machine) die Clientumgebung ist.
- Container in Application-Server-Umgebungen vor Version 7, auf die Feature Pack for EJB 3.0 nicht angewendet wurde,
- Umgebungen, die keine Umgebungen mit WebSphere Application Server sind.
Interoperabilität
Es können unerwartete Ergebnisse generiert werden, wenn ein WebSphere-Zusatzprodukt oder ein anderes Produkt, das in einer Version von Application Server ausgeführt wird, die EJB 3.0 oder 3.1 nicht unterstützt, versucht, eine Methode in einer mit EJB 3.x kompatiblen Enterprise-Bean auf einem separaten Server über Fernzugriff aufzurufen, auf dem eine Version von Application Server ausgeführt wird, die EJB 3.0 oder 3.1 unterstützt. Wenn diese Produkte versuchen, eine Methode über die ferne EJB-3.x-Geschäftsschnittstelle der Enterprise-Bean aufzurufen, können sie Ausnahmen empfangen, die in EJB 3.0 eingeführt wurden und an die Umgebung zurückgesendet werden, die nicht mit EJB 3.x kompatibel ist.
Dieses Szenario könnte auch ein Problem für den Administrator einer Umgebung darstellen, die eine Kombination von Zusatzprodukten mit einer Mischung von mit EJB 3.x kompatiblen und nicht kompatiblen Application-Server-Instanzen enthält.
- javax.ejb.ConcurrentAccessException
- javax.ejb.EJBAccessException
- javax.ejb.EJBTransactionRequiredException
- javax.ejb.EJBTransactionRolledbackException
- javax.ejb.NoSuchEJBException
Sehen Sie sich den Schritt zur Implementierung von EJB-Modulen an, um potenzielle Interoperabilitätsprobleme zu adressieren.
EJB-2.x-Module
Vor der EJB-Implementierung im Application-Server-Produkt müssen in den EJB-2.x-Modulen, die in EJB-3.0- oder EJB-3.1-Module konvertiert wurden, alle von WebSphere Application Server generierten Dateien (einschließlich Stub- und Tie-Klassen) gelöscht werden.