Java 2 Enterprise Edition

1. Java 2 Enterprise Edition Imre Gábor gabor@aut.bme.hu

2. Tartalom • A J2EE áttekintése • Middleware szolgáltatások • Enterprise Java Beans • Alkotóelemei • Típusai

3. Java 2 Enterprise Edition (J2EE) • Vállalati információs rendszerek fejlesztése során sok hasonló követelmény (pl. biztonság, integrálhatóság más rendszerekkel) • Az ilyen feladatokat érdemes általánosan megoldani, és valamilyen keretrendszerre rábízni • A J2EE a Java platform azon része, mely támogatást nyújt ezen igények megoldására

4. Java 2 Enterprise Edition Architektúra • Többrétegű • Kliens-szerver • Komponens alapú

5. XML Web Services HTTP RMI-IIOP JMS JDBC(SQL) Megfelelő protokoll XML Web Services A J2EE alkalmazás szerver Vastag kliens, applet, CORBA kliens Nem java rendszer Böngésző,mobil eszköz Servlet Jsp J2EE szerver EJB Connector Üzenetsor Adatbázis Öröklött rendszer Nem java rendszer

6. Web komponensek • Servlet • Dinamikus weboldalak generálása • Web konténer futtatja (plug-in a web serverben) • JSP • Html-be ágyazott java kód • Servletté fordul le • Saját tag-ek definiálása

7. A kliens kérésének kiszolgálása Kliensek Hálózat Web szerver Web konténer EJB konténer Adatforrás DBMS

8. J2EE technológiák • Nyílt szabvány  sok implementáció • J2EE 1.3 tanúsítvány = adott API-k implementálása • Pl. : • JDBC 2.0 • EJB 2.0 • Servlet 2.3 • JSP 1.2 • JMS 1.0

9. Elterjedt J2EE szerverek • Oracle Application Server • BEA WebLogic Server • IBM WebSphere Application Server • Sun One • JBoss (Open source) • Piaci részesedés 2002. márciusában:

10. Enterprise Java Beans (EJB) • Szabványos felülettel rendelkező, elosztott szerver oldali komponensek, melyek az üzleti logikát tartalmazzák • EJB konténer futtatja őket • Elfedi a hálózati kommunikációt (RMI-IIOP) • Elfedi a többszálúságot • Elfedi a tranzakciókezelést • Egyéb szolgáltatásokat nyújt

11. Middleware szolgáltatások • Olyan szolgáltatások, melyeket általában a középső réteg valósít meg • Távoli eljáráshívás • Szálkezelés • Terheléskiegyenlítés • Átlátszó hibakezelés • Perzisztencia • Tranzakciókezelés • Objektumok életciklusa • Aszinkron üzenetkezelés • Biztonság

12. Tranzakciós API Biztonsági szolgáltatás Kliens Elosztott objektum Biztonsági API Tranzakció szolgáltatás Távoli interfész Csonk Váz Adatbázis meghajtó Hálózat Adatbázis API Explicit middleware

13. Az explicit middleware hátrányai • Felduzzad a forráskód • Nem rugalmas a middleware (ha eladjuk a komponenst, ki kell adni a forráskódot, ha a vevő pl. más tranzakciókezelést akar)

14. Implicit middleware Elosztott objektum Biztonsági API Biztonsági szolgáltatás Távoli interfész Kliens Kérésmeg-szakító Tranzakció szolgáltatás Tranzakciós API Távoli interfész Adatbázis meghajtó Csonk Váz Adatbázis API Hálózat

15. Implicit middleware • Külön leíró fájl tartalmazza, milyen middleware szolgáltatásokat veszünk igénybe • A Kérésmegszakító a leíró fájl alapján generálódik • A forráskód valóban csak üzleti logikát tartalmaz • A leíró fájlt módosíthatja a vevő, a forráskódot nem kell kiadnunk

16. Miből áll egy EJB? • Cél: implicit middleware 1. Az Enterprise Bean osztály (implementációs osztály): • Ebben írjuk meg az üzleti logikát (=a kifelé nyújtott metódusok implementációit) • javax.ejb.SessionBean vagy javax.ejb.EntityBean vagy javax.ejb.MessageDrivenBean interface-t kell implementálnia, ezek különböző metódusok megvalósítását írják elő, de mindegyik a javax.ejb.EnterpriseBean-ből származik, az meg a java.io.Serializable-ból (ami nem ír elő metódust, csak egy marker interface)

17. Miből áll egy EJB? 2. Az EJB objektum: • A kliensek mindig ezt hívják, ez a leíró fájl alapján meghív bizonyos middleware API-kat (pl. RMI-IIOP), majd delegálja a kéréseket az EnterpriseBean osztálynak • Vagyis ez a Kérésmegszakító • A konténer generálja ezt az osztályt (ezáltal nem kell middleware API-kal foglalkoznunk), • De hogyan? - leírjuk egy interface-ben, milyen metódusokat akarunk felkínálni, ennek a neve:

18. Miből áll egy EJB? 3. Remote interface: • javax.ejb.EJBObject interface-ből származik (ez már eleve előír pár metódust), ez pedig a java.rmi.Remote-ból  • minden metódus java.rmi.RemoteException–t dob • távolról hívhatók lesznek a metódusok • a metódusok paramétereinek és visszatérési értékeinek szerializálhatónak kell lenni • deklaráljuk benne a bean által felkínált metódusokat

19. Az eddigiek együttműködése

20. Miből áll még egy EJB? • A kliens hogyan szerez referenciát az EJB objektumra? • Közvetlenül nem példányosíthatja, mert más gépen lehet, mint a kliens • De az meg nem érdekel minket, hogy hol van (= hely átlátszóságot akarunk) • Megoldás: valami Factorytól kellene megszerezni a referenciát • Ezt a Factoryt hívjuk Home objektumnak (4.), feladatai: • EJB objektumok létrehozása, megszüntetése, megkeresése • A konténer generálja, tartalmazhat pl. terhelés kiegyenlítő logikát • De ha konténer generálja, honnan tudja, hogyan kell inicializálni az EJB objektumot? Megoldás:

21. Miből áll még egy EJB? 5. A Home interface: • javax.ejb.EJBHome interface-ből kell származnia(ez már eleve előír pár metódust), ez pedig a java.rmi.Remote-ból  • minden metódus java.rmi.RemoteException-t dob • távolról hívhatók lesznek a metódusok • a metódusok paramétereinek és visszatérési értékeinek szerializálhatónak kell lenni • deklarálunk benne megfelelő inicializáló metódusokat (entity bean esetén finder metódusokat is) • a konténer generálja a Home objektumot, ami ezt az interface-t implementálja, ez majd az EnterpriseBean osztálynak delegálja pl. a create metódust (amit ott kell megírni)

22. Referencia szerzése

23. Felmerülő kérdések • Melyik osztályból akkor hány példány is van? • Konténer-specifikus, de szerencsére általában nem érdekel minket • Tipikusan egy Home objektum, az kezeli a konkurenciát, és több kliens kérésére akár több EJB-objektumot hozhat létre • Egy EJB objektumhoz tartozhat több implementációs osztály (instance pooling), ekkor az EJB objektumok többszálúak (de nem mi írjuk!), vagy tartozhat egy implementációs osztály, akkor mindegyik EJB objektum egyszálú

24. Felmerülő kérdések • A kliens a Home objektumtól kér referenciát az EJB objektumra, annak küld kéréseket, ami delegálja azt az implementációs osztálynak, de honnan kapunk referenciát a Home objektumra?? Megoldás: JNDI lookup-pal

25. JNDI • Java Naming and Directory Service • névfeloldási szolgáltatás • a komponensek(EJB-k, web komponensek) a külső erőforrásokat (adatbázis, üzenetsor) és más komponenseket egy logikai néven keresztül érik el, az erőforrás fizikai elhelyezkedésének és hivatkozási azonosítójának ismerete nélkül • külső függőségeket az összeállítás és telepítés során kell meghatározni és feloldani • a külső erőforrás esetleges cseréje nem érinti a komponenseket

26. Mi kell még egy EJB-hez? • A home interface és a remote interface távoli eljárásokat deklarálnak nagy overhead • EJB 2.0-tól vezették be aLocal interface(5.)-t és aLocal home interface(6.)-t, ami lehetővé teszi, hogy ezt az overhead-etkiküszöböljük  így persze csak azonos alkalmazás szerveren futó kliensek érik el őket • javax.ejb.EJBLocalObject ill. javax.ejb.EJBLocalHome interface-ből kell származtatni, a metódusok nem dobnak java.rmi.RemoteException-t • Referencia szerinti paraméterátadás, nem érték szerinti  más lesz a hívások szemantikája • A kliens kódban kell változtatni, ha local interface-en keresztül akarom hívni a beant • Egy EJB komponensnek nem kötelező remote és local interface-t is tartalmaznia

27. Mi kell még egy EJB-hez? • A deployment descriptor(7.) • XML fájl, amiben deklaráljuk a kívánt middleware szolgáltatásokat • Gyártó specifikus fájlok(8.) • Extra szolgáltatások beállításai, amik nincsenek benne az EJB specifikációban, de egyes gyártók felkínálhatnak • Az EJB-hez szükséges fájlokat (1-8, akár több EJB-ét is) egy .jar fájlban archiváljuk

28. Egy konkrét EJB (HelloWorld) osztálydiagrammja

29. EJB konténer Kliens 5: EJB objektum visszaadása Tranzakciók, Biztonság, Perzisztencia 3: EJB objektum létrehozása EJB Home objektum 1:Home objektum keresése 7: Middleware API-k hívása 6: A bean metódusának meghívása Enterprise Bean 10: A metódus visszatér 4: EJB objektum létrehozása EJB objektum 2: Home objektum visszaadása 8: A kérés delegálása 9: A metódus visszatér JNDI névszolgáltatás A kliens együttműködése az EJB komponenssel

30. A 3 fajta EJB • Session bean • Entity bean • Message-driven bean • Az EJB típusát deklarálni kell a deployment descriptorban

31. Session bean • üzleti folyamatokat reprezentálnak (pl. hitelkártya-kezelés, árszámítás) • az egyes használati eseteknek metódusokat feleltethetünk meg, az összetartozó metódusokat pedig egy session beanhez rendelhetjük • Lehet állapotmentes vagy állapottal rendelkező • Állapotmentesség = a kliens nem számíthat arra, hogy végig ugyanazzal a beannel fog kommunikálni, emiatt nem tárolhat benne állapotot  inicializáló metódusának nincs bemenő paramétere • Állapottal rendelkezőre példa: online bevásárló kocsi

32. Session bean (állapottal) • Sok kliens, mindegyikhez külön bean példányelfogy a memória • Bean állapotát háttértárra menti a konténer (passziválás) • Ha egy passzivált beanhez tartozó kliens ismét kéréssel fordul a beanhez, vissza kell tölteni az állapotát (aktiválás) • nem a mi feladatunk az állapot mentése, ezt a konténer végzi, nekünk csak csak a bean által tartott erőforrásokat kell elengedni illetve újra megszerezni passziváláskor ill. aktiváláskor

33. Állapotmentes session bean életciklusa

34. Állapottal rendelkező session bean életciklusa

35. Entity Bean • Feladatuk az adatok perzisztens tárolása • Az adatbázissal tarja a kapcsolatot • Főneveket (entitásokat) reprezentálnak • Objektum-Relációs leképezést valósítanak meg • Egy entity bean példány = az adatbázis egy sorának memóriabeli cache-e

36. O-R leképezés

37. O-R leképezés • Entity bean létrehozása  SQL INSERT • Entity bean megszüntetése  SQL DELETE • Entity bean megkeresése(pl. elsődleges kulcs alapján), és betöltése a memóriába  SQL SELECT • Entity bean módosítása után az adat visszaírása az adatbázisba  SQL UPDATE

38. BMP-CMP • Bean Managed Persistence • A megfelelő SQL utasításokat a programozónak kell megírni a JDBC API segítségével, az életciklus megfelelő szakaszaihoz kapcsolódó metódusokban • Container Managed Persistence • A bean metódusai absztraktak, a konténer származtat belőlük egy osztályt, az tartalmaz minden JDBC kódot  sok kódolástól mentesíti a programozót

39. Message-driven bean • Aszinkron üzenetkezelést végez • Vállalati üzenetkezelő rendszerek (IBM MQSeries ill. most már WebSphere MQ, MSMQ) • Egyetlen metódusa van(onMessage()), azt nem lehet meghívni  nem kell remote, home és local interface • Ez az egy metódus viszont magától aktiválódik, ha olyan üzenetsorba kerül üzenet, amire a bean feliratkozott

40. Messaging architektúrák • Point-to-Point modell

41. Messaging architektúrák • Publish-Subscribe modell

42. Irodalom • Roman,Ed, Ambler,Scott, Jewell,Tyler : Mastering Enterprise JavaBeans. John Wiley and Sons, Inc., New York, Chichester, Weinheim, Brisbane, Singapore, Toronto, 2002. • Marinescu, Floyd : EJB Design Patterns. John Wiley and Sons, Inc., New York, Chichester, Weinheim, Brisbane, Singapore, Toronto, 2002.