Programmering

Hva er EJB? Utviklingen av Enterprise JavaBeans

Enterprise JavaBeans (EJB) er en spesifikasjon for utvikling av store, distribuerte forretningsapplikasjoner på Java-plattformen. EJB 1.0 ble utgitt i 1998. Den siste utgivelsen, EJB 3.2.3, er vedtatt for inkludering i Jakarta EE, hvor den vil bli omdøpt til Jakarta Enterprise Beans.

EJB arkitektur

EJB-arkitekturen består av tre hovedkomponenter: enterprise beans (EJBs), EJB-containeren og Java-applikasjonsserveren. EJB-er kjører inne i en EJB-container, og EJB-containeren kjører inne i en Java-applikasjonsserver.

Det er to typer EJB - sesjonsbønner og meldingsdrevne bønner:

  • Sesjonsbønner påkalles av klienten og gjør bedriftsfunksjonalitet som transaksjoner og ressursadministrasjon tilgjengelig for klienten programmatisk.
  • Meldingsdrevne bønner også kapsle inn og levere bedriftsfunksjonalitet, men de er asynkrone og hendelsesdrevne. Meldingsdrevne bønner lytter og svarer på hendelser, og kan ikke påberopes av klienten.

En gang brukt til å gi utholdenhet i EJB-systemet, har enhetsbønner blitt erstattet av Java Persistence API. Fortsett å lese for å lære mer om øktbønner og meldingsdrevne bønner.

EJB vs JavaBeans

Enterprise JavaBeans var den første komponentbaserte utviklingsmodellen for Java EE. EJB ligner JavaBeans i å være komponentbasert, men det er der likheten ender:

  • EN JavaBean er en Java-klasse som innkapsler flere objekter og samsvarer med visse konvensjoner. JavaBeans brukes hovedsakelig for utvikling av klientsiden.
  • An enterprise bønne (EJB) er en Java-klasse gjennomsyret med spesifikke funksjoner på serversiden. Bedriftsbønner brukes i store applikasjoner og systemer.

Sesjonsbønner

EN øktbønne er den mest generiske typen bedriftsbønne, som representerer en del forretningsfunksjonalitet som kan kalles av en klient. Klienten i dette tilfellet kan være en annen klasse i den lokale JVM eller en ekstern samtale.

EJB-beholderen administrerer økt bønns livssyklus, som bestemmes av bønnens tilstand:

  • Statsløse sesjonsbønner ligner forespørselsomfanget i Java Servlet API. Statsløse sesjonsbønner inneholder en bit av funksjonalitet som kan kalles, men er ellers statsløse.
  • Stateful session beans er bare tilknyttet en klient, og knytter seg til den klientens pågående økt. Stateful session beans fungerer på samme måte som sesjonsomfanget i Servlet API.
  • Singleton bønner ligner applikasjonsomfanget i Servlet API. En singleton øktbønne eksisterer bare en gang for hver klient.

Trådsikkerhet med sesjonsbønner

En stateful session bønne kan bare nås av en klient om gangen, så trådsikkerhet er garantert når du jobber med denne typen bønner. Statsløse sesjonsbønner og singletonbønner er mer fleksible, slik at samtidige tilkoblinger må administreres av utvikleren. Du er ansvarlig for trådsikkerheten når du arbeider med denne typen bønner.

Meldingsdrevne bønner

Meldingsdrevne bønner (MDB) påkalles via JMS-meldinger (Java Message Service). JMS fungerer som et distribuert kommandomønster, der den meldingsdrevne bønnen fungerer som lytter til kommandoen. Når en melding kommer om et emne eller kø, blir den meldingsdrevne bønnen som lytter til dette emnet påkalt.

Meldingsdrevne bønner brukes ikke like ofte som øktbønner, men de er kraftige. Siden de er asynkrone og hendelsesdrevne, er de spesielt nyttige for langvarige jobber der det er viktig å spare ressurser.

Den enkleste arkitekturen vil bestå av EJB-applikasjonen og dens container og server, som koordinerer med meldingstjenesten som behandler MDB-ene. I produksjonen vil arkitekturen din sannsynligvis inkludere en tredje komponent dedikert til å konsumere bønnene. Under utvikling kan alle disse komponentene kjøre på samme lokale maskin.

Figur 1 viser en typisk hendelsesdrevet arkitektur med meldingsdrevne bønner.

Matthew Tyson

Å jobbe med meldingsdrevne bønner er mer involvert enn å bruke sesjonsbønner. I et hendelsesdrevet miljø trenger du vanligvis en meldingsmegler som ActiveMQ.

Mens øktbønner er enklere, og dermed oftere brukt i EJB, har hendelsesdrevne arkitekturer blitt populære, spesielt med eksplosjonen av mikrotjenester.

EJB-merknader

Å definere og konsumere bedriftsbønner var et fast punkt for mange utviklere frem til EJB 3.0, som introduserte merknader til EJB-spesifikasjonen. Kommentarer gjør det veldig enkelt å konfigurere bedriftsbønner for et bredt spekter av funksjonalitet som finnes i Java EE. Fortsett å lese for å komme i gang med EJB-merknader.

@Stateless: Definer en statsløs øktbønne

For å utpeke en klasse som en statsløs øktbønne, bruker du javax.ejb.Stateless kommentar, som vist i liste 1.

Oppføring 1. @Stateless annotation example

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

