Wat is EJB? De evolutie van Enterprise JavaBeans

Enterprise JavaBeans (EJB) is een specificatie voor het ontwikkelen van grootschalige, gedistribueerde bedrijfstoepassingen op het Java-platform. EJB 1.0 werd uitgebracht in 1998. De meest recente versie, EJB 3.2.3, is goedgekeurd voor opname in Jakarta EE, waar het de naam Jakarta Enterprise Beans krijgt.

EJB-architectuur

De EJB-architectuur bestaat uit drie hoofdcomponenten: Enterprise Beans (EJB's), de EJB-container en de Java-applicatieserver. EJB's worden uitgevoerd in een EJB-container en de EJB-container wordt in een Java-applicatieserver uitgevoerd.

Er zijn twee soorten EJB - sessiebonen en berichtgestuurde bonen:

  • Sessionbeans worden aangeroepen door de client en maken bedrijfsfunctionaliteit zoals transacties en resourcebeheer programmatisch beschikbaar voor de client.
  • Berichtgestuurde bonen omvatten ook bedrijfsfunctionaliteit en leveren deze, maar ze zijn asynchroon en gebeurtenisgestuurd. Berichtgestuurde bonen luisteren en reageren op gebeurtenissen en kunnen niet worden aangeroepen door de client.

Eenmaal gebruikt om persistentie in het EJB-systeem te bieden, zijn entity beans vervangen door de Java Persistence API. Blijf lezen voor meer informatie over sessiebonen en berichtgestuurde bonen.

EJB versus JavaBeans

Enterprise JavaBeans was het eerste op componenten gebaseerde ontwikkelingsmodel voor Java EE. EJB is vergelijkbaar met JavaBeans omdat het op componenten is gebaseerd, maar daar houdt de overeenkomst op:

  • Een JavaBean is een Java-klasse die meerdere objecten omvat en voldoet aan bepaalde conventies. JavaBeans worden voornamelijk gebruikt voor ontwikkeling aan de clientzijde.
  • Een enterprise bean (EJB) is een Java-klasse die doordrenkt is met specifieke server-side-mogelijkheden. Enterprise-bonen worden gebruikt in grootschalige bedrijfstoepassingen en -systemen.

Sessie bonen

Een sessionbean is het meest algemene type enterprise-bean en vertegenwoordigt een stuk bedrijfsfunctionaliteit dat door een klant kan worden aangeroepen. De client kan in dit geval een andere klasse in de lokale JVM zijn of een externe oproep.

De EJB-container beheert de levenscyclus van de sessieboon, die wordt bepaald door de staat van de bonen:

  • Stateless session beans zijn vergelijkbaar met het aanvraagbereik in de Java Servlet API. Staatloze sessiebonen bevatten een brok aan opvraagbare functionaliteit, maar zijn verder staatloos.
  • Stateful sessiebeans zijn slechts aan één client gekoppeld en hechten aan de lopende sessie van die client. Stateful session beans werken op dezelfde manier als het sessiebereik in de Servlet API.
  • Singleton Beans zijn vergelijkbaar met het toepassingsbereik in de Servlet API. Een singleton session-bean bestaat slechts één keer voor elke client.

Rijg de veiligheid in met bonen

Een stateful sessionbean kan slechts door één client tegelijk worden geopend, dus de veiligheid van de draad is gegarandeerd wanneer u met dit type bean werkt. Staatloze sessiebonen en singletonbonen zijn flexibeler, waardoor gelijktijdige verbindingen mogelijk zijn, die door de ontwikkelaar moeten worden beheerd. U bent verantwoordelijk voor de draadveiligheid wanneer u met deze soorten bonen werkt.

Berichtgestuurde bonen

Message-driven Beans (MDB's) worden aangeroepen via JMS-berichten (Java Message Service). JMS werkt als een gedistribueerd opdrachtpatroon, waarbij de berichtgestuurde bean fungeert als luisteraar voor de opdracht. Wanneer een bericht over een onderwerp of wachtrij binnenkomt, wordt de berichtgestuurde bean die naar dat onderwerp luistert aangeroepen.

Berichtgestuurde bonen worden niet zo vaak gebruikt als sessiebonen, maar ze zijn krachtig. Omdat ze asynchroon en gebeurtenisgestuurd zijn, zijn ze vooral handig voor langlopende taken waarbij het belangrijk is om bronnen te sparen.

De eenvoudigste architectuur zou bestaan ​​uit de EJB-applicatie en zijn container en server, die coördineren met de berichtenservice die de MDB's verwerkt. Tijdens de productie zou uw architectuur waarschijnlijk een derde component bevatten die is bedoeld om de bonen te consumeren. Bij de ontwikkeling konden al deze componenten op dezelfde lokale computer worden uitgevoerd.

Figuur 1 toont een typische gebeurtenisgestuurde architectuur met berichtgestuurde bonen.

Matthew Tyson

Het werken met berichtgestuurde bonen is ingewikkelder dan het gebruik van sessiebonen. In een event-gestuurde omgeving heb je doorgaans een message broker zoals ActiveMQ nodig.

Hoewel sessiebonen eenvoudiger zijn en dus vaker worden gebruikt in EJB, zijn gebeurtenisgestuurde architecturen populair geworden, vooral met de explosie van microservices. 

EJB-annotaties

Het definiëren en consumeren van bedrijfsbonen was een knelpunt voor veel ontwikkelaars tot EJB 3.0, dat annotaties introduceerde bij de EJB-specificatie. Annotaties maken het heel eenvoudig om enterprise-beans te configureren voor een breed scala aan functies die in Java EE worden aangetroffen. Blijf lezen om aan de slag te gaan met EJB-annotaties.

@Stateless: definieer een staatloze sessieboon

Om een ​​klasse aan te duiden als een stateless session bean, gebruikt u de javax.ejb.Statelessannotatie, zoals weergegeven in Listing 1.

Listing 1. @Stateless annotatievoorbeeld

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

Deze staatloze bean bevat een eenvoudige handtekening die geen argumenten accepteert en een string retourneert. Laat u echter niet misleiden door eenvoud: deze bean kan alles doen wat u nodig heeft, inclusief interactie met andere bonen, services of de gegevenslaag van uw toepassing.

@EJB: Consumeer een staatloze sessieboon

Als je eenmaal een sessieboon hebt gedefinieerd, is het gebruik ervan zo eenvoudig:

Listing 2. @EJB annotatievoorbeeld

 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 was de eerste specificatie die een gemakkelijke manier bood om bedrijfslogica in Java-applicaties voor ondernemingen in te kapselen en opnieuw te gebruiken. Verre van de zwaargewicht kolos van weleer, is EJB vandaag een slank, op annotaties gebaseerd raamwerk waarmee u direct toegang krijgt tot een breed scala aan bedrijfsfunctionaliteit. Overweeg EJB de volgende keer dat u wordt gevraagd om snel een gedistribueerde, schaalbare bedrijfsapplicatie op te voeren. U zult misschien aangenaam verrast zijn.

Dit verhaal, "Wat is EJB? De evolutie van Enterprise JavaBeans" werd oorspronkelijk gepubliceerd door JavaWorld.