Java 2 Enterprise Edition

Slides:



Advertisements
Hasonló előadás
Windows Communication Foundation (WCF)
Advertisements

RESTful Web Service tesztelése
Adatbázis gyakorlat 1. Szerző: Varga Zsuzsanna ELTE-IK (2004) Budapest
Kliens-szerver architektúra
© Kozsik Tamás Adatbáziskezelés •Relációs adatbáziskezelők •Noha a Java objektum-elvű, egyelőre nem az objektum-elvű adatbáziskezelőket támogatja.
Programozás III STRING-XML.
MSN-kompatibilis egyéni emotikonok kezelése XMPP/Jabber-ben Bemutatás Németh Ádám,
IBM Software Group © 2006 IBM Corporation Hatékonyság és üzleti intelligencia Egységesített felület meglévő alkalmazásainkhoz Szabó János Technikai szakértő.
Adatbázisok SQL. TARTALOM Szijártó M.2 Témakörök  Az SQL tulajdonságai  A műveletek fajtái  Objektum-műveletek  Lekérdezések Tulajdonságok és műveletek.
Programozás III KOLLEKCIÓK 2..
Többfelhasználós és internetes térkép kezelés, megjelenítés.
J2EE keretrendszerek vizsgálata Önálló laboratórium, 2008 tavasz Farkas Gábor, OTX0QR Konzulens: Imre Gábor.
Oracle Java fejlesztési stratégiája
RMI = Remote Method Invocation
Objective-C Készítette: Fahmi Arman B5EXTQ
Tanszéki konzulens: Horváth Ákos Készítette: Kóródi Norbert.
Fájlkezelés, IO Kivételkezelés Belső osztályok
Az ETR technológia DEXTER Informatikai kft..
Fejlett Programozási Technikák 2.
UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Programozás II. 6. Gyakorlat const, static, dinamikus 2D.
Fejlett Programozási Technológiák II. Világos Zsolt 1. gyakorlat.
Fejlett Programozási Technológiák II. Világos Zsolt 7. gyakorlat.
9. Háttér logika Dr. Bilicki Vilmos Szegedi Tudományegyetem
Bevezetés a J2EE világába
A Java programozási nyelvSoós Sándor 1/20 Java programozási nyelv 11. rész – Adatbázis-programozás Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai.
Az e-kereskedelem (e-business)
Osztott alkalmazások kezelése. VIR elosztott architektúra indítékai: - meglévő komponensek integrációja - WEB / Internet elterjedése (nemzetköziség) -
WEB Technológiák Dr. Pance Miklós – Kolcza Gábor Miskolci Egyetem.
JSP és JavaBean JavaServer Pages és Java Beans Fabók Zsolt Általános Informatikai Tanszék Miskolci Egyetem.
SPRING FRAMEWORK bemutatása
Előadó: Kárpáti Péter Üzleti folyamatvezérlés nagyvállalati környezetben (BizTalk Server 2004, Office InfoPath 2003 és Windows.
Implementing Demeter: A Resource Management Tool used by Morgan Stanley’s Farm Engineering Team (In English) Maczika Száva Jenő MASRAAI.ELTE Programtervező.
Bevezetés az ebXML-be Forrás: An Introduction to ebXML ebXML and Web Services Practical Considerations In Implementing Web Services Romin IraniRomin Irani.
SOAP alapismeretek A SOAP egy egyszerű XML alapú protokoll, ami lehetővé teszi, hogy az alkalmazások információt cseréljenek a HTTP-én keresztül. Forrás:
WEB Technológiák ISAPI ME Általános Informatikai Tsz. dr. Kovács László.
WEB MES (webes gyártásirányító rendszer)
Hálózatkezelési újdonságok Windows 7 / R2
Perzisztencia-megoldások Java Technológiával Molnár István, Simon Géza.
Anyagadatbank c. tárgy gyakorlat Féléves tematika Adatbázis alapfogalmak, rendszerek Adatmodellek, adatbázis tervezés Adatbázis műveletek.
Appletek és Servletek Demeter Lehel 641-es csoport.
Web Application for Resource Planning
Publikációs portál Initial J2EE architecture UML bázisú modellezés és analízis Csapat: UML7 (Percze Dániel, Rajnai Zoltán, Ráth István, Tóth Dániel, Vágó.
Publikációs portál Platform Specific Model UML bázisú modellezés és analízis Csapat: UML7 (Percze Dániel, Rajnai Zoltán, Ráth István, Tóth Dániel, Vágó.
Budapest, június 28. Ontológia kezelő modul tervezése szöveges információt kezelő informatikai rendszer számára Förhécz András BME Méréstechnika.
LOGO Webszolgáltatások Készítette: Kovács Zoltán IV. PTM.
Hernyák Zoltán Programozási Nyelvek II.
1 Hernyák Zoltán Programozási Nyelvek II. Eszterházy Károly Főiskola Számítástudományi tsz.
1 Hernyák Zoltán Web: Magasszintű Programozási Nyelvek I. Eszterházy.
APEX BMF, II. félév.
Android alkalmazások tesztelése
Komoróczy Tamás 1 Java programozási nyelv A nyelv alapjai.
WEB Technológiák WEB-DB és XML ME Általános Informatikai Tsz. dr. Kovács László.
Komponens-absztrakció. Objektum-orientált paradigma korlátai Feltételezés az interfészekről: 1. öröklés és aggregáció alkalmazható, 2. közös programozási.
XML fejlesztések TSQL fejlesztések Tábla paraméter SQLCLR fejlesztések 8k limit feloldása Több paraméteres UDA-ek Ordered UDF-ek Entity Framework ADO.NET.
Java web programozás 11..
Enterpise JavaBeans Simon Balázs
Müller László vezető fejlesztő EQL Soft Informatikai és Tanácsadó Kft.
Az OSI modell 3. fejezet.
Gyurkó György. Az állapotmodellezés célja Általánosságban ugyanaz, mint a többi dinamikus modellezési technikáé: Jobban megismerni a problémát. Finomítani.
Java web programozás 7-8..
Webes MES keretrendszer fejlesztése Kiss Miklós Dániel G-5S8 Tervezésvezető: Dr. Hornyák Olivér.
Java web programozás 5..
OpenCMS programozói bevezetés Krizsán Zoltán iit me.
Java web programozás 6..
Java Csoport Antal Péter Bátfai Norbert Jeszenszky Péter.
Palotás Ádám és Fodor Gergely Oracle Data Integrator Bemutató és gyakorlat
Programozás III JPA.
EJB üzenet vezérelt bean (MDB)
Hibernate / EclipseLink / OpenJPA összehasonlítás
JBoss Wildfly Kalla Mór
Előadás másolata:

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

Tartalom A J2EE áttekintése Middleware szolgáltatások Enterprise Java Beans Alkotóelemei Tí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 Architektúra Többrétegű Kliens-szerver Komponens alapú

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

Web komponensek Servlet JSP 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 Kliensek Hálózat Web szerver Web konténer EJB konténer Adatforrás 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:

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 Biztonsági Kliens Elosztott objektum Tranzakció Csonk Váz Elosztott objektum Hálózat Távoli interfész Tranzakció szolgáltatás Adatbázis meghajtó Biztonsági API Tranzakciós Adatbázis

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 Elosztott objektum Biztonsági szolgáltatás Kliens 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

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 lenni deklará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 EJB Home objektum EJB objektum Enterprise Bean Tranzakciók, Biztonság, Perzisztencia JNDI névszolgáltatás 1:Home objektum keresé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á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

Á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 Container 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

Messaging architektúrák Publish-Subscribe modell

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.