Programmering

EJB 3.0 i et nøtteskall

Til tross for flere positive, hindrer kompleksiteten i Enterprise JavaBeans-arkitekturen adopsjonen av J2EE. EJB-arkitekturen er trolig den eneste J2EE-komponenten som har sviktet så stort i å levere J2EEs løfte om økt utviklerproduktivitet grundig enkel utvikling. EJB 3.0 gjør et nytt forsøk på å levere det løftet ved å redusere EJBs kompleksitet for utviklere. EJB 3.0 reduserer antall programmeringsgjenstander som utviklere kan tilby, eliminerer eller minimerer tilbakeringingsmetoder som kreves for å implementeres, og reduserer kompleksiteten til enhetsbønneprogrammeringsmodellen og O / R-kartleggingsmodellen.

I denne artikkelen dekker jeg først de viktigste endringene i EJB 3.0. Det er viktig å ha det grunnleggende på plass før du dykker ned i EJB 3.0-bassenget. Deretter gir jeg et oversikt på høyt nivå av EJB 3.0-utkastet og går deretter inn på detaljene i den foreslåtte spesifikasjonen, og tar hensyn til alle endringer en etter en: innvirkning på typer bedriftsbønner, O / R-kartleggingsmodell, enhet- relasjonsmodell, EJB QL (EJB Query Language), etc.

Bakgrunn

De to viktigste endringene i den foreslåtte EJB 3.0-spesifikasjonen er bruken av programkommentarer som ble introdusert i Java 5 og den nye O / R-kartleggingsmodellen basert på dvalemodus.

Metadata-anlegget i Java 5

Java 5 (tidligere kalt J2SE 1.5, eller Tiger) har introdusert et nytt programkommentaranlegg til språket. Med dette anlegget kan du definere egendefinerte merknader og deretter kommentere felt, metoder, klasser osv. Med disse merknadene. Kommentarer påvirker ikke semantikk i programmet, men verktøy (kompileringstid eller kjøretid) kan inspisere disse kommentarene for å generere flere konstruksjoner (som en distribusjonsbeskrivelse) eller håndheve ønsket kjøretidsoppførsel (som en EJB-komponents statelige natur). Kommentarer kan inspiseres gjennom kildeparsering (f.eks. Kompilatorer eller IDE-verktøy) eller ved å bruke tilleggsrefleksjon-API-er som er lagt til i Java 5. Kommentarer kan defineres slik at de bare er tilgjengelige på kildekodenivå, på det kompilerte klassenivået eller ved kjøretid . Alle merknader som er foreslått i EJB 3.0 tidlige utkast, har en Retensjonspolitikk av RUNTIME. Dette øker klassens minneavtrykk marginalt, men gjør livet til containerleverandør og verktøyleverandør mye enklere.

Se Ressurser for videre lesing om dette emnet.

Dvalemodus

Dvalemodus er et populært, åpen kildekode O / R-kartleggingsrammeverk for Java-miljøer, ment å beskytte utviklere mot de vanligste datapersistensrelaterte programmeringsoppgavene. Den har også et spesifikt Hibernate Query Language (HQL), avtrykk som kan sees i den nye EJB QL. Hibernate tilbyr fasiliteter for datainnhenting og oppdatering, tilkoblingssamling, transaksjonsadministrasjon, deklarativ enhetsforholdsadministrasjon og deklarative og programmatiske spørsmål.

Fugleperspektiv

Endringene i den foreslåtte EJB 3.0-spesifikasjonen kan deles inn i to kategorier:

  • En kommentarbasert EJB-programmeringsmodell, i tillegg til EJB 2.1-modellen for å definere applikasjonens atferd gjennom distribusjonsbeskrivere og flere grensesnitt.
  • Den nye utholdenhetsmodellen for enhetsbønner. EJB QL har også endret seg betydelig.

Det er også flere bivirkninger ved disse forslagene, som en ny klientprogrammeringsmodell, bruk av forretningsgrensesnitt og en livssyklus for bønner. Vær oppmerksom på at EJB 2.1-programmeringsmodellen (med distribusjonsbeskrivelser og hjem / eksterne grensesnitt) fortsatt er gyldig. Den nye forenklede modellen erstatter ikke helt EJB 2.1-modellen.

EJB-merknader

Et av ekspertgruppens viktige mål er å redusere antall gjenstander en bønneleverandør må levere, og gruppen har gjort en ganske ryddig jobb med å nå det målet. I EJB 3.0-verdenen er alle slags bedriftsbønner bare vanlige gamle Java-objekter (POJO) med passende kommentarer. Kommentarer kan brukes til å definere bønnens forretningsgrensesnitt, O / R-kartinformasjon, ressursreferanser og omtrent alt annet som ble definert gjennom distribusjonsbeskrivere eller grensesnitt i EJB 2.1. Implementeringsbeskrivelser er ikke lenger påkrevd; hjemmegrensesnittet er borte, og du trenger ikke nødvendigvis å implementere et forretningsgrensesnitt (containeren kan generere det for deg).

