Enterprise Java Beans

Enterprise JavaBeans (EJB) sind standardisierte Komponenten innerhalb eines Java-EE-Servers (Java Enterprise Edition). Sie vereinfachen die Entwicklung komplexer mehrschichtiger verteilter Softwaresysteme mittels Java. Mit Enterprise JavaBeans können wichtige Konzepte für Unternehmensanwendungen, z. B. Transaktions-, Namens- oder Sicherheitsdienste, umgesetzt werden, die für die Geschäftslogik einer Anwendung nötig sind.

Komponenten

Enterprise JavaBeans 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 von einem 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.

Von der Version 5 an unterstützt Java EE ein Attachment, Detachment und Reattachment. Die Entity Bean ist nun ein POJO, dessen Persistenz mit Hilfe des EntityManagers gesteuert werden kann. Das bekannte Java-EE-Entwurfsmuster „Datentransferobjekt“ (englisch DataTransferObject, kurz: DTO) ist somit aus technischer Sicht nicht mehr erforderlich, da nun Geschäftsobjekte über verschiedene Schichten, beispielsweise zu einem Client, transportiert werden könnten. Datentransferobjekte dienen der Abstraktion von Geschäftsobjekten (also der Repräsentation reiner Daten ohne Verhalten), und der Entkopplung verschiedener Anwendungsschichten.

Session Bean

Session Beans bilden insbesondere Vorgänge ab, die der Nutzer mit dem System durchführt. Sie bedienen sich häufig mehrerer Entity Beans, 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 zustandsbehafteten (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 (JMS) verwendet. Diese Sorte von Beans wird z. B. häufig für die Kommunikation mit Legacy-Systemen genutzt.

Web Services

Ab Version 1.4 erlaubt die J2EE-Spezifikation den Aufruf von Stateless Session Beans als Web Services und beschreibt einen Mechanismus, der die Schnittstelle eines Web Service 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, containerspezifische 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.

Transaktionen

Eine wesentliche Funktion von EJB-Containern ist die Verwaltung von Transaktionen. Jede Methode einer EJB hat ein sogenanntes Transaktionsattribut, das festlegt, welche Art von Transaktion die EJB benötigt und unterstützt.

NotSupported

Die Methode unterstützt keine Transaktionen. Der EJB-Container gibt keinen Transaktionskontext an die Methode und unterbricht die Transaktion bis zum Ende des Methodenaufrufs. Wenn die Methode andere EJBs aufruft, so laufen auch diese ohne Transaktion.

Required

Die Methode kann nur innerhalb einer Transaktion aufgerufen werden. Falls der Aufrufer nicht Teil einer Transaktion ist, beginnt der EJB-Container eine neue Transaktion die endet, sobald die Methode verlassen wird.

Supports

Die Methode kann sowohl innerhalb als auch außerhalb einer Transaktion aufgerufen werden. Im ersten Fall entspricht das Verhalten NotSupported, im zweiten Required.

RequiresNew

Die Methode benötigt eine eigene Transaktion. Der EJB-Container beginnt beim Aufruf der Methode immer eine neue Transaktion, die mit der Rückkehr aus dem Aufruf endet. Ist der Aufrufer bereits Teil einer Transaktion so wird diese vorübergehend ausgesetzt.

Mandatory

Der Aufrufer muss Teil einer Transaktion sein. Andernfalls meldet der EJB-Container einen Fehler, indem er eine Ausnahme (Exception) vom Typ javax.transaction.TransactionRequiredException wirft.

Never

Die Methode darf niemals innerhalb einer Transaktion aufgerufen werden. Falls doch, wirft der EJB-Container eine Ausnahme.

Version 3.0

Die Komplexität und die fehlende Objektorientiertheit der EJB-Technologie waren stets Kritikpunkte. Aus diesem Grunde wurde eine neue Spezifikation entwickelt, die eine deutliche Vereinfachung bringen soll. Neuerungen in EJB 3.0 sind unter anderen:

• Einführung von Annotationen
• Vereinfachung der EJB-API
  • Es werden keine Home Interfaces mehr benötigt.
  • Schnittstellen wie SessionBean oder MessageDrivenBean müssen nicht mehr implementiert werden.
  • 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 Annotationen deklariert.
  • Nur noch benötigte Rückruffunktionen (callback functions) müssen implementiert werden.

Siehe auch

• XDoclet als Vorgänger zu Annotationen
• JavaBeans

Literatur

• O. Ihns, S. Heldt, R. Wirdemann, H. Zuzmann: Enterprise JavaBeans komplett, Oldenbourg, 2003, ISBN 3486273795
• Oliver Ihns, Dierk Harbeck, Stefan M. Heldt, Holger Koschek, Jo Ehm, Carsten Sahling, Roman Schlömmer : EJB 3 professionell dpunkt, Heidelberg 2007, ISBN 978-3898644310
• Olaf Zwintzscher: Software-Komponenten im Überblick, W3L, 2004, ISBN 3937137602
• Debu Panda, Reza Rahman, Derek Lane: EJB 3 in Action, Manning Publications 2007, ISBN 1933988347

Weblinks

• EJB bei Sun Microsystems (englisch)
• Offizielles Java EE 5-Tutorial von Sun Microsystems (englisch, behandelt Enterprise Beans ab Kapitel 20)
• EJB 3.0 Implementierung von Oracle (englisch)
• EJB 3.0 Implementierung von JBoss (englisch)
• EJB (3.0) Glossar