Jakarta Enterprise Beans
Enterprise Java Beans (EJB) sind standardisierte Komponenten innerhalb eines J2EE-Servers (Java 2 Enterprise Edition). Sie vereinfachen die Entwicklung komplexer mehrschichtiger verteilter Softwaresysteme mittels Java. Im Gegensatz zu den Java Beans, die für die Präsentation eingesetzt werden, also z. B. als visuelle Steuerelemente (Buttons, Scrollbars), stellen Enterprise Java Beans wichtige Konzepte für Unternehmensanwendungen bereit, z.B. Transaktions-, Namens- oder Sicherheitsdienste, die für die „Geschäftslogik“ einer Anwendung benötigt werden.
Komponenten
Enterprise Java Beans gibt es in mehreren unterschiedlichen Ausprägungen für verschiedene Klassen von Anwendungsfällen. Sie können entweder remote ("entfernt", also über Prozess- und Rechnergrenzen hinweg) oder lokal (innerhalb einer VM) angesprochen werden.
Entity Bean
Entity-Beans modellieren die dauerhaften (persistenten) Daten des Systems. Beispiele sind physikalisch vorhandene Dinge wie Benutzer, Informationsstrukturen wie Adressen oder archivierte Vorgangsinformationen wie Rechnungen. Sie repräsentieren z.B. einen Datensatz aus einer Datenbank.
Die Persistenz kann entweder vom Bean-Entwickler selbst programmiert ("Bean Managed Persistence", BMP) oder vom EJB-Container bereitgestellt werden ("Container Managed Persistence", CMP). Bei CMP wird im Deployment Descriptor (siehe unten) unter anderem der Name eines abstrakten Schemas definiert, was üblicherweise dem Namen einer Datenbanktabelle entspricht, in der EJBs einer Klasse abgelegt werden.
Session Bean
Session-Beans bilden insbesondere Vorgänge ab, die der Nutzer mit dem System durchführt. Sie bedienen sich häufig mehrerer EntityBeans, um die Auswirkungen des Prozesses darzustellen.
Man unterscheidet zustandslose ("stateless") und zustandsbehaftete ("stateful") Session-Beans.
Eine zustandsbehaftete Session Bean hat ein eigenes Gedächtnis. Sie kann Informationen aus einem Methodenaufruf speichern, damit sie bei einem späteren Aufruf einer anderen (oder der gleichen) Methode wieder zur Verfügung stehen. Die Zustandsbehaftung wird durch die Vergabe einer eindeutigen ID umgesetzt, über diese ID können die stateful Session Beans unterschieden werden.
Im Gegensatz dazu müssen einer zustandslosen Session Bean bei jedem Aufruf alle Informationen als Parameter übergeben werden, die für die Abarbeitung dieses Aufrufs benötigt werden. Da eine zustandslose Session Bean keine Informationen speichern kann, ist sie nicht von anderen Session Beans der gleichen Klasse unterscheidbar, sie hat also keine eigene Identität.
Message Driven Bean
Message Driven Beans sind diejenigen Komponenten, die EJB-Systeme für asynchrone Kommunikation zugänglich machen. Hierzu wird der Java Message Service verwendet. Diese Sorte von Beans wird z. B. häufig für die Kommunikation mit Legacy-Systemen genutzt.
WebService
Ab Version 1.4 erlaubt die J2EE-Spezifikation den Aufruf von Stateless Session Beans als Webservices und beschreibt einen Mechanismus, der die Schnittstelle eines Webservice auf die Schnittstelle einer EJB abbildet.
Konfiguration (Deployment Descriptor)
Der EJB-Standard schreibt neben den Enterprise Java Beans auch einen sogenannten Deployment Descriptor (frei übersetzt "Einsatz-Beschreibung") vor. Dieser Deployment Descriptor ist eine XML-Datei, in der Eigenschaften von EJBs definiert werden, die nicht hart codiert sind. Dazu zählen:
- Name, Klasse und Schnittstellen einer EJB.
- Informationen darüber, ob bestimmte Methoden unter bestimmten Arten von Transaktionen aufgerufen werden dürfen oder müssen.
- Referenzen auf Ressourcen, die der Bean vom Container bereitgestellt werden müssen, z.B. Datenquellen.
- Referenzen auf andere EJBs oder Webservices.
- Optional die Definition der Endpunkte von Webservices als die die EJBs angeboten werden sollen.
- Für Entity Beans mit Container Managed Persistence der Name ihres abstrakten Schemas sowie die Definition ihrer persistenten Felder und Beziehungen untereinander. Außerdem können Queries für bestimmte Suchmethoden (sogenannte Finders) definiert werden.
Neben diesen standardisierten Eigenschaften definieren EJB-Container zusätzliche container-spezifische Eigenschaften. Zum Zeitpunkt der Installation können diese Eigenschaften je nach Container auf unterschiedliche Art angegeben werden - in Java-Properties-Dateien, XML-Dateien oder interaktiv.
Ausblick
Die Komplexität und die fehlende Objektorientiertheit der EJB-Technologie war stets ein Kritikpunkt. Aus diesem Grunde wurde eine neue Spezifikation entwickelt, die eine deutliche Vereinfachung bringen soll. Neuerungen in EJB 3.0 sind unter anderem:
- Einführen von Annotations
- Vereinfachung der EJB-API
- Es werden keine Home Interfaces mehr benötigt.
- Keine Vererbung von Basisbeanklassen wie „
SessionBean
“, „MessageDrivenBean
“ oder „EntityBean
“. - Alle Bean-Klassen sind ausschließlich POJOs. Das heißt, der Code muss nicht durch EJB-Implementierungsdetails „verschmutzt“ werden, die benötigten Informationen werden als Annotations deklariert.
- Nur noch benötigte Rückruffunktionen (callback function) müssen implementiert werden.
Literatur
- O. Ihns, S. Heldt, R. Wirdemann, H. Zuzmann: Enterprise JavaBeans komplett, Oldenbourg, 2003, ISBN 3486273795
- Olaf Zwintzscher: Software-Komponenten im Überblick, W3L, 2004, ISBN 3937137602
Siehe auch
- XDoclet als Vorgänger zu Annotations
Weblinks
- EJB bei Sun Microsystems (englisch)
- Offizielles J2EE-Tutorial von Sun Microsystems (englisch, behandelt Enterprise Beans ab Kapitel 23)
- EJB 3.0 Implementierung von Oracle (englisch)
- EJB 3.0 Implementierung von Jboss (englisch)
- EJB (3.0) Glossar