Jakarta Enterprise Beans

Jakarta Enterprise Beans (früher Enterprise JavaBeans, EJB) sind standardisierte Komponenten innerhalb der Java-EE-Plattform. Sie vereinfachen die Entwicklung komplexer mehrschichtiger verteilter Softwaresysteme mit Java. So 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 physisch 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“ (engl. data transfer object, 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 dienten zuvor 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. Auch für die Ausführung von klassischerweise asynchron auszuführenden Operationen (z. B. dem Verschicken einer Mail), von deren Erfolg und Dauer die Performanz einer übergeordneten Anwendung nicht abhängen sollte, bieten sich Message Driven Beans an.

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.

Beispiel

Anschaulich kann man die unterschiedlichen Komponenten an einem Onlineshop erklären. Eine zustandslose Session Bean könnte etwa die Daten eines Suchergebnisses nach einem bestimmten Artikel beinhalten. Eine solche Suchliste muss nicht persistent gespeichert sein, sondern kann nach einmaliger Betrachtung verworfen werden. Eine zustandsbehaftete Session Bean ist der Warenkorb, in den man die Artikel hineinlegt. Dieser sollte zumindest für den Zeitraum gespeichert werden, in dem der Kunde auf der Seite stöbert und eventuell weitere Artikel hineinlegt. Eine Entity Bean speichert letztendlich die Kundendaten, mit denen sich der Kunde bei dem Shop registriert hat. Diese müssen wiederum persistent gespeichert werden, sonst müsste man sich bei jedem Besuch der Seite neu registrieren.[1]

Konfiguration (Deployment Descriptor)

Der EJB-Standard definiert neben den Enterprise Java Beans auch einen sogenannten Deployment Descriptor (frei übersetzt „Einsatz-Beschreibung“). Dieser Deployment Descriptor ist eine XML-Datei, in der vor Version 3 des Standards immer die eigentliche EJB-Definition stattfand, da hier der Zusammenhang zwischen den verschiedenen Java-Klassen und -Interfaces, aus denen eine EJB besteht, hergestellt werden musste.

Ab Version 3 können die meisten Angaben, für die zuvor der Deployment Descriptor notwendig war, mit Annotationen direkt im Java-Code implementiert werden. Dadurch kann der Deployment Descriptor ganz entfallen. Er kann aber auch dazu benutzt werden, die Angaben in den Annotations zu überschreiben.

Neben diesen standardisierten Eigenschaften definieren EJB-Container zusätzliche, containerspezifische Eigenschaften.

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 (Default)
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 nach dem Verlassen der Methode wieder beendet wird. Dies ist gemäß dem convention over configuration-Prinzip das Standardverhalten, sofern der Entwickler kein Transaktionsattribut angibt.
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 (ab Java EE 5) sind unter anderen:

  • Entity Beans sind obsolet geworden, stattdessen sollen Persistent Entities verwendet werden
  • Einführung von Annotationen, wodurch fast alle Angaben im Deployment Descriptor ersetzt werden und dieser oft entfallen kann.
  • 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.

Version 3.1

EJB 3.1 (ab Java EE 6) bringt zusätzlich folgende Neuerungen:

  • Es gibt Singletons, von denen (in einer Anwendung in einem Server) nur eine Instanz existiert. Für die Singletons wird eine eigene Unterstützung für Nebenläufigkeit implementiert (Bean Managed Concurrency oder Container Managed Concurrency)
  • Asynchrone Aufrufe von Business-Methoden sind möglich.
  • Es werden keinerlei Interfaces mehr benötigt (No-Interface-View). Solche EJBs können dann zwar nur lokal verwendet werden, dafür aber stark vereinfacht direkt von den JSF-Seiten.
  • EJBs haben genau definierte JNDI-Namen in verschiedenen Namensräumen: java:global, java:app und java:module.
  • EJBs müssen nicht mehr in einer separaten ejb-jar Datei verteilt werden, sondern können direkt in das .war Archiv mitpaketiert werden.

Siehe auch

Literatur

  • Olaf Zwintzscher: Software-Komponenten im Überblick. W3L, 2004, ISBN 3-937137-60-2
  • Oliver Ihns, Dierk Harbeck, Stefan M. Heldt, Holger Koschek, Jo Ehm, Carsten Sahling, Roman Schlömmer: EJB 3 professionell. dpunkt, Heidelberg 2007, ISBN 978-3-89864-431-0
  • Debu Panda, Reza Rahman, Derek Lane: EJB 3 in Action. Manning Publications, 2007, ISBN 1-933988-34-7
  • O. Ihns, S. Heldt, R. Wirdemann, H. Zuzmann: Enterprise JavaBeans komplett, Oldenbourg, 2003, ISBN 3-486-27379-5

Weblinks

Einzelnachweise

  1. ↑ Nach: Tanenbaum, van Steen: Distributed Systems: Principles and Paradigms. 2006