Enterprise JavaBeans 2.0, kas izlaists 2. jūnijā, nav tikai punktu izlaidums, bet arī jauna specifikācijas versija. EJB 2.0 specifikācija ar nedaudz vairāk nekā 500 lappusēm ir par 200 lappusēm (par 66 procentiem) garāka nekā iepriekšējā EJB 1.1 specifikācija. Vissvarīgākās izmaiņas specifikācijā ir tās, kas veiktas konteineru pārvaldītā noturībā (CMP), un pilnīgi jauna pupiņu veida - MessageDrivenBean.
Lielākā daļa izmaiņu EJB 2.0 ir atrodamas jauna CMP komponenta modeļa definīcijā. Tas radikāli atšķiras no vecā CMP modeļa, jo tas ievieš pilnīgi jaunu dalībnieku neatlaidības menedžeris, un pilnīgi jauns veids, kā definēt konteineru pārvaldītos laukus, kā arī attiecības ar citām pupiņām un atkarīgajiem objektiem.
Programmas ieviešana MessageDrivenBean (ziņojuma pupiņa) ir arī nozīmīga. Ziņojuma pupiņa apzīmē JMS (Java Message Service) integrāciju ar EJB, lai izveidotu pilnīgi jauna veida pupiņas, kas paredzētas asinhrono JMS ziņojumu apstrādei. Šis aizraujošais jaunais pupiņu veids nodrošina JMS klientiem komponentu modeli, ļaujot tos izvietot bagātīgā un izturīgā EJB konteineru sistēmas vidē.
Specifikācijā ir veiktas daudzas citas mazākas izmaiņas. Lai arī šīs citas izmaiņas ir svarīgas, tās galvenokārt attiecas uz specifikācijas pastiprināšanu, lai novērstu neskaidrības un padarītu komponentus pārnēsājamākus. Šis raksts koncentrējas uz jaunajiem CMP un ziņojumu pupu komponentu modeļiem, kas ieviesti EJB 2.0.
Es sniedzu vairākus konkrētus piemērus, tāpēc tam jābūt diezgan viegli sekojamam un saprotamam. EJB iesācējiem materiāls tomēr varētu būt grūtāks, jo tiek pieņemts, ka lasītājiem ir pamatzināšanas par EJB. Lai iegūtu papildinformāciju par EJB, lūdzu, skatiet resursus.
Konteineru pārvaldīta noturība
Konteineru pārvaldītā neatlaidība ir radikāli mainījusi EJB 2.0. EJB 2.0 versijā noturības pārvaldnieks izpildes laikā automātiski apstrādā CMP entītijas pupiņu noturību. Neatlaidības pārvaldnieks ir atbildīgs par entītijas pupiņu kartēšanu datubāzē, pamatojoties uz jaunu pupu noturības pārvaldnieka līgumu ar nosaukumu abstrakta noturības shēma. Turklāt neatlaidības pārvaldnieks ir atbildīgs par meklēšanas metožu ieviešanu un izpildi, pamatojoties uz jaunu vaicājuma valodu, ko sauc EJB QL.
Ir svarīgi atzīmēt, ka produktiem, kas atbilst EJB 2.0 specifikācijai, jāatbalsta EJB 1.1 CMP modelis, kā arī jaunais EJB 2.0 modelis. Lai gan šie modeļi nav saderīgi, EJB 1.1 modelim ir nepieciešams atbalsts, lai nodrošinātu savietojamību atpakaļ.
Abstraktā noturības shēma
Lai saprastu, kā darbojas abstraktā noturības shēma un kāpēc tā ir svarīga, es jums ātri pārskatīšu, kā ar CMP rīkojas EJB 1.1, un pēc tam apspriedīšu, kā tas ir definēts EJB 2.0.
EJB 1.1 CMP modelis
EJB 1.1 pupiņu izstrādātājs ir atbildīgs par pupiņu klases pastāvīgo lauku pasludināšanu par Java primitīviem vai seriālizējamiem tipiem. Šie piemēri parāda Darbinieks uzņēmuma pupiņu klase, kā noteikts EJB 1.1, ar vairākiem CMP laukiem:
// Employee bean klases publiskā klase EmployeeBean īsteno java.ejb.EntityBean {// instances laukus EntityContext ejbContext; // konteineru pārvaldītie lauki public int identitāte; public String firstName; public String lastName; valsts dubultā alga; publiskās adreses adrese; public Integer ejbCreate (int id, String fname, String lname) {identitāte = id; firstName = fname; uzvārds = uzvārds; return null; } ...} // No adreses atkarīgā klase publiskā klase Adrese īsteno Serializējamo {publisko virknes ielu; publiskā Stīgu pilsēta; valsts stīgu valsts; publiskais stīgu rāvējslēdzējs; } Ja neatlaidībai tiek izmantota relāciju datu bāze, primitīvie lauki, piemēram, identitāti, vārds, uzvārds, un alga ir diezgan viegli saglabājamas, jo tās labi piesaista SQL tipus, piemēram, VESELS SKAITLIS, CHAR, un DUBULA.
EJB 1.1 nodrošina CMP pupiņu XML izvietošanas deskriptors cmp lauks elementi pastāvīgo lauku (konteineru pārvaldīto lauku) identificēšanai pupiņu klasē. Kā parādīts zemāk, cmp lauks elementi tiek izmantoti, lai atšķirtu laukus, kas ir ierakstīti datu bāzē, un tos, kuri nav. Piemēram, ejbKonteksts lauks nav iekļauts konteineru pārvaldīto lauku sarakstā, un tāpēc tas nav pastāvīgs lauks.
DarbinieksEJB ... Konteiners ... identitātes vārdsVārds uzvārds algas adrese ...
Konteineru nodrošinātājs piegādā rīku pupiņu pastāvīgo lauku kartēšanai datu bāzu tabulu kolonnās, parasti viena tabula uz pupiņu. Serializējami veidi, piemēram, Adresetomēr ir grūtāk pastāvēt. EJB 1.1 nav standarta paņēmiena, kā sērijveidojamos objektus kartēt relāciju datu bāzē. Lai gan Adrese klasei ir savs lauku kopums, XML izvietošanas deskriptors nenodrošina mehānismu šo lauku kartēšanai datu bāzē. Vairumā gadījumu tika sagaidīts, ka seriālizējami objekti, piemēram, Adrese tiktu saglabāts kā binārs tips, ko dažreiz sauc par a lāse ierakstiet datu bāzes tabulā.
Šī problēma tiek saasināta, jo entītijas pupiņu datu shēma kļūst arvien sarežģītāka. An Darbinieks piemēram, pupā var būt daudz bērnu priekšmetu, kas līdzīgi Adrese, piemēram, Ieguvumi un Darba pozīcija. Šie bērnu objekti, kurus sauc par atkarīgiem objektiem, var veidot sarežģītus objektu grafikus, kas aptver vairākas tabulas relāciju datu bāzē. Turklāt CMP EJB 1.1 versijā lielākoties ir nepietiekams pastāvīgām attiecībām ar citām pupiņām. EJB 1.1 gadījumā, ja pupai būtu jāuztur attiecības ar citu pupiņu, konteiners kā saiti automātiski izmantotu primāro atslēgu vai rokturi. Tas ir izrādījies diezgan neapstrādāts mehānisms attiecību uzturēšanai ar citām pupiņām, kuru dabiskās attiecības var būt divvirzienu vai atkarīgas no laukiem, kurus nav viegli attēlot ar primāro atslēgu vai rokturi.
EJB 2.0 CMP modelis
Programmā EJB 2.0 jauns līgums starp CMP entītijas pupiņu un neatlaidības pārvaldnieku ļauj noteikt sarežģītākas un pārnēsājamākas pupu-pupiņu, pupu-atkarīgu un pat atkarīgu-atkarīgu objektu attiecības uzņēmuma pupiņā.
Neatlaidīgais pārvaldnieks ir jauns Enterprise JavaBeans izvietošanas procesa dalībnieks. Konteineru pārdevējs vai pārdevējs, kas specializējas neatlaidības uzturēšanā noteiktā datubāzē, var nodrošināt noturības pārvaldnieku. Ideja ir nošķirt pupiņu attiecību pārvaldības mehānismu no konteinera, kas ir atbildīgs par drošības, darījumu un resursu pārvaldību. Pienākumu nodalīšana ļauj dažādiem neatlaidības vadītājiem strādāt ar dažādiem konteineriem. Tas arī ļauj subjekta pupiņām kļūt pārnēsājamākām starp EJB pārdevējiem, kā arī neatlaidības vadītājiem.
Ja esat strādājis vai pētījis CocoBase, produktu no Thought Inc., kas automātiski ģenerē BMP (Bean Managed Persistence) pupiņas EJB 1.1 konteineriem, jūs jau esat nedaudz pārzinājis, kā varētu darboties neatlaidīgs pārvaldnieka rīks. CocoBase ģenerē visu datu bāzes piekļuves loģiku BMP pupiņām, pamatojoties uz informāciju par objektu-relāciju kartēšanas informāciju, ko sniedz pupiņu izvietotājs. EJB 2.0 versijā noturības pārvaldnieks var ģenerēt CMP entītiju kartēšanu relāciju datu bāzē, pamatojoties uz izvietošanas deskriptora sniegto informāciju, pupas abstrakto noturības shēmu un izvietotāja veikto darbu. Noturības pārvaldnieks tomēr neaprobežojas ar relāciju datu bāzi. Noturības pārvaldniekus var izstrādāt arī objektu datu bāzēm, kā arī mantotajām un ERP sistēmām, piemēram, SAP.
Lai noturības pārvaldnieks tiktu atdalīts no konteinera, bija jānosaka līgums starp pupiņu un neatlaidības pārvaldnieku. Līgums izpaužas jaunajā abstraktā noturības shēmā. Šī shēma tiek definēta, izmantojot jaunu XML elementu kopu izvietošanas aprakstā un kodu idiomu kopu CMP entītijas pupās. EJB 2.0 versijā CMP pupiņu klase tiek pasludināta par abstraktu, un tās pastāvīgajiem un attiecību laukiem piekļūst, izmantojot abstraktas piekļuves un mutatora metodes, kuru metožu paraksti tiek piesaistīti īpašiem elementiem XML izvietošanas aprakstā.
Kad pupiņa ir izvietota, jūs izmantosiet pastāvīgus pārvaldnieka rīkus, lai ģenerētu abstrakto pupiņu klases un no tām atkarīgo objektu klašu konkrētu ieviešanu, pamatojoties uz XML izvietošanas deskriptoru un pupiņu klasi. Konkrētie ieviešanas varianti ietvers datu piekļuves kodu, kas izpildlaikā faktiski nolasīs un ierakstīs pupiņu stāvokli datu bāzē. Izpildes laikā konteiners pupiņu nodrošinātāja abstrakto klašu vietā izmanto noturības pārvaldnieka rīku radītās apakšklases.
Lai diskusijai dotu nedaudz gaļas, tiek sniegts CMP entītijas piemērs, kas konkrētāk izskaidro abstraktās noturības shēmas darbību.
CMP entītijas piemērs EJB 2.0
EJB 2.0 konteinera pārvaldītā entītijas pupiņa ir definēta kā abstrakta, un tās pastāvīgie lauki nav tieši definēti pupiņu klasē. Tā vietā ir izstrādāta abstrakta noturīga shēma, kas ļauj pupiņu nodrošinātājam netieši deklarēt noturīgos laukus un pupiņu attiecības. Zemāk ir Darbinieks pupiņa, kas izmanto jauno abstrakto pastāvīgo shēmu. Ievērojiet, ka pupu klasē nav deklarēts neviens no pastāvīgajiem laukiem.
publisks abstrakts EmployeeBean ievieš javax.ejb.EntityBean {. // instances lauki EntityContext ejbContext; // konteinera pārvaldītie pastāvīgie lauki public abstract void setIdentity (int identitāte); public abstract int getIdentity (); publisks abstrakts void setFirstName (String firstName); publiski abstrakta virkne getFirstName (); public abstract void setLastName (String lastName); publiski abstrakta virkne getLastName (); // konteineru pārvaldīto attiecību lauki public abstract abstrakt void setContactInfo (ContactInfo info); publisks abstrakts ContactInfo getContactInfo (); ...} Šīs pupas XML izvietošanas aprakstā abstraktā noturības shēma deklarē konteinera pārvaldītos laukus un attiecības.
DarbinieksEJB ... Konteiners ... identitātes vārdsVarda uzvārds ...
