Java 2 Enterprise Edition

Imre Gábor

gabor@aut.bme.hu

Tartalom

A J2EE áttekintése Middleware szolgáltatások Enterprise Java Beans

AlkotóelemeiTípusai

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

Java 2 Enterprise Edition

Többrétegű Kliens-szerver Komponens alapú

Architektúra

J2EE szerver

A J2EE alkalmazás szerver

Servlet Jsp

EJB

Connector

Nem java rendszer

Vastag kliens, applet,CORBA kliens

Böngésző,mobil eszköz

Nem java rendszer

Öröklött rendszerÜzenetsor Adatbázis

XML Web Services

XML Web Services HTTP

RMI-IIOP

JMS JDBC(SQL)

Megfelelő protokoll

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

A kliens kérésének kiszolgálása

Web konténer Adatforrás

EJB konténer

Hálózat

Web szerver

Kliensek

DBMS

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

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:

34%

34%

6%

26%BEA

IBM

ORACLE

Egyéb

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

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

Explicit middleware

Kliens

Csonk Váz

Elosztott objektum

Hálózat

Távoliinterfész

Tranzakciószolgáltatás

Adatbázis meghajtó

Biztonságiszolgáltatás

BiztonságiAPI

TranzakciósAPI

AdatbázisAPI

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)

Implicit middleware

Tranzakciószolgáltatás

Távoliinterfész

BiztonságiAPI

Kliens

Csonk Váz

Kérésmeg-szakító

Adatbázis meghajtó

Biztonságiszolgáltatás

AdatbázisAPI

Elosztott objektum

TranzakciósAPITávoli

interfész

Hálózat

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

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)

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:

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 lennideklaráljuk benne a bean által felkínált

metódusokat

Az eddigiek együttműködése

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:

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)

Referencia szerzése

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ú

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

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

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 a Local interface(5.) -t és a Local home interface(6.)-t, ami lehetővé teszi, hogy ezt az overhead-et kikü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

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

Egy konkrét EJB (HelloWorld) osztálydiagrammja

A kliens együttműködése az EJB komponenssel

Kliens

EJB Home objektum

EJB objektumEnterprise

Bean

Tranzakciók,Biztonság,

Perzisztencia

JNDI névszolgáltatás

1:Home objektumkeresése

2: Home objektum

visszaadása

3: EJB objektum létrehozása

4: EJB objektum létrehozása

5: EJB objektum visszaadása

6: A bean metódusának meghívása

7: Middleware API-k hívása

8: A kérés delegálása

9: A metódus visszatér

10: A metódus visszatér

EJB konténer

A 3 fajta EJB

Session bean Entity bean Message-driven bean Az EJB típusát deklarálni kell a

deployment descriptorban

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

Session bean (állapottal) Sok kliens, mindegyikhez külön bean

példányelfogy 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

Állapotmentes session bean életciklusa

Állapottal rendelkező session bean életciklusa

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

O-R leképezés

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

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

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

Messaging architektúrák

Point-to-Point modell

Request Q

Reply QReply Q

A

B

Messaging architektúrák

Publish-Subscribe modell

Topic:Tozsdei arvaltozasok

Topic:Valutaarfolyam valtozasok

Topic:Penzugy

Topic:Vallalati hirek

AAlkalmazás(subscriber / publisher)

BAlkalmazás(subscriber)

CAlkalmazás(publisher)

DAlkalmazás(publisher)

Message 1

Message 2Message 1Message 2

Message 3

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.