EJB konténer

Az EJB konténer az EJB szerverek azon része, amely tárolja és menedzseli a szerveren futó alkalmazások EJB komponenseit. Implicit középrétegként szolgál, elősegítve ezáltal az elosztott rendszerek fejlesztését és működtetését adott szintű transzparencia biztosításával. Konkrét fizikai megvalósítását az EJB specifikáció nem rögzíti le, ennek részleteit az alkalmazásszerver gyártókra bízza.

A konténer által ellátandó főbb feladatok a következők:

Erőforrás hozzáférési szolgáltatás biztosítása az EJB-khez
Az EJB-k életciklusának menedzselése
Az EJB-k kliensoldali elérhetőségének biztosítása
Tranzakciókezelés támogatása
Elosztott rendszerek esetén skálázhatóságot biztosító szolgáltatások nyújtása

Erőforrás hozzáférés - JNDI

Az EJB konténer része egy JNDI (Java Naming and Directory Interface) katalógus. Ez a ragasztó, ami összetartja az egyes EJB-ket. Kereshető formában tárolja a katalógusba beregisztrált objektum referenciákat, továbbá képes az együttműködésre a hierarchikus információ tárolásra képes címtár alapú rendszerekkel. A JNDI önmagában csak egy interfész a referenciák kereséséhez és tárolásához. A név és könyvtárazási szolgáltatást tetszőleges katalógustechnológia megvalósíthatja (LDAP, RMI, COS, DNS, stb).

A JNDI a neki átadott referenciákból a fájlrendszerek könyvtárszerkezetéhez hasonló hierarchikus adatstruktúrát épít fel. Adott erőforrás eléréshez ismernünk kell a sémát, ami alatt a katalógus tárolja azt, a kontextust, amibe tartozik és az erőforrás nevét. Az előző analógiánál maradva a kontextusokra tekinthetünk úgy, mintha könyvtárak lennének, amelyek az egyes erőforrásokat, mint fájlokat tartalmazzák.

A JNDI használata az EJB 2.1-es specifikációjáig a javax.naming csomagot használva a megfelelő metódus hívásokon keresztül történt. Az EJB 3.0-ban bevezetett annotációk használatával ezt a feladatot az EJB konténer szinte teljes egészében átveszi a fejlesztőktől. Ezt a mechanizmust erőforrás injektálásnak nevezzük melynek lényege, hogy a konténer a megfelelően felannotált (@Resource annotáció) mezőkhöz automatikusan képes hozzárendelni a megfelelő erőforrásokat a konténer indulásakor vagy később a futás alatt.

EJB-k menedzselése

Az EJB-k életciklusának menedzselése függ a kezelendő Bean típusától, mivel az eltérő komponensek eltérő életciklussal rendelkeznek.

Állapotmentes(Stateless) Session Bean

Az állapotmentes Session Bean osztályokkal olyan üzleti funkcionalitásokat valósítanak meg, amelyek során nem történik állapottárolás. A kliens az üzleti folyamat során akár több különböző objektumával is kommunikálhat ugyanannak az állapotmentes Session Bean osztálynak.

A konténer feladatai az állapotmentes Session Bean életciklus menedzsmentje során:

Példányosítja az objektumot. Ez történhet egy beérkező kliens create() metódus hívására, de nem feltétlenül kell így lennie.
Példányosítás után meghívja rá a setSessionContext(), majd ejbCreate() metódusokat. Az EJB objektumhoz ezután bármikor befuthatnak feldolgozandó kliens kérések.
Időzített metódus hívás esetén meghívhatja az objektum ejbTimeOut() metódusát, ha lejárt a válaszidő.
A konténer, ha úgy találja tetszőleges állapotmentes EJB objektumot megszüntethet. Az objektum felszabadítása előtt mindig meghívja annak ejbRemove() metódusát.

Állapottal rendelkező (Stateful) Session Bean

