Enterprise JavaBeans 2.0, der blev udgivet 2. juni, er ikke kun en punktudgivelse, men også en ny version af specifikationen. På godt 500 sider er EJB 2.0-specifikationen 200 sider (66 procent) længere end den tidligere EJB 1.1-specifikation. De vigtigste ændringer i specifikationen er dem, der foretages i containeradministreret persistens (CMP) og introduktionen af en helt ny bønnetype, MessageDrivenBean.
Hovedparten af ændringerne i EJB 2.0 findes i definitionen af en ny CMP-komponentmodel. Det er radikalt forskelligt fra den gamle CMP-model, fordi den introducerer en helt ny deltager, the persistens manager, og en helt ny måde at definere containerstyrede felter på, såvel som forhold til andre bønner og afhængige objekter.
Indførelsen af MessageDrivenBean (meddelelsesbønnen) er også vigtig. Meddelelsesbønnen repræsenterer integrationen af JMS (Java Message Service) med EJB for at oprette en helt ny type bønner designet til at håndtere asynkrone JMS-meddelelser. Den spændende nye bønnetype giver en komponentmodel til JMS-klienter, der gør det muligt for dem at blive implementeret i det rige og robuste miljø i et EJB-containersystem.
Der er mange andre mindre ændringer foretaget i specifikationen. Disse andre ændringer er, selvom de er vigtige, mest beskæftiget med at stramme specifikationen for at fjerne uklarheder og gøre komponenterne mere bærbare. Denne artikel fokuserer på de nye CMP- og meddelelsesbønnekomponentmodeller introduceret i EJB 2.0.
Jeg giver flere konkrete eksempler, så det skal være ret let at følge og forstå. EJB-nybegyndere kan dog finde materialet vanskeligere, da det antages, at læsere har en grundlæggende forståelse af EJB. For mere information om EJB'er, se Ressourcer.
Containerstyret vedholdenhed
Containerstyret vedholdenhed har gennemgået radikale ændringer i EJB 2.0. I EJB 2.0 håndterer persistensadministratoren vedvarende CMP-enhedsbønner automatisk ved kørsel. Persistensadministratoren er ansvarlig for at kortlægge enhedens bønne til databasen baseret på en ny kontrakt med bønne-persistens manager kaldet abstrakt persistensskema. Derudover er persistensmanageren ansvarlig for at implementere og udføre find-metoder, der er baseret på et nyt forespørgselssprog kaldet EJB QL.
Det er vigtigt at bemærke, at produkter, der overholder EJB 2.0-specifikationen, skal understøtte EJB 1.1 CMP-modellen såvel som den nye EJB 2.0-model. Selvom disse modeller ikke er kompatible, kræves der support til EJB 1.1-modellen for at sikre bagudkompatibilitet.
Det abstrakte persistensskema
For at forstå, hvordan det abstrakte persistensskema fungerer, og hvorfor det er vigtigt, vil jeg hurtigt gennemgå for dig, hvordan CMP håndteres i EJB 1.1, og derefter diskutere, hvordan det er defineret i EJB 2.0.
EJB 1.1 CMP-modellen
I EJB 1.1 er bønneudvikleren ansvarlig for at erklære bønneklassens vedvarende felter som enten Java-primitive eller serieiserbare typer. De følgende eksempler viser en Medarbejder Enterprise Bean Class, som defineret i EJB 1.1, med flere CMP-felter:
// medarbejderbønneklassen offentlig klasse EmployeeBean implementerer java.ejb.EntityBean {// instansfelter EntityContext ejbContext; // containeradministrerede felter offentlig int-identitet; offentlig streng fornavn; offentlig streng efternavn; offentlig dobbelt løn offentlig adresse public Integer ejbCreate (int id, String fname, String lname) {identity = id; fornavn = fnavn; efternavn = lname; returnere null; } ...} // Adresseafhængig klasse offentlig klasse Adresse implementerer Serialiserbar {offentlig String street; offentlig String by; offentlig strengstat; offentlig lynlås; } Når en relationsdatabase bruges til vedholdenhed, er de primitive felter som f.eks identitet, fornavn, efternavnog løn er ret lette at vedvare, da de kortlægges pænt til SQL-typer som f.eks HELTAL, CHARog DOBBELT.
I EJB 1.1 leverer XML-implementeringsbeskrivelsen for en CMP-bønne cmp-felt elementer til identifikation af de vedvarende felter (containeradministrerede felter) i bønneklassen. Som vist nedenfor er cmp-felt elementer bruges til at skelne mellem de felter, der er skrevet til databasen, og dem der ikke er. F.eks ejbContext felt er ikke medtaget på listen over containeradministrerede felter og er derfor ikke et vedvarende felt.
MedarbejderEJB ... Container ... identitet fornavn efternavn lønadresse ...
Containerudbyderen leverer et værktøj til at kortlægge bønnens vedvarende felter til kolonnerne i databasetabellerne, normalt en tabel pr. Bønne. Serialiserbare typer såsom Adresseer imidlertid sværere at vedholde. I EJB 1.1 er der ingen standard måde at kortlægge objekter, der kan serialiseres, til en relationsdatabase. Selvom Adresse klasse har sit eget sæt felter, XML-implementeringsbeskrivelsen giver ikke en mekanisme til at kortlægge disse felter til databasen. I de fleste tilfælde forventedes det, at genstande, der kan serialiseres, f.eks Adresse ville være vedvarende som en binær type, som undertiden kaldes en klat type til en databasetabel.
Problemet forværres, da enhedsbønnens dataskema vokser i kompleksitet. En Medarbejder bønne kan for eksempel have mange børneobjekter, der ligner Adresse, såsom Fordele og Job position. Disse underordnede objekter, kaldet afhængige objekter, kan danne komplekse objektgrafer, der spænder over flere tabeller i en relationsdatabase. Derudover er CMP i EJB 1.1 stort set utilstrækkelig til vedvarende forhold til andre bønner. I EJB 1.1, hvis en bønne skulle opretholde et forhold til en anden bønne, ville containeren automatisk bruge den primære nøgle eller håndtag som et link. Det har vist sig at være en ret rå mekanisme til at opretholde forhold til andre bønner, hvis naturlige forhold kan være tovejs eller afhængigt af felter, der ikke let er repræsenteret af den primære nøgle eller håndtag.
EJB 2.0 CMP-modellen
I EJB 2.0 giver en ny kontrakt mellem CMP-enhedens bønne og persistensmanager dig mulighed for at definere mere komplekse og bærbare bønne-til-bønner, bønner-afhængige og endda afhængige-afhængige objektforhold inden for en enhedsbønne.
Den vedvarende manager er en ny deltager i Enterprise JavaBeans implementeringsprocessen. Containerleverandøren eller en leverandør, der er specialiseret i vedholdenhed til en bestemt database, kan levere persistensadministratoren. Ideen er at adskille den mekanisme, der bruges til at styre bønneforhold, fra containeren, som er ansvarlig for styring af sikkerhed, transaktioner og ressourcer. Adskillelsen af ansvarsområder gør det muligt for forskellige persistensledere at arbejde med forskellige containere. Det giver også enhedsbønner mulighed for at blive mere bærbare på tværs af EJB-leverandører såvel som persistensadministratorer.
Hvis du har arbejdet med eller studeret CocoBase, et produkt fra Thought Inc., der automatisk genererer BMP (Bean Managed Persistence) bønner til EJB 1.1-containere, er du allerede lidt fortrolig med, hvordan et vedvarende managerværktøj kan fungere. CocoBase genererer al databaseadgangslogik for BMP-bønner baseret på information om objekt-til-relationskortlægning leveret af bønneinstallatøren. I EJB 2.0 kan persistensadministratoren generere en kortlægning af CMP-enheder til en relationsdatabase baseret på information leveret af installationsbeskrivelsen, bønnens abstrakte persistensskema og arbejde udført af deployeren. Persistensadministratoren er dog ikke begrænset til en relationsdatabase. Persistensledere kan også udvikles til objektdatabaser såvel som ældre og ERP-systemer som SAP.
For at persistensmanageren kunne adskilles fra containeren, måtte der defineres en kontrakt mellem bønnen og persistensmanageren. Kontrakten manifesteres i det nye abstrakte skema for vedholdenhed. Dette skema er defineret gennem et nyt sæt XML-elementer i implementeringsbeskrivelsen og et sæt kodeidiomer i CMP-enhedsbønnerne. I EJB 2.0 erklæres CMP-bønneklassen som abstrakt, og der er adgang til dens vedvarende felter og forholdsfelter ved hjælp af abstrakte accessor- og mutatormetoder, hvis metodesignaturer kortlægges til specielle elementer i XML-implementeringsbeskrivelsen.
Når bønnen er implementeret, bruger du vedvarende managerværktøjer til at generere en konkret implementering af den abstrakte bønneklasse og dens afhængige objektklasser baseret på XML-implementeringsbeskrivelsen og bønneklassen. De konkrete implementeringer vil omfatte dataadgangskoden, der rent faktisk læser og skriver bønnens tilstand til databasen ved kørsel. Ved kørsel bruger containeren de underklasser, der genereres af persistensstyringsværktøjerne i stedet for de abstrakte klasser, der er defineret af bønneudbyderen.
For at give noget kød til diskussionen gives der et eksempel på en CMP-enhed, der mere konkret forklarer, hvordan det abstrakte persistensskema fungerer.
Et eksempel på CMP-enhed i EJB 2.0
I EJB 2.0 defineres en containerstyret enhedsbønne som abstrakt, og dens vedvarende felter defineres ikke direkte i bønneklassen. I stedet for er der udviklet et abstrakt vedvarende skema, der lader bønneudbyderen indirekte erklære de vedvarende felter og bønneforhold. Nedenfor er et eksempel på Medarbejder bønne, der bruger det nye abstrakte vedvarende skema. Bemærk, at ingen af de vedvarende felter er angivet i bønneklassen.
offentlig abstrakt EmployeeBean implementerer javax.ejb.EntityBean {. // instansfelter EntityContext ejbContext; // containerstyrede vedvarende felter offentlig abstrakt ugyldigt setIdentity (int-identitet); offentlig abstrakt int getIdentity (); offentlig abstrakt ugyldigt setFirstName (String firstName); offentlig abstrakt String getFirstName (); offentlig abstrakt ugyldigt setLastName (streng efternavn); offentlig abstrakt String getLastName (); // container-administrerede forholdsfelter offentlig abstrakt ugyldigt setContactInfo (ContactInfo info); offentlig abstrakt ContactInfo getContactInfo (); ...} I XML-implementeringsbeskrivelsen for denne bønne erklærer det abstrakte persistensskema de containerstyrede felter og relationer.
MedarbejderEJB ... Container ... identitet fornavn efternavn ... KontaktInfo KontaktInfo gade bystat zip-telefonTelefonarbejdeTelefon-e-mail ... Medarbejder-ContactInfo medarbejder-har-kontaktinfo en MedarbejderEJB kontaktInfo KontaktInfo kontaktinfo_tilhører_medarbejder en KontaktInfo
