EJB 3
Tartalom Az EJB 2.1 problémái Az EJB 3 megoldásai
Miért nem szeretik sokan az EJB 2.1-et? bonyolult a fejlesztés: sok file (legalább 3 java + legalább 2 xml), a fejlesztı eszközök varázslóival kell karbantartani a bean osztálynak implementálnia kell a javax.ejb.session/entity/messagedrivenbean interfészt callback metódusokat definiál, amiket nem használunk mindig, mégis implementálni kell egy EJB metódus meghívása több sornyi kód: home interfész megkeresése a JNDI API-val home interfész create() metódusának hívása különféle Exception-ök kötelezı kezelése entity beanek használata esetén: a session facade tervezési minta miatt DTO osztályok
Miért nem szeretik sokan az EJB 2.1-et? bonyolult a telepítés: telepítésleíró (XML fájl) karbantartása konténer specifikus fájlok karbantartása bonyolult tesztelés: konténeren belül: gyakorlatilag egy másik komponens (Servlet/JSP) megírását igényli konténeren kívül: csak lokális interfészes EJB-hez emiatt írjunk remote-ot is?
Miért nem szeretik sokan az EJB 2.1-et? bonyolult debuggolás: server log fájljainak analizálása: nem hatékony nagy fájlok esetén az alkalmazás szervert futtató JVM-hez csatlakozni debuggerrel: nem minden alkalmazás szerverhez van ilyen támogatás
Miért használjunk mégis az EJB-ket? Az üzleti logikát meg lehet hagyományos Java osztályokban is valósítani, de érdemes az EJB-ket használni, ha: az üzleti logika távoli elérése szükséges (más JVM-bıl, esetleg más géprıl) rugalmas middleware szolgáltatások: tranzakciókezelés (akár elosztott) a metódusokhoz való hozzáférést deklaratívan akarjuk szabályozni öröklött alkalmazásokkal kell együttmőködni követelmény a skálázhatóság O-R leképezést akarunk megvalósítani (bár erre voltak korábban is Java SE technológiák: JDO, Hibernate) elıírják
EJB 3 célja az EJB architektúra egyszerősítése a fejlesztı szempontjából az eddig nyújtott szolgáltatások természetesen megmaradnak + számos új feature
Mik az egyszerősítések? sok file spóroljunk velük: a telepítésleíró helyett ún. annotációkkal defináljuk a forráskódban amit eddig a telepítésleíróban tettünk ráadásul ezeket az annotációkat is csak akkor kelljen megadni, ha eltérünk a defaulttól (ehhez persze specifikálni kell, mi a default) home interfész elhagyása session beaneknél az entity beanek helyett POJO perzisztencia a perzisztens entitásoknál kiesik a remote/local interfész is DTO osztályok elhagyhatók (+sok egyéb feature)
Mik az egyszerősítések? sok kódsor ne legyen kötelezı nem kell a javax.ejb.enterprisebean interfészeket implementálni (ha valamelyik callback metódus szükséges, annotációval jelöljük meg) EJB meghívásának egyszerősítése: a home interfész kiküszöbölése JNDI keresés kihagyása, helyette külsı erıforrások injektálása Minden kivétel javax.ejb.ejbexception-be csomagolva dobódjon tovább (ez egy RuntimeException, így nem kötelezı elkapni)
Annotációk A Java SE 5 újítása Az EJB 3 erısen épít rá A forráskódba (osztály, metódus, tagváltozó elé) illesztett metaadat Közvetlenül nem a program jelentését módosítja, hanem azt, hogy különbözı eszközök és libraryk hogyan kezeljék (ez persze végül a futási idejő mőködésre hatással van) Korábban: komment javadoc XDoclet A Java 5 egységes szintaxist határoz meg,és standard módszert saját annotációk definiálására
Annotációk szintaxis @AnnotációNeve(paraméter1=érték1, paraméter2=érték2...) ha csak egy paraméter van: @AnnotációNeve(érték) is lehetséges ha nem adunk át paramétert: @AnnotációNeve, vagy @AnnotációNeve() A paraméter tömb is lehet, ekkor értéke a szokásos tömb szintaxis {elem1, elem2,...}
Beépített annotációk a Java SE 5 compilere 3 annotációt ismer alapból: @Override: gépelési hibák elkerülése @Deprecated: elavult metódusok megjelölésére (korábban commentben) @SurpressWarnings: különféle warningok elrejtését végzi
Saját annotációk @interface interfészben definiáljuk az annotáció nevét, és hogy milyen paramétereket fogad el a paraméterek metódus szintaxissal adhatók meg ha csak egy paraméter van, annak value() nevet kell adni lehetséges visszatérési érték: egyszerő típus String Class Annotation enum ezek tömbjei lehet default értékük
Példa (egyszerő dokumentáció) import hu.bme.aait.todo... @TODO(item= Javítani ) public void mymethod{...} package hu.bme.aait; public @interface TODO{ public enum Severity { CRITICAL, IMPORTANT, TRIVIAL, DOCUMENTATION }; Severity severity() default Severity.IMPORTANT; String item(); }
Példa annotáció futási idejő feldolgozására public class Foo { @Test public static void m1() {...} public static void m2() {...} } public class RunTests { public static void main(string[] args){ int passed = 0, failed = 0; for (Method m:class.forname(args[0]).getmethods()) { if (m.isannotationpresent(test.class)) { try { m.invoke(null); passed++; } catch (Throwable ex){ System.out.printf("Test %s failed: %s %n", m,ex.getcause()); failed++; } } } System.out.printf("Passed: %d, Failed %d%n", passed, failed); } }
Meta-annotációk Annotációk annotálására Annotáció definiálásánál egyéb részletek megadására használatos: @Target: megadhatjuk, mire alkalmazható az annotáció, pl.: @Target({ElementType.METHOD, ElementType.CONSTRUCTOR}) public @interface Test{}
Meta-annotációk @Retention: hogyan kezelje a complier az annotációt? Lehetséges értékek: RetentionPolicy.SOURCE: a fordító nem fordítja le RetentionPolicy.CLASS: a fordító belerakja a class fájlba, de a JVM ignorálja futás közben RetentionPolicy.RUNTIME: futás közben beolvassa a JVM a class fájlból
Meta-annotációk @Documented: az annotáció kerüljön bele a javadoc-ba (enélkül nem kerül bele) @Inherited: az ezzel megjelölt annotációval annotált osztály a gyermekosztályaira is örökíti az annotációt
Java EE annotációk A Java EE 5 egy sor annotációt definiál, az alkalmazás szerver gyártó feladata ezeket az annotációkat értelmezni a komponensek telepítéskor, és a komponens fejlesztıje által annotációk által definiált futási idejő szolgáltatásokat biztosítani Vagyis a telepítésleírók szerepét veszi át Alapelv: a telepítésleírók továbbra is használhatók, és felüldefiniálják az annotációkat, ha az is van (ez különösen fontos, ha harmadik fél számára újrafelhasználhatóvá akarjuk tenni)
EJB 3 session bean 2 fájl már elég: Enterprise bean osztály business interfész ráadásul ezeknek ne kelljen semmilyen ejb-specifikus interfészt megvalósítaniuk (POJO-k = Plain Old Java Object) Meg kell oldani: a 2 fájl összerendelését (nincs DD), állapotkezelés definiálását (nincs DD) a callback metódusok definiálását (nem implementálunk ejbspecifikus IF-eket) inicializálást, referencia szerzését (nincs home IF, és nem akarunk JNDI hívásokat sem)
Megoldások bean osztály és business IF összerendelése: az implements kulcsszó elég, ha csak egy interfészt implementál a bean osztály lokális interfésznek tekintjük, hacsak nem rakunk @Remote annotációt az IF vagy a bean osztályhoz ha több interfészt implementál: a @Local illetve a @Remote paraméterében adható meg, hogy ezek közül melyik része a lokális/remote interfésznek a java.io.serializable, Externalizable, és a javax.ejb package interfészei nem számítanak bele
Megoldások állapotkezelés megadása: a bean osztályra @Stateful vagy @Stateless megadása jelentésük ugyanaz mint 2.1-ben (ugyanolyan életciklust biztosít számukra a konténer)
Megoldások callback metódusok: a bean osztály nem implementál interfészeket, helyette megjelöl metódusokat, ha kezelni akar bizonyos eseményeket (ezek a metódusok más osztályban is lehetnek, lásd késıbb az Interceptoroknál) ejbcreate() @PostConstruct ejbacitvate() @PostActivate ejbpassivate() @PrePassivate ejbremove() @Remove (ezt a kliens hívja, ha állapottal rendelkezı) @PreDestroy: ezt a konténer hívja eltávolítás elıtt
Megoldások referencia szerzés az EJB hívásához: telepítéskor nem muszáj JNDI nevet adni az EJB-nek, mert a teljesen kvalifikált nevét kapja defaultként (ha mégis adunk:@stateful(name= ejb/myname )) ha a kliens konténerben fut (pl. más EJB vagy web komponens): függıség injektálás (dependency injection) @EJB annotációval konténeren kívüli kliens: JNDI lookup marad, de a keresés eredménye egybıl referencia a beanre, nemcsak a home hasonló függıség injektálás más erıforrásokra is (pl. adatbázis, JMS üzenetsor, EJB context): @Resource
Interceptorok Aspektus orientált programozás: a teljes alkalmazásra kiterjedı szempontok (aspektusok), pl. loggolás, biztonsági ellenırzés végigvezetése a teljes alkalmazáson nehézkes lehet csak OO technikákkal AOP alapgondolata: ezeket valahol külön implementáljuk, a kódban valahogyan definiáljuk, hova kerüljenek be, és egy átszövı (weaver) segítségével álljon elı a kész program általában meglévı nyelvek kiterjesztésével támogatják az AOP-ot
Interceptorok Az EJB 3 által definiált interceptorok az AOP kezdetleges támogatásának tekinthetık session és message-driven beanekre definiálhatók, vagy egyes metódusokra megszakítják a bean metódusát, módosíthatják a bemenı paramétereket, akár meg is akadályozhatják a tényleges meghívást (Servlet Filterekhez hasonló)
Interceptorok hozzáadása az EJB-hez @Interceptor({Interceptor1.class) mivel egy annotáció csak egyszer szerepelhet, ha többet akarunk: @Interceptors({Interceptor1.class, Interceptor2.class,...}) ez általános elv annotációknál a lista sorrendjében hívódnak meg az interceptorok mint mindent, ezt is meg lehet adni DD-ben is
Interceptor írása tetszıleges Java osztály, paraméter nélküli konstruktorral az interceptor metódus @AroundInvoke-kal van annotálva, dobhat Exception-t használhat függıség injektálást a hívott EJB biztonsági és tranzakciós kontextusában fut bemenı paramétere egy InvocationContext, ezen keresztül éri el a megszakított metódust, paramétereket, a bean példányt, és ebbe rakhat névvel azonosított adatokat más interceptorok számára ha egy EJB callback metódusát külön osztályba rakjuk, akkor azt nem @AroundInvoke-kal, hanem a @PostConstruct, @PrePassivate, stb. annotációkkal kell megjelölni