Vad är EJB? Utvecklingen av Enterprise JavaBeans

Enterprise JavaBeans (EJB) är en specifikation för att utveckla storskaliga, distribuerade affärsapplikationer på Java-plattformen. EJB 1.0 släpptes 1998. Den senaste versionen, EJB 3.2.3, har antagits för inkludering i Jakarta EE, där den kommer att döpas om till Jakarta Enterprise Beans.

EJB-arkitektur

EJB-arkitekturen består av tre huvudkomponenter: företagsbönor (EJB), EJB-behållaren och Java-applikationsservern. EJB körs inuti en EJB-behållare och EJB-behållaren körs inuti en Java-applikationsserver.

Det finns två typer av EJB - sessionbönor och meddelandestyrda bönor:

  • Sessionsbönor åberopas av klienten och gör företagsfunktionalitet såsom transaktioner och resurshantering tillgänglig för klienten programmatiskt.
  • Meddelandestyrda bönor inkapslar och levererar även företagsfunktionalitet, men de är asynkrona och händelsestyrda. Meddelandestyrda bönor lyssnar och svarar på händelser och kan inte åberopas av klienten.

En gång används för att ge uthållighet i EJB-systemet har enhetsbönor ersatts av Java Persistence API. Fortsätt läsa för att lära dig mer om sessionbönor och meddelandestyrda bönor.

EJB vs JavaBeans

Enterprise JavaBeans var den första komponentbaserade utvecklingsmodellen för Java EE. EJB liknar JavaBeans i att vara komponentbaserad, men det är där likheten slutar:

  • En JavaBean är en Java-klass som inkapslar flera objekt och överensstämmer med vissa konventioner. JavaBeans används främst för utveckling av klientsidan.
  • En företagsböna (EJB) är en Java-klass genomsyrad av specifika funktioner på serversidan. Enterprise bönor används i storskaliga affärsapplikationer och system.

Sessionsbönor

En sessionböna är den mest generiska typen av företagsbönor, vilket representerar en bit av affärsfunktionalitet som kan anropas av en klient. Klienten kan i det här fallet vara en annan klass i den lokala JVM eller ett fjärransamtal.

EJB-behållaren hanterar sessionens böns livscykel, som bestäms av bönans tillstånd:

  • Stateless session beans liknar begäran i Java Servlet API. Statslösa sessionbönor innehåller en bit av samtalbar funktionalitet men är annars statslösa.
  • Stateful session bönor är endast associerade med en klient och bifogas klientens pågående session. Stateful session beans fungerar på samma sätt som sessionsomfånget i Servlet API.
  • Singleton bönor liknar applikationsomfånget i Servlet API. En singleton session bean finns bara en gång för varje klient.

Trådsäkerhet med sessionbönor

En stativ sessionböna kan bara nås av en klient åt gången, så trådsäkerhet garanteras när du arbetar med den här typen av bönor. Stateless session bönor och singleton bönor är mer flexibla, vilket möjliggör samtidiga anslutningar, som måste hanteras av utvecklaren. Du ansvarar för trådsäkerheten när du arbetar med dessa typer av bönor.

Meddelandestyrda bönor

Meddelandestyrda bönor (MDB) anropas via JMS-meddelanden (Java Message Service). JMS fungerar som ett distribuerat kommandomönster, där den meddelandestyrda bönan fungerar som lyssnare för kommandot. När ett meddelande anländer till ett ämne eller kö anropas den meddelandestyrda bönan som lyssnar på det ämnet.

Meddelandestyrda bönor används inte så ofta som sessionbönor, men de är kraftfulla. Eftersom de är asynkrona och händelsestyrda är de särskilt användbara för långvariga jobb där det är viktigt att spara resurser.

Den enklaste arkitekturen skulle bestå av EJB-applikationen och dess behållare och server, som samordnar med meddelandetjänsten som behandlar MDB: erna. I produktionen skulle din arkitektur sannolikt innehålla en tredje komponent som är avsedd att konsumera bönorna. Under utveckling kan alla dessa komponenter köras på samma lokala maskin.

Figur 1 visar en typisk händelsestyrd arkitektur med meddelandestyrda bönor.

Matthew Tyson

Att arbeta med meddelandestyrda bönor är mer involverat än att använda sessionbönor. I en händelsestyrd miljö behöver du vanligtvis en meddelandemäklare som ActiveMQ.

Medan sessionsbönor är enklare och därmed vanligare i EJB har händelsestyrda arkitekturer blivit populära, särskilt med explosionen av mikrotjänster. 

EJB-anteckningar

Att definiera och konsumera företagsbönor var en fast punkt för många utvecklare fram till EJB 3.0, som introducerade anteckningar till EJB-specifikationen. Annoteringar gör det mycket enkelt att konfigurera företagsbönor för ett brett spektrum av funktioner som finns i Java EE. Fortsätt läsa för att komma igång med EJB-anteckningar.

@Stateless: Definiera en statslös sessionböna

För att utse en klass som en statslös sessionböna använder du javax.ejb.Statelesskommentaren, som visas i Listing 1.

Listing 1. @Stateless annotation example

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

Denna statslösa böna innehåller en enkel signatur som inte tar några argument och returnerar en sträng. Låt inte enkelheten lura dig, men den här bönan kan göra allt du behöver, inklusive interaktion med andra bönor, tjänster eller applikationens datalager.

@EJB: Konsumera en statslös sessionböna

När du väl har definierat en sessionböna är det så enkelt att använda den:

Listing 2. @EJB-annoteringsexempel

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

Här injicerar vi den statslösa bönan i en servlet, och sedan är den tillgänglig för användning. Lägg märke till hur bönan identifieras under @EJBanteckningen. Den "statslösa" beteckningen säger att den här bönan inte spårar klienten. Eftersom den är statslös, vet vi också att denna böna är föremål för trådning om den utför något arbete utanför den åberopade metoden.

@Remote: Definiera ett fjärranslutet EJB-gränssnitt

I ovanstående exempel antog jag att EJB- och EJB-klienten kördes i samma JVM. Om företagets bönor och dess klient körs i separata JVM: er måste EJB definiera ett @Remotegränssnitt. I det här fallet är det upp till dig att definiera och implementera gränssnittet, som visas i Listing 3.

Listing 3. @Remote annotationsexempel

 @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 var den första specifikationen som erbjuder ett enkelt sätt att inkapsla och återanvända affärslogik i företagets Java-applikationer. EJB idag är långt ifrån den gamla tunga behemten i dag ett magert, kommentarbaserat ramverk som låter dig få tillgång till ett brett utbud av företagsfunktionalitet, direkt ur lådan. Tänk på EJB nästa gång du blir ombedd att snabbt öka en distribuerad, skalbar affärsapplikation. Du kan bli positivt överraskad.

Denna berättelse, "Vad är EJB? Utvecklingen av Enterprise JavaBeans" publicerades ursprungligen av JavaWorld.