For eksempel erklærer du en statsløs øktbønne ved å bruke @Stateless kommentar på Java-klassen. For stateful beans, the @Fjerne merknader er merket på en bestemt metode for å indikere at bønneforekomsten skal fjernes etter at en samtale til den merkede metoden er fullført.

For å redusere mengden informasjon du må spesifisere for en komponent, har ekspertgruppen vedtatt en konfigurasjon-for-unntak tilnærming, noe som betyr at du gir intuitive standardverdier for alle merknader, slik at det meste av den vanlige informasjonen kan utledes.

Den nye utholdenhetsmodellen

De nye enhetsbønnene er også bare POJOer med noen få merknader og er ikke vedvarende enheter etter fødselen. En enhetsforekomst blir vedvarende når den er assosiert med en EntityManager og blir en del av en utholdenhetskontekst. En utholdenhetskontekst er løst synonymt med en transaksjonskontekst; med strenge ord, eksisterer den implisitt med transaksjonens omfang.

Enhetsforholdene er også definert gjennom merknader. I tillegg gjøres O / R-kartlegging også gjennom merknader, og det gis støtte for flere databasespesifikke operasjoner. Med EJB 2.1 brukte utviklere egne designmønstre eller brukte ikke-bærbare teknikker (for eksempel genereringsstrategier for automatisk nøkkel).

Graver dypt

Det er nå på tide å komme nærmere inn på forslagene som er gjort i EJB 3.0 tidlige utkast. La oss starte med alle fire typer bedriftsbønner og deretter gå videre til forslagene som er generelle for hele EJB-programmeringsmodellen.

Statsløse sesjonsbønner:

En statsløs øktbønne (SLSB), skrevet på EJB 3.0-måten, er bare en vanlig Java-fil med en klassemerkning på @Stateless. Bønneklassen kan implementere javax.ejb.SessionBean grensesnitt, men er ikke påkrevd (og vil vanligvis ikke).

En SLSB har ikke noe hjemmegrensesnitt lenger - faktisk krever ingen EJB-type det. Bønneklassen kan eller ikke implementere et forretningsgrensesnitt. Hvis det ikke implementerer noen forretningsgrensesnitt, genereres et forretningsgrensesnitt ved hjelp av alle offentlige metoder. Hvis bare visse metoder skulle eksponeres i forretningsgrensesnittet, kan alle disse metodene merkes med @BusinessMethod kommentar. Som standard er alle genererte grensesnitt lokale, men @Remote merknader kan brukes til å indikere at et eksternt grensesnitt skal genereres.

Følgende få kodelinjer er nok til å definere a Hei Verden bønne. Med EJB 2.1 ville den samme bønnen ha krevd minst to grensesnitt, en implementeringsklasse med flere tomme metodeimplementeringer og en distribusjonsbeskrivelse.

importere javax.ejb. *; / ** * En statsløs øktbønne som ber om å generere et eksternt forretningsgrensesnitt * for det. * / @Stateless @Remote offentlig klasse HelloWorldBean {public String sayHello () {return "Hello World !!!"; }} 

Se Ressurser for den fullstendige kildekoden som følger med denne artikkelen.

Stateful session beans

Historien med stateful session beans (SFSB) er stort sett den samme for SLSB, bortsett fra et par SFSB-spesifikke punkter:

  • En SFSB bør ha en måte å initialisere seg på (levert gjennom ejbCreate () metode i EJB 2.1 og tidligere). EJB 3.0-spesifikasjonen foreslår at slike initialiseringsmetoder gis som egendefinerte metoder og eksponeres gjennom bønnens forretningsgrensesnitt. Tjenesten ligger nå hos klienten å ringe passende initialiseringsmetoder før du bruker bønnen. Ekspertgruppen diskuterer fortsatt behovet for å gi en kommentar som markerer en bestemt metode for initialisering.
  • Bønneleverandøren kan merke hvilken som helst SFSB-metode med @Fjerne merknad for å indikere at bønneinstansen må fjernes etter at den merkede metoden er kalt. Igjen diskuterer ekspertgruppen fortsatt om et anlegg er nødvendig for å indikere at bønnen ikke må fjernes hvis metoden ikke fullføres normalt.

Her er min mening om de to åpne sakene:

  • Skal det være en kommentar til initialiseringsmetoden? Min stemme er ja — med den forutsetningen at containeren vil sikre at minst en av initialiseringsmetodene blir kalt før noen annen forretningsmetode blir kalt. Dette beskytter ikke bare mot utilsiktede programmeringsfeil, men gjør også containeren mer trygg på å gjenbruke SFSB-forekomster. For klarhetens skyld, la meg her nevne at nei angitt initialisering metoder (som ejb Opprett) er under vurdering; ekspertgruppen vurderer bare å ha en merknad som en metode som initialiseringsmetode.
  • Skulle det være konfigurerbart at unormal avslutning av @Fjerne metoden fjerner ikke bønneinstansen? Igjen, min stemme er ja. Det vil bare gi bedre kontroll til bønneleverandøren og klientprogrammerere. Bare ett spørsmål gjenstår: hva skjer med de bønnene som er merket å være ikke fjernet ved et mislykket anrop til fjerningsmetoden, og fjerningsmetoden for en bestemt forekomst fullføres aldri vellykket? Det er ingen måte å fjerne disse forekomsten programmatisk, men de vil bli fjernet ved tidsavbrudd for økten.

