Enterprise JavaBeans 2.0, utgitt 2. juni, er ikke bare en poengutgivelse, men også en ny versjon av spesifikasjonen. På litt over 500 sider er EJB 2.0-spesifikasjonen 200 sider (66 prosent) lengre enn den forrige EJB 1.1-spesifikasjonen. De viktigste endringene i spesifikasjonen er de som er gjort til container-managed persistence (CMP) og introduksjonen av en helt ny bønnetype, MessageDrivenBean.
Hovedtyngden av endringene i EJB 2.0 finnes i definisjonen av en ny CMP-komponentmodell. Det er radikalt forskjellig fra den gamle CMP-modellen fordi den introduserer en helt ny deltaker, the utholdenhetsleder, og en helt ny måte å definere containerstyrte felt på, samt forhold til andre bønner og avhengige objekter.
Innføringen av MessageDrivenBean (meldingsbønnen) er også viktig. Meldingsbønnen representerer integrasjonen av JMS (Java Message Service) med EJB for å lage en helt ny type bønner designet for å håndtere asynkrone JMS-meldinger. Den spennende nye bønnetypen gir en komponentmodell for JMS-klienter, slik at de kan distribueres i det rike og robuste miljøet til et EJB-containersystem.
Det er mange andre mindre endringer som er gjort i spesifikasjonen. De andre endringene, selv om de er viktige, er mest opptatt av å stramme spesifikasjonen for å eliminere uklarheter og gjøre komponentene mer bærbare. Denne artikkelen fokuserer på de nye CMP- og meldingsbønnekomponentmodellene introdusert i EJB 2.0.
Jeg gir flere konkrete eksempler, så det skal være ganske enkelt å følge og forstå. EJB-nybegynnere kan imidlertid finne materialet vanskeligere siden det antas at leserne har en grunnleggende forståelse av EJB. For mer informasjon om EJB, se Ressurser.
Beholderstyrt utholdenhet
Beholderstyrt utholdenhet har gjennomgått radikale endringer i EJB 2.0. I EJB 2.0 håndterer persistensbehandleren persistens av CMP-enhetsbønner automatisk ved kjøretid. Utholdenhetsansvarlig er ansvarlig for å kartlegge enhetsbønnen til databasen basert på en ny kontrakt for bønne-utholdenhetsleder kalt abstrakt utholdenhetsskjema. I tillegg er utholdenhetsansvarlig ansvarlig for å implementere og utføre finnemetoder basert på et nytt spørrespråk kalt EJB QL.
Det er viktig å merke seg at produkter som oppfyller EJB 2.0-spesifikasjonen, må støtte både EJB 1.1 CMP-modellen og den nye EJB 2.0-modellen. Selv om disse modellene ikke er kompatible, kreves det støtte for EJB 1.1-modellen for å sikre bakoverkompatibilitet.
Det abstrakte utholdenhetsskjemaet
For å forstå hvordan det abstrakte utholdenhetsskjemaet fungerer og hvorfor det er viktig, vil jeg raskt gjennomgå for deg hvordan CMP håndteres i EJB 1.1, og deretter diskutere hvordan det er definert i EJB 2.0.
EJB 1.1 CMP-modellen
I EJB 1.1 er bønneutvikleren ansvarlig for å erklære bønneklassens vedvarende felt som enten Java-primitive eller serieiserbare typer. Følgende eksempler viser en Ansatt enterprise bønne klasse, som definert i EJB 1.1, med flere CMP felt:
// den offentlige klassen EmployeeBean implementerer java.ejb.EntityBean {// forekomstfelt EntityContext ejbContext; // container-administrerte felt offentlig int identitet; offentlig streng fornavn; offentlig strengens etternavn; offentlig dobbeltlønn; offentlig adresse; public Integer ejbCreate (int id, String fname, String lname) {identity = id; fornavn = fname; etternavn = lname; return null; } ...} // Adresseavhengig klasse offentlig klasse Adresse implementerer Serializable {public String street; offentlig String city; offentlig strengstat; offentlig streng zip; } Når en relasjonsdatabase brukes til utholdenhet, vil de primitive feltene som identitet, fornavn, etternavn, og lønn er ganske enkle å vedvare siden de tilordnes pent til SQL-typer som INTEGER, CHAR, og DOBBELT.
I EJB 1.1 gir XML-distribusjonsbeskrivelsen til en CMP-bønne cmp-felt elementer for å identifisere de vedvarende feltene (containerstyrte felt) i bønneklassen. Som vist nedenfor, cmp-felt elementer brukes til å skille mellom feltene som er skrevet til databasen og de som ikke er det. For eksempel ejbContext feltet er ikke inkludert i listen over containerstyrte felt og er derfor ikke et vedvarende felt.
EmployeeEJB ... Container ... identitet fornavn etternavn lønnsadresse ...
Containerleverandøren leverer et verktøy for å kartlegge bønnens vedvarende felt til kolonnene i databasetabellene, vanligvis en tabell per bønne. Serialiserbare typer som Adresseer imidlertid vanskeligere å vedvare. I EJB 1.1 er det ingen standard måte å kartlegge gjenstander som kan serieiseres til en relasjonsdatabase. Selv om Adresse klasse har sitt eget sett med felt, gir ikke XML-distribusjonsbeskrivelsen en mekanisme for å kartlegge disse feltene til databasen. I de fleste tilfeller var det forventet at serieobjekter som Adresse ville være vedvarende som en binær type, som noen ganger kalles a klatt type, til en databasetabell.
Det problemet forverres ettersom enhetsbønnens dataskjema vokser i kompleksitet. An Ansatt bønne kan for eksempel ha mange barneobjekter som ligner på Adresse, som for eksempel fordeler og Jobb stilling. Disse underordnede objektene, kalt avhengige objekter, kan danne komplekse objektgrafer som strekker seg over flere tabeller i en relasjonsdatabase. I tillegg er CMP i EJB 1.1 stort sett utilstrekkelig for vedvarende forhold til andre bønner. I EJB 1.1, hvis en bønne skulle opprettholde et forhold til en annen bønne, ville containeren automatisk bruke primærnøkkelen eller håndtaket som en lenke. Det har vist seg å være en ganske rå mekanisme for å opprettholde forhold til andre bønner hvis naturlige forhold kan være toveis eller avhengig av felt som ikke lett representeres av primærnøkkelen eller håndtaket.
EJB 2.0 CMP-modellen
I EJB 2.0 lar en ny kontrakt mellom CMP-enhetens bønne og utholdenhetsbehandling definere mer komplekse og bærbare bønne-til-bønner, bønne-til-avhengige og til og med avhengige-til-avhengige objektforhold innenfor en enhetsbønne.
Den vedvarende lederen er en ny deltaker i Enterprise JavaBeans distribusjonsprosessen. Containerleverandøren eller en leverandør som spesialiserer seg på utholdenhet til en bestemt database, kan gi utholdenhetsbehandling. Ideen er å skille mekanismen som brukes til å administrere bønneforhold fra containeren, som er ansvarlig for styring av sikkerhet, transaksjoner og ressurser. Adskillelsen av ansvarsforhold gjør at forskjellige utholdenhetsledere kan jobbe med forskjellige containere. Det gjør det også mulig for enhetsbønner å bli mer bærbare på tvers av EJB-leverandører så vel som utholdenhetsledere.
Hvis du har jobbet med eller studert CocoBase, et produkt fra Thought Inc. som automatisk genererer BMP (Bean Managed Persistence) bønner for EJB 1.1-containere, er du allerede litt kjent med hvordan et vedvarende lederverktøy kan fungere. CocoBase genererer all databasetilgangslogikk for BMP-bønner basert på informasjon om objekt-til-relasjonell kartlegging gitt av bønnedistribusjonen. I EJB 2.0 kan utholdenhetsbehandling generere en kartlegging av CMP-enheter til en relasjonsdatabase basert på informasjon gitt av distribusjonsbeskrivelsen, bønnens abstrakte utholdenhetsskjema og arbeid utført av distribusjonen. Utholdenhetslederen er imidlertid ikke begrenset til en relasjonsdatabase. Persistensledere kan også utvikles for objektdatabaser samt eldre og ERP-systemer som SAP.
For at utholdenhetsforvalteren kunne skilles fra beholderen, måtte det defineres en kontrakt mellom bønnen og utholdenhetsforvalteren. Kontrakten manifesteres i det nye abstrakte utholdenhetsskjemaet. Dette skjemaet er definert gjennom et nytt sett med XML-elementer i distribusjonsbeskrivelsen og et sett med kodeidiomer i CMP-enhetsbønnene. I EJB 2.0 blir CMP-bønneklassen erklært som abstrakt, og dens vedvarende felt og relasjonsfelt er tilgjengelig ved hjelp av abstrakte tilgangs- og mutatormetoder hvis metodesignaturer tilordnes til spesielle elementer i XML-distribusjonsbeskrivelsen.
Når bønnen distribueres, vil du bruke vedvarende lederverktøy for å generere en konkret implementering av den abstrakte bønneklassen og dens avhengige objektklasser basert på XML-distribusjonsbeskrivelsen og bønneklassen. De konkrete implementeringene vil omfatte datatilgangskoden som faktisk vil lese og skrive bønnens tilstand til databasen ved kjøretid. Ved kjøretid bruker containeren underklassene som genereres av verktøyene for utholdenhetsbehandling i stedet for de abstrakte klassene som er definert av bønneleverandøren.
For å gi litt kjøtt til diskusjonen, gis et eksempel på en CMP-enhet som forklarer mer konkret hvordan det abstrakte utholdenhetsskjemaet fungerer.
Et eksempel på CMP-enhet i EJB 2.0
I EJB 2.0 er en containerstyrt enhetsbønne definert som abstrakt, og dens vedvarende felt er ikke definert direkte i bønneklassen. I stedet er det utviklet et abstrakt vedvarende skjema som lar bønneleverandøren erklære de vedvarende feltene og bønneforholdene indirekte. Nedenfor er et eksempel på Ansatt bønne som bruker det nye abstrakte vedvarende skjemaet. Legg merke til at ingen av de vedvarende feltene er erklært i bønneklassen.
offentlig abstrakt EmployeeBean implementerer javax.ejb.EntityBean {. // forekomstfelt EntityContext ejbContext; // container-administrerte vedvarende felt offentlig abstrakt ugyldig setIdentity (int identitet); offentlig abstrakt int getIdentity (); offentlig abstrakt ugyldig setFirstName (streng fornavn); offentlig abstrakt String getFirstName (); offentlig abstrakt ugyldig setLastName (String etternavn); offentlig abstrakt String getLastName (); // container-administrerte forhold felt offentlig abstrakt ugyldig setContactInfo (ContactInfo info); offentlig abstrakt KontaktInfo getContactInfo (); ...} I XML-distribusjonsbeskrivelsen for den bønnen erklærer det abstrakte utholdenhetsskjemaet de containerstyrte feltene og relasjonene.
EmployeeEJB ... Container ... identitet fornavn etternavn ... ContactInfo ContactInfo street city state zip homeTelefonarbeidTelefon e-post ... Employee-ContactInfo medarbeider-har-contactinfo en ansattEJB contactInfo ContactInfo contactinfo_belongsto_ Employee one ContactInfo
