Kljub številnim pozitivnim vidikom zapletenost arhitekture Enterprise JavaBeans ovira sprejem J2EE. Arhitektura EJB je verjetno edina komponenta J2EE, ki ji je tako neuspešno uspelo uresničiti obljubo J2EE o večji produktivnosti razvijalcev in enostavnosti razvoja. EJB 3.0 še enkrat poskuša uresničiti to obljubo z zmanjšanjem zapletenosti EJB za razvijalce. EJB 3.0 zmanjša število programskih artefaktov, ki jih morajo razvijalci zagotoviti, odpravi ali zmanjša metode povratnega klica, ki jih je treba implementirati, in zmanjša zapletenost modela programiranja entitete fižol in modela preslikave O / R.
V tem članku najprej obravnavam najpomembnejše spremembe v EJB 3.0. Pred potopom v bazen EJB 3.0 je pomembno, da imate na voljo osnove. Nato podam pogled na osnutek EJB 3.0 na visoki ravni, nato se podrobno seznanim s predlagano specifikacijo, pri čemer sem pozoren na posamezne spremembe: vpliv na vrste fižolov v podjetju, model kartiranja O / R, entiteta- model odnosa, EJB QL (EJB Query Language) itd.
Ozadje
Dve najpomembnejši spremembi v predlagani specifikaciji EJB 3.0 sta uporaba programske opreme za označevanje, uvedena v Javi 5, in novi model preslikave O / R, ki temelji na hibernaciji.
Objekt za metapodatke v Javi 5
Java 5 (prej imenovana J2SE 1.5 ali Tiger) je v jezik uvedla novo programsko opombo. S to možnostjo lahko določite pripombe po meri in nato s temi pripisi pripišete polja, metode, razrede itd. Pripisi ne vplivajo neposredno na semantiko programa, toda orodja (čas prevajanja ali izvajanje) lahko te pripise pregledajo, da ustvarijo dodatne konstrukcije (na primer deskriptor razmestitve) ali uveljavijo želeno vedenje izvajalnega okolja (kot je narava komponente EJB). Pripombe je mogoče pregledati z razčlenjevanjem vira (npr. Prevajalniki ali orodja IDE) ali z uporabo dodatnih API-jev za odsev, dodanih v Javi 5. Pripise lahko določite tako, da so na voljo samo na ravni izvorne kode, na ravni prevedenega razreda ali med izvajanjem . Vsi pripisi, predlagani v zgodnjem osnutku EJB 3.0, imajo RetentionPolicy od RUNTIME. To nekoliko poveča odtis spomina v razredu, vendar olajša življenje ponudnika vsebnikov in ponudnikov orodij.
Za nadaljnje branje te teme glejte Vire.
Hibernate
Hibernate je priljubljeno odprtokodno ogrodje preslikave O / R za okolja Java, namenjeno zaščiti razvijalcev pred najpogostejšimi programskimi nalogami, povezanimi z obstojnostjo podatkov. Ima tudi poseben Hibernate Query Language (HQL), katerega odtise je mogoče videti v novem EJB QL. Hibernate ponuja zmogljivosti za pridobivanje in posodabljanje podatkov, združevanje povezav, upravljanje transakcij, upravljanje odnosov deklarativnih entitet ter deklarativne in programske poizvedbe.
Pogled iz ptičje perspektive
Spremembe predlagane specifikacije EJB 3.0 lahko razdelimo v dve kategoriji:
- Programski model EJB na osnovi pripisov, poleg modela EJB 2.1, ki opredeljuje vedenje aplikacije s pomočjo uvajalnih deskriptorjev in več vmesnikov.
- Nov model obstojnosti za fižol entitet. Tudi EJB QL se je bistveno spremenil.
Ti predlogi imajo tudi več stranskih učinkov, kot so nov model programiranja odjemalcev, uporaba poslovnih vmesnikov in življenjski cikel entitete. Upoštevajte, da je programski model EJB 2.1 (z uvajalnimi deskriptorji in vmesniki za dom / oddaljeni vmesnik) še vedno veljaven. Novi poenostavljeni model ne nadomešča v celoti modela EJB 2.1.
Pripisi EJB
Eden pomembnih ciljev strokovne skupine je zmanjšati število artefaktov, ki jih mora ponuditi fižol, in skupina je pri doseganju tega cilja opravila precej lepo delo. V svetu EJB 3.0 so vse vrste poslovnih fižolov pravične navadni stari predmeti Java (POJO) z ustreznimi pripisi. Pripise lahko uporabimo za opredelitev poslovnega vmesnika fižola, informacije o preslikavi O / R, sklice na vire in skoraj vse drugo, kar je bilo definirano s pomočjo uvajalnih deskriptorjev ali vmesnikov v EJB 2.1. Deskriptorji razmestitve niso več potrebni; domačega vmesnika ni več in vam ni treba nujno implementirati poslovnega vmesnika (vsebnik ga lahko ustvari za vas).
Na primer, razglasite sean brez sestave brez stanja z uporabo @Stateless pripis v razredu Java. Za fižol s statusom @Odstrani pripis je označen na določeni metodi, kar pomeni, da je treba primerek zrna odstraniti po zaključku klica označene metode.
Da bi zmanjšali količino informacij, ki jih morate navesti za komponento, je strokovna skupina sprejela a konfiguracija po izjemi pristop, kar pomeni, da za vse pripise zagotovite intuitivne privzete vrednosti, tako da je mogoče sklepati na večino skupnih informacij.
Nov model vztrajnosti
Tudi novi fižol entitet so samo POJO-ji z nekaj pripisi in po rojstvu niso trajne entitete. Primerek entitete postane trajen, ko je povezan z EntityManager in postane del a kontekst vztrajnosti. Kontekst obstojnosti je ohlapno sinonim za kontekst transakcije; s strogimi besedami implicitno soobstaja z obsegom transakcije.
Razmerja entitet so definirana tudi s pripisi. Poleg tega se preslikava O / R izvaja tudi s pripisi in je na voljo podpora za več operacij, specifičnih za bazo podatkov. Z EJB 2.1 so razvijalci uporabili lastne vzorce oblikovanja ali uporabili neprenosljive tehnike (na primer strategije samodejnega ustvarjanja ključev).
Kopanje globoko
Zdaj je čas, da se poglobimo v podrobnosti predlogov v zgodnjem osnutku EJB 3.0. Začnimo z vsemi štirimi vrstami fižolov v podjetju in nato nadaljujemo s splošnimi predlogi za celoten programski model EJB.
Fižol za zasedanje brez državljanstva:
Bean seje brez državljanstva (SLSB), napisan na način EJB 3.0, je zgolj navadna datoteka Java s pripisom na ravni razreda @Stateless. Razred fižol lahko izvaja javax.ejb.SessionBean vmesnika, vendar ga ni treba (in običajno ne).
SLSB nima več domačega vmesnika - pravzaprav ga noben tip EJB ne zahteva. Razred fižol lahko izvaja poslovni vmesnik ali pa tudi ne. Če ne izvaja nobenega poslovnega vmesnika, se poslovni vmesnik ustvari z uporabo vseh javnih metod. Če bi morali biti v poslovnem vmesniku izpostavljeni samo določeni načini, so lahko vse te metode označene z @BusinessMethod pripis. Privzeto so vsi ustvarjeni vmesniki lokalni, vendar @ Oddaljeno Pripis lahko označi, da je treba ustvariti oddaljeni vmesnik.
Naslednjih nekaj vrstic kode je dovolj za določitev a Pozdravljen, svet fižol. Z EJB 2.1 bi isti grah zahteval vsaj dva vmesnika, en izvedbeni razred z več izvedbami prazne metode in deskriptor razmestitve.
uvoz javax.ejb. *; / ** * Bean seje brez stanja, ki zahteva, da se zanj ustvari oddaljeni poslovni * vmesnik. * / @Stateless @Remote javni razred HelloWorldBean {javni niz sayHello () {return "Hello World !!!"; }} Za celotno izvorno kodo, ki spremlja ta članek, glejte Vire.
Stabilni fižol seje
Zgodba s fižoli sej s stanjem s stanjem (SFSB) je skoraj enaka za SLSB, razen nekaterih točk, značilnih za SFSB:
- SFSB bi moral imeti način, da se sam inicializira (zagotovljen prek
ejbCreate ()metoda v EJB 2.1 in starejših). Specifikacija EJB 3.0 predlaga, da se takšne inicializacijske metode zagotovijo kot metode po meri in izpostavijo prek poslovnega vmesnika fižola. Zdaj je stranka dolžna poklicati ustrezne metode inicializacije, preden uporabi grah. Strokovna skupina še vedno razpravlja o potrebi po pripisu, ki označuje določeno metodo za inicializacijo. - Ponudnik fižola lahko katero koli metodo SFSB označi z
@Odstranioznačuje, da je treba primerek graha odstraniti po klicu označene metode. Spet strokovna skupina še vedno razpravlja o tem, ali je objekt potreben za označevanje, da fižola ne smemo odstraniti, če se metoda ne konča normalno.
Tukaj je moje mnenje o dveh odprtih vprašanjih:
- Ali mora obstajati pripis za metodo inicializacije? Moj glas je pritrdilen - ob predpostavki, da bo vsebnik zagotovil, da bo vsaj ena od načinov inicializacije poklicana pred klicem katere koli druge poslovne metode. To ne samo ščiti pred naključnimi programskimi napakami, ampak tudi naredi vsebnik bolj samozavesten glede ponovne uporabe primerkov SFSB. Za jasnost naj tukaj omenim, da ne določena inicializacija metode (kot
ejbCreate) so v obravnavi; strokovna skupina razmišlja samo o tem, da bi oznako z oznako označili kot metodo inicializacije. - Ali bi bilo mogoče konfigurirati tako nenavadno ukinitev
@Odstranimetoda ne odstrani primerka graha? Še enkrat, moj glas je pritrdilen. Ponudnikom fižola in programerjem odjemalcev bo zagotovil le boljši nadzor. Ostaja samo eno vprašanje: kaj se zgodi s tistim fižolom, ki je označen kot ne odstranjena ob neuspešnem klicu metode remove in metoda odstranitve določenega primerka se nikoli ne zaključi uspešno? Teh primerkov ni mogoče programsko odstraniti, vendar bodo odstranjeni ob izteku seje.
Za primer SFSB glejte izvorno kodo.
Sporočilo usmerjeni fižol
Sporočni fižol (MDB) je edina vrsta fižola, ki mora implementirati poslovni vmesnik. Vrsta tega vmesnika označuje vrsto sistema za sporočanje, ki ga podpira grah. Za MDB, ki temeljijo na JMS (Java Message Service), je ta vmesnik javax.jms.MessageListener. Upoštevajte, da poslovni vmesnik MDB ni resnično posel vmesnik, je le vmesnik za sporočanje.
Entitetni fižol
Entitetni fižol je označen z @Entiteta in vse lastnosti / polja v razredu entitete entitete ne označena z @Prehodno pripombe štejejo za trajne. Obstojna polja entitetnih zrn so izpostavljena prek lastnosti v slogu JavaBean ali samo kot javna / zaščitena polja razreda Java.
Entiteti fižol lahko uporabljajo pomožne razrede za predstavitev stanja zrna entitete, vendar primerki teh razredov nimajo trajne identitete. Namesto tega je njihov obstoj močno povezan s primerkom fižola lastnika entitete; tudi teh predmetov ni mogoče deliti med entitetami.
Za nekaj primerov fižolov entitet glejte izvorno kodo.
Entitetni odnosi
EJB 3.0 podpira tako enosmerna kot dvosmerna razmerja med fižoli entitet, ki so lahko razmerja ena na ena, ena na več, več na eno ali veliko na veliko. Vendar se dve strani dvosmernega razmerja ločujeta kot lastniška in obratna stran. Lastniška stran je odgovorna za širjenje sprememb odnosov do baze podatkov. Pri združenjih veliko do več mora biti stran lastništva izrecno določena. Pravzaprav gre za hrbtno stran, ki jo določa isInverse = true opomba na hrbtni strani ManyToMany pripis; iz tega je razvidna lastniška stran. Ali strokovna skupina ni rekla, da olajša EJB?
O / R preslikava
Model preslikave O / R se je tudi bistveno spremenil iz pristopa, ki temelji na abstraktni vztrajnosti, v tistega, ki ga navdihuje hibernacija. Čeprav strokovna skupina o modelu še razpravlja in bo jasna slika prikazana šele z naslednjim osnutkom, ta osnutek vsebuje jasne indikacije splošnega pristopa.
Prvič, preslikava O / R bo v samem razredu entitete entitete podana z opombami. Pristop je tudi sklicevanje na konkretne tabele in stolpce namesto na abstraktno shemo obstojnosti. Model preslikave O / R ima notranjo podporo za izvorni SQL; to je podpora na globlji ravni, ne samo zmožnost izvajanja izvornih poizvedb SQL. Na primer, pripis definicij stolpcev (@ Stolpec) ima člana columnDefinition to je lahko nekaj takega columnDefinition = "BLOB NOT NULL".
Model odjemalskega programiranja
Odjemalec EJB lahko pridobi sklic na poslovni vmesnik fižola z uporabo mehanizma vbrizga (@Inject pripis). Uporaba novo predstavljenega @ javax.ejb.EJBContext.lookup () metoda je drug pristop. Toda specifikacija ni jasna, kako samostojni odjemalec Java pridobi sklic na primerek fižola, saj se samostojni odjemalci Java izvajajo v odjemalskem vsebniku J2EE in nimajo dostopa do @ javax.ejb.EJBContext predmet. Obstaja še en mehanizem - na novo uveden univerzalni objekt konteksta: @ javax.ejb.Context (). Spet pa spec ne pove, kako je mogoče ta predmet uporabiti v odjemalskem vsebniku.
EJB QL
Poizvedbe lahko definirate s pomočjo @NamedQuery pripis. Dva člana tega pripisa sta ime in queryString. Ko je poizvedba definirana, je do nje mogoče dostopati s pomočjo EntityManager.createNamedQuery (ime) metoda. S klicem lahko ustvarite tudi običajno poizvedbo v slogu JDBC (Java Database Connectivity) EntityManager.createQuery (ejbqlString) ali izvorno poizvedbo z EntityManager.createNativeQuery (nativeSqlString).
EJB QL poizvedbe imajo lahko tako pozicijske kot imenovane parametre. The javax.ejb.Query vmesnik ponuja metode za nastavitev teh parametrov, izvajanje posodobitev, navajanje rezultatov itd.
Tu je en primer, kako je mogoče ustvariti in izvršiti poizvedbo EJB QL:
.. .. @NamedQuery (name = "findAllCustomersWithName", queryString = "SELECT c FROM Customer c WHERE c.name LIKE: custName") .. .. @Inject public EntityManager em; kupci = em.createNamedQuery ("findAllCustomersWithName") .setParameter ("custName", "Smith") .listResults (); Sledi nekaj izboljšav samega QL:
