Was ist EJB? Die Entwicklung von Enterprise JavaBeans

Enterprise JavaBeans (EJB) ist eine Spezifikation für die Entwicklung umfangreicher, verteilter Geschäftsanwendungen auf der Java-Plattform. EJB 1.0 wurde 1998 veröffentlicht. Die aktuellste Version, EJB 3.2.3, wurde zur Aufnahme in Jakarta EE übernommen, wo sie in Jakarta Enterprise Beans umbenannt wird.

EJB-Architektur

Die EJB-Architektur besteht aus drei Hauptkomponenten: Enterprise Beans (EJBs), dem EJB-Container und dem Java-Anwendungsserver. EJBs werden in einem EJB-Container ausgeführt, und der EJB-Container wird in einem Java-Anwendungsserver ausgeführt.

Es gibt zwei Arten von EJB - Session Beans und Message Driven Beans:

  • Session Beans werden vom Client aufgerufen und stellen dem Client Unternehmensfunktionen wie Transaktionen und Ressourcenverwaltung programmgesteuert zur Verfügung.
  • Nachrichtengesteuerte Beans kapseln und liefern auch Unternehmensfunktionen, sind jedoch asynchron und ereignisgesteuert. Nachrichtengesteuerte Beans hören zu und reagieren auf Ereignisse und können vom Client nicht aufgerufen werden.

Nach der Verwendung zur Bereitstellung der Persistenz im EJB-System wurden Entity-Beans durch die Java-Persistenz-API ersetzt. Lesen Sie weiter, um mehr über Session Beans und Message Driven Beans zu erfahren.

EJB vs JavaBeans

Enterprise JavaBeans war das erste komponentenbasierte Entwicklungsmodell für Java EE. EJB ähnelt JavaBeans, da es komponentenbasiert ist, aber hier endet die Ähnlichkeit:

  • Eine JavaBean ist eine Java-Klasse, die mehrere Objekte kapselt und bestimmten Konventionen entspricht. JavaBeans werden hauptsächlich für die clientseitige Entwicklung verwendet.
  • Eine Enterprise Bean (EJB) ist eine Java-Klasse mit bestimmten serverseitigen Funktionen. Enterprise Beans werden in großen Geschäftsanwendungen und -systemen verwendet.

Session Beans

Eine Session-Bean ist die allgemeinste Art von Enterprise-Bean, die einen Teil der Geschäftsfunktionalität darstellt, die von einem Client aufgerufen werden kann. Der Client kann in diesem Fall eine andere Klasse in der lokalen JVM oder ein Remote-Aufruf sein.

Der EJB-Container verwaltet den Session-Bean-Lebenszyklus, der durch den Status der Bean bestimmt wird:

  • Stateless Session Beans ähneln dem Anforderungsbereich in der Java Servlet API. Stateless Session Beans enthalten einen Teil der aufrufbaren Funktionen, sind aber ansonsten zustandslos.
  • Stateful Session Beans sind nur einem Client zugeordnet und werden an die laufende Sitzung dieses Clients angehängt. Stateful Session Beans funktionieren ähnlich wie der Sitzungsbereich in der Servlet-API.
  • Singleton-Beans ähneln dem Anwendungsbereich in der Servlet-API. Eine Singleton-Session-Bean ist für jeden Client nur einmal vorhanden.

Fadensicherheit mit Session Beans

Auf eine Stateful Session Bean kann jeweils nur von einem Client zugegriffen werden, sodass die Thread-Sicherheit gewährleistet ist, wenn Sie mit dieser Art von Bean arbeiten. Statuslose Session Beans und Singleton Beans sind flexibler und ermöglichen gleichzeitige Verbindungen, die vom Entwickler verwaltet werden müssen. Sie sind für die Sicherheit der Fäden verantwortlich, wenn Sie mit diesen Bohnensorten arbeiten.

Nachrichtengesteuerte Bohnen

Message-Driven Beans (MDBs) werden über JMS-Nachrichten (Java Message Service) aufgerufen. JMS funktioniert wie ein verteiltes Befehlsmuster, bei dem die nachrichtengesteuerte Bean als Listener für den Befehl fungiert. Wenn eine Nachricht in einem Thema oder einer Warteschlange eintrifft, wird die nachrichtengesteuerte Bean aufgerufen, die dieses Thema abhört.

Nachrichtengesteuerte Beans werden nicht so häufig verwendet wie Session-Beans, sind jedoch leistungsstark. Da sie asynchron und ereignisgesteuert sind, sind sie besonders nützlich für Jobs mit langer Laufzeit, bei denen es wichtig ist, Ressourcen zu schonen.

Die einfachste Architektur würde aus der EJB-Anwendung und ihrem Container und Server bestehen, die mit dem Nachrichtendienst koordinieren, der die MDBs verarbeitet. In der Produktion würde Ihre Architektur wahrscheinlich eine dritte Komponente enthalten, die dem Verbrauch der Bohnen gewidmet ist. In der Entwicklung könnten alle diese Komponenten auf demselben lokalen Computer ausgeführt werden.

Abbildung 1 zeigt eine typische ereignisgesteuerte Architektur mit nachrichtengesteuerten Beans.

Matthew Tyson

Das Arbeiten mit nachrichtengesteuerten Beans ist aufwändiger als das Verwenden von Session Beans. In einer ereignisgesteuerten Umgebung benötigen Sie normalerweise einen Nachrichtenbroker wie ActiveMQ.