Se kildekoden for et eksempel på SFSB.

Meldingsdrevne bønner

Message-driven beans (MDBs) er den eneste typen bønner som må implementere et forretningsgrensesnitt. Dette grensesnittets type indikerer typen meldingssystem som bønnen støtter. For JMS (Java Message Service) -baserte MDB-er, er dette grensesnittet javax.jms.MessageListener. Merk at MDB-forretningsgrensesnittet ikke virkelig er et virksomhet grensesnitt, er det bare et meldingsgrensesnitt.

Enhetsbønner

Enhetsbønner er merket med @Enhet kommentar, og alle egenskaper / felt i klassen for enhetsbønne ikke merket med @Flyktig merknader blir ansett som vedvarende. Enhetsbønne vedvarende felt eksponeres gjennom egenskaper i JavaBean-stil eller akkurat som offentlige / beskyttede Java-felt.

Enhetsbønner kan bruke hjelperklasser for å representere enhetens bønnetilstand, men forekomster av disse klassene har ikke en vedvarende identitet. I stedet er deres eksistens sterkt knyttet til den bønnsinstansen som eier eieren; disse objektene kan ikke deles på tvers av enheter.

Se kildekoden for noen eksempler på enhetsbønner.

Enhetsrelasjoner

EJB 3.0 støtter både ensrettet og toveis forhold mellom enhetsbønner, som kan være en-til-en, en-til-mange, mange-til-en eller mange-til-mange relasjoner. Imidlertid skilles de to sidene av et toveis forhold som eiersiden og den omvendte siden. Eiersiden er ansvarlig for å forplante endringer i forhold til databasen. For mange-til-mange foreninger må eiersiden spesifiseres spesifikt. Egentlig er det baksiden som er spesifisert av isInverse = sant kommentarmedlem på baksiden Mange kommentar; fra det trekkes eiersiden. Nå sa ikke ekspertgruppen at det gjorde EJB enklere?

O / R-kartlegging

O / R-kartleggingsmodellen har også endret seg betydelig fra den abstrakte-utholdenhetsskjema-baserte tilnærmingen til en dvalemodusinspirert. Selv om ekspertgruppen fremdeles diskuterer modellen, og et klart bilde vil dukke opp bare med neste utkast, inneholder dette utkast klare indikasjoner på den generelle tilnærmingen.

For det første vil O / R-kartleggingen bli spesifisert i klassen for enhetsbønne ved å legge merke til. Tilnærmingen er også å referere til konkrete tabeller og kolonner i stedet for det abstrakte utholdenhetsskjemaet. O / R-kartleggingsmodellen har egen støtte for innfødt SQL; det vil si støtte på et dypere nivå, ikke bare muligheten til å kjøre innfødte SQL-spørsmål. For eksempel definerer kolonnedefinisjonen kommentar (@Kolonne) har et medlem columnDefinition det kan være noe sånt columnDefinition = "BLOB NOT NULL".

Klientprogrammeringsmodell

En EJB-klient kan skaffe seg en referanse til bønnens forretningsgrensesnitt ved hjelp av injeksjonsmekanismen (@Injiser kommentar). Bruker den nylig introduserte @ javax.ejb.EJBContext.lookup () metoden er en annen tilnærming. Men spesifikasjonen er ikke klar over hvordan en frittstående Java-klient får referanse til en bønneinstans siden de frittstående Java-klientene kjører i en J2EE-klientcontainer og mangler tilgang til @ javax.ejb.EJBContext gjenstand. Det er enda en mekanisme - et nylig introdusert universelt kontekstobjekt: @ javax.ejb.Context (). Men igjen, spesifikasjonen sier ikke hvordan dette objektet kan brukes i en klientcontainer.

EJB QL

Spørringer kan defineres gjennom @NamedQuery kommentar. To medlemmer av denne kommentaren er Navn og queryString. Når det er definert, kan du få tilgang til dette spørsmålet ved hjelp av EntityManager.createNamedQuery (navn) metode. Du kan også opprette en vanlig JDBC-stil (Java Database Connectivity) spørring ved å ringe EntityManager.createQuery (ejbqlString) eller et innfødt spørsmål ved hjelp av EntityManager.createNativeQuery (nativeSqlString).

EJB QL-spørsmål kan ha både posisjonelle og navngitte parametere. De javax.ejb. spørring grensesnittet gir metoder for å sette disse parametrene, utføre oppdateringer, liste resultater osv.

Her er et eksempel på hvordan et EJB QL-spørsmål kan opprettes og utføres:

.. .. @NamedQuery (name = "findAllCustomersWithName", queryString = "VELG c FRA Kunde c HVOR c.navn LIKE: custName") .. .. @Injiser offentlig EntityManager em; kunder = em.createNamedQuery ("findAllCustomersWithName") .setParameter ("custName", "Smith") .listResults (); 

Følgende viser noen av de flere forbedringene som er gjort i selve QL:

$config[zx-auto] not found$config[zx-overlay] not found