Ejb 3.1
EJB 3.1[szerkesztés]
Az EJB 3.1 az Enterprise JavaBeans (EJB) specifikáció jelenleg legfrissebb változata, amely az EJB 3.0 által kijelölt úton haladva tovább próbálja egyszerűsíteni a Java EE programozási modellt, ugyanakkor számos hasznos, új funkciót is hozzáad az eddigiekhez. A legfőbb változásokról dióhéjban:
Opcionális EJB interfészek[szerkesztés]
Az EJB 3.1-ben az üzleti interfészek használata opcionálissá vált, ezzel az utolsó akadály is elhárult az elől, hogy az EJB-k valódi POJO-k legyenek. Természetesen ez nem azt jelenti, hogy soha sem kell interfészeket írnunk az EJB komponenseinkhez, de sok olyan eset előfordulhat a fejlesztés során, amikor az interfész bevezetése csak egy szükségtelen plusz absztrakció, és igazából csak terhet jelent.
Singleton Session Bean[szerkesztés]
Az EJB 3.1-ben megjelentek az ún. Singleton Session Bean-ek, amelyek gyakorlatilag a Singleton tervezési mintát valósítják meg. Általában olyan adatok tárolására használjuk, amelyeket alkalmazásszinten el akarunk érni. Jól használhatók például olyan cache létrehozására, amelyet bárhonnan az alkalmazásból elérhetünk. A konténer garantálja, hogy mindig fenn fog tartani egy megosztott példányt a Singleton Session Bean-ből.
Hordozható, globális JNDI nevek[szerkesztés]
Az EJB korábbi verzióiban sok problémát okozott az, hogy a különböző alkalmazásszerverek használatakor különbözőképpen kellett a JNDI neveket megadni. Az EJB 3.1-ben a globális JNDI nevek egy szabványos mintát kell, hogy kövessenek, amely így hordozhatóvá válik az alkalmazásszerverek között: java:global[/<alkalmazásnév>]/<modulnév>/<beannév>#<interfésznév>
Továbbfejlesztett Timer Service[szerkesztés]
Egy fontos újítás az EJB 3.1-ben, hogy deklaratívan képesek vagyunk előírni egyes EJB metódusok időzített meghívását. Egyszerűen csak el kell látnunk a megfelelő EJB metódust egy @Schedule annotációval. Például a @Schedule(minute=”45”, hour=”10”, dayOfWeek=”Fri”) annotációt elhelyezve egy metóduson megadhatjuk, hogy az adott metódus minden pénteken 10:45-kor fusson le.
Aszinkron Session Bean-ek[szerkesztés]
Sokszor van szükségünk adatok aszinkron feldolgozására. Erre egy megoldás lehet a message driven bean-ek használata, amely ugyan nem bonyolult, de néha mégis túl sok plusz munkát jelenthet, ha csak egyetlen metódus aszinkron hívására van szükségünk. EJB 3.1-ben már egy másik, végtelenül egyszerű megoldás is létezik az aszinkron metódushívásra, egyszerűen csak az @Asynchronous annotációt kell elhelyeznünk az aszinkron módon meghívandó metóduson. Ilyenkor a meghíváskor a konténer azonnal visszaadja a vezérlést a hívónak, és a metódust egy külön szálon hajtja végre.
EJB Lite[szerkesztés]
Számos olyan nagyvállalati alkalmazás létezik, amelyek nem használják ki az EJB összes lehetőségét (például üzenetküldés, web servicek), csak a lehetőségek egy szűk részhalmazát (például session beanek, függőség injektálás). Ezen alkalmazások számára tökéletes megoldás lehet az EJB Lite használata, amely az EJB specifikáció egy "könnyebb súlyú" változata. Az EJB Lite segítségével használhatjuk a stateless, statefeul, singleton session beaneket, de csak a lokális interfészek és az interfész nélküli beanek támogatottak, az aszinkron hívásra nincs lehetőség, elérhetőek az interceptorok, a deklaratív biztonság és tranzakciókezelés, viszont a metódusok időzített hívása nem támogatott.
WAR fájlba történő csomagolás[szerkesztés]
Korábban még a legegyszerűbb EJB alapú alkalmazásoknál is a webalkalmazásunkat war fájlba kellett csomagolni, az EJB-ket egy jar fájlba, a kettőt együtt pedig egy külön ear fájlba kellett helyezni, amit aztán telepíthettünk. A 3.1-egy verziótól kezdve a EJB-k elhelyezhetőek a war kiterjesztésű állományokba is a WEB-INF/classes könyvtárba.
Beágyazott konténer[szerkesztés]
Sokáig az EJB-k használata ellen az egyik legkomolyabb ellenérv a nehéz tesztelhetőség volt, hiszen az EJB-k használatához szükségünk volt egy futó konténerre. A 3.1-es verzióval kezdődően nincs többé létjogosultsága ennek az ellenérvnek, hiszen a beágyazott konténer lehetővé teszi, hogy az alkalmazásszerver elindítása nélkül is tesztelni tudjuk az enterprise beanjeinket.