Während Session Beans einfacher sind und daher in EJB häufiger verwendet werden, sind ereignisgesteuerte Architekturen insbesondere mit der Explosion von Microservices populär geworden. 

EJB-Anmerkungen

Das Definieren und Konsumieren von Enterprise-Beans war für viele Entwickler ein Knackpunkt bis EJB 3.0, das Anmerkungen zur EJB-Spezifikation einführte. Mit Anmerkungen ist es sehr einfach, Enterprise-Beans für eine Vielzahl von Funktionen in Java EE zu konfigurieren. Lesen Sie weiter, um mit EJB-Anmerkungen zu beginnen.

@Stateless: Definieren Sie eine zustandslose Session-Bean

Um eine Klasse als zustandslose Session-Bean zu bestimmen, verwenden Sie die javax.ejb.StatelessAnmerkung, wie in Listing 1 gezeigt.

Listing 1. Beispiel für eine Annotation @Stateless

 import javax.ejb.Stateless; @Stateless public class MyStatelessBean { public String getGreeting() { return "Hello JavaWorld."; } } 

Diese zustandslose Bean enthält eine einfache Signatur, die keine Argumente akzeptiert und eine Zeichenfolge zurückgibt. Lassen Sie sich jedoch nicht von der Einfachheit täuschen: Diese Bean kann alles tun, was Sie benötigen, einschließlich der Interaktion mit anderen Beans, Diensten oder der Datenschicht Ihrer Anwendung.

@EJB: Verbrauchen Sie eine zustandslose Session-Bean

Sobald Sie eine Session Bean definiert haben, ist ihre Verwendung so einfach:

Listing 2. Beispiel für eine @ EJB-Anmerkung

 public class MyServlet extends HttpServlet { @EJB MyStatelessBean myEjb; public void doGet(HttpServletRequest request, HttpServletResponse response) { response.getWriter().write("EJB Says " + testStatelessEjb.getGreeting()); } } 

Here, we inject the stateless bean into a servlet, and then it's available for use. Notice how the bean is identified under the @EJB annotation. The "stateless" designation tells us this bean will not track the client. Because it's stateless, we also know this bean is subject to threading if it does any work outside the invoked method.

@Remote: Define a remote EJB interface

In the above examples, I assumed the EJB and EJB client were running in the same JVM. If the enterprise bean and its client are running in separate JVMs, then the EJB must define a @Remote interface. In this case, it's up to you to define and implement the interface, as shown in Listing 3.

Listing 3. @Remote annotation example

 @Remote public interface MyStatelessEjbRemote { String sayHello(String name); } 

The remote interface is sent to the client to invoke. Calls to it will then be fulfilled by the EJB's server-side implementation. The MyStatelessBean example in Listing 4 implements the remote interface.

Listing 4. Implementing a remote interface

 public class MyStatelessBean implements MyStatelessEjbRemote{ ... } 

A remote interface is implemented just like a normal class implementing an interface. As the consumer of a remote EJB, the client application must be able to access the class definition for the remote interface. You can package the class definition for the remote interface as a dependency JAR.

Local vs remote interface

While it's important to know how to implement a remote interface, in practice it's more common to use a local interface. The local interface is used by default and works whenever the EJB is invoked within the same JVM context. Using the remote interface comes into play when the application is distributed across multiple JVMs.

Stateful sessions beans and singleton beans

The process for defining and consuming stateful @Session beans and @Singleton beans is the same as what you've seen for @Stateless beans. Remember the semantics:

  • Multiple session beans can be instantiated and used for the same client.
  • A singleton bean will exist only once for the entire application.

Thread safety and scheduling with singletons

Thread safety is built in when you're working with session beans, but both stateless and singleton beans can be accessed concurrently by multiple clients. Developers are responsible for thread safety when implementing these types of beans.

Singleton beans offer some support for thread safety via the @Lock annotation. You can use the @Lock annotation on singleton bean methods to set read/write privileges for each method. The two options are @Lock(LockType.READ) or @Lock(LockType.WRITE), which is the default.

Another useful feature of singleton beans is the ability to schedule tasks in a simple way, using the @Schedule annotation. Listing 5 shows how to schedule a task daily at noon.

Listing 5. @Schedule annotation example

 @Singleton public class MySchedulerBean { @Schedule(hour = "12") void doIt() { System.out.println("Hello at Noon!"); } } 

CDI vs EJB

CDI, or Context and Dependency Injection is a newer enterprise specification that some developers have proposed could replace EJB.

At a high level, CDI offers a general-purpose component framework, while EJB stands out for its richly featured, individual components. Whereas CDI uses dependency injection to define and reference any software component, EJB components are more formally defined, with each offering a specific set of capabilities out of the box. Both specs are planned for future development as part of Jakarta EE, where the question of whether CDI should replace EJB will eventually be resolved.

Conclusion

Enterprise JavaBeans war die erste Spezifikation, die eine einfache Möglichkeit zur Kapselung und Wiederverwendung von Geschäftslogik in Enterprise Java-Anwendungen bot. EJB ist heute ein schlankes, auf Anmerkungen basierendes Framework, mit dem Sie sofort auf eine Vielzahl von Unternehmensfunktionen zugreifen können. Ziehen Sie EJB in Betracht, wenn Sie das nächste Mal aufgefordert werden, eine verteilte, skalierbare Geschäftsanwendung schnell hochzufahren. Sie könnten angenehm überrascht sein.

Diese Geschichte "Was ist EJB? Die Entwicklung von Enterprise JavaBeans" wurde ursprünglich von JavaWorld veröffentlicht.