Az állapottal rendelkező Session Bean olyan esetekben használatos, amikor a kliens több kérésén átívelő állapotot akarunk tárolni. A rendelkezésre álló memória végessége miatt nem kivitelezhető, hogy minden klienshez egy külön Session Bean-t rendeljünk. Ennek a problémának a megoldása a konténerre hárul.

A konténer feladatai az állapottal rendelkező Session Bean életciklus menedzsmentje során:

Példányosítja az objektumot. Ez történhet egy beérkező kliens create() metódus hívására, de nem feltétlenül kell így lennie.
Példányosítás után meghívja rá a setSessionContext(), majd valamelyik ejbCreate() metódusát. Egy állapottal rendelkező Session Bean-nek több, eltérő paraméterezésű ejbCreate() metódusa is lehet, amelyekhez külön create() metódusok tartoznak a Bean Home objektumában. Az EJB objektumhoz ezután bármikor befuthatnak feldolgozandó kliens kérések.
A konténer kiválaszt egy Session Bean-t, majd passziválja.
A konténer kiválaszt egy Session Bean-t, majd aktiválja.
A konténer meghívhatja a régóta nem hivatkozott objektumok ejbTimeout() metódusát, aminek hatására az objektum megszűnik (nincs ejbRemove() hívás!!!).
A konténer, ha úgy találja tetszőleges állapottal rendelkező EJB objektumot megszüntethet. Az objektum felszabadítása előtt mindig meghívja annak ejbRemove() metódusát.

Állapottal rendelkező Session Bean passziválása

A Bean passziválásakor a konténer meghívja az objektum ejbPassivate() metódusát, aminek hatására annak a kliensnek az állapota, amihez korábban az objektum hozzá volt rendelve, mentésre kerül az adatbázisba. Szintén ezen metódus hívással kerülnek felszabadításra az EJB által korábban birtokolt erőforrások (file-ok, adatbázis, kapcsolatok, hálózati kapcsolatok, stb.). Az állapotmentés a konténer feladata, a fejlesztőnek csak az erőforrás felszabadításról kell gondoskodnia. Az állapottal rendelkező Session Bean ezzel passzív állapotba kerül, azaz nincs klienshez rendelve. Egy objektum passziválása nem csak az előbbi helyzetben fordulhat elő. A konténer bármikor dönthet úgy, hogy passzivál egy állapottal rendelkező Session Bean-t, egyetlen feltétellel: az aktuálisan tranzakcióban részt vevő és metódust végrehajtó Bean-t kötelező a memóriában tartani.

Állapottal rendelkező Session Bean aktiválása

A Bean aktiválására akkor van szükség, ha egy kliens kérés kiszolgálása már nem oldható meg új Bean példányosításával. Ekkor a konténer egy passzivál egy objektumot vagy keres egyet a már passziváltak közül, ha van ilyen és aktiválja a kliens számára. Ehhez meghívja a Bean ejbActivate() metódusát, ami az ejbPassivate() inverzének tekinthető. Betölti az adatbázisból a kliens állapotát és lefoglalja számára a szükséges erőforrásokat.

Üzenet vezérelt(Message Driven) Bean

Az üzenet vezérelt Bean-ek működése jelentősen eltér a Session Bean-ek működésétől, ezért a konténer meglehetősen eltérően kezeli őket.

A konténer feladatai az állapottal rendelkező Session Bean életciklus menedzsmentje során:

Példányosítja az objektumot.
Példányosítás után meghívja az objektum setMessageDrivenContext() metódusát, amivel beállítja a Bean kontextusát.
Minden a Bean-nek szoló üzenet megérkezése esetén meghívja annak onMessage() metódusát.
A konténer, ha úgy találja tetszőleges üzenet vezérelt objektumot megszüntethet. Az objektum felszabadítása előtt mindig meghívja annak ejbRemove() metódusát.

AZ EJB-k kliensoldali elérhetőségének biztosítása

