Jakarta Enterprise Beans - Jakarta Enterprise Beans

Jakarta Enterprise Beans ( EJB ; ehemals Enterprise JavaBeans) ist eine von mehreren Java-APIs für den modularen Aufbau von Unternehmenssoftware . EJB ist eine serverseitige Softwarekomponente , die die Geschäftslogik einer Anwendung kapselt . Ein EJB -Webcontainer bietet eine Laufzeitumgebung für webbezogene Softwarekomponenten, einschließlich Computersicherheit , Java-Servlet-Lebenszyklusverwaltung , Transaktionsverarbeitung und anderer Webdienste . Die EJB-Spezifikation ist eine Teilmenge der Java EE- Spezifikation.

Spezifikation

Die EJB-Spezifikation wurde ursprünglich 1997 von IBM entwickelt und später 1999 von Sun Microsystems (EJB 1.0 und 1.1) übernommen und im Rahmen des Java Community Process als JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB) erweitert 3,0), JSR 318 (EJB 3,1) und JSR 345 (EJB 3,2).

Die EJB-Spezifikation bietet eine Standardmethode zum Implementieren der serverseitigen (auch als " Back-End " bezeichneten) "Business" -Software, die normalerweise in Unternehmensanwendungen zu finden ist (im Gegensatz zu "Front-End" -Benutzeroberflächensoftware ). Solche Software adressiert die gleichen Problemtypen, und Lösungen für diese Probleme werden von Programmierern häufig wiederholt neu implementiert. Jakarta Enterprise Beans soll häufig auftretende Probleme wie Persistenz , Transaktionsintegrität und Sicherheit auf standardmäßige Weise behandeln, sodass sich Programmierer auf die jeweiligen Teile der Unternehmenssoftware konzentrieren können.

Allgemeine Verantwortlichkeiten

In der EJB-Spezifikation wird detailliert beschrieben, wie ein Anwendungsserver die folgenden Verantwortlichkeiten bereitstellt:

• Transaktionsverarbeitung
• Integration in die Persistenzdienste der Jakarta Persistence (JPA)
• Parallelitätskontrolle
• Ereignisgesteuerte Programmierung mit Jakarta Messaging (JMS) und Jakarta Connectors (JCA)
• Asynchroner Methodenaufruf
• Arbeit planen
• Namens- und Verzeichnisdienste über Java Naming and Directory Interface (JNDI)
• Interprozesskommunikation mit RMI-IIOP und Webdiensten
• Sicherheit ( JCE und JAAS )
• Bereitstellung von Softwarekomponenten auf einem Anwendungsserver

Darüber hinaus definiert die Jakarta Enterprise Beans-Spezifikation die Rollen, die der EJB-Container und die EJBs spielen, sowie die Bereitstellung der EJBs in einem Container. Beachten Sie, dass in der EJB-Spezifikation nicht detailliert beschrieben wird, wie ein Anwendungsserver Persistenz bereitstellt (eine Aufgabe, die an die JPA-Spezifikation delegiert ist), sondern wie die Geschäftslogik problemlos in die vom Anwendungsserver angebotenen Persistenzdienste integriert werden kann.

Geschichte

Unternehmen stellten fest, dass die Verwendung von EJBs zur Kapselung der Geschäftslogik eine Leistungsbeeinträchtigung mit sich brachte. Dies liegt daran, dass die ursprüngliche Spezifikation nur den Remote-Methodenaufruf über CORBA (und optional andere Protokolle) zulässt, obwohl die große Mehrheit der Geschäftsanwendungen diese verteilte Computerfunktionalität tatsächlich nicht benötigt . In der EJB 2.0-Spezifikation wurde dieses Problem behoben, indem das Konzept lokaler Schnittstellen hinzugefügt wurde, die von Anwendungen, die nicht auf mehrere Server verteilt waren, direkt ohne Leistungseinbußen aufgerufen werden konnten.

Die EJB 3.0-Spezifikation ( JSR 220) war eine Abkehr von ihren Vorgängern und folgte einem neuen, leichten Paradigma. EJB 3.0 zeigt einen Einfluss von Spring auf die Verwendung einfacher Java-Objekte und die Unterstützung der Abhängigkeitsinjektion , um die Konfiguration und Integration heterogener Systeme zu vereinfachen. Gavin King, der Erfinder von Hibernate, hat am EJB 3.0-Prozess teilgenommen und ist ein ausgesprochener Verfechter der Technologie. Viele Funktionen, die ursprünglich in Hibernate enthalten waren, wurden in die Java Persistence API integriert , die in EJB 3.0 die Entity Beans ersetzt . Die EJB 3.0-Spezifikation basiert stark auf der Verwendung von Anmerkungen (eine Funktion, die der Java-Sprache mit Version 5.0 hinzugefügt wurde) und der Konvention über die Konfiguration , um einen viel weniger ausführlichen Codierungsstil zu ermöglichen. Dementsprechend ist EJB 3.0 in der Praxis viel leichter und fast eine völlig neue API, die wenig Ähnlichkeit mit den vorherigen EJB-Spezifikationen aufweist.

Beispiel

Das Folgende zeigt ein grundlegendes Beispiel dafür, wie ein EJB im Code aussieht:

@Stateless 
public class CustomerService { 
  

  private EntityManager entityManager; 
   
  public void addCustomer(Customer customer) { 
    entityManager.persist(customer); 
  } 
}

Das Obige definiert eine Serviceklasse zum Speichern eines Kundenobjekts (über O / R-Zuordnung ). Die EJB kümmert sich um die Verwaltung des Persistenzkontexts, und die Methode addCustomer () ist standardmäßig transaktions- und threadsicher. Wie gezeigt, konzentriert sich die EJB nur auf Geschäftslogik und Persistenz und weiß nichts über eine bestimmte Präsentation.

Ein solcher EJB kann von einer Klasse in z. B. der Webebene wie folgt verwendet werden:

@Named	
@RequestScoped
public class CustomerBacking {
   @EJB 
   private CustomerService customerService;

   public String addCustomer(Customer customer) {
      customerService.addCustomer(customer);
      context.addMessage(...); // abbreviated for brevity
      return "customer_overview";
   }
}

Das Obige definiert eine JSF-Backing-Bean ( JavaServer Faces ), in die der EJB mithilfe der Annotation @EJB eingefügt wird. Die addCustomer-Methode ist normalerweise an eine UI-Komponente gebunden, z. B. eine Schaltfläche. Im Gegensatz zur EJB enthält die Backing Bean keine Geschäftslogik oder keinen Persistenzcode, sondern delegiert solche Bedenken an die EJB. Die Backing Bean kennt eine bestimmte Präsentation, von der die EJB nichts wusste.

Arten von Enterprise Beans

Ein EJB-Behälter enthält zwei Hauptbohnensorten:

• Sitzungs-Beans, die entweder "Stateful", "Stateless" oder "Singleton" sein können und auf die entweder über eine lokale (gleiche JVM) oder Remote- Schnittstelle (unterschiedliche JVM) oder direkt ohne Schnittstelle zugegriffen werden kann. In diesem Fall gilt die lokale Semantik. Alle Session Beans unterstützen die asynchrone Ausführung für alle Ansichten (lokal / remote / keine Schnittstelle).
• Message Driven Beans (MDBs, auch als Message Beans bezeichnet). MDBs unterstützen auch die asynchrone Ausführung, jedoch über ein Messaging-Paradigma.

Session Beans

Stateful Session Beans

Stateful Session Beans sind Geschäftsobjekte mit Status : Das heißt, sie verfolgen, mit welchem ​​aufrufenden Client sie sich während einer Sitzung befassen, und daher ist der Zugriff auf die Bean-Instanz streng auf jeweils nur einen Client beschränkt. Wenn der gleichzeitige Zugriff auf eine einzelne Bean trotzdem versucht wird, serialisiert der Container diese Anforderungen, aber über die Annotation @AccessTimeout kann der Container stattdessen eine Ausnahme auslösen. Der Status von Stateful Session Beans kann vom Container automatisch beibehalten (passiviert) werden, um Speicher freizugeben, nachdem der Client einige Zeit nicht auf die Bean zugegriffen hat. Der erweiterte JPA-Persistenzkontext wird ausdrücklich von Stateful Session Beans unterstützt.

Beispiele

• Das Auschecken in einem Webshop wird möglicherweise von einer Stateful-Session-Bean durchgeführt, die anhand ihres Status verfolgt, wo sich der Kunde im Checkout-Prozess befindet, und möglicherweise Sperren für die vom Kunden gekauften Artikel hält (aus Sicht einer Systemarchitektur) Es wäre weniger ideal, wenn der Client diese Sperren verwaltet.

Zustandslose Sitzungsbohnen

Stateless Session Beans sind Geschäftsobjekte, denen kein Status zugeordnet ist. Der Zugriff auf eine einzelne Bean-Instanz ist jedoch immer noch auf jeweils nur einen Client beschränkt. Der gleichzeitige Zugriff auf die Bean ist verboten. Wenn versucht wird, gleichzeitig auf eine einzelne Bean zuzugreifen, leitet der Container jede Anforderung einfach an eine andere Instanz weiter. Dadurch wird eine zustandslose Session-Bean automatisch threadsicher. Instanzvariablen können während eines einzigen Methodenaufruf von einem Client an der Bohne, aber die Inhalte dieser Instanzvariablen nicht zu konservierenden garantiert über verschiedene Client verwendet werden Methode Anrufe. Instanzen von Stateless Session Beans werden normalerweise zusammengefasst. Wenn ein zweiter Client direkt nach Abschluss eines von einem ersten Client durchgeführten Methodenaufrufs auf eine bestimmte Bean zugreift, erhält er möglicherweise dieselbe Instanz. Der fehlende Aufwand für die Aufrechterhaltung einer Konversation mit dem anrufenden Client macht ihn weniger ressourcenintensiv als Stateful Beans.

Beispiele

• Das Senden einer E-Mail an den Kundensupport wird möglicherweise von einer zustandslosen Bean verarbeitet, da dies ein einmaliger Vorgang ist und nicht Teil eines mehrstufigen Prozesses.
• Ein Benutzer einer Website, der auf das Feld "Über zukünftige Aktualisierungen auf dem Laufenden halten" klickt, kann einen Aufruf einer asynchronen Methode der Session Bean auslösen, um den Benutzer zu einer Liste in der Datenbank des Unternehmens hinzuzufügen (dieser Aufruf ist asynchron, da der Benutzer dies nicht tut müssen warten, um über Erfolg oder Misserfolg informiert zu werden).
• Das Abrufen mehrerer unabhängiger Daten für eine Website, z. B. eine Liste von Produkten und der Verlauf des aktuellen Benutzers, wird möglicherweise auch von asynchronen Methoden einer Session-Bean verarbeitet (diese Aufrufe sind asynchron, da sie auf diese Weise parallel ausgeführt werden können, was möglicherweise der Fall ist erhöht die Leistung). In diesem Fall gibt die asynchrone Methode eine zukünftige Instanz zurück.

Singleton Session Beans

Singleton Session Beans sind Geschäftsobjekte mit einem globalen gemeinsamen Status innerhalb einer JVM. Der gleichzeitige Zugriff auf die einzige Bean-Instanz kann vom Container (Container-Managed Concurrency, CMC) oder von der Bean selbst (Bean-Managed Concurrency, BMC) gesteuert werden. CMC kann mithilfe der @ Lock-Annotation optimiert werden, die angibt, ob für einen Methodenaufruf eine Lesesperre oder eine Schreibsperre verwendet wird. Darüber hinaus können Singleton Session Beans mithilfe der Annotation @Startup explizit die Instanziierung beim Start des EJB-Containers anfordern.

Beispiele

• Das Laden einer globalen täglichen Preisliste, die für jeden Benutzer gleich ist, kann mit einer Singleton-Session-Bean erfolgen, da die Anwendung dadurch nicht immer wieder dieselbe Abfrage an eine Datenbank durchführen muss ...

Nachrichtengesteuerte Bohnen

Nachrichtengesteuerte Beans sind Geschäftsobjekte, deren Ausführung durch Nachrichten anstelle von Methodenaufrufen ausgelöst wird. Die Message Driven Bean wird unter anderem verwendet, um eine benutzerfreundliche Abstraktion auf hoher Ebene für die JMS- Spezifikation ( Java Message Service ) auf niedrigerer Ebene bereitzustellen . Möglicherweise werden JMS-Nachrichtenwarteschlangen oder Nachrichtenthemen abonniert, was normalerweise über das Attribut activityConfig der Annotation @MessageDriven erfolgt. Sie wurden in EJB hinzugefügt, um eine ereignisgesteuerte Verarbeitung zu ermöglichen. Im Gegensatz zu Session Beans verfügt eine MDB nicht über eine Clientansicht (lokal / remote / keine Schnittstelle), d.h. e. Clients können eine MDB-Instanz nicht nachschlagen. Eine MDB wartet nur auf eingehende Nachrichten in einer JMS-Warteschlange oder einem JMS-Thema und verarbeitet sie automatisch. Die Java EE-Spezifikation benötigt nur JMS-Unterstützung, Message Driven Beans können jedoch auch andere Messaging-Protokolle unterstützen. Solche Protokolle können asynchron sein, können aber auch synchron sein. Da Session Beans auch synchron oder asynchron sein kann, ist der Hauptunterschied zwischen Session- und Message Driven Beans nicht die Synchronität, aber der Unterschied zwischen (objektorientiert) Methode rufenden und Messaging .

Beispiele