Denne statsløse bønnen inneholder en enkel signatur som ikke tar noen argumenter og returnerer en streng. Ikke la enkelhet lure deg, skjønt: denne bønnen kan gjøre alt du trenger den til, inkludert samhandling med andre bønner, tjenester eller applikasjonens datalag.

@EJB: Bruk en statsløs øktbønne

Når du har definert en øktbønne, er det så enkelt å bruke den:

Oppføring 2. @EJB kommentareksempel

 offentlig klasse MyServlet utvider HttpServlet {@EJB MyStatelessBean myEjb; public void doGet (HttpServletRequest request, HttpServletResponse response) {response.getWriter (). skriv ("EJB Says" + testStatelessEjb.getGreeting ()); }} 

Her injiserer vi statsløs bønne i en servlet, og så er den tilgjengelig for bruk. Legg merke til hvordan bønnen identifiseres under @EJB kommentar. Den "statsløse" betegnelsen forteller oss at denne bønnen ikke vil spore klienten. Fordi den er statsløs, vet vi også at denne bønnen er gjenstand for threading hvis den gjør noe utenfor den påkalte metoden.

@Remote: Definer et eksternt EJB-grensesnitt

I eksemplene ovenfor antok jeg at EJB- og EJB-klienten kjørte i samme JVM. Hvis bedriftsbønnen og dens klient kjører i separate JVM-er, må EJB definere en @Remote grensesnitt. I dette tilfellet er det opp til deg å definere og implementere grensesnittet, som vist i Listing 3.

Listing 3. @Fjernkommentareksempel

 @Remote offentlig grensesnitt MyStatelessEjbRemote {String sayHello (String name); } 

Det eksterne grensesnittet sendes til klienten for å påkalle. Anrop til det blir da oppfylt av EJBs implementering av serveren. De MyStatelessBean eksempel i Listing 4 implementerer det eksterne grensesnittet.

Oppføring 4. Implementering av et eksternt grensesnitt

 offentlig klasse MyStatelessBean implementerer MyStatelessEjbRemote {...} 

Et eksternt grensesnitt er implementert akkurat som en vanlig klasse som implementerer et grensesnitt. Som forbruker av en ekstern EJB, må klientapplikasjonen kunne få tilgang til klassedefinisjonen for det eksterne grensesnittet. Du kan pakke klassedefinisjonen for det eksterne grensesnittet som en avhengighets-JAR.

Lokalt vs eksternt grensesnitt

Selv om det er viktig å vite hvordan man implementerer et eksternt grensesnitt, er det i praksis vanligere å bruke et lokalt grensesnitt. Det lokale grensesnittet brukes som standard og fungerer når EJB påkalles innenfor samme JVM-kontekst. Bruk av det eksterne grensesnittet spiller inn når applikasjonen distribueres over flere JVM-er.

Stateful sessions bønner og singleton bønner

Prosessen for å definere og konsumere stateful @Økt bønner og @Singleton bønner er det samme som det du har sett for @Stateless bønner. Husk semantikken:

  • Flere øktbønner kan instantiseres og brukes til samme klient.
  • En singleton bønne vil bare eksistere en gang for hele applikasjonen.

Trådsikkerhet og planlegging med singler

Trådsikkerhet er innebygd når du jobber med øktbønner, men både statsløse og singletonbønner kan nås av flere klienter samtidig. Utviklere er ansvarlige for trådsikkerhet når de implementerer denne typen bønner.

Singleton bønner tilbyr litt støtte for trådsikkerhet via @Låse kommentar. Du kan bruke @Lock-merknaden på singleton-bønnemetoder for å angi lese- / skriverettigheter for hver metode. De to alternativene er @Lock (LockType.READ) eller @Lock (LockType.WRITE), som er standard.

En annen nyttig funksjon av singletonbønner er muligheten til å planlegge oppgaver på en enkel måte ved hjelp av @Rute kommentar. Oppføring 5 viser hvordan du planlegger en oppgave daglig ved middagstid.

Oppføring 5. @Schedule-kommentareksempel

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

CDI mot EJB

CDI, eller Context and Dependency Injection er en nyere foretaksspesifikasjon som noen utviklere har foreslått kan erstatte EJB.

På høyt nivå tilbyr CDI et generelt komponentrammeverk, mens EJB skiller seg ut for sine rikt utvalgte, individuelle komponenter. Mens CDI bruker avhengighetsinjeksjon for å definere og referere til hvilken som helst programvarekomponent, er EJB-komponenter mer formelt definert, og hver tilbyr et spesifikt sett med muligheter ut av esken. Begge spesifikasjonene er planlagt for fremtidig utvikling som en del av Jakarta EE, hvor spørsmålet om CDI skal erstatte EJB til slutt vil bli løst.

Konklusjon

Enterprise JavaBeans var den første spesifikasjonen som ga en enkel måte å kapsle inn og gjenbruke forretningslogikk i enterprise Java-applikasjoner. Langt fra den tunge tyngdekraften fra gamle dager, er EJB i dag et magert, kommentarbasert rammeverk som lar deg få tilgang til et bredt spekter av bedriftsfunksjonaliteter, rett ut av boksen. Vurder EJB neste gang du blir bedt om å raskt øke en distribuert, skalerbar forretningsapplikasjon. Du kan bli positivt overrasket.

Denne historien, "Hva er EJB? Utviklingen av Enterprise JavaBeans" ble opprinnelig utgitt av JavaWorld.