Der große Erfolg von Java spiegelt sich in dem breiten Anwendungsspektrum wider, das sich diese Technologie in kurzer Zeit erschlossen hat. Aus der ursprünglichen Programmiersprache für Web-Applets entwuchs eine Plattform für die Entwicklung von verteilten Client-Server-Anwendungen. Viele der dazu nötigen APIs wurden rasch als De-facto-Standard in der Industrie etabliert. Beispiele hierfür sind die Java Database Connectivity (JDBC) als Schnittstelle zu Datenbanken oder das Java Naming and Directory Interface (JNDI).
Mit den Enterprise Javabeans (EJB) verfügt Java nun seit geraumer Zeit über ein Komponentenmodell für den Server-seitigen Einsatz. Die Entwicklung von EJB begann 1997, Mitte 1999 wurde die Spezifikation 1.1 veröffentlicht. EJBs können wie folgt definiert werden:
Enterprise Javabeans ist ein standardisiertes Server-seitiges Komponentenmodell für Component-Transaction-Monitore (CTM).
CTM sind im Kontext typischer Client-Server-Applikationen relevant, die in der Regel eine sogenannte dreischichtige Architektur aufweisen: Clients mit Präsentationslogik (first tier), Server mit Business-Logik (middle tier) und andere Server-seitige Ressourcen, wie zum Beispiel Datenbanken (third tier). Die Kommunikation zwischen den einzelnen Schichten erfolgt über spezielle Protokolle, beispielsweise Corba, DCOM oder Java-RMI.
In CTMs konvergieren zwei unterschiedliche Technologien, nämlich Transaction Processing Monitoren wie "IBM CICS" oder "Bea Tuxedo" sowie Object Request Broker, wie sie von Corba, DCOM oder Java-RMI her bekannt sind. Die relativ neue Middleware erleichtert die Entwicklung und den Einsatz von Business-Anwendungen, weil sie die gesamte Infrastruktur für Transaktionen, verteilte Objekte, Nebenläufigkeit, Sicherheit, Persistenz und Ressourcenverwaltung zur Verfügung stellt. Sie sind einfach anzuwenden und auch auf eine große Anzahl von Clients skalierbar. Somit sind CTM im Gegensatz zu den beiden Vorgängertechnologien, die nur Teile davon automatisieren konnten, ein erheblicher Fortschritt.
EJB als Standard für objektbasierte Transaktionen
Der erste Ansatz für einen CTM kam 1996 von Microsoft mit dem Microsoft Transaction Server auf Basis von DCOM. Er konnte sich aber nicht als allgemeingültiger Standard durchsetzen, weil er nur unter Windows läuft. Produkte von IBM, BEA oder Hitachi, die auf dem offenen Standard Corba aufbauen, verwenden verschiedene Server-seitige Komponentenmodelle, die jedoch untereinander nicht kompatibel sind. Nachdem alle diese Hersteller schon frühzeitig auf den Java-Zug aufgesprungen sind, zeichnet sich EJB als einheitliche Technik für diese verschiedenen Welten ab. Genau diese Absicht verfolgte Sun mit der Spezifikation von "EJB Servers" (CTMs, die die EJB-Spezifikation erfüllen).
Um Mißverständnisse zu vermeiden, sei vorweg betont, daß der Begriff EJB nichts mit Java- beans zu tun hat. Die Namensgleichheit soll ausdrücken, daß es sich in beiden Fällen um Komponenten handelt. EJBs kommen in zwei unterschiedlichen Varianten vor, den Entity Beans und den Session Beans. Entity Beans beschreiben Business-Objekte, beispielsweise bei einem Hotel-Reservierungssystem einen Kunden oder ein Hotelzimmer. Ihre Daten werden immer persistent gehalten, am besten in einer Datenbank.
Entity Beans repräsentieren die Geschäftsobjekte
Session Beans sind eine logische Erweiterung der Client-Applikation auf dem Server und verwalten Arbeitsabläufe im Kontext einer Transaktion. Ein Beispiel hierfür wäre der Vorgang der Zimmerreservierung. Session Beans beschreiben im allgemeinen Prozesse, die nicht persistent gehalten werden, aber den Zustand der Business-Objekte verändern können. Im Fall der Hotelzimmer könnte deren Status durch den Vorgang einer Reservierung oder Stornierung zwischen "frei" und "reserviert" wechseln.
Entity Beans repräsentieren eine konsistente und wiederverwendbare Schnittstelle zu Daten in der Datenbank. Die Methoden beschreiben, wie Daten in der Datenbank gelesen und geändert werden können beziehungsweise wie die Entity Beans untereinander in Beziehung stehen. Auf Entity Beans greift meist eine Vielzahl von Clients zu. Daher müssen sie Nebenläufigkeit unterstützen. Das geschieht aber automatisch. Die EJB-Spezifikation untersagt deshalb ausdrücklich die Verwendung des Methoden-Attributs "synchronized". EJB-Container müssen in der Spezifikation 1.0 Entitiy Beans noch nicht unterstützen, in der bevorstehenden Version 2.0 wird dies aber zur Pflicht werden.
Session Beans beschreiben Arbeitsabläufe so, daß die Details für den Client unsichtbar sind. Die Verwendung der Session Beans ist nicht zwingend - der Client könnte auch direkt auf Entity Beans zugreifen -, aber das würde den Nachteil mit sich bringen, daß bei jeder Änderung der Entity Beans der Client modifiziert werden muß und damit die Wiederverwendung des Codes, der die Arbeitsabläufe beschreibt, beeinträchtigt wird. Session Beans verringern zudem die Netzwerkbelastung, weil nur mehr ein Aufruf für das Anstoßen der Session nötig ist, und sie reduzieren auch die Anzahl der Remote-Referenzen der Clients. Bei einer Hotelzimmerreservierung würde der Client normalerweise Referenzen auf das Hotel, die Zimmer und andere Objekte benötigen. Mit einer Session Bean (ReservationAgent) erhält der Client nur mehr eine einzige Referenz, und zwar auf die Session Bean selbst.
EJB als Integrationsplattform
Die Java-Technologie geht mit der Spezifikation der EJBs einen entscheidenden Schritt in Richtung Enterprise Computing Platform. Waren die Anfänge von Java noch durch die naive Vorstellung geprägt, daß in Zukunft alles in Java entwickelt würde, definiert der EJB-Standard, wie verschiedene Technologien sauber in die Java-Welt integrierbar sind.
Einen entscheidenden Beitrag leistet die EJB-Spezifikation auch dadurch, daß das Komponentenmodell gegenüber allen möglichen Clients offen ist. Diese können Java-Komponenten, Active-X-Controls oder Corba-Objekte sein, die über das jeweils adäquate Protokoll in einer verteilten Client-Server-Architektur auf eine EJB zugreifen.
EJB-Architektur
Eine EJB besteht immer aus zwei Interfaces und zwei Klassen, die Klassen im Paket javax.ejb erweitern:
Remote Interface: beschreibt die nach außen hin sichtbaren Business-Methoden der Bean; dieses Interface erweitert EJBObject.
Home Interface: stellt Methoden zum Erzeugen, Löschen und Suchen von EJBs zur Verfügung; erweitert EJBHome.
Bean Class: enthält die Implementierung der Business-Methoden. Der Client arbeitet aber nie mit der Bean Class direkt, sondern nur mit den Interfaces; erweitert Entity Bean beziehungsweise Session Bean.
Primary Key: einfache Klasse, die einen Verweis auf einen Satz in einer Datenbank enthält, wo die persistenten Felder der Entity Beans gespeichert werden; implementiert "Serializable".
Hinter den Kulissen steht aber noch eine Reihe weiterer Klassen und Werkzeuge zur Verfügung, wie etwa verschiedene Descriptor-Klassen, die das Verhalten einer EJB steuern.
Die Klassen DeploymentDescriptor, ControlDescriptor, AccessControlDescriptor, EntityDescriptor und SessionDescriptor werden vom sogannten Container (EJBContext) verwendet, der konzeptionell die EJB-Umgebung darstellt und eine EJB verwaltet.
Die einzelnen Parameter, wie beispielsweise Sicherheit, Transaktions-Kontext, können mit einem geeigneten Property-Editor bearbeitet und auch zur Laufzeit verändert werden, ähnlich wie die Eigenschaften einer Javabean.
Angeklickt
Besonders die Hersteller von TP-Monitoren und Applikations-Servern schicken sich an, ihre Software um Unterstützung für Enterprise Javabeans (EJB) zu erweitern. Damit erschließt sich dem Anwender ein einheitliches Programmiermodell für die Middleware unterschiedlicher Anbieter. Die Spezifikation von EJB unterscheidet zwischen Session und Entity Beans. Letztere müssen von EJB-Containern derzeit noch nicht unterstützt werden, doch soll sich dies mit EJB 2.0 ändern.
*Egbert Althammer (althammeracm.org) und Wolfgang Pree (preeacm.org) sind Mitarbeiter des C. Doppler Lab for Software Research der Universität Konstanz.