• Das Senden eines Konfigurationsupdates an mehrere Knoten kann durch Senden einer JMS-Nachricht an ein 'Nachrichtenthema' erfolgen und von einer Message Driven Bean verarbeitet werden, die dieses Thema abhört (das Nachrichtenparadigma wird hier verwendet, da der Absender das nicht kennen muss Anzahl der Verbraucher, ihren Standort oder sogar ihren genauen Typ).
• Das Senden eines Jobs an einen Arbeitscluster kann durch Senden einer JMS-Nachricht an eine 'Nachrichtenwarteschlange' erfolgen und kann auch von einer Message Driven Bean verarbeitet werden, diesmal jedoch durch Abhören einer Warteschlange (das Nachrichtenparadigma und die Warteschlange werden seitdem verwendet Der Absender muss sich nicht darum kümmern, welcher Mitarbeiter den Job ausführt, aber er muss sicherstellen, dass ein Job nur einmal ausgeführt wird.
• Das Verarbeiten von Timing-Ereignissen aus dem Quartz-Scheduler kann von einer Message Driven Bean verarbeitet werden. Wenn ein Quarz- Trigger ausgelöst wird, wird die MDB automatisch aufgerufen. Da Java EE standardmäßig nichts über Quartz weiß, wäre ein JCA- Ressourcenadapter erforderlich, und die MDB würde mit einem Verweis darauf versehen.

Ausführung

EJBs werden in einem EJB-Container bereitgestellt, normalerweise auf einem Anwendungsserver . Die Spezifikation beschreibt, wie ein EJB mit seinem Container interagiert und wie Clientcode mit der Container / EJB-Kombination interagiert. Die von Anwendungen verwendeten EJB-Klassen sind im javax.ejb Paket enthalten. (Das javax.ejb.spi Paket ist eine Dienstanbieterschnittstelle, die nur von EJB-Containerimplementierungen verwendet wird.)

Clients von EJBs instanziieren diese Beans nicht direkt über den neuen Java-Operator, sondern müssen stattdessen eine Referenz über den EJB-Container erhalten. Diese Referenz ist normalerweise keine Referenz auf die Implementierungs-Bean selbst, sondern auf einen Proxy , der entweder die vom Client angeforderte lokale oder Remote-Geschäftsschnittstelle dynamisch implementiert oder einen Untertyp der tatsächlichen Bean dynamisch implementiert. Der Proxy kann dann direkt in die Schnittstelle oder Bean umgewandelt werden. Ein Client soll eine "Ansicht" auf dem EJB haben, und die lokale Schnittstelle, die Remote-Schnittstelle und der Bean-Typ selbst entsprechen jeweils der lokalen Ansicht, der Remote-Ansicht und der Ansicht ohne Schnittstelle.

Dieser Proxy wird benötigt, um dem EJB-Container die Möglichkeit zu geben , einer Bean transparente Querschnittsdienste ( AOP- ähnliche Dienste) wie Transaktionen, Sicherheit, Abfangen, Injektionen und Remoting bereitzustellen. Ein Client ruft beispielsweise eine Methode auf einem Proxy auf, die zuerst eine Transaktion mit Hilfe des EJB-Containers startet und dann die eigentliche Bean-Methode aufruft. Wenn die Bean-Methode zurückgegeben wird, beendet der Proxy die Transaktion (dh durch Festschreiben oder Durchführen eines Rollbacks) und überträgt die Kontrolle zurück an den Client.

Der EJB-Container ist dafür verantwortlich, dass der Client-Code über ausreichende Zugriffsrechte auf eine EJB verfügt. Sicherheitsaspekte können über Anmerkungen deklarativ auf eine EJB angewendet werden.

Transaktionen

EJB-Container müssen sowohl containerverwaltete ACID- Transaktionen als auch Bean-verwaltete Transaktionen unterstützen.

Container-Managed Transactions (CMT) sind standardmäßig für Aufrufe von Session Beans aktiv. Das heißt, es ist keine explizite Konfiguration erforderlich. Dieses Verhalten kann von der Bean über Anmerkungen deklarativ optimiert werden. Bei Bedarf kann eine solche Konfiguration später im Bereitstellungsdeskriptor überschrieben werden. Das Optimieren umfasst das Ausschalten von Transaktionen für die gesamte Bean oder bestimmte Methoden oder das Anfordern alternativer Strategien für die Weitergabe von Transaktionen und das Starten oder Beitreten einer Transaktion. Solche Strategien befassen sich hauptsächlich mit dem, was passieren soll, wenn eine Transaktion zum Zeitpunkt des Aufrufs der Bean bereits ausgeführt wird oder nicht. Folgende Varianten werden unterstützt:

Alternativ kann die Bean auch über eine Annotation deklarieren, dass sie Transaktionen programmgesteuert über die JTA- API verarbeiten möchte . Diese Betriebsart wird als Bean Managed Transactions (BMT) bezeichnet, da die Bean selbst die Transaktion anstelle des Containers abwickelt.

Veranstaltungen

JMS ( Java Message Service ) wird zum Senden von Nachrichten von Beans an Clients verwendet, damit Clients asynchrone Nachrichten von diesen Beans empfangen können. MDBs können verwendet werden, um Nachrichten von Clients mithilfe einer JMS- Warteschlange oder eines Themas asynchron zu empfangen .

Namens- und Verzeichnisdienste

Als Alternative zur Injektion können Clients eines EJB mithilfe der Java Naming and Directory Interface (JNDI) einen Verweis auf das Proxy-Objekt der Session Bean (den EJB-Stub ) erhalten . Diese Alternative kann in Fällen verwendet werden, in denen keine Injektion verfügbar ist, z. B. in nicht verwaltetem Code oder eigenständigen Remote-Java SE-Clients, oder wenn programmgesteuert bestimmt werden muss, welche Bean abgerufen werden soll.

JNDI-Namen für EJB-Session-Beans werden vom EJB-Container über das folgende Schema zugewiesen:

(Einträge in eckigen Klammern kennzeichnen optionale Teile)

Eine einzelne Bean kann durch einen beliebigen Namen erhalten werden, der den obigen Mustern entspricht, abhängig vom 'Standort' des Clients. Clients im selben Modul wie die erforderliche Bean können den Modulbereich und größere Bereiche verwenden, Clients in derselben Anwendung wie die erforderliche Bean können den App-Bereich und höher verwenden usw.

Beispielsweise könnte Code, der im selben Modul wie die CustomerService-Bean ausgeführt wird (wie in dem weiter oben in diesem Artikel gezeigten Beispiel angegeben) , den folgenden Code verwenden, um einen (lokalen) Verweis darauf zu erhalten:

CustomerServiceLocal customerService =
    (CustomerServiceLocal) new InitialContext().lookup("java:module/CustomerService");

Remoting / verteilte Ausführung

Für die Kommunikation mit einem Client, der in der Programmiersprache Java geschrieben ist, kann eine Session-Bean eine Remote-Ansicht über eine mit @ Remote kommentierte Schnittstelle verfügbar machen. Auf diese Weise können diese Beans von Clients in anderen JVMs aufgerufen werden, die sich möglicherweise selbst auf anderen (Remote-) Systemen befinden. Aus Sicht des EJB-Containers ist jeder Code in einer anderen JVM entfernt.

Stateless- und Singleton-Session-Beans können auch eine "Webdienst-Client-Ansicht" für die Remote-Kommunikation über WSDL und SOAP oder einfaches XML verfügbar machen . Dies folgt den JAX-RPC- und JAX-WS- Spezifikationen. JAX-RPC-Unterstützung wird jedoch für die zukünftige Entfernung vorgeschlagen. Um JAX-WS zu unterstützen, wird die Session-Bean mit der Annotation @WebService und mit Methoden versehen, die mit der Annotation @WebMethod remote verfügbar gemacht werden sollen.

Obwohl in der EJB-Spezifikation die Exposition in keiner Weise als RESTful-Webdienste erwähnt wird und diese Form der Kommunikation nicht explizit unterstützt wird, unterstützt die JAX-RS- Spezifikation EJB ausdrücklich. Gemäß der JAX-RS-Spezifikation können Stateless- und Singleton-Session-Beans über die Annotation @Path Root-Ressourcen sein, und EJB-Geschäftsmethoden können über die Annotationen @GET, @PUT, @POST und @DELETE Ressourcenmethoden zugeordnet werden. Dies gilt jedoch nicht als "Webdienst-Client-Ansicht", die ausschließlich für JAX-WS und JAX-RPC verwendet wird.

Die Kommunikation über Webdienste ist typisch für Clients, die nicht in der Programmiersprache Java geschrieben sind, aber auch praktisch für Java-Clients, die Probleme haben, den EJB-Server über eine Firewall zu erreichen. Darüber hinaus können Java-Clients webdienstbasierte Kommunikation verwenden, um die arkanen und schlecht definierten Anforderungen an die sogenannten "Client-Bibliotheken" zu umgehen. Eine Reihe von JAR-Dateien, die ein Java-Client in seinem Klassenpfad haben muss, um mit dem Remote-EJB-Server zu kommunizieren. Diese Client-Bibliotheken stehen möglicherweise in Konflikt mit Bibliotheken, über die der Client möglicherweise bereits verfügt (z. B. wenn der Client selbst auch ein vollständiger Java EE-Server ist), und ein solcher Konflikt wird als sehr schwer oder unmöglich zu lösen angesehen.

Erbe

Heimschnittstellen und erforderliche Geschäftsschnittstelle

Mit EJB 2.1 und früher hatte jeder EJB eine Java - Implementierung zur Verfügung zu stellen Klasse und zwei Java - Schnittstellen. Der EJB-Container hat Instanzen der Java-Implementierungsklasse erstellt, um die EJB-Implementierung bereitzustellen. Die Java-Schnittstellen wurden vom Client-Code der EJB verwendet.

Erforderlicher Bereitstellungsdeskriptor

Bei EJB 2.1 und früheren Versionen war für die EJB-Spezifikation ein Bereitstellungsdeskriptor erforderlich. Dies war erforderlich, um einen Mechanismus zu implementieren, mit dem EJBs unabhängig von der ausgewählten EJB-Plattform konsistent bereitgestellt werden konnten . Informationen darüber, wie die Bean bereitgestellt werden soll (z. B. der Name der Home- oder Remote-Schnittstelle, ob und wie die Bean in einer Datenbank gespeichert werden soll usw.), mussten im Bereitstellungsdeskriptor angegeben werden.

Der Bereitstellungsdeskriptor ist ein XML- Dokument mit einem Eintrag für jede zu implementierende EJB. Dieses XML-Dokument enthält die folgenden Informationen für jede EJB:

• Name der Home-Oberfläche
• Java-Klasse für die Bean (Geschäftsobjekt)
• Java-Schnittstelle für die Home-Oberfläche
• Java-Schnittstelle für das Geschäftsobjekt
• Permanenter Speicher (nur für Entity Beans)
• Sicherheitsrollen und Berechtigungen
• Stateful oder Stateless (für Session Beans)

Alte EJB-Container von vielen Anbietern erforderten mehr Bereitstellungsinformationen als die in der EJB-Spezifikation. Sie würden die zusätzlichen Informationen als separate XML-Dateien oder ein anderes Konfigurationsdateiformat benötigen. Ein Anbieter von EJB-Plattformen stellte im Allgemeinen seine eigenen Tools zur Verfügung, mit denen dieser Bereitstellungsdeskriptor gelesen und möglicherweise eine Reihe von Klassen generiert wurde, die die jetzt veralteten Home- und Remote-Schnittstellen implementieren.

Seit EJB 3.0 ( JSR 220 ) wird der XML-Deskriptor durch Java-Annotationen ersetzt, die in der Enterprise Bean-Implementierung (auf Quellenebene) festgelegt wurden. Es ist jedoch weiterhin möglich, anstelle (oder zusätzlich zu) den Annotationen einen XML-Deskriptor zu verwenden. Wenn sowohl ein XML-Deskriptor als auch Annotationen auf dasselbe Attribut in einer Enterprise Bean angewendet werden, überschreibt die XML-Definition die entsprechende Annotation auf Quellenebene, obwohl einige XML-Elemente auch additiv sein können (z. B. eine Aktivierungskonfigurations-Eigenschaft in XML mit a Ein anderer Name als der, der bereits über eine Annotation @ActivationConfigProperty definiert wurde, wird hinzugefügt, anstatt alle vorhandenen Eigenschaften zu ersetzen.

Containervarianten

Ab EJB 3.1 definiert die EJB-Spezifikation zwei Varianten des EJB-Containers. eine Vollversion und eine eingeschränkte Version. Die eingeschränkte Version entspricht einer geeigneten Teilmenge der Spezifikation namens EJB 3.1 Lite und ist Teil des Webprofils von Java EE 6 (das selbst eine Teilmenge der vollständigen Java EE 6-Spezifikation ist).

EJB 3.1 Lite schließt die Unterstützung für die folgenden Funktionen aus:

• Remote-Schnittstellen
• RMI-IIOP-Interoperabilität
• JAX-WS-Webdienstendpunkte
• EJB Timer Service (@Schedule, @Timeout)
• Asynchrone Session-Bean-Aufrufe (@Asynchronous)
• Nachrichtengesteuerte Bohnen

EJB 3.2 Lite schließt weniger Funktionen aus. Insbesondere werden @Asynchronous und @ Schedule / @ Timeout nicht mehr ausgeschlossen, aber für @Schedule wird das Attribut "persistent", das in vollem EJB 3.2 unterstützt wird, nicht unterstützt. Die vollständige Ausschlussliste für EJB 3.2 Lite lautet:

• Remote-Schnittstellen
• RMI-IIOP-Interoperabilität
• JAX-WS-Webdienstendpunkte
• Persistente Timer (Attribut "persistent" in @Schedule)
• Nachrichtengesteuerte Bohnen

Versionsgeschichte

EJB 4.0, endgültige Veröffentlichung (2020-05-22)

Jakarta Enterprise Beans 4.0 war als Teil von Jakarta EE 9 eine Tool-Version, mit der hauptsächlich API-Paketnamen vom Top-Level- javax.ejb Paket in das Top-Level- jakarta.ejb Paket verschoben wurden .

Weitere Änderungen betrafen das Entfernen veralteter APIs, die für die Umstellung auf das neue Top-Level-Paket sinnlos waren, und das Entfernen von Funktionen, die von Funktionen abhingen, die aus Java oder anderen Bereichen in Jakarta EE 9 entfernt wurden. Die folgenden APIs wurden entfernt:

• Methoden, die darauf basieren, java.security.Identity welche aus Java 14 entfernt wurden.
• Methoden, die sich auf Jakarta XML RPC stützen , um das Entfernen von XML RPC von der Jakarta EE 9-Plattform widerzuspiegeln.
• veraltete EJBContext.getEnvironment() Methode.
• "Unterstützung für verteilte Interoperabilität", um die Entfernung von CORBA aus Java 11 und der Jakarta EE 9-Plattform widerzuspiegeln.

Weitere geringfügige Änderungen umfassen das Markieren der Enterprise Beans 2.x-API-Gruppe als "Optional" und das Schedule Wiederholbarmachen der Anmerkung.

EJB 3.2.6, endgültige Veröffentlichung (23.08.2019)

Jakarta Enterprise Beans 3.2 als Teil von Jakarta EE 8 und obwohl immer noch die Abkürzung "EJB" verwendet wird, wurde dieser Satz von APIs von der Eclipse Foundation offiziell in "Jakarta Enterprise Beans" umbenannt, um nicht auf Oracle "Java" zuzugreifen "Marke.

EJB 3.2, endgültige Veröffentlichung (28.05.2013)

JSR 345 . Enterprise JavaBeans 3.2 war eine relativ kleine Version, die hauptsächlich Erläuterungen zu Spezifikationen enthielt und einige Einschränkungen aufhob, die durch die Spezifikation auferlegt wurden, aber im Laufe der Zeit keinen wirklichen Zweck zu erfüllen schienen. Es wurde auch verlangt, dass einige vorhandene vollständige EJB-Funktionen in EJB 3 Lite enthalten sind, und die Funktionalität, die in EJB 3.1 beschnitten werden sollte, wurde tatsächlich beschnitten (optional gemacht).

Die folgenden Funktionen wurden hinzugefügt:

• Die Passivierung einer Stateful Session Bean kann über das Attribut @Stateful Annotation deaktiviert werden (passivationCapable = false).
• TimerService kann alle aktiven Timer im selben EJB-Modul abrufen (konnte zuvor nur Timer für die Bean abrufen, in der der TimerService aufgerufen wurde).
• Lebenszyklusmethoden (z. B. @PostConstruct) können für Stateful Session Beans unter Verwendung der vorhandenen Annotation @TransactionAttribute transaktional sein
• Autocloseable-Schnittstelle durch einbettbaren Container implementiert

EJB 3.1, endgültige Veröffentlichung (10.12.2009)

JSR 318 . Der Zweck der Enterprise JavaBeans 3.1-Spezifikation besteht darin, die EJB-Architektur weiter zu vereinfachen, indem ihre Komplexität aus Sicht des Entwicklers reduziert und gleichzeitig neue Funktionen hinzugefügt werden, um den Anforderungen der Community gerecht zu werden:

• Lokale Ansicht ohne Schnittstelle (Ansicht ohne Schnittstelle)
• .war Verpackung von EJB-Komponenten
• EJB Lite: Definition einer Teilmenge von EJB
• Tragbare globale EJB- JNDI- Namen
• Singletons (Singleton Session Beans)
• Anwendungsinitialisierungs- und Herunterfahrereignisse
• Verbesserungen des EJB-Timer-Dienstes
• Einfache Asynchronität (@Asynchron für Session Beans)

EJB 3.0, endgültige Veröffentlichung (2006-05-11)

JSR 220 - Wichtige Änderungen : Diese Version hat das Schreiben von EJBs mithilfe von "Anmerkungen" anstelle der in Version 2.x verwendeten komplexen "Bereitstellungsdeskriptoren" erheblich vereinfacht. Die Verwendung von Heim- und Remote-Schnittstellen sowie der Datei ejb-jar.xml war in dieser Version ebenfalls nicht mehr erforderlich, da sie durch eine Geschäftsschnittstelle und eine Bean ersetzt wurde, die die Schnittstelle implementiert.

EJB 2.1, endgültige Veröffentlichung (24.11.2003)

JSR 153 - Wichtige Änderungen :

• Webdienstunterstützung (neu): Statuslose Session Beans können über SOAP / HTTP aufgerufen werden . Außerdem kann ein EJB mithilfe der neuen Dienstreferenz problemlos auf einen Webdienst zugreifen.
• EJB-Timer-Service (neu): Ereignisbasierter Mechanismus zum Aufrufen von EJBs zu bestimmten Zeiten.
• Nachrichtengesteuerte Beans akzeptieren Nachrichten aus anderen Quellen als JMS .
• Nachrichtenziele (dieselbe Idee wie EJB-Referenzen, Ressourcenreferenzen usw.) wurden hinzugefügt.
• Ergänzungen der EJB-Abfragesprache (EJB-QL): ORDER BY, AVG, MIN, MAX, SUM, COUNT und MOD.
• Das XML-Schema wird zum Angeben von Bereitstellungsdeskriptoren verwendet und ersetzt DTDs

EJB 2.0, endgültige Veröffentlichung (22.08.2001)

JSR 19 - Wesentliche Änderungen : Allgemeine Ziele :

• Die Standardkomponentenarchitektur zum Erstellen verteilter objektorientierter Geschäftsanwendungen in Java .
• Ermöglichen Sie das Erstellen verteilter Anwendungen, indem Sie Komponenten kombinieren, die mit Tools verschiedener Hersteller entwickelt wurden .
• Vereinfachen Sie das Schreiben von (Unternehmens-) Anwendungen: Anwendungsentwickler müssen die Transaktions- und Statusverwaltungsdetails auf niedriger Ebene, Multithreading, Verbindungspooling und andere komplexe APIs auf niedriger Ebene nicht verstehen.
• Folgt der Philosophie "Einmal schreiben, überall ausführen" von Java . Eine Enterprise-Bean kann einmal entwickelt und dann ohne Neukompilierung oder Änderung des Quellcodes auf mehreren Plattformen bereitgestellt werden.
• Behandeln Sie die Entwicklungs-, Bereitstellungs- und Laufzeitaspekte des Lebenszyklus einer Unternehmensanwendung.
• Definieren Sie die Verträge, mit denen Tools mehrerer Anbieter Komponenten entwickeln und bereitstellen können, die zur Laufzeit zusammenarbeiten können.
• Kompatibel mit vorhandenen Serverplattformen sein. Anbieter können ihre vorhandenen Produkte erweitern, um EJBs zu unterstützen.
• Kompatibel mit anderen Java- APIs sein.
• Bieten Sie Interoperabilität zwischen Enterprise Beans und Java EE-Komponenten sowie Nicht-Java-Programmiersprachenanwendungen.
• Kompatibel mit den CORBA-Protokollen (RMI-IIOP) sein.

EJB 1.1, endgültige Veröffentlichung (1999-12-17)

Wichtige Änderungen :

• XML-Bereitstellungsdeskriptoren
• Standard-JNDI-Kontexte
• RMI über IIOP
• Sicherheit - rollengesteuert, nicht methodengesteuert
• Entity Bean-Unterstützung - obligatorisch, nicht optional

Ziele für Release 1.1:

• Bessere Unterstützung für das Zusammenstellen und Bereitstellen von Anwendungen.
• Geben Sie die Verantwortlichkeiten der einzelnen EJB-Rollen genauer an.

EJB 1.0 (1998-03-24)

Auf der JavaOne 1998 , der dritten Java-Entwicklerkonferenz von Sun (24. bis 27. März), angekündigt. Ziele für Release 1.0:

• Definiert die unterschiedlichen "EJB-Rollen", die von der Komponentenarchitektur übernommen werden.
• Definierte die Client-Ansicht von Enterprise Beans.
• Definierte die Ansicht des Enterprise Bean-Entwicklers.
• Definierte die Verantwortlichkeiten eines EJB-Container-Anbieters und eines Server-Anbieters. Zusammen bilden diese ein System, das die Bereitstellung und Ausführung von Enterprise Beans unterstützt.

Verweise

Externe Links

• Offizielle Website
• Java EE 8 API Javadocs
• EJB 3.0 API Javadocs
• Die EJB 3.0-Spezifikation
• Suns EJB 3.0 Tutorial
• EJB (3.0) Glossar
• EJB FAQ
• JSR 345 (EJB 3.2)
• JSR 318 (EJB 3.1)
• JSR 220 (EJB 3.0)
• JSR 153 (EJB 2.1)
• JSR 19 (EJB 2.0)
• "Arbeiten mit nachrichtengesteuerten Bohnen" von EJB3 in Aktion, zweite Ausgabe
• Der Client ruft eine EJB auf