Enterprise JavaBeans (EJB) je specifikacija za razvoj obsežnih, porazdeljenih poslovnih aplikacij na platformi Java. EJB 1.0 je bil izdan leta 1998. Najnovejša izdaja, EJB 3.2.3, je bila sprejeta za vključitev v Džakarto EE, kjer se bo preimenovala v Jakarta Enterprise Beans.
EJB arhitektura
Arhitektura EJB je sestavljena iz treh glavnih komponent: zrna podjetja (EJB), vsebnika EJB in aplikacijskega strežnika Java. EJB se izvajajo znotraj vsebnika EJB, vsebnik EJB pa znotraj strežnika aplikacij Java.
Obstajata dve vrsti EJB - sejni fižol in fižol na osnovi sporočil:
- Sejni fižol jih kliče stranka in stranki programsko omogočajo funkcionalnost podjetja, kot so transakcije in upravljanje virov.
- Sporočilo usmerjeni fižol prav tako združujejo in zagotavljajo poslovne funkcije, vendar so asinhrone in usmerjene na dogodke. Sporočilo usmerjeni fižol posluša in se odziva na dogodke in ga stranka ne more sklicati.
Enkrat uporabljeni za zagotavljanje obstojnosti v sistemu EJB je zrn entitet nadomestil API za obstojnost Java. Nadaljujte z branjem, če želite izvedeti več o fižolih sej in fižolih na podlagi sporočil.
EJB vs JavaBeans
Enterprise JavaBeans je bil prvi razvojni model Java EE, ki temelji na komponentah. EJB je podoben JavaBeansu, ker temelji na komponentah, toda tu se podobnost konča:
- A JavaBean je razred Java, ki zajema več predmetov in ustreza določenim konvencijam. JavaBeans se uporabljajo predvsem za razvoj na strani odjemalca.
- An poslovni fižol (EJB) je razred Java, prežet s posebnimi zmožnostmi na strani strežnika. Podjetni fižol se uporablja v velikih poslovnih aplikacijah in sistemih.
Sejni fižol
A sejni fižol je najbolj generična vrsta poslovnega zrna, ki predstavlja del poslovne funkcionalnosti, ki jo lahko pokliče odjemalec. V tem primeru je odjemalec lahko drug razred v lokalnem JVM ali oddaljeni klic.
Vsebnik EJB upravlja življenjski cikel seje fižola, ki ga določa stanje fižola:
- Fižol za zasedanje brez državljanstva so podobni obsegu zahteve v API-ju Java Servlet. Sejni zrni brez državljanstva vsebujejo del funkcij, ki jih je mogoče klicati, sicer pa so brez stanja.
- Stabilni fižol seje so povezani samo z enim odjemalcem in se pritrdijo na njegovo trenutno sejo. Fižol seje s stanjem deluje podobno kot obseg seje v API-ju Servlet.
- Singleton fižol so podobni obsegu aplikacije v API-ju Servlet. Enkratni sejni sev obstaja samo enkrat za vsako stranko.
Varnost niti s fižoli
Do seva do zrna s stanjem lahko dostopa samo ena stranka naenkrat, zato je pri delu s to vrsto zrna zagotovljena varnost niti. Fižol seje brez državljanstva in enojni fižol sta bolj prilagodljiva in omogočata sočasne povezave, ki jih mora upravljati razvijalec. Za delo s temi vrstami fižola ste odgovorni za varnost niti.
Sporočilo usmerjeni fižol
Sporočilo usmerjeni fižoli (MDB) se prikličejo prek sporočil JMS (Java Message Service). JMS deluje kot porazdeljeni vzorec ukaza, pri čemer grah, ki ga poganja sporočilo, deluje kot poslušalec ukaza. Ko v temo ali čakalno vrsto prispe sporočilo, se prikliče grah na podlagi sporočil, ki posluša to temo.
Sporočilo usmerjeni fižoli niso tako pogosto uporabljeni kot sejni fižoli, so pa zmogljivi. Ker so asinhroni in jih vodijo dogodki, so še posebej uporabni za dolgotrajna dela, kjer je pomembno prihraniti sredstva.
Najenostavnejša arhitektura bi bila sestavljena iz aplikacije EJB ter njenega vsebnika in strežnika, ki se usklajuje s storitvijo sporočil, ki obdeluje MDB. V proizvodnji bi vaša arhitektura verjetno vključevala tretjo komponento, namenjeno uživanju fižola. V razvoju bi lahko vse te komponente delovale na istem lokalnem računalniku.
Na sliki 1 je prikazana tipična arhitektura, ki jo vodijo dogodki, s fižoli na podlagi sporočil.
Matthew Tyson Delo s fižoli, ki temeljijo na sporočilih, je bolj vključeno kot uporaba fižolov sej. V okolju, ki temelji na dogodkih, običajno potrebujete posrednika sporočil, kot je ActiveMQ.
Medtem ko so sejni zrni enostavnejši in se zato pogosteje uporabljajo v EJB, so arhitekture, ki jih vodijo dogodki, postale priljubljene, zlasti z eksplozijo mikro storitev.
Pripisi EJB
Opredelitev in poraba fižola za podjetja je bila za mnoge razvijalce ovira do EJB 3.0, ki je uvedlo opombe k specifikaciji EJB. Z opombami je zelo enostavno konfigurirati fižol podjetja za široko paleto funkcij, ki jih najdemo v Java EE. Nadaljujte z branjem, če želite začeti z opombami EJB.
@Stateless: Določite fižol seje brez državljanstva
Če želite razred označiti kot sejni seboj brez stanja, uporabite javax.ejb.Stateless kot je prikazano v seznamu 1.
Seznam 1. Primer primera @Stateless
uvoz javax.ejb.Stateless; @Stateless javni razred MyStatelessBean {public String getGreeting () {return "Hello JavaWorld."; }} Ta bean brez stanja vsebuje preprost podpis, ki ne zajema nobenih argumentov in vrne niz. Ne dovolite, da vas preprostost zavede: ta zrn lahko stori vse, kar potrebujete, vključno z interakcijo z drugimi zrni, storitvami ali podatkovno plastjo vaše aplikacije.
@EJB: Užijte fižol seje brez državljanstva
Ko definirate sejni fižol, je njegova uporaba tako preprosta:
Seznam 2. Primer primera @EJB
javni razred MyServlet razširja HttpServlet {@EJB MyStatelessBean myEjb; javna void doGet (zahteva HttpServletRequest, odgovor HttpServletResponse) {response.getWriter (). write ("EJB pravi" + testStatelessEjb.getGreeting ()); }} Tu fižol brez državljana vbrizgamo v strežniški programček, nato pa je na voljo za uporabo. Upoštevajte, kako je fižol označen pod @EJB pripis. Oznaka "brez državljanstva" nam pove, da fižol ne bo sledil odjemalcu. Ker je brez državljanstva, vemo tudi, da je ta fiž predmet navojev, če opravlja kakršno koli delo zunaj priklicane metode.
@Remote: Določite oddaljeni vmesnik EJB
V zgornjih primerih sem domneval, da sta odjemalec EJB in EJB delovala v istem JVM. Če se grah podjetja in njegova stranka izvajata v ločenih JVM-jih, mora EJB definirati a @ Oddaljeno vmesnik. V tem primeru morate sami določiti in implementirati vmesnik, kot je prikazano v seznamu 3.
Seznam 3. @ Primer oddaljenega pripisa
@Remote javni vmesnik MyStatelessEjbRemote {String sayHello (ime niza); } Oddaljeni vmesnik se pošlje odjemalcu, da ga pokliče. Nato bo klice nanjo izpolnila strežniška izvedba EJB. The MyStatelessBean primer v seznamu 4 izvaja oddaljeni vmesnik.
Seznam 4. Implementacija oddaljenega vmesnika
javni razred MyStatelessBean implementira MyStatelessEjbRemote {...} Oddaljeni vmesnik je izveden tako kot običajni razred, ki izvaja vmesnik. Kot odjemalec oddaljenega EJB mora imeti odjemalska aplikacija dostop do definicije razreda za oddaljeni vmesnik. Definicijo razreda za oddaljeni vmesnik lahko zapakirate kot JAR odvisnosti.
Lokalni vs oddaljeni vmesnik
Čeprav je pomembno vedeti, kako implementirati oddaljeni vmesnik, je v praksi pogosteje uporaba lokalnega vmesnika. Lokalni vmesnik se uporablja privzeto in deluje vsakič, ko se EJB prikliče v istem kontekstu JVM. Uporaba oddaljenega vmesnika pride v poštev, ko je aplikacija porazdeljena po več JVM-jih.
Fižol sej s stanjem in enojni fižol
Postopek za določanje in porabo stanja @Session fižol in @Singleton fižol je enako tistemu, kar ste že videli @Stateless fižol. Ne pozabite na semantiko:
- Za isti odjemalec je mogoče ustvariti primere za več sej seja in jih uporabiti.
- Singleton fižol bo obstajal samo enkrat za celotno aplikacijo.
Varnost niti in razporejanje niti z enim samim zaslonom
Varnost niti je vgrajena, ko delate s fižoli sej, vendar lahko več odjemalcev hkrati dostopa do fižolov brez stanja in posameznih zrn. Razvijalci so odgovorni za varnost niti pri uporabi teh vrst fižola.
Singleton fižol nudi nekaj podpore za varnost niti prek @Lock pripis. Z opombo @Lock za posamezne metode zrna lahko nastavite pravice branja / pisanja za vsako metodo. Dve možnosti sta @Lock (LockType.READ) ali @Lock (LockType.WRITE), kar je privzeto.
Druga koristna lastnost enojnega fižola je sposobnost preprostega razporejanja nalog z uporabo @ Načrtuj pripis. Seznam 5 prikazuje, kako razporediti opravilo vsak dan opoldne.
Seznam 5. Primer primera pripisa @Schedule
@Singleton javni razred MySchedulerBean {@Schedule (hour = "12") void doIt () {System.out.println ("Pozdrav opoldne!"); }} CDI proti EJB
CDI ali Context and Dependency Injection je novejša specifikacija podjetja, za katero so nekateri razvijalci predlagali, da bi lahko nadomestila EJB.
Na visoki ravni CDI ponuja okvir splošnih komponent, medtem ko EJB izstopa s svojimi bogato opremljenimi posameznimi komponentami. Medtem ko CDI uporablja vbrizganje odvisnosti za definiranje in sklicevanje na katero koli programsko komponento, so komponente EJB bolj formalno opredeljene, pri čemer vsaka ponuja določen nabor zmogljivosti že takoj. Obe specifikaciji sta načrtovani za prihodnji razvoj v okviru Jakarta EE, kjer bo sčasoma rešeno vprašanje, ali naj CDI nadomesti EJB.
Zaključek
Enterprise JavaBeans je bila prva specifikacija, ki je ponudila enostaven način inkapsulacije in ponovne uporabe poslovne logike v podjetniških aplikacijah Java. Danes EJB še zdaleč ni najtežji behemoth, vitko ogrodje, ki temelji na pripisih in vam omogoča neposreden dostop do široke palete poslovnih funkcij. Razmislite o EJB, ko boste naslednjič pozvani k hitri rasti distribuirane, razširljive poslovne aplikacije. Morda boste prijetno presenečeni.
To zgodbo "Kaj je EJB? Razvoj Enterprise JavaBeans" je prvotno objavil JavaWorld.
