Enterprise JavaBeans 2.0, ki je izšel 2. junija, ni le točkovna izdaja, temveč tudi nova različica specifikacije. Na nekaj več kot 500 straneh je specifikacija EJB 2.0 za 200 strani (66 odstotkov) daljša od prejšnje specifikacije EJB 1.1. Najpomembnejše spremembe v specifikaciji so spremembe trajnosti, ki jo upravlja posoda (CMP), in uvedba popolnoma novega tipa fižola, MessageDrivenBean.
Glavnina sprememb v EJB 2.0 najdemo v definiciji novega modela komponent CMP. Korenito se razlikuje od starega modela CMP, ker predstavlja povsem novega udeleženca, vodja vztrajnostiin popolnoma nov način definiranja polj, ki jih upravlja vsebnik, pa tudi odnosov z drugimi fižoli in odvisnimi predmeti.
Uvedba MessageDrivenBean (sporočilo bean) je prav tako pomembno. Sporočilo bean predstavlja integracijo JMS (Java Message Service) z EJB, da ustvari povsem novo vrsto fižola, ki je zasnovan za obdelavo asinhronih sporočil JMS. Ta novi vznemirljivi fižol ponuja komponentni model za odjemalce JMS, ki jim omogoča razmestitev v bogatem in robustnem okolju sistema zabojnikov EJB.
Obstaja še veliko drugih manjših sprememb v specifikaciji. Te druge spremembe, čeprav so pomembne, se večinoma ukvarjajo s poostritvijo specifikacij, da bi odpravili nejasnosti in naredili komponente bolj prenosljive. Ta članek se osredotoča na nove modele komponent CMP in komponent fižol sporočil, predstavljene v EJB 2.0.
Navajam več konkretnih primerov, zato bi ga bilo treba dokaj enostavno slediti in razumeti. Za začetnike EJB pa bo gradivo morda težje, saj se domneva, da bralci osnovno razumejo EJB. Za več informacij o EJB glejte Viri.
Vztrajnost, ki jo upravlja zabojnik
Vztrajnost, ki jo upravlja zabojnik, je v EJB 2.0 doživela korenite spremembe. V EJB 2.0 upravitelj obstojnosti samodejno obravnava obstojnost zrn entitete CMP med izvajanjem. Upravitelj obstojnosti je odgovoren za preslikavo zrna entitete v bazo podatkov na podlagi nove pogodbe upravitelja obstojnosti zrn, imenovane abstraktna shema obstojnosti. Poleg tega je upravitelj obstojnosti odgovoren za izvajanje in izvajanje metod iskanja, ki temeljijo na novem jeziku poizvedbe, imenovanem EJB QL.
Pomembno je omeniti, da morajo izdelki, ki ustrezajo specifikaciji EJB 2.0, podpirati model EJB 1.1 CMP in novi model EJB 2.0. Čeprav ti modeli niso združljivi, je za zagotovitev povratne združljivosti za model EJB 1.1 potrebna podpora.
Abstraktna shema obstojnosti
Da bi razumeli, kako deluje abstraktna shema obstojnosti in zakaj je pomembna, vam bom na hitro ogledal, kako se s CMP ravna v EJB 1.1, in nato razpravljal o tem, kako je opredeljen v EJB 2.0.
Model EJB 1.1 CMP
V EJB 1.1 je razvijalec fižola odgovoren za razglasitev trajnih polj razreda fižola kot primitivne ali serijske vrste Java. Naslednji primeri kažejo Zaposleni razred zrna podjetja, kot je opredeljen v EJB 1.1, z več polji CMP:
// javni razred razreda Employee bean EmployeeBean izvaja java.ejb.EntityBean {// polja primerka EntityContext ejbContext; // polja, ki jih upravlja vsebnik, javna identiteta int; javni String firstName; javni String lastName; javna dvojna plača; naslov za javni naslov; javno celo število ejbCreate (int id, String fname, String lname) {identiteta = id; firstName = ime; lastName = lname; vrni null; } ...} // Naslov razreda javnega razreda, odvisen od naslova, izvaja Serializable {public String street; javno mesto String; javno stanje niza; javni String zip; } Ko se za obstojnost uporablja relacijska baza podatkov, se primitivna polja, kot je identiteta, ime, priimek, in plača je dokaj enostavno vztrajati, saj se lepo povezujejo z vrstami SQL, kot je INTEGER, CHAR, in DVOJNA.
V EJB 1.1 ponuja deskriptor razmestitve XML za zrno CMP cmp-polje elementi za prepoznavanje trajnih polj (polj, ki jih upravlja vsebnik) v razredu fižola. Kot je prikazano spodaj, cmp-polje elementi se uporabljajo za razlikovanje med polji, ki so zapisana v bazo podatkov, in tistimi, ki niso. Na primer ejbContext polje ni vključeno v seznam polj, ki jih upravlja vsebnik, in zato ni trajno polje.
ZaposleniEJB ... Zabojnik ... identiteta imePriime ime plače naslov ...
Ponudnik vsebnika dobavi orodje za preslikavo trajnih polj zrna v stolpce v tabelah zbirke podatkov, ponavadi eno tabelo na zrn. Serializirane vrste, kot so Naslovvendar je težje vztrajati. V EJB 1.1 ni standardnega načina preslikave serializiranih predmetov v relacijsko bazo podatkov. Čeprav je Naslov class ima svoj nabor polj, deskriptor razmestitve XML ne zagotavlja mehanizma za preslikavo teh polj v bazo podatkov. V večini primerov je bilo pričakovati, da bodo serializirani predmeti, kot so Naslov bi obstajal kot binarni tip, ki se včasih imenuje a blob v tabelo baze podatkov.
Ta težava se poslabša, saj se shema podatkov fižola entitete zaplete. An Zaposleni bean, na primer, ima lahko veliko podrejenih predmetov, podobnih Naslov, kot naprimer Prednosti in Delovno mesto. Ti podrejeni predmeti, imenovani odvisni predmeti, lahko tvorijo zapletene grafe objektov, ki obsegajo več tabel v relacijski bazi podatkov. Poleg tega CMP v EJB 1.1 večinoma ni primeren za trajne odnose z drugimi fižoli. V EJB 1.1, če naj bi zrn ohranil odnos z drugim zrnom, bi vsebnik samodejno uporabil primarni ključ ali ročaj kot povezavo. To se je izkazalo za dokaj surov mehanizem za vzdrževanje odnosov z drugimi fižoli, katerih naravni odnosi so lahko dvosmerni ali odvisni od polj, ki jih primarni ključ ali ročaj ne predstavlja zlahka.
Model EJB 2.0 CMP
V EJB 2.0 nova pogodba med zrnom entitete CMP in upraviteljem obstojnosti omogoča definiranje bolj zapletenih in prenosnih odnosov med zrni od zrna do zrna, od fižola do odvisnika in celo odvisnimi od odvisnosti znotraj fižola entitete.
Stalni upravitelj je novi udeleženec v procesu uvajanja Enterprise JavaBeans. Prodajalec vsebnika ali prodajalec, ki je specializiran za obstojnost določene baze podatkov, lahko zagotovi upravitelja obstojnosti. Ideja je ločiti mehanizem, ki se uporablja za upravljanje odnosov fižolov, od vsebnika, ki je odgovoren za upravljanje varnosti, transakcij in virov. Ločitev odgovornosti različnim vodjem vztrajnosti omogoča delo z različnimi vsebniki. Omogoča tudi, da fižol entitet postane bolj prenosljiv tako pri prodajalcih EJB kot tudi pri upraviteljih obstojnosti.
Če ste sodelovali s CocoBase, izdelkom podjetja Thought Inc., ki samodejno generira zrna BMP (Bean Managed Persistence) za vsebnike EJB 1.1 ali ste jih preučevali, ste že nekoliko seznanjeni z delovanjem trajnega orodja za upravljanje. CocoBase generira vso logiko dostopa do zbirke podatkov za fižol BMP na podlagi informacij o preslikavanju med objektom in relacijo, ki jih nudi razmestitvenik fižola. V EJB 2.0 lahko upravitelj obstojnosti generira preslikavo entitet CMP v relacijsko bazo podatkov na podlagi informacij, ki jih posreduje deskriptor razmestitve, abstraktna shema obstojnosti fižola in delo, ki ga opravi uvajalnik. Upravitelj obstojnosti pa ni omejen na relacijsko bazo podatkov. Upravitelje obstojnosti je mogoče razviti tudi za zbirke podatkov objektov, pa tudi za starejše in ERP sisteme, kot je SAP.
Da bi bil upravitelj obstojnosti ločen od vsebnika, je bilo treba določiti pogodbo med zrnom in upraviteljem obstojnosti. Pogodba se kaže v novi abstraktni shemi obstojnosti. Ta shema je definirana z novim naborom elementov XML v deskriptorju razmestitve in naborom idiomov kode v zrnih entitet CMP. V EJB 2.0 je razred graha CMP razglašen za abstraktnega in do njegovih trajnih in relacijskih polj se dostopa z uporabo abstraktnih metod dostopa in mutatorja, katerih podpisi metode se preslikajo na posebne elemente v deskriptorju razmestitve XML.
Ko je fiž razporejen, boste s trajnimi orodji upravitelja ustvarili konkretno izvedbo abstraktnega razreda fižola in njegovih odvisnih razredov predmetov na podlagi deskriptorja razmestitve XML in razreda graha. Konkretne izvedbe bodo vključevale kodo za dostop do podatkov, ki bo dejansko prebrala in zapisala stanje zrna v bazo podatkov med izvajanjem. V času izvajanja vsebnik uporablja podrazrede, ki jih ustvarijo orodja upravitelja obstojnosti, namesto abstraktnih razredov, ki jih definira ponudnik graha.
Da bi razpravi dali nekaj mesa, je na voljo primer entitete CMP, ki natančneje razloži, kako deluje abstraktna shema obstojnosti.
Primer entitete CMP v EJB 2.0
V EJB 2.0 je sestavni del entitete, ki ga upravlja vsebnik, opredeljen kot abstrakten in njegova trajna polja niso definirana neposredno v razredu graha. Namesto tega je bila razvita abstraktna trajna shema, ki omogoča ponudniku graha, da posredna deklarira trajna polja in povezave fižola. Spodaj je primer Zaposleni bean, ki uporablja novo abstraktno obstojno shemo. Upoštevajte, da nobeno trajno polje ni prijavljeno v razredu zrna.
javni povzetek EmployeeBean izvaja javax.ejb.EntityBean {. // polja primerka EntityContext ejbContext; // trajna polja, ki jih upravlja vsebnik, public abstract void setIdentity (int identiteta); javni povzetek int getIdentity (); javna abstraktna void setFirstName (String firstName); javni povzetek String getFirstName (); javna abstraktna void setLastName (String lastName); javni povzetek String getLastName (); // polja odnosov, ki jih upravlja vsebnik, javna abstraktna void setContactInfo (ContactInfo info); javni povzetek ContactInfo getContactInfo (); ...} V deskriptorju razmestitve XML tega zrna abstraktna shema obstojnosti razglasi polja in odnose, ki jih upravlja vsebnik.
ZaposleniEJB ... Zabojnik ... identiteta firstName priimek ... ContactInfo ContactInfo ulica mesto država zip homePhone službaTelefon e-pošta ... Zaposleni-ContactInfo zaposleni-ima-kontaktinfo one ZaposleniEJB contactInfo ContactInfo contactinfo_belongsto_employee one ContactInfo