A konténer minden általa tartalmazott EJB-hez példányosít egy Home objektumot, amelytől a kliensek referenciát kérhetnek az EJB objektumokra. Minden EJB-hez tartozik egy Home interfész, amely tartalmazza az EJB példányosításával megszüntetésével, keresésével, gyűjteményezésével kapcsolatos metódusok deklarációit. A Home interfészeket megvalósító konkrét osztályokat, amelyekből a Home objektumok példányosítva vannak, a konténer generálja le. Egy konténeren belül nincs rögzítve, hogy hány Home objektum lehet egyidejűleg példányosítva, ezt a specifikáció a gyártóra bízza, de általában minden EJB osztályhoz csak egy Home objektumot tárolnak a konténerek. A konténer dönti el, hogy a kliensektől beérkező kérések esetén egy új EJB objektumot hoz létre vagy egy meglévőről ad referenciát.

Konténer által biztosított tranzakciókezelés

A tranzakciókezelésre kétféle lehetőséget biztosít az EJB technológia. Az egyik lehetőség, hogy a megfelelő java API-kat (pl.: JTA) felhasználva az egyes Bean-ekben a szoftverfejlesztő maga gondoskodik a tranzakciókezelésről. A feladat másik megoldása, ha a tranzakció kezelést a konténerre bízzuk.

A megfelelő annotációk használatával vagy az egyes EJB-k telepítésleírójában kell jeleznünk, ha a tranzakciókezelést, mint implicit középréteg szolgáltatást igénybe szeretnénk venni a konténertől. Amennyiben így döntünk, úgy a konténer fogja legenerálni a tranzakció indítással, jóváhagyással és visszagörgetéssel kapcsolatos kódrészleteket. Entity Bean-ek esetén kötelező a konténer által kezelt tranzakciók használata. A tranzakció pontos működését metódus szinten ún. tranzakciós attribútumokkal definiálhatjuk. A segítségükkel beállíthatjuk, hogy az adott metódus meghívása esetében szükséges-e a tranzakció kezelés, valamit rendelkezhetünk arról is, hogy mi történjék, ha híváskor még folyamatban van egy vagy több korábban indult tranzakció.

Tranzakciós attribútumok:

Mandatory: metódushíváskor ha már indult tranzakció, akkor a metódus becsatlakozik. Ha nincs élő tranzakció, akkor konténer kivételt dob.

Never: metódushíváskor ha nincs élő tranzakció, akkor a konténer sem indít és a metódus tranzakciókezelés nélkül fut le. Ha van élő tranzakció, akkor a konténer kivételt dob.

NotSupported: metódushíváskor ha már indult tranzakció, akkor a konténer felfüggeszti azt. Ha nincs élő tranzakció, akkor a konténer sem indít. A metódus tranzakciókezelés nélkül fut le. A lefutása után az esetleg felfüggesztett tranzakciók folytatódnak.

Required: metódushíváskor ha már indult tranzakció, akkor a metódus becsatlakozik. Ha nincs élő tranzakció, akkor a konténer indít egyet.

RequiresNew: metódushíváskor ha nincs élő tranzakció, akkor a konténer indít egyet. Ha van, akkor a futó tranzakciókat felfüggeszti és egy újat indít a metódusnak. A metódushívás után folytatódnak a korábban megkezdett tranzakciók.

Support: metódushíváskor ha már indult tranzakció, akkor a metódus becsatlakozik. Ha nincs élő tranzakció, akkor nincs tranzakciókezelés.

Skálázhatóság

A konténer dönti el, hogy a kliensektől beérkező kéréseket egyetlen EJB-nek továbbítja vagy többnek, hogy csökkentse a terhelésnövekedés miatti várakozás időt. Szintén a konténer hatáskörébe tartozik EJB példányok számának szükségszerű növelése vagy csökkentése. A skálázhatóság ezen szintű biztosítása a szoftverfejlesztő számára teljes mértékben transzparens.

Külső hivatkozások

Informatikai portál • összefoglaló, színes tartalomajánló lap