Java Reference
In-Depth Information
den eine Kennung für das RMI-Objekt, die aufzurufende Methode und die Parameter an den
RMI-Server übermittelt. Innerhalb des RMI-Servers befi ndet sich ein sogenanntes Skeleton,
welche das Gegenstück des Stubs darstellt. Das Skeleton nimmt die vom Stub übermittelten
Daten entgegen, interpretiert sie und ru die entsprechende Methode mit den übertragenen
Parametern auf dem angegebenen RMI-Objekt auf. Nach dem Ende des Methodenaufrufs
wird vom Skeleton eine Antwort an den Stub zurückgeschickt, die im Falle einer Methode,
die nicht void ist, auch den Rückgabewert oder alternativ die geworfene Ausnahme enthält.
Der Stub wartet auf die Antwort, interpretiert sie und kehrt entweder normal vom Metho-
denaufruf zurück oder wir die übermittelte Ausnahme.
Die Interaktion eines Clients mit einer EJB-Komponente erfolgt auch über RMI. Es gibt
jedoch zwei wesentliche Unterschiede gegenüber dem „normalen“ RMI:
!
Bei RMI wird für ein RMI-Objekt ein Eintrag in der RMI-Registry vorgenommen (die Beto-
nung in diesem Satz liegt auf Objekt). Es kann somit auch vorkommen, dass mehrere
RMI-Objekte derselben Klasse erzeugt und unter jeweils unterschiedlichen Namen in der
RMI-Registry angemeldet werden. Der RMI-Client kann sich durch Angabe des betreff en-
den Namen gezielt die Fernsteuerung für das gewünschte dazugehörige Objekt beschaf-
fen. Im Gegensatz dazu wird bei EJB ein Eintrag in den Namensdienst für eine Bean-
Klasse gemacht (die Betonung liegt hier auf Klasse im Gegensatz zu Objekt). Bean-Klassen
sind solche, die „von außen“ über RMI angesprochen werden können. Die Erzeugung und
auch das Löschen von Objekten einer Bean-Klasse wird vom EJB-Container und nicht von
der Anwendung vorgenommen, wobei es dabei je nach Art der Bean-Klasse unterschied-
liche Strategien gibt (dazu später mehr in Abschnitt 13.4).
!
Bei RMI ru das Skeleton direkt die Methode auf dem RMI-Objekt auf. Bei EJB befi ndet
sich dagegen zwischen dem Skeleton und dem Bean-Objekt nochmals ein Proxy-Objekt,
das Teil des EJB-Containers ist. Dieses Proxy-Objekt, das wir im Folgenden EJB-Proxy
nennen werden, führt vor und nach dem Aufruf der eigentlichen Anwendungsmethode
der Bean-Klasse zusätzliche Funktionen aus, die wesentlich für EJB sind und die den
Einsatz eines EJB-Servers ausmachen. Dazu gehört u. a. die Auswahl eines geeigneten
Objekts, um den Methodenaufruf durchzustellen, wobei ein solches Objekt unter Umstä n-
den dabei zuerst erzeugt werden muss. Aber auch andere Funktionen wie das Starten
einer neuen Transaktion oder die Überprüfung, ob dem aufrufenden Client erlaubt ist
diese Methode auszuführen, werden vom EJB-Proxy erledigt. Wenn man Stub und Skele-
ton zusammen als Proxy begrei , der die Funktion zur Überschreitung von Adressraum-
und Rechnergrenzen erbringt, dann sind bei einem Aufruf einer Bean-Methode zwei Pro-
xies involviert. Diese Situation ist in Bild 13.5 dargestellt. Nur die grau hinterlegten Teile
führen dabei anwendungsspezifi schen Code aus; der Rest kommt von EJB bzw. RMI.
EJB-Client
EJB-Server
EJB-Container
EJB-Komponente
Anwendung
EJB-Proxy
Bean-Objekt
Bild 13.5
Interaktion zwischen
EJB-Client und
EJB-Server
Stub
Skeleton
