EJB 3.0 pähkinänkuoressa

Useista positiivisista syistä Enterprise JavaBeans -arkkitehtuurin monimutkaisuus estää J2EE: n käyttöönottoa. EJB-arkkitehtuuri on luultavasti ainoa J2EE-komponentti, joka on epäonnistunut niin surkeasti toimittamalla J2EE: n lupauksen kehittäjien tuottavuuden lisäämisestä helposti kehitettävissä. EJB 3.0 yrittää jälleen kerran toteuttaa lupauksen vähentämällä EJB: n monimutkaisuutta kehittäjille. EJB 3.0 vähentää kehittäjien tarjoamien ohjelmointiartefaktien määrää, eliminoi tai minimoi toteutettavat takaisinsoittomenetelmät ja vähentää entiteettipapujen ohjelmointimallin ja O / R-kartoitusmallin monimutkaisuutta.

Tässä artikkelissa käsittelen ensin EJB 3.0: n merkittävimpiä muutoksia. On tärkeää, että perusasiat ovat paikallaan ennen sukellusta EJB 3.0 -allas. Seuraavaksi annan korkean tason kuvan EJB 3.0 -luonnoksesta ja pääsen sitten ehdotetun eritelmän yksityiskohtiin kiinnittäen huomiota kaikkiin muutoksiin yksi kerrallaan: vaikutus yrityspapujen tyyppeihin, O / R-kartoitusmalli, entiteetti- suhdemalli, EJB QL (EJB Query Language) jne.

Tausta

Kaksi merkittävintä muutosta ehdotetussa EJB 3.0 -määrittelyssä ovat Java 5: ssä käyttöön otetun ohjelman annotointimahdollisuuden käyttö ja uusi horrostilaan perustuva O / R-kartoitusmalli.

Sisällönkuvaustiedot Java 5: ssä

Java 5 (aikaisemmin nimeltään J2SE 1.5 tai Tiger) on tuonut kielelle uuden ohjelman huomautusominaisuuden. Tällä toiminnolla voit määrittää mukautettuja merkintöjä ja merkitä sitten kentät, menetelmät, luokat jne. Näillä merkinnöillä. Merkinnät eivät vaikuta suoraan ohjelman semantiikkaan, mutta työkalut (käännösaika tai ajonaika) voivat tarkastaa nämä merkinnät ja luoda ylimääräisiä rakenteita (kuten käyttöönoton kuvaaja) tai pakottaa halutun ajonaikaisen käyttäytymisen (kuten EJB-komponentin tilallinen luonne). Merkinnät voidaan tarkastaa lähteen jäsentämisen avulla (esim. Kääntäjät tai IDE-työkalut) tai käyttämällä Java 5: ään lisättyjä muita heijastussovellusliittymiä. Merkinnät voidaan määritellä saataville vain lähdekooditasolla, käännetyn luokan tasolla tai ajon aikana . Kaikissa EJB 3.0: n varhaisessa luonnoksessa ehdotetuissa merkinnöissä on a Säilytyspolitiikka / RUNTIME. Tämä lisää luokan muistinjälkeä marginaalisesti, mutta helpottaa konttitoimittajan ja työkalujen toimittajan elämää.

Katso lisätietoja aiheesta aiheesta Resurssit.

Lepotila

Hibernate on suosittu, avoimen lähdekoodin O / R-kartoituskehys Java-ympäristöille, joka on tarkoitettu suojaamaan kehittäjiä yleisimmiltä tietojen pysyvyyteen liittyvistä ohjelmointitehtävistä. Sillä on myös erityinen horrostilan kyselykieli (HQL), jonka jäljet näkyvät uudessa EJB QL: ssä. Horrostila tarjoaa tilat tietojen hakuun ja päivittämiseen, yhteyksien yhdistämiseen, tapahtumien hallintaan, selittävien entiteettisuhteiden hallintaan sekä deklaratiivisiin ja ohjelmisiin kyselyihin.

Lintuperspektiivi

Ehdotetun EJB 3.0 -erittelyn muutokset voidaan jakaa kahteen luokkaan:

Merkintöihin perustuva EJB-ohjelmointimalli, EJB 2.1 -mallin lisäksi sovelluksen käyttäytymisen määritteleminen käyttöönottokuvaajien ja useiden rajapintojen avulla.
Uusi pysyvyysmalli entisöpapuille. Myös EJB QL on muuttunut merkittävästi.

Näillä ehdotuksilla on myös useita sivuvaikutuksia, kuten uusi asiakasohjelmointimalli, liiketoimintaliittymien käyttö ja yrityksen papujen elinkaari. Huomaa, että EJB 2.1-ohjelmointimalli (sisältäen asennuskuvaajat ja koti / etärajapinnat) on edelleen voimassa. Uusi yksinkertaistettu malli ei korvaa kokonaan EJB 2.1 -mallia.

EJB-merkinnät

Yksi asiantuntijaryhmän tärkeistä tavoitteista on vähentää papujen tarjoajan toimittamien esineiden määrää, ja ryhmä on tehnyt melko siistin työn tavoitteen saavuttamiseksi. EJB 3.0 -maailmassa kaikenlaiset yrityspavut ovat oikeudenmukaisia tavalliset vanhat Java-objektit (POJO) asianmukaisilla merkinnöillä. Huomautuksia voidaan käyttää papun liiketoimintaliittymän, O / R-kartoitustietojen, resurssiviitteiden ja kaiken muun määrittelemiseen, joka määritettiin käyttöönottokuvaajien tai käyttöliittymien avulla EJB 2.1: ssä. Käyttöönoton kuvauksia ei enää tarvita; kodin käyttöliittymä on poissa, eikä sinun tarvitse välttämättä ottaa käyttöön liiketoimintaliittymää (säilö voi luoda sen sinulle).

Esimerkiksi ilmoitat kansalaisuudettoman istuntopapun käyttämällä @Stateless merkintä Java-luokassa. Valtaville pavuille @Poista merkintä on merkitty tietylle menetelmälle osoittamaan, että papu-ilmentymä tulisi poistaa sen jälkeen, kun kutsu merkittyyn menetelmään on valmis.

Komponentille määritettävien tietojen määrän vähentämiseksi asiantuntijaryhmä on hyväksynyt a kokoonpano poikkeuksittain lähestymistapa, eli annat intuitiiviset oletusarvot kaikille merkinnöille, jotta suurin osa yleisistä tiedoista voidaan päätellä.

Uusi pysyvyysmalli

Uudet entiteettipavut ovat myös vain POJO: ita muutamalla merkinnällä, eivätkä ne ole syntymänsä perusteella pysyviä kokonaisuuksia. Entiteetti-ilmentymä muuttuu pysyväksi, kun se on yhdistetty EntityManager ja siitä tulee osa a pysyvyyden konteksti. Pysyvyyskonteksti on löyhästi synonyymi tapahtumakontekstiin; tiukasti sanottuna se on implisiittisesti rinnakkain liiketoimen laajuuden kanssa.

Entiteettisuhteet määritellään myös merkinnöillä. Lisäksi O / R-kartoitus tehdään myös merkintöjen avulla ja tarjotaan tukea useille tietokantakohtaisille operaatioille. EJB 2.1: n kanssa kehittäjät käyttivät omia suunnittelumallejaan tai käyttivät ei-kannettavia tekniikoita (esimerkiksi automaattisten avainten luomisstrategioita).

Kaivaa syvälle

Nyt on aika tutustua EJB 3.0: n varhaisessa luonnoksessa tehtyjen ehdotusten yksityiskohtiin. Aloitetaan kaikista neljästä yrityspaputyypistä ja siirrytään sitten yleisiin ehdotuksiin koko EJB-ohjelmointimalliin.

Tilattomat istuntopavut:

Tilaton istuntopapu (SLSB), joka on kirjoitettu EJB 3.0-tavalla, on vain tavallinen Java-tiedosto, jonka luokkatason merkintä on @Stateless. Papuluokka voi toteuttaa javax.ejb.SessionBean käyttöliittymä, mutta sitä ei vaadita (eikä yleensä vaadita).

SLSB: llä ei ole enää kotiliitäntää - itse asiassa mikään EJB-tyyppi ei vaadi sitä. Papuluokka voi toteuttaa tai olla käyttämättä liiketoimintaliittymää. Jos se ei ota käyttöön mitään liiketoimintaliittymiä, yritysliittymä luodaan käyttämällä kaikkia julkisia menetelmiä. Jos liiketoimintaliittymässä tulisi paljastaa vain tietyt menetelmät, kaikki nämä menetelmät voidaan merkitä @BusinessMethod merkintä. Oletuksena kaikki luodut rajapinnat ovat paikallisia, mutta @Etä huomautusta voidaan käyttää osoittamaan, että etärajapinta tulisi luoda.

Muutama seuraava koodirivi riittää a: n määrittelemiseen Hei maailma papu. EJB 2.1: n kanssa sama papu olisi edellyttänyt vähintään kahta rajapintaa, yhden toteutusluokan, jossa on useita tyhjiä menetelmien toteutuksia, ja käyttöönoton kuvauksen.

tuo javax.ejb. *; / ** * Valtaton istuntopapu, joka pyytää etäyrityksen * käyttöliittymän luomista sille. * / @Stateless @Remote public class HelloWorldBean {public String sayHello () {return "Hello World !!!"; }}

Tämän artikkelin mukana toimitettu täydellinen lähdekoodi löytyy Resursseista.

Tilalliset istuntopavut

Tarina tilallisista istuntopavuista (SFSB) on melkein sama SLSB: lle, paitsi muutama SFSB-kohtainen kohta:

SFSB: llä tulisi olla tapa alustaa itsensä (tarjotaan SFS: n kautta ejbLuo () menetelmä (EJB 2.1 ja aiemmat). EJB 3.0 -määrittely ehdottaa, että tällaiset alustusmenetelmät tarjotaan mukautetuina menetelminä ja paljastetaan papun liiketoimintaliittymän kautta. Asiakkaan vastuulla on nyt kutsua asianmukaiset alustusmenetelmät ennen pavun käyttöä. Asiantuntijaryhmä keskustelee edelleen tarpeesta antaa huomautus, joka merkitsee tiettyä alustamismenetelmää.
Pavun tarjoaja voi merkitä minkä tahansa SFSB-menetelmän @Poista huomautus, joka osoittaa, että papu-ilmentymä on poistettava, kun annotoitu menetelmä on kutsuttu. Jälleen asiantuntijaryhmä keskustelee edelleen siitä, onko laite tarpeen sen osoittamiseksi, että papua ei saa poistaa, jos menetelmä ei toteudu normaalisti.

Tässä on mielipiteeni kahdesta avoimesta asiasta:

Pitäisikö alustusmenetelmälle olla olemassa huomautus? Äänestän kyllä - olettaen, että säilö varmistaa, että ainakin yksi alustustavoista kutsutaan ennen minkään muun liiketoimintamenetelmän kutsumista. Tämä ei vain suojaa tahattomilta ohjelmointivirheiltä, vaan myös tekee kontista varmempaa SFSB-instanssien uudelleenkäytöstä. Selvyyden vuoksi haluan mainita tässä, että ei nimetty alustus menetelmät (kuten ejbLuo) ovat tarkasteltavana; asiantuntijaryhmä harkitsee vain merkintämerkintämenetelmän käyttämistä alustamismenetelmänä.
Pitäisikö sen olla konfiguroitavissa @Poista menetelmä ei poista papu-esiintymää? Ääneni on jälleen kyllä. Se antaa vain paremman hallinnan papujen tarjoajalle ja asiakasohjelmoijille. Vain yksi kysymys on jäljellä: mitä tapahtuu niille pavuille, jotka on merkitty ei poistetaan epäonnistuneesta kutsusta poistomenetelmään ja tietyn esiintymän poistomenetelmä ei koskaan onnistu? Ei ole mitään tapaa poistaa näitä esiintymiä ohjelmallisesti, mutta ne poistetaan istunnon aikakatkaisun yhteydessä.

Katso SFSB: n esimerkki lähdekoodista.

Viestipohjaiset pavut

Viestipohjaiset pavut (MDB) ovat ainoat pavut, joiden on toteutettava liiketoimintaliittymä. Tämän käyttöliittymän tyyppi ilmoittaa papujärjestelmän tyypin, jota papu tukee. JMS (Java Message Service) -pohjaisille MDB-levyille tämä käyttöliittymä on javax.jms.MessageListener. Huomaa, että MDB-liiketoimintaliittymä ei todellakaan ole liiketoimintaa käyttöliittymä, se on vain viestiliittymä.

Entity pavut

Entiteettipavut on merkitty @Entity merkinnät ja kaikki entiteettipapuluokan ominaisuudet / kentät ei merkitty @Transient merkintöjä pidetään pysyvinä. Entiteettipapujen pysyvät kentät paljastetaan JavaBean-tyylisten ominaisuuksien tai aivan kuten julkisten / suojattujen Java-luokan kenttien kautta.

Entiteettipavut voivat käyttää auttajaluokkia esittäessään entisöpapujen tilaa, mutta näiden luokkien esiintymillä ei ole pysyvää identiteettiä. Sen sijaan heidän olemassaolonsa on sidottu vahvasti omistavan yksikön papu-instanssiin; myöskään nämä objektit eivät ole jaettavissa kaikkien yksiköiden välillä.

Katso lähdekoodista joitain esimerkkikokonaispapuja.

Entiteettisuhteet

EJB 3.0 tukee sekä yksisuuntaisia että kaksisuuntaisia suhteita entisöpapujen välillä, jotka voivat olla yksi-yhteen, yksi-moniin, moni-yhteen tai monet moniin-moniin-suhteet. Kaksisuuntaisen suhteen kaksi puolta erotetaan kuitenkin omistaja- ja käänteispuolena. Omistava puoli on vastuussa suhteiden muutosten levittämisestä tietokantaan. Monille monille -yhdistyksille omistajapuoli on määriteltävä erikseen. Oikeastaan se on kääntöpuoli, jonka määrittelee isInverse = true merkinnän jäsen kääntöpuolella MonetToMany merkintä; siitä johtuu omistajapuoli. Eikö asiantuntijaryhmä sanonut, että se helpotti EJB: tä?

O / R-kartoitus

O / R-kartoitusmalli on myös muuttunut merkittävästi abstraktista pysyvyydestä-skeemaan perustuvasta lähestymistavasta horrostilaan innoittamaan. Vaikka asiantuntijaryhmä keskustelee edelleen mallista, ja selkeä kuva syntyy vasta seuraavan luonnoksen yhteydessä, tässä luonnoksessa on selkeät viitteet yleisestä lähestymistavasta.

Yhdelle O / R-kartoitus määritetään itse entisöpapuluokassa merkinnöillä. Lisäksi lähestymistapana on viitata konkreettisiin taulukoihin ja sarakkeisiin abstraktin pysyvyyskaavan sijasta. O / R-kartoitusmallilla on luontainen tuki natiiville SQL: lle; ts. tuki syvemmällä tasolla, ei vain kyky suorittaa natiivia SQL-kyselyjä. Esimerkiksi sarakemääritelmien merkinnät (@Column) on jäsen sarakeMääritelmä se voi olla jotain columnDefinition = "BLOB EI NULL".

Asiakasohjelmointimalli

EJB-asiakas voi hankkia viitteen pavun liiketoimintaliittymään injektiomekanismin avulla (@Pistää merkintä). Käyttämällä äskettäin käyttöönotettua @ javax.ejb.EJBContext.lookup () menetelmä on toinen lähestymistapa. Mutta määrittely ei ole selvä siitä, miten erillinen Java-asiakas saa viittauksen pavun ilmentymään, koska erilliset Java-asiakkaat toimivat J2EE-asiakassäiliössä ja niillä ei ole pääsyä @ javax.ejb.EJBContext esine. On vielä toinen mekanismi - vasta käyttöön otettu universaali kontekstikohde: @ javax.ejb.Context (). Mutta jälleen kerran, tekninen tiedote ei sano, miten tätä objektia voidaan käyttää asiakassäiliössä.

EJB QL

Kyselyt voidaan määritellä @NimedQuery merkintä. Kaksi tämän merkinnän jäsentä ovat nimi ja queryString. Kun tämä kysely on määritelty, sitä voidaan käyttää EntityManager.createNamedQuery (nimi) menetelmä. Voit myös luoda tavallisen JDBC-tyylisen (Java Database Connectivity) kyselyn soittamalla EntityManager.createQuery (ejbqlString) tai natiivikysely käyttäen EntityManager.createNativeQuery (nativeSqlString).

EJB QL -kyselyillä voi olla sekä sijainti- että nimettyjä parametreja. javax.ejb.Kysely käyttöliittymä tarjoaa menetelmät näiden parametrien asettamiseksi, päivitysten suorittamiseksi, tulosten luetteloimiseksi jne.

Tässä on yksi esimerkki siitä, miten EJB QL -kysely voidaan luoda ja suorittaa:

.. .. @NimedQuery (name = "findAllCustomersWithName", queryString = "SELECT c FROM Client c WHERE c.name LIKE: custName") .. .. @ Inject public EntityManager em; asiakkaat = em.createNamedQuery ("findAllCustomersWithName") .setParameter ("custName", "Smith") .listResults ();

Seuraavassa luetellaan joitain itse QL: ään tehtyjä parannuksia: