„Enterprise JavaBeans 2.0“, išleistas birželio 2 d., Yra ne tik taškinis leidimas, bet ir nauja specifikacijos versija. Kiek daugiau nei 500 puslapių EJB 2.0 specifikacija yra 200 puslapių (66 proc.) Ilgesnė nei ankstesnė EJB 1.1 specifikacija. Svarbiausi specifikacijos pakeitimai yra pakeitimai, susiję su konteinerių valdomu patvarumu (CMP) ir visiškai naujo pupelių tipo, „MessageDrivenBean“.
Didžioji dalis EJB 2.0 pakeitimų yra apibrėžta naujo CMP komponento modelio apibrėžime. Jis kardinaliai skiriasi nuo senojo CMP modelio, nes pristato visiškai naują dalyvį atkaklumo vadybininkas, ir visiškai naujas būdas apibrėžti konteinerių valdomus laukus, taip pat santykius su kitomis pupelėmis ir priklausomais objektais.
Įvadas „MessageDrivenBean“ (pranešimo pupelė) taip pat reikšminga. Pranešimų pupelė reiškia JMS (Java Message Service) integraciją su EJB, kad būtų sukurtas visiškai naujo tipo pupelės, skirtos asinchroniniams JMS pranešimams tvarkyti. Šis įdomus naujo pupelių tipas suteikia JMS klientams komponentinį modelį, leidžiantį juos įdiegti turtingoje ir tvirtoje EJB konteinerių sistemos aplinkoje.
Yra daugybė kitų mažesnių specifikacijos pakeitimų. Šie svarbūs pakeitimai, nors ir yra svarbūs, dažniausiai yra susiję su specifikacijos sugriežtinimu, siekiant pašalinti neaiškumus ir padaryti komponentus nešiojamus. Šiame straipsnyje pagrindinis dėmesys skiriamas naujiems CMP ir pranešimų pupelių komponentų modeliams, pristatytiems EJB 2.0.
Pateikiu keletą konkrečių pavyzdžių, todėl tai turėtų būti gana lengva sekti ir suprasti. Tačiau EJB naujokams medžiaga gali būti sunkesnė, nes daroma prielaida, kad skaitytojai iš esmės supranta EJB. Norėdami gauti daugiau informacijos apie EJB, žr. Šaltinius.
Konteinerių valdomas atkaklumas
Konteinerių valdomame atkaklume radikaliai pasikeitė EJB 2.0. EJB 2.0 versijoje atkaklumo tvarkytuvas automatiškai tvarko CMP subjekto pupelių patvarumą vykdymo metu. Atkaklumo vadybininkas yra atsakingas už subjekto pupelių susiejimą su duomenų baze, remiantis nauja pupelių atkaklumo vadybininko sutartimi, vadinama abstrakta atkaklumo schema. Be to, atkaklumo vadybininkas yra atsakingas už paieškos metodų, pagrįstų nauja užklausos kalba, vadinamą, įgyvendinimą ir vykdymą EJB QL.
Svarbu pažymėti, kad produktai, atitinkantys „EJB 2.0“ specifikaciją, turi palaikyti „EJB 1.1 CMP“ modelį ir naują „EJB 2.0“ modelį. Nors šie modeliai nėra suderinami, norint užtikrinti suderinamumą atgal, reikia palaikyti EJB 1.1 modelį.
Abstrakti atkaklumo schema
Norėdami suprasti, kaip veikia abstrakti patvarumo schema ir kodėl ji svarbi, greitai apžvelgsiu, kaip CMP tvarkoma EJB 1.1 versijoje, tada aptarsiu, kaip ji apibrėžiama EJB 2.0.
EJB 1.1 CMP modelis
EJB 1.1 versijoje pupelių kūrėjas yra atsakingas už pupelių klasės patvarių laukų paskelbimą „Java“ primityviais arba serijiniais tipais. Šie pavyzdžiai rodo Darbuotojas įmonės pupelių klasė, apibrėžta EJB 1.1, su keliais CMP laukais:
// „Employee bean“ klasės viešoji klasė „EmployeeBean“ įgyvendina java.ejb.EntityBean {// egzempliorių laukus EntityContext ejbContext; // konteinerio valdomi laukai public intidentity; public String firstName; public String lastName; valstybės dvigubas atlyginimas; viešasis adresas; public Integer ejbCreate (int id, String fname, String lname) {tapatybė = id; vardas = vardas; pavardė = lname; return null; } ...} // Nuo adreso priklausanti klasė viešoji klasė Adresas įgyvendina Serializable {public String street; viešasis styginių miestas; viešoji styginė valstybė; viešasis styginių užtrauktukas; } Kai reliacinė duomenų bazė naudojama atkaklumui, primityvūs laukai, pvz tapatybė, Pirmas vardas, pavardėir atlyginimas yra gana lengva išlaikyti, nes jie gerai susiejami su SQL tipais, tokiais kaip INTEGER, CHARir DVIGUBAS.
EJB 1.1 pateikia CMP pupelių XML diegimo aprašą cmp laukas elementai, skirti pupelių klasėje nustatyti nuolatinius laukus (konteinerio valdomus laukus). Kaip parodyta žemiau, cmp laukas elementai naudojami norint atskirti laukus, kurie yra įrašyti į duomenų bazę, ir tuos, kurie nėra. Pavyzdžiui, ejbKontekstas laukas nėra įtrauktas į sudėtinių rodinių valdomų laukų sąrašą, todėl nėra nuolatinis laukas.
DarbuotojasEJB ... Konteineris ... tapatybės vardasPavardėPavadinimo algos adresas ...
Konteinerių tiekėjas pateikia įrankį, skirtą nuolatiniams pupelių laukams susieti su duomenų bazės lentelių stulpeliais, paprastai po vieną lentelę kiekvienai pupelei. Serijiniai tipai, tokie kaip Adresastačiau sunkiau išsilaikyti. EJB 1.1 versijoje nėra standartinio serijinių objektų susiejimo su reliacine duomenų baze būdo. nors Adresas klasė turi savo laukų rinkinį, XML diegimo aprašas nepateikia tų laukų susiejimo su duomenų baze mechanizmo. Daugeliu atvejų buvo tikimasi, kad serijiniai objektai, tokie kaip Adresas būtų išlieka kaip dvejetainis tipas, kuris kartais vadinamas a dėmė tipo, į duomenų bazės lentelę.
Ši problema dar labiau paaštrėja, nes subjekto pupelių duomenų schema tampa vis sudėtingesnė. An Darbuotojas Pavyzdžiui, pupelė gali turėti daug panašių vaikų objektų Adresas, toks kaip Privalumai ir Darbo vieta. Šie antriniai objektai, vadinami priklausomaisiais objektais, gali sudaryti sudėtingus objektų grafikus, apimančius kelias lenteles reliacinėje duomenų bazėje. Be to, EJB 1.1 CMP iš esmės nėra pakankamas palaikyti santykius su kitomis pupelėmis. EJB 1.1 versijoje, jei pupelė turėtų palaikyti ryšį su kita pupele, konteineris automatiškai naudos pirminį raktą arba rankeną kaip nuorodą. Tai pasirodė esąs gana neapdorotas santykių palaikymo su kitomis pupelėmis mechanizmas, kurio natūralus ryšys gali būti dvikryptis arba priklausomas nuo laukų, kuriuos nėra lengva atvaizduoti pagrindiniu raktu ar rankena.
EJB 2.0 CMP modelis
„EJB 2.0“ nauja sutartis tarp CMP subjekto pupelių ir atkaklumo tvarkytuvės leidžia apibrėžti sudėtingesnius ir nešiojamus pupelių pupelių, pupelių ir priklausomų ir net priklausomų objektų santykius subjekto pupelėse.
Nuolatinis vadybininkas yra naujas „Enterprise JavaBeans“ diegimo proceso dalyvis. Konteinerių pardavėjas arba pardavėjas, kuris specializuojasi tam tikros duomenų bazės atkaklumo srityje, gali pateikti atkaklumo tvarkytuvę. Idėja yra atskirti mechanizmą, naudojamą pupelių santykiams valdyti, nuo talpyklos, kuri yra atsakinga už saugumo, operacijų ir išteklių valdymą. Atskyrus atsakomybę, skirtingi atkaklumo vadybininkai leidžia dirbti su skirtingais konteineriais. Tai taip pat leidžia subjekto pupelėms tapti labiau nešiojamoms EJB pardavėjams ir patvarumo valdytojams.
Jei dirbote ar studijavote „CocoBase“, „Thought Inc.“ produktą, kuris automatiškai generuoja BMP (pupelių valdomo patvarumo) pupeles EJB 1.1 konteineriams, jūs jau esate šiek tiek susipažinęs su tuo, kaip gali veikti atkaklus valdytojo įrankis. „CocoBase“ sukuria visą BMP pupelių prieigos prie duomenų bazės logiką, remdamasi pupelių diegėjo pateikta objekto ir reliacijos žemėlapio informacija. „EJB 2.0“ versijoje atkaklumo valdytojas gali sukurti CMP subjektų atvaizdavimą reliacinėje duomenų bazėje, remdamasis diegimo aprašo pateikta informacija, pupelės abstrakčia atkaklumo schema ir diegėjo atliktu darbu. Tačiau atkaklumo valdytojas neapsiriboja reliacine duomenų baze. Tvarumo valdytojai taip pat gali būti sukurti objektų duomenų bazėms, taip pat senoms ir ERP sistemoms, tokioms kaip SAP.
Kad atkaklumo vadybininkas būtų atskirtas nuo konteinerio, turėjo būti apibrėžta pupelių ir atkaklumo vadybininko sutartis. Sutartis pasireiškia naujoje abstrakčioje atkaklumo schemoje. Ši schema apibrėžiama naudojant naują XML elementų rinkinį diegimo apraše ir kodo idiomų rinkinį CMP subjekto pupelėse. EJB 2.0 versijoje CMP pupelių klasė yra paskelbta abstrakčia, o jos nuolatiniai ir ryšių laukai pasiekiami naudojant abstrakčius prieigos ir mutatoriaus metodus, kurių metodo parašai susiejami su specialiais XML diegimo aprašo elementais.
Kai diegsite pupelę, naudosite nuolatinius tvarkytuvės įrankius, kad sukurtumėte konkretų abstrakčios pupelių klasės ir nuo jos priklausančių objektų klasių įgyvendinimą pagal XML diegimo aprašą ir pupelių klasę. Konkrečiuose diegimuose bus prieigos prie duomenų kodas, kuris vykdymo metu iš tikrųjų nuskaitys ir įrašys pupelių būseną į duomenų bazę. Vykdymo metu sudėtinis rodinys naudoja atkaklumo tvarkytuvo įrankių sugeneruotus poklasius, o ne abstrakčias klases, kurias apibrėžia pupelių teikėjas.
Norėdami pateikti šiek tiek mėsos diskusijai, pateikiamas CMP subjekto pavyzdys, kuriame konkrečiau paaiškinama, kaip veikia abstrakti patvarumo schema.
CMP subjekto pavyzdys EJB 2.0 versijoje
EJB 2.0 konteinerio valdoma subjekto pupelė apibrėžta kaip abstrakti, o jos nuolatiniai laukai pupelių klasėje nėra tiesiogiai apibrėžti. Vietoj to buvo sukurta abstrakti nuolatinė schema, leidžianti pupelių tiekėjui nuolatinius laukus ir ryšius su pupelėmis deklaruoti netiesiogiai. Žemiau yra pavyzdys Darbuotojas pupelė, naudojanti naują abstrakčią nuolatinę schemą. Atkreipkite dėmesį, kad nė vienas iš nuolatinių laukų nėra deklaruotas pupelių klasėje.
viešas abstraktus „EmployeeBean“ įgyvendina javax.ejb.EntityBean {. // egzemplioriaus laukai EntityContext ejbContext; // konteinerio valdomi nuolatiniai laukai public abstract void setIdentity (int identity); public abstract int getIdentity (); public abstract void setFirstName (String firstName); vieša abstrakti eilutė getFirstName (); public abstract void setLastName (String lastName); vieša abstrakta eilutė getLastName (); // konteinerio valdomų santykių laukai public abstract void setContactInfo (ContactInfo info); vieša santrauka „ContactInfo“ getContactInfo (); ...} Šios pupelės XML diegimo apraše abstrakčioji patvarumo schema skelbia konteinerio valdomus laukus ir ryšius.
DarbuotojasEJB ... Konteineris ... tapatybės vardasPavardėPavardė ... SusisiekiteInfo KontaktaiInfo gatvės miesto valstija pašto adresasPhone darbasTelefono el. Paštas ... Darbuotojas-kontaktasInfo darbuotojas-turi-kontaktinę informaciją apie vieną Darbuotojas
