Enterprise JavaBeans
![]() |
Ez a szócikk szaklektorálásra, tartalmi javításokra szorul. A felmerült kifogásokat a szócikk vitalapja részletezi. Ha nincs indoklás a vitalapon, bátran távolítsd el a sablont! |
Ez a szócikk sürgős javításra/bővítésre szorul, mert vállalhatatlan, katasztrofális állapotban van. A felmerült kifogásokat a szócikk vitalapja részletezi. Ha nincs indoklás a vitalapon, bátran távolítsd el a sablont! |
Az Enterprise JavaBeanek (EJB) moduláris vállalati alkalmazásokban használt szerveroldali komponensek. Általában az üzleti logika implementációját tartalmazzák. Az EJB specifikációt eredetileg az IBM adta ki 1997-ben. Később, 1999-ben, a Sun Microsystems is elfogadta, alkalmazta (EJB 1.0 és 1.1), és tovább terjesztették a Java Community Process alatt mint JSR19, JSR152, JSR220 és JSR318.[1]
Tartalomjegyzék
Története[szerkesztés]
Az EJB 1.0 specifikációt az IBM fejlesztette ki 1997-ben, majd a Sun Microsystems 1999-ben adoptálta.[2] A Java Community Process keretében fejlesztették tovább specifikációt és Java Specification Request dokumentumokként kerültek nyilvánosságra az újabb verziók:
Verzió | Specifikáció | Kiadás éve |
---|---|---|
EJB 1.0 | 1998 | |
EJB 1.1 | 1999 | |
EJB 2.0 | JSR 19 | 2001 |
EJB 2.1 | JSR 153 | 2003 |
EJB 3.0 | JSR 220 | 2006 |
EJB 3.1 | JSR 318 | 2009 |
EJB 3.2 | JSR 345 | 2013 |
EJB Specifikáció[szerkesztés]
Az EJB specifikációt arra tervezték, hogy egy alapvető módszer legyen a vállalati alkalmazásokban levő back-end üzleti kódok megvalósítására. Ezekben a kódokban gyakran ugyanazok a hibák jelentek meg, és ezeket a problémákat a programozók újra és újra ugyanúgy oldották meg. Az EJB-t arra hozták létre, hogy kezelje a perzisztenciát, a tranzakciók integritását és az adatvédelmet úgy, hogy a programozók szabadon koncentrálhassanak a megoldandó problémákra.
Az EJB specifikáció részletezi egy alkalmazás szolgáltatásait:
- Tranzakciókezelés
- Integráció a Java Persistence API által nyújtott perzisztenciaszolgáltatással
- Konkurenciakezelés
- Események kezelése a Java Message Service-zel, és a Java EE Connector Architecture használatával
- Aszinkron metódushívás
- Feladatütemezés
- Elnevezési- és könyvtár szolgáltatások (JNDI)
- Távoli eljáráshívás RMI-IIOP és webszolgáltatásokon keresztül
- Biztonság (Java Cryptography Extension (JCE) és JAAS)
- Szoftver komponensek telepítése alkalmazásszerverre
Mi több, az EJB specifikáció azokat a kötelességeket írja le, amit az EJB konténer és maga az EJB tartalmaz, mint ahogy azt is, hogy hogyan kell telepíteni az EJB konténert. Megjegyzendő, hogy a jelenlegi EJB specifikáció nem részletezi többé, hogy egy alkalmazás hogyan gondoskodik a perzisztenciáról (egy olyan feladatról, ami a JPA specifikáció delegáltja), de ehelyett részletezi, hogy az üzleti logika könnyedén integrálható a perzisztencia szolgáltatásokkal, amiket a kiszolgáló alkalmazás nyújt.
A megjelenés utáni csalódás[szerkesztés]
A problémák gyorsan előkerültek, ennek következtében az EJB hírneve kopni kezdett. Néhány API fejlesztő úgy gondolta, hogy az EJB API-ja sokkal összetettebb, mint amihez hozzá voltak szokva. A rengeteg ellenőrzött kivétel, igényelt interfész és a bean osztályok absztrakt osztályként való implementálása szokatlan és természetellenes volt a legtöbb programozó számára. Ismert, hogy az EJB szabvány nagyon összetett problémákat próbált kezelni. Ilyen pl. az objektum-relációs leképzés vagy a tranzakció épség. Ennek ellenére sok programozó az API-t is hasonló, vagy még nehezebbnek vélte, így alakult ki az a széles körű felfogás, miszerint az EJB által bemutatott összetettség nem nyújt igazi hasznot.
Mi több, a cégek úgy találták, hogy az EJB használata az üzleti logikában rontotta a teljesítményt. Ez azért történhetett, mert az eredeti specifikáció csak a CORBA-n, esetleg más hasonló protokollokon keresztül engedte a távoli eljárás hívást (és opcionálisan minden más eljárást is), annak ellenére, hogy a legtöbb üzleti alkalmazásnak nincs is szüksége az elosztott számítási funkcióra. Az EJB 2.0 specifikáció ennek az aggodalomnak a megszüntetésesre jött létre. Ezt úgy akarták kivitelezni, hogy hozzáadták a helyi interfész koncepcióját, amelyet egyenes úton lehetett hívni anélkül, hogy a többszörös szervereken eloszló alkalmazások által előhozott probléma megjelent volna.
Széles körben az EJB 1.0 által felmerült problémák megoldásaként mutatták be. Bonyolultsága azonban továbbra is hátráltatta az EJB elfogadását. Habár a kiváló fejlesztői környezetek az ismétlődő feladatok automatizálásával megkönnyítették az EJB létrehozását és használatát, ugyancsak ezek az eszközök nem segítették a technológia megtanulását. Ezen felül egy ellenálló mozgalom kezdett kibontakozni a programozók között. A fő eredménye ennek az ellenállásnak az EJB-hez képest könnyűsúlyúnak nevezhető Hibernate és a Spring keretrendszer lett. (A Hibernate a perzisztenciát és az object-relational mapping-et valósítja meg, a Spring framework pedig egy alternatív és kevésbé "bőbeszédű" módot nyújt az üzleti logika kódolásához). Annak ellenére, hogy a nagyobb cégek nem támogatták, ezek a technológiák ismertek lettek, és sok olyan cég kezdte használni őket, amelyek csalódtak az EJB-ben.
Az EJB-t a Java BluePrints, és a Sun Java Pet Store demója támogatta. Az EJB használata vitatható és befolyásoló volt. A Java EE programozók, mint például Rod Johnson, megkíséreltek egy olyan választ létrehozni a Java Pet Store-ra, ami támogatja az EJB használatát, és kiemelten hangsúlyozza annak fontosságát. A Sun létrehozott egy alternatívát, amit Plain Old Java Objects-nek neveztek (POJO). Az új EJB 3.0 használata könnyebb lett az EJB 2.0-nál, és több lehetőséget is nyújtott a fejlesztőknek.
Az EJB újraalkotása[szerkesztés]
A cégek egymás között megegyeztek abban, hogy az EJB specifikáció elsődleges előnye, az elosztott alkalmazások tranzakciós épségének biztosítását a legtöbb üzleti alkalmazás kevéssé használja. Sokkal hasznosabbak voltak a könnyűsúlyú keretrendszerek által nyújtott funkciók. Példa erre a Spring, vagy a Hibernate.
Ennek megfelelően az EJB 3.0 (JSR 220) radikálisan különbözött az ősöktől, és ezt az új mintát követte. Nyilvánvaló a hasonlóság abban a Springgel, ahogy a POJO-kat használja. Továbbá a dependency injectiont is megvalósítja, ami egyszerűsíti a heterogén rendszer felépítését és összekapcsolását. Gavin King a Hibernate megalapítója is részt vett az EJB 3.0 folyamatában, és a technológia köztudott szószólója. A Hibernate sok jellegzetessége megjelenik a Java Persistence API-ban, ami az entity beanst helyettesíti az EJB 3.0-ban. Az EJB 3.0 erősen az annotációkon alapul, bár megtartotta a korábbi konfigurációs lehetőségeket is.
Ezek az annotációk a Java nyelvhez az 5.0-s megjelenésével lettek hozzáadva, hogy egy kevéssé bőbeszédű és biztonságosabb kódoló stílust hozzanak létre. Ennek megfelelően a gyakorlatban az EJB 3.0 egy majdnem teljesen új API, ami könnyebb súlyú, és csak kevéssé hasonlít a megelőző EJB specifikációkra.
Példa[szerkesztés]
A következő példa azt mutatja be, hogy hogyan is néz ki egy EJB gyakorlatban:
@Local
public interface CustomerServiceLocal {
void addCustomer(Customer customer);
}
@Stateless
public class CustomerService implements CustomerServiceLocal {
@PersistenceContext
private EntityManager entityManager;
public void addCustomer(Customer customer) {
entityManager.persist(customer);
}
}
A fenti kód egy egyszerű alkalmazás osztály lokális interfész implementációja, melynek segítségével állandó customer objektumot, illetve proxyt hoz létre (az O/R mapping-en keresztül). Az EJB a perzisztenciára koncentrál és az addCustomer()
mód tranzakcionális és szálbiztos a beállítások miatt. Ahogy azt láthattuk, az EJB csak a perzisztenciára és az üzleti logikára koncentrál, más egyedi részleteket, felépítést nem ismer.
Az EJB-t osztályokban is lehet használni mint a következő példában is:
@Named
@RequestScoped
public class CustomerBacking {
@EJB CustomerServiceLocal customerService;
public String addCustomer() {
customerService.addCustomer(customer);
context.addMessage(...); // abbreviated for brevity
return "customer_overview";
}
}
A fenti kódolás egy JSF backing bean-t mutat be, amibe a @EJB annotáció hatására a konténer egy EJB-t injektál. Az addCustomer
metódus a felhasználói felület egyes komponenseihez kapcsolódik, mint például egy gomb. Az EJB-vel ellentétben, a backing bean nem tartalmaz semmilyen üzleti logikát vagy perzisztencia kódot, de delegálja az efféle kéréseket az EJB-nek. A backing bean tud olyan egyedi implementációkról is, amiről az EJB-nek nincs tudomása.
EJB típusok[szerkesztés]
Az EJB-k három csoportra oszthatók: [3]
Session beanek[szerkesztés]
A session bean-ek lehetnek:[4]
Állapotmentesek (stateless)[szerkesztés]
Az állapotmentes session bean[5] nem perzisztens bean. Nem tárol állapotot a sessionről, így az egyes hívásai függetlenek. Állapota lehet. Mivel az állapotmentes session bean példányai nem tárolnak a klienstől származó adatot, így a metódusainak végrehajtásához szükséges összes adat a metódusok paramétereiből származik.
Ezek a beanek nem használhatók párhuzamosan,[6] viszont két hívás között ki tudnak szolgálni egy másik klienst is. Hogyha igény lenne a párhuzamos használatra, akkor a két szál külön példányt kap,[7] így az állapotmentes session garantáltan szálbiztos. A metódusok hivatkozhatnak a bean belső állapotára, de nincs arra garancia, hogy két hívás között ne változzon meg az állapota.
Az adminisztrációs költségek csökkentése éredkében a konténer egy készletet tart fent; egy bean egymás után több kliensnek is odaadható. Mivel nem tartanak fenn állapotot, ezért kezelésük egyszerűbb, és kevésbé időigényes, mint az állapottartó session beaneké.
Állapottartók (stateful)[szerkesztés]
Az állapottartó beanek[8] üzleti objektumok, amelyek mezőikben tárolják a klienstől kapott információkat, és megőrzik őket az egész session folyamán. Kapcsolatuk szorosabb, mint a kliens és az állapotmentes beaneké; elvben egy munkamenet során egy bean egy klienshez tartozik,[6] ám ha egyszerre sok klienst kell kiszolgálni, akkor a konténer dönthet úgy, hogy a beant állapotának elmentése (passziválás) után egy másik kliensnek ad oda (aktiválás). Ezért fontos, hogy a bean állapota elmenthető, szerializálható legyen.
A bean állapotát a munkamenet végéig őrzi meg. Ekkor a kliens bezárja a kapcsolatot, és a bean állapotának törlése után visszakerül a készletbe. Előfordul, hogy a kliens nem zárja be a munkafolyamatot; ekkor egy idő múlva a konténer elveszi a beant, hogy ne fogyjon el a készlet. Ez az idő a @AccessTimeout annotációval adható meg.[9] Az állapottartó session beanek támogatják a JPA kiterjesztett perzisztencia kontextust.[10]
Példa: Klasszikus példa a bevásárlókocsi, ami számon tartja a munkafolyamat alatt, hogy a vásárló milyen termékeket tett bele, esetleges lockokkal az adatbázisban. A végén a megrendelés zárja a munkamenetet.
Szingletonok (singleton)[szerkesztés]
A szingletonok[11][12] olyan üzleti objektumok, amelyek állapota megosztott egy JVM-en belül. A konkurens hozzáférést alapértelmezetten a konténer kezeli (Container-managed concurrency, CMC), de ez megváltoztatható. Ekkor a beannek magának kell biztosítania, hogy megőrizze állapotának konzisztens voltát (Bean-managed concurrency, BMC). A CMC-nek jelezhetjük a @Lock annotációval, hogy író vagy olvasó lockot igénylünk-e.
A szingleton beanek konkurensen használt beanek, amelyekből elvben egy példány létezik; gyakorlatilag azonban minden JVM-nek saját példánya van. Alapértelmezetten lustán jönnek létre, de ezt megváltoztathatjuk a @Startup annotációval.
Példa: Cachelés, vagy a napi árlista központi nyilvántartása.
Üzenetvezérelt bean[szerkesztés]
Az üzenet vezérelt beanek (MDB) olyan vállalati beanek, amelyek üzenetek aszinkron feldolgozását teszik lehetővé Java EE alkalmazások számára. Többek között a JMS (Java Message Service) kommunikáció magasabb szintű absztrakcióját nyújtja. Feliratkozhat JMS üzenetsorokra vagy témákra, rendszerint a @MessageDriven activationConfig attribútumának hatására. Ezek az EJB-hez rendelődnek, hogy lehetővé tegyék az eseményvezérelt feldolgozást.
Eltérően a session beanektől, az MDB-knek nincs interfészük a kliensek számára, és a kliensek nem is kereshetnek ilyen példányt. Az általa figyelt üzenetsorokra vagy témákra érkező üzeneteket dolgozza fel. A Java EE csak a JMS támogatását írja elő, habár ez más üzenetküldési protokollokat is támogathat. Ezek a protokollok lehetnek szinkronok és aszinkronok is. A fő különbség nem is ebben rejlik, hanem a metódushívás és az üzenetküldés közötti különbségben.
Példák:
- Több csomópontnak kell értesítést küldeni a beállításokról úgy, hogy az üzenetküldőnek ne kelljen ismernie a címzetteket, a helyüket vagy a számukat. A témára egy erre feliratkozott MDB küldi az üzeneteket.
- Egy szálkészletnek kell elvégzendő feladatokat közvetíteni. Mindegy, hogy az adott feladatot melyik szál végzi el a készletből. Az üzenetvezérelt bean egy üzenetsorra küldi az információt. Az üzenetsor biztosítja, hogy egy feladatot ne végezzenek el többen.
Entitás bean (Entity bean)[szerkesztés]
Az entitás bean szerveroldali Java-EE komponens, amely adatbázisban nyilvántartott adatokat képvisel, így van neki azonosító kulcsa. A fenti típusoktól eltérően távoli referenciáival együtt túléli a konténer összeomlását is. Az EJB 2.0-ban definiálták őket, és az EJB 3.0 óta elavultnak számítanak, és a JPA API helyettesíti őket.
Ebből is két fajta van: BMP (Bean Management Beans) és CMP (Container Managed Beans). Míg az első esetben a fejlesztőnek magának kell gondoskodnia a perzisztencia megoldásáról betartva az EJB szabványt, addig a második esetben a perzisztencia vezérlést teljes egészében a konténerre bízható, és ténylegesen csak az üzleti logika megvalósítására lehet összpontosítani.
Működés[szerkesztés]
A rendszer az EJB-ket konténerekbe telepíti (deployolja), amelyek rendszerint alkalmazásszerveren belül futnak. A specifikáció leírja, hogyan kapcsolódik az EJB a konténerhez, és a kliens kód hogy működik együtt a konténerrel és az EJB-vel. Az EJB-k megvalósításához szükséges eszközök a javax.ejb csomagban találhatók. A javax.ejb.spi a szerver kiszolgáló eszközöket tartalmazza, amelyeket a konténerek használnak.
A kliensek nem példányosítják közvetlenül az EJB-ket, hanem kérnek a konténertől egy példányt. A konténer egy referenciát ad vissza, ami nem magára az EJB példányra hivatkozik, hanem egy proxy objektumra. Ez vagy a helyi vagy a távoli üzleti interfészt valósítja meg a kliens kérése szerint, vagy dinamikusan implementálja az EJB altípusát. Mindemiatt a proxy típusa olyan, hogy megfelel a kliens által elvárt interfésznek. Azt mondjuk, hogy a kliensnek van egy nézete az EJB-ről, ami lehet távoli, helyi vagy nem interfész nézet aszerint, hogy melyik interfészt, vagy magát a beant mutatja-e.
Ez a proxy lehetőséget ad a konténernek, hogy különböző szolgáltatásokat nyújtson rajta keresztül, így tranzakciókezelést, távoli eljáráshívást, injektálást, adatvédelmet. Egyes szolgáltatások az aspektusorientált programozás szerint szerveződnek, mint például az interceptorok.
Például a kliens meghívja a proxy egy metódusát. Ennek hatására előbb elindul egy tranzakció a szerveren, majd az EJB üzleti metódusa is elindul. Miután a metódus visszatért, a proxy fejezi be a tranzakciót, és visszaadja a vezérlést a kliensnek.
Tranzakciók[szerkesztés]
Az EJB konténereknek támogatniuk kell mind a konténermenedzselt KATI (angolul: ACID) tranzakciókat, mind a bean menedzselt tranzakciókat.[13] A KATI rövidítés a konzisztencia, atomicitás, tartósság és izoláltság szavakat foglalja magába, amelyek a tranzakciók jellemzői.
Alapértelmezetten a konténer kezeli a tranzakciókat (CMT), így ezt nem kell beállítani. A bean ezt segítheti különféle annotációkkal, amelyek leírják például, hogy melyik művelet milyen lockot igényel. Vannak annotációk, amelyek megváltoztatják a tranzakcionális viselkedést, vagy kikapcsolják a tranzakciókat. A metódusok egyenként is megjelölhetők. Ez a viselkedés magában foglalja, hogy hogyan reagáljanak arra, hogy a kliens tranzakciót kezdeményezett, vagy tranzakción kívül hívták meg.[14][15] Az interceptorok indíthatnak vagy leállíthatnak tranzakciókat, tehát nem mindig a kliens viselkedése a meghatározó.
Típus | Leírás |
---|---|
MANDATORY | Ha nincs tranzakció, akkor hibát jelez, különben csatlakozik a tranzakcióhoz. |
REQUIRED | Ha nincs tranzakció, akkor újat indít. Ha van, akkor csatlakozik hozzá. Ez az alapértelmezett viselkedés. |
REQUIRES_NEW | Ha van tranzakció, akkor azt félreteszi. Minden esetben új tranzakciót indít. |
SUPPORTS | Ha van tranzakció, akkor csatlakozik hozzá, különben tranzakción kívül fut le. |
NOT_SUPPORTED | Ha van tranzakció, akkor azt félreteszi, és tranzakción kívül fut le. |
NEVER | Ha van tranzakció, akkor kivételt dob. Sosem indít tranzakciót. |
A bean deklarálhatja annotációval, hogy a tranzakciókat ő kezeli a JTA API használatával. Ezt nevezik bean által vezérelt tranzakcióknak (BMT), mivel nem a konténer, hanem a bean végzi a tranzakciók kezelését.[16]
Események[szerkesztés]
Az eseményekről a beanek a JMS témákra vagy üzenetsorokba küldött üzenettel értesíthetik a klienst. A kliensektől aszinkron érkező üzeneteket MDB-k fogadják, szintén a JMS eszközeinek felhasználásával.
Névszolgáltatás[szerkesztés]
Az injekció alternatívájaként a kliensek a Java névszolgáltatást (JNDI) is igénybe vehetik a proxy referencia megszerzéséhez. Ez használható akkor, ha az injektálás nem érhető el, például nem menedzselt kódban, vagy távoli különálló Java SE kliensek esetén, vagy pedig akkor, hogyha a kódban kell meghatározni, hogy milyen beant keresünk.
Az EJB konténer a következő JNDI neveket adja az EBJ session beaneknek:[17][18][19]
Hatókör | Névminta |
---|---|
Globális | java:global[/<alk-név>]/<modul-név>/<bean-név>[!<teljes-minősített-interfész-név>] |
Alkalmazás | java:app/<modul-név>/<bean-név>[!<teljes-minősített-interfész-név>] |
Modul | java:module/<bean-név>[!<teljes-minősített-interfész-név>] |
A szögletes zárójelben levő tagok opcionálisak
A kliens helyétől függően az ezekre a mintákra illeszkedő neveken érheti el a proxyt. Az azonos modulban levő kliensek használhatják bármelyiket, míg az azonos alkalmazásban levő csak akkor hívhatja a modulbeli nevét, ha ugyanabban a modulban van, különben csak a két távolabbi meghatározás közül választhat.
Például, ha a kliens ugyanabban a modulban van, mint a fenti példában a CustomerService, akkor a következő kóddal kérhet rá (helyi) referenciát:
CustomerServiceLocal customerService =
(CustomerServiceLocal) new InitialContext().lookup("java:module/CustomerService");
Távoli, vagy elosztott végrehajtás[szerkesztés]
Az EJB session beanek támogatják a távoli eljáráshívást.
A szintén Java nyelvű kliens a bean távoli nézetében annyit lát, amennyit a bean @Remote annotációban megadott interfésze mutat.[20] Ez a nézet más JVM-ből, illetve más számítógépről is látható, és lehetővé teszi, hogy onnan is meghívhassák a bean metódusait. Az EJB konténer szempontjából minden távol van, ami más JVM-ben fut.
Az állapotmentes és a szingleton session beanek webszolgáltatás kliens nézetet is nyújthatnak a WSDL és a SOAP eszközeivel, vagy XML segítségével.[21][22][23] Mindezek a JAX-RPC és JAX-WS specifikációt követik, azonban tervezik a JAX-RPC támogatásának eltávolítását.[24] A JAX-WS használatához a bean meg kell annotálni a @WebService annotációval, és az így hívható metódusait megjelölni a @WebMethod annotációval.
A JAX-RS specifikáció explicit támogatja az EJB beaneket.[25] A JAX-RS specifikáció szerint az állapotmentes és a szingleton beanek gyökér erőforrások lehetnek a @Path annotáció hatására, és az EJB üzleti metódusok leképezhetők erőforrás metódusokká a @GET, @PUT, @POST és @DELETE annotációkkal. Ez azonban nem számít webszolgáltatás kliens nézetnek, amit csak a JAX-WS és a JAX-RPC használ.
A webszolgáltatás útján végbemenő kommunikáció jellemző a nem Java nyelvű kliensekre, de kényelmes a Java nyelvű klienseknek is, hogyha egy tűzfal miatt nem érik el közvetlenül az EJB szervert. Sőt, a kliensnek nem kell telepítenie további kliens oldali könyvtárakat (jar fájlokat), amelyek ütközhetnek a kliens által használt más eszközökkel. Az ilyenm konfliktusokat nagyon nehéz, vagy akár lehetetlen megoldani.[26]
Az üzenetvezérelt beanekhez nem specifikáltak támogatást a távoli elérhetőséghez, de mivel végpontokon hallgatnak, implicit módon távoli komponensek az általuk hallgatott végpont típusának tulajdonságaival ellátva.
Biztonság[szerkesztés]
Az EJB konténernek biztosítania kell a klienseknek azt a jogot, hogy hozzáférjenek az EJB-hez.[27] Az EJB-kben a hozzáférés szintje annotációkkal szabható testre.[28]
Legacy[szerkesztés]
Helyi interfész és megkövetelt interfész[szerkesztés]
Az EJB 2.1-gyel bezárólag az EJB-knek két interfészt és egy megvalósító osztályt kellett nyújtaniuk. A konténer példányosította az implementáló osztályt, hogy EJB implementációt hozzon létre. Az interfészeket a kliensek használták.
A két interfészt Home és Remote interfészekként kellett specifikálni, és az EJB távoli metódusainak szignatúráit deklarálták. A metódusok lehettek osztály és példány szintűek is. Az osztályszintű metódusokat a Home interfész deklarálta. Ugyanez írta le az EJB megtalálásához vagy létrehozásához szükséges metódusokat is. A példány szintű metódusokat a Remote interfész írta le.
Elvárt telepítési (deployment) leíró[szerkesztés]
Az EJB 2.1-gyel bezárólag az EJB specifikácuiója megkövetelte a telepítésleírót. Ennek azt a mechanizmust kellett leírnia, hogy hogy lehet az EJB-ket konzisztensen telepíteni (deployolni) a kiválasztott specifikus EJB platformtól függetlenül. Ennek a bean telepítését, köztük a Home és a Remote interfészek nevét és adatbázisban való tárolás módját is tartalmaznia kellett.
A telepítésleíró egy XML fájl volt, ami felsorolta az összes EJB-t, és mindegyiknél megadta a következő információkat:
- A Home interfész neve
- A bean Java osztálya
- A Home interfész Java interfésze
- A bean Java interfésze
- Ha a bean entitásbean, akkor az adatbázis megnevezése
- Biztonsági szerepek és jogok
- Ha a bean session bean, akkor állapotmentes, vagy állapottartó-e
Több terjesztő EJB konténerei további információkat igényeltek, akár további XML fájlokban, vagy más formátumokban. A terjesztők további eszközöket nyújtottak, amelyek olvasták ezeket a fájlokat, és további osztályokat is generálhattak, amelyek a Home és a Remote interfészeket implementálták.
Az EJB 3.0-tól a szükséges információk annotációkkal is megadhatók az EJB implementációjában, de továbbra is van lehetőség az XML leíró használatára. Ez a leíró fájl felülírhatja az annotációkat, habár egyes elemek additívan viselkednek, vagyis ezeknél az XML nem felülírja, hanem kiegészíti az annotációkat.
Konténerváltozatok[szerkesztés]
Az EJB 3.1-től kezdve az EJB specifikáció kétféle konténert definiál: teljes és korlátozott változatot.[29][30] A korlátozott változat nem támogat minden feathure-t, és az EJB 3.1 Lite specifikációt valósítja meg, és a Java EE 6's web profile-nak is része.
Az EJB 3.1 Lite nem támogatja a következőket:[31]
- Távoli interfész
- RMI-IIOP együttműködés
- JAX-WS webszolgáltatás végpontok
- EJB időzítő szolgáltatások, mint a @Schedule, @Timeout
- Aszinkron session bean hívások @Asynchronous
- Üzenetvezérelt beanek
Az EJB 3.2 Lite több eszközt támogat, nem zárja ki az Asynchronous és @Schedule/@Timeout annotációkat, habár a teljes verzióhoz képest nem támogatja a persistent attributumot. Tehát a következőket zárja ki:
- Távoli interfész
- RMI-IIOP együttműködés
- JAX-WS webszolgáltatás végpontok
- Üzenetvezérelt beanek
Jegyzetek[szerkesztés]
- ↑ Enterprise JavaBeans Technology. (Hozzáférés: 2010. február 5.)
- ↑ J2EE Design and Development, © 2002 Wrox Press Ltd., p. 5.
- ↑ Types of Enterprise Beans. (Hozzáférés: 2010. február 5.)
- ↑ State Management Modes. (Hozzáférés: 2010. február 5.)
- ↑ JSR 318, 4.7, http://jcp.org/en/jsr/detail?id=318
- ^ a b JSR 318, 4.10.3, http://jcp.org/en/jsr/detail?id=318
- ↑ JSR 318, 4.3.14, http://jcp.org/en/jsr/detail?id=318
- ↑ JSR 318, 4.6, http://jcp.org/en/jsr/detail?id=318
- ↑ JSR 318, 4.3.14, 21.4.2, http://jcp.org/en/jsr/detail?id=318
- ↑ http://blogs.sun.com/enterprisetechtips/entry/extended_persistence_context_in_stateful
- ↑ JSR 318, 4.8, http://jcp.org/en/jsr/detail?id=318
- ↑ Singleton EJB. Openejb.apache.org. (Hozzáférés: 2012. június 17.)
- ↑ JSR 318, Chapter 13, http://jcp.org/en/jsr/detail?id=318
- ↑ JSR 318, 13.6.2, http://jcp.org/en/jsr/detail?id=318
- ↑ Transaction Annotations. Openejb.apache.org. (Hozzáférés: 2012. június 17.)
- ↑ JSR 318, 13.3.6, http://jcp.org/en/jsr/detail?id=318
- ↑ JSR 318, 4.4, http://jcp.org/en/jsr/detail?id=318
- ↑ Portable Global JNDI names (MaheshKannan). Blogs.oracle.com. (Hozzáférés: 2012. június 17.)
- ↑ Portable Global JNDI Names (Ken Saks's Blog). Blogs.oracle.com. (Hozzáférés: 2012. június 17.)
- ↑ JSR 318, Chapter 15, http://jcp.org/en/jsr/detail?id=318
- ↑ JSR 318, 2.6, http://jcp.org/en/jsr/detail?id=318
- ↑ JSR 318, 3.2.4, http://jcp.org/en/jsr/detail?id=318
- ↑ JSR 318, 4.3.6, http://jcp.org/en/jsr/detail?id=318
- ↑ JSR 318, 2.7, http://jcp.org/en/jsr/detail?id=318
- ↑ JSR 311, Chapter 6.2, http://jcp.org/en/jsr/detail?id=311
- ↑ Communication between JBoss AS 5 and JBoss AS 6 | JBoss AS | JBoss Community. Community.jboss.org. (Hozzáférés: 2012. június 17.)
- ↑ JSR 318, Chapter 17, http://jcp.org/en/jsr/detail?id=318
- ↑ Security Annotations. Openejb.apache.org. (Hozzáférés: 2012. június 17.)
- ↑ Resin Java EE 6 Web Profile - Resin 3.0. Wiki.caucho.com, 2010. február 12. (Hozzáférés: 2012. június 17.)
- ↑ JSR 318, 21.1 EJB 3.1 Lite, http://jcp.org/en/jsr/detail?id=318
- ↑ JSR 318, Table 27 - Required contents of EJB 3.1 Lite and Full EJB 3.1 API, http://jcp.org/en/jsr/detail?id=318
Fordítás[szerkesztés]
Ez a szócikk részben vagy egészben az Enterprise JavaBeans című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel.