Java Reference
In-Depth Information
Realisierung der parallelen Abarbeitung von HTTP-Anforderungen durch mehrere Threads
werden von einem sogenannten Servlet-Container übernommen. Die Situation ist für EJBs
ganz ähnlich. Auch hier soll sich die Anwendungsentwicklerin nicht um wiederkehrende
Aufgaben kümmern müssen, sondern diese werden vom EJB-Container übernommen. Dazu
ge hört die Transaktionssteuerung und die Zugriff skontrolle. Da man bei EJB von einer sehr
großen Zahl von Clients ausgeht, spielt auch das Management der von den Clients genutz-
ten Objekte eine große Rolle. Darauf wird im Laufe dieses Kapitels noch detaillierter einge-
gangen.
Eine EJB-Anwendung ist eine Komponente, die im laufenden Betrieb unabhängig von ande-
ren Komponenten installiert, neu installiert und deinstalliert werden kann. Ein EJB-Contai-
ner bildet die Ausführungsumgebung für EJB-Anwendungen und stellt somit das Kompo-
nenten-Framework dar. Java-EE-Server wie Glassfi sh von der Firma Oracle oder JBoss von
der Firma Redhat stellen in der Regel nicht nur einen EJB-Container, sondern auch einen
Web-Server mit Servlet-Container sowie ein Datenbanksystem bereit, so dass mit einem
einzigen Server die drei Server-Schichten einer 4-Komponenten-Architektur (s. Bild 13.4)
abgedeckt werden können.
■
132 Interaktion mit EJB-Komponenten
Die Interaktion zwischen einer Client-Anwendung und einer EJB-Komponente (linker Pfeil
in Bild 13.3) bzw. zwischen einem Servlet und einer EJB-Komponente (zweiter Pfeil von
links in Bild 13.4) erfolgt in Form eines Methodenaufrufs. Da der Client und die EJB-Kom-
ponente in der Regel auf unterschiedlichen Rechnern, zumindest aber in unterschiedlichen
Adressräumen (d. h. in unterschiedlichen Prozessen) laufen, handelt es sich bei diesem
Methodenaufruf in der Regel um einen Fernmethodenaufruf (RMI: Remote Method Invo-
cation).
Das Prinzip von RMI lässt sich in aller Kürze so zusammenfassen: In einer RMI-Server-
Anwendung werden ein oder mehrere RMI-Objekte erzeugt. Ein RMI-Objekt ist ein Objekt
einer Klasse, die bestimmte Bedingungen erfüllen muss. Insbesondere muss eine solche
Klasse eine Schnittstelle implementieren, die zwar nicht von RMI vorgegeben wird, sondern
anwendungsspezifi sch vom Anwendungsentwickler defi niert werden kann, die aber selbst
wieder gewissen Regeln unterworfen ist. Ein RMI-Objekt wird dann vom RMI-Server in
einer sogenannten RMI-Registry unter einem frei gewählten Namen angemeldet. In der
RMI-Registry wird zu dem gewählten Namen aber nicht das RMI-Objekt selbst, sondern eine
Art Fernsteuerung für das Objekt eingetragen. Ein RMI-Client, der in der Regel auf einem
anderen Rechner läu , muss den Rechner, auf dem die RMI-Registry und der RMI-Server
laufen, sowie den Namen eines RMI-Objekts kennen. Er kann mit diesem Wissen eine
Anfrage an die RMI-Registry stellen und erhält die Fernsteuerung zurück, über die er dann
Methoden auf dem RMI-Objekt, welches auf dem RMI-Server liegt, aufrufen kann. Bei der
Fernsteuerung handelt es sich um einen sogenannten Stub. Die Klasse des Stub-Objekts
implementiert dieselbe Schnittstelle wie die Klasse des RMI-Objekts. Der Programmcode
des Stubs ist für alle implementierten Methoden derselbe: Über eine Netzverbindung wer-
