Enterprise JavaBeans (EJB) er en specifikation til udvikling af store, distribuerede forretningsapplikationer på Java-platformen. EJB 1.0 blev frigivet i 1998. Den nyeste udgivelse, EJB 3.2.3, er blevet vedtaget til optagelse i Jakarta EE, hvor den bliver omdøbt til Jakarta Enterprise Beans.
EJB-arkitektur
EJB-arkitekturen består af tre hovedkomponenter: enterprise bønner (EJB'er), EJB-containeren og Java-applikationsserveren. EJB'er kører inde i en EJB-container, og EJB-containeren kører inde i en Java-applikationsserver.
Der er to typer EJB - session bønner og meddelelsesdrevne bønner:
- Sessionsbønner påberåbes af klienten og gør virksomhedsfunktionalitet såsom transaktioner og ressourcestyring tilgængelig for klienten programmatisk.
- Beskedstyrede bønner indkapsler og leverer også virksomhedsfunktionalitet, men de er asynkrone og hændelsesdrevne. Beskedstyrede bønner lytter og reagerer på begivenheder og kan ikke påberåbes af klienten.
Når de er brugt til at give vedholdenhed i EJB-systemet, er enhedsbønner blevet fortrængt af Java Persistence API. Fortsæt læsning for at lære mere om session bønner og meddelelsesdrevne bønner.
EJB vs JavaBeans
Enterprise JavaBeans var den første komponentbaserede udviklingsmodel til Java EE. EJB ligner JavaBeans i at være komponentbaseret, men det er her ligheden slutter:
- EN JavaBean er en Java-klasse, der indkapsler flere objekter og overholder visse konventioner. JavaBeans bruges primært til udvikling af klientsiden.
- En Enterprise Bean (EJB) er en Java-klasse gennemsyret med specifikke server-side muligheder. Enterprise bønner bruges i store forretningsapplikationer og -systemer.
Sessionsbønner
EN session bønne er den mest generiske type virksomhedsbønne, der repræsenterer et stykke forretningsfunktionalitet, der kan kaldes af en klient. I dette tilfælde kan klienten være en anden klasse i den lokale JVM eller et fjernopkald.
EJB-containeren administrerer sessionsbønnens livscyklus, som bestemmes af bønnens tilstand:
- Statsløse session bønner svarer til anmodningsomfanget i Java Servlet API. Statsløse session bønner indeholder en del af kaldbar funktionalitet, men er ellers statsløse.
- Stateful session bønner er kun knyttet til en klient og vedhæftes klientens igangværende session. Stateful session beans fungerer på samme måde som sessionsomfanget i Servlet API.
- Singleton bønner ligner applikationsomfanget i Servlet API. En singleton session bønne findes kun én gang for hver klient.
Trådsikkerhed med sessionbønner
En stateful session bønne kan kun fås af en klient ad gangen, så trådsikkerhed er garanteret, når du arbejder med denne type bønner. Statsløse sessionbønner og singletonbønner er mere fleksible, hvilket giver mulighed for samtidige forbindelser, som skal administreres af udvikleren. Du er ansvarlig for trådsikkerhed, når du arbejder med disse typer bønner.
Beskedstyrede bønner
Meddelelsesdrevne bønner (MDB'er) påkaldes via JMS-meddelelser (Java Message Service). JMS fungerer som et distribueret kommandomønster, hvor den meddelelsesdrevne bønne fungerer som lytter til kommandoen. Når en besked ankommer til et emne eller kø, påberåbes den meddelelsesdrevne bønne, der lytter om dette emne.
Meddelelsesdrevne bønner bruges ikke så almindeligt som sessionbønner, men de er stærke. At være asynkrone og begivenhedsdrevne er de især nyttige til langvarige job, hvor det er vigtigt at spare ressourcer.
Den enkleste arkitektur ville bestå af EJB-applikationen og dens container og server, der koordinerer med meddelelsestjenesten, der behandler MDB'erne. I produktionen vil din arkitektur sandsynligvis omfatte en tredje komponent dedikeret til at forbruge bønnerne. Under udvikling kunne alle disse komponenter køre på den samme lokale maskine.
Figur 1 viser en typisk begivenhedsdrevet arkitektur med meddelelsesdrevne bønner.
Matthew Tyson At arbejde med meddelelsesdrevne bønner er mere involveret end at bruge sessionsbønner. I et hændelsesdrevet miljø har du typisk brug for en meddelelsesmægler som ActiveMQ.
Mens sessionbønner er enklere og dermed mere almindeligt anvendt i EJB, er begivenhedsdrevne arkitekturer blevet populære, især med eksplosionen af mikrotjenester.
EJB-kommentarer
Definition og forbrug af enterprise-bønner var et fast punkt for mange udviklere indtil EJB 3.0, der introducerede kommentarer til EJB-specifikationen. Annotationer gør det meget nemt at konfigurere enterprise-bønner til en lang række funktioner, der findes i Java EE. Fortsæt med at læse for at komme i gang med EJB-kommentarer.
@Stateless: Definer en statsløs session bønne
For at udpege en klasse som en statsløs session bønne, bruger du javax.ejb.Stateless kommentar, som vist i liste 1.
Listing 1. @Stateless annotation eksempel
import javax.ejb.Stateless; @Stateless public class MyStatelessBean {public String getGreeting () {return "Hej JavaWorld."; }} Denne statsløse bønne indeholder en simpel signatur, der ikke tager nogen argumenter og returnerer en streng. Men lad ikke enkelheden narre dig: Denne bønne kan gøre alt, hvad du har brug for, inklusive interaktion med andre bønner, tjenester eller din applikations datalag.
@EJB: Forbrug en statsløs session bønne
Når du har defineret en session bønne, er det så simpelt at bruge det:
Liste 2. Eksempel på @EJB-kommentar
offentlig klasse MyServlet udvider HttpServlet {@EJB MyStatelessBean myEjb; offentlig ugyldig doGet (HttpServletRequest anmodning, HttpServletResponse svar) {respons.getWriter (). skriv ("EJB siger" + testStatelessEjb.getGreeting ()); }} Her injicerer vi den statsløse bønne i en servlet, og så er den tilgængelig til brug. Bemærk hvordan bønnen identificeres under @EJB kommentar. Den "statsløse" betegnelse fortæller os, at denne bønne ikke sporer klienten. Fordi den er statsløs, ved vi også, at denne bønne er genstand for trådning, hvis den udfører noget arbejde uden for den påberåbte metode.
@Remote: Definer en ekstern EJB-grænseflade
I ovenstående eksempler antog jeg, at EJB og EJB-klienten kørte i samme JVM. Hvis virksomhedens bønne og dens klient kører i separate JVM'er, skal EJB definere en @Fjern interface. I dette tilfælde er det op til dig at definere og implementere grænsefladen, som vist i liste 3.
Listing 3. @Fjernkommentareksempel
@Remote offentlig grænseflade MyStatelessEjbRemote {String sayHello (String name); } Fjerninterfacet sendes til klienten for at påberåbe sig. Opkald til det vil derefter blive opfyldt ved EJB's implementering af serversiden. Det MyStatelessBean eksempel i Listing 4 implementerer den eksterne grænseflade.
Fortegnelse 4. Implementering af en ekstern grænseflade
offentlig klasse MyStatelessBean implementerer MyStatelessEjbRemote {...} En ekstern grænseflade implementeres ligesom en normal klasse, der implementerer en grænseflade. Som forbruger af en ekstern EJB skal klientapplikationen kunne få adgang til klassedefinitionen for den eksterne grænseflade. Du kan pakke klassedefinitionen til den eksterne grænseflade som en afhængigheds-JAR.
Lokal vs ekstern grænseflade
Selvom det er vigtigt at vide, hvordan man implementerer en ekstern grænseflade, er det i praksis mere almindeligt at bruge en lokal grænseflade. Den lokale grænseflade bruges som standard og fungerer, når EJB påberåbes inden for den samme JVM-kontekst. Brug af den eksterne grænseflade kommer i spil, når applikationen distribueres over flere JVM'er.
Stateful session bønner og singleton bønner
Processen til at definere og forbruge stateful @Session bønner og @Singleton bønner er det samme som hvad du har set for @Stateless bønner. Husk semantikken:
- Flere session bønner kan instantieres og bruges til den samme klient.
- En singleton bønne vil kun eksistere en gang for hele applikationen.
Trådsikkerhed og planlægning med singletoner
Trådsikkerhed er indbygget, når du arbejder med sessionbønner, men både statsløse og singletonbønner kan fås samtidigt af flere klienter. Udviklere er ansvarlige for trådsikkerhed, når de implementerer disse typer bønner.
Singleton bønner tilbyder en vis støtte til trådsikkerhed via @Låse kommentar. Du kan bruge @Lock-kommentaren på singleton-bønnemetoder til at indstille læse / skrive-rettigheder for hver metode. De to muligheder er @Lock (LockType.READ) eller @Lock (LockType.WRITE), som er standard.
En anden nyttig funktion ved singletonbønner er evnen til at planlægge opgaver på en enkel måde ved hjælp af @Tidsplan kommentar. Liste 5 viser, hvordan man planlægger en opgave dagligt ved middagstid.
Liste 5. Eksempel på kommentar til @Schedule
@Singleton public class MySchedulerBean {@Schedule (hour = "12") ugyldig doIt () {System.out.println ("Hello at Noon!"); }} CDI vs EJB
CDI eller Context and Dependency Injection er en nyere virksomhedsspecifikation, som nogle udviklere har foreslået, kan erstatte EJB.
På et højt niveau tilbyder CDI en komponentramme til generelle formål, mens EJB skiller sig ud for sine rigt udvalgte, individuelle komponenter. Mens CDI bruger afhængighedsinjektion til at definere og henvise til enhver softwarekomponent, er EJB-komponenter mere formelt definerede, hvor hver tilbyder et specifikt sæt funktioner ud af kassen. Begge specifikationer er planlagt til fremtidig udvikling som en del af Jakarta EE, hvor spørgsmålet om, hvorvidt CDI skal erstatte EJB, til sidst vil blive løst.
Konklusion
Enterprise JavaBeans var den første specifikation, der tilbyder en nem måde at indkapsle og genbruge forretningslogik i Java-applikationer til virksomheder. Langt fra den gamle tunge vægt, er EJB i dag en slank, annoteringsbaseret ramme, der giver dig adgang til en bred vifte af virksomhedsfunktionalitet lige ud af kassen. Overvej EJB næste gang du bliver bedt om hurtigt at øge en distribueret, skalerbar forretningsapplikation. Du bliver måske behageligt overrasket.
Denne historie, "Hvad er EJB? Udviklingen af Enterprise JavaBeans" blev oprindeligt udgivet af JavaWorld.
