J2EE [email protected]

J2EE - deklaratívne riešenie programátorských problémov • Posun od memory managmentu ďalej... • Prenos zložitých implementačných konceptov na ramená kontainera a resource adapterov: – – – – –

Distribuovanosť Transakčnosť Multithreading Deklaratívna bezpečnosť Resource management

• Vyvojár sa môže zamerať len na business logiku, kontainer interpretáciu vyššie uvedených konceptov • Vývojár uvádza niektorý z konceptov deklaratívnym spôsobom • Rozdelenie úloh a zodpovedností medzi viac rolí

Zodpovednosti v J2EE • J2EE rieši aj životný cyklus projektu rozdelením zodpovedností v tomto cykle medzi 6 rolí – – – – – –

Enterprise bean provider Application assembler EJB deployer EJB server provider EJB container provider System administrator

• Toto rozdelenie malo zásadný vplyv aj na spôsob akým sa implementujú komponenty. Hlavne ide o oddlenie rolí bean provider, assembler a deployer.

Viacvrstvová architektúra • J2EE rozdeľuje aj problematiku riešenú v aplikáciach na viac vrstiev – Vrstva dát a dátových služieb – Vrstva manipulácie s dátami, resp vrstva business logiky – Prezentačná vrstva

Client Tier

Client

Client

Client

Load balancer Web Tier Cluster

Web Server

Web Server

Web Server

App Tier Cluster

App Server

App Server

App Server

Database Tier Cluster

Db Server

Db Server

Enterprise JavaBeans • Enterprise Java Beans – server side komponenty, každá na rieši špecifický typ úlohy – Session Beans – určené na implementáciu business logiky • Staless • Statefull

– Entity Beans – reprezentujú perzistentné objekty – Message Driven Beans (MDB) – spracovanie asynchrónnych JMS správ – TimerBean (EJB 3.0)

• Bežia v kontaineri. Zverejňujú rozhrane pre kontainer aj pre klienta • Nikdy nie su prístupné priamo klientovi. Kontainer implementuje proxies. Proxy rieši implementáciu transakčnosti, multithreadingu atď.

Kontainer • Vytvára runtime prostredie pre beh komponentov – implementuje zložité implementačné koncepty v tzv. Proxy triedach - sú to vlastne interceptory volaní. • Spravuje všetky zdroje: inštancie komponentov, databázové pripojenia, thready. Rieši pooling (reuse) týchto zdrojov atď. • 3 typy – EJB Container – beh ejb komponentov – Web Container – beh servletov a jsp – Client container – klient aplikácie, gui, console..., je klientom ejb kontainera.

EJB Programming Restrictions • EJB Bean – must not use the java.io package to attempt to access files and directories in the file system. – must not use thread synchronization primitives to synchronize execution of multiple instances. – must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast. – must not attempt to load a native library. – must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity). – must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard. – must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final. – ... http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html

Rozhrania komponent • Len Beany, nie MDB • Business metódy – component interfaces – Local a Remote interfaces

• Životný cyklus komponenty – home interfaces – Local Home a Remote Home interface

Component interfaces • Local – rýchlejšie rozhranie – určené pre časté volania a volania v rámci jednej VM. – Pozor, parametre sa predávajú odkazom, nie hodnotou – Typické použitie • Web komponenta volá bean komponentu, Jsp volá bean • implementácia WS over stateless bean • Session bean používa entity beans

– Odporúča sa pri prístupe ku entity beanom. Vid session facade.

• Remote – rozhranie sprístupňuje komponentu v distribuovanom prostredí – – – – –

Dostupné klientovi zo vzdialenej VM Paremetre sú predávané hodnotou -> marshaling overhead Gerovanie “heavy” stubov (proxy) Transportný mechanizmus je RMI over IOOP Neviete kde sa nachádza komponenta, ktorá obslúži volanie

Component interfaces Local interface musí implementovať javax.ejb.EJBLocalObject public interface SapServiceLocal extends javax.ejb.EJBLocalObject { public String SendObjMsgToSap(Object obj) throws ClientException; public String sapPrijatieRec(String transXmlEnc) throws ClientException; }

Remote interface musí implementovať javax.ejb.EJBObject, metódy na rozhraní musia deklarovať aj java.rmi.RemoteException

public interface SapService extends javax.ejb.EJBObject { public String sapPrijatieRec(String transXmlEnc) throws ClientException,java.rmi.RemoteException; public String vyhSapZaslanieVozidla(String transXmlEnc)throws ClientException,java.rmi.RemoteException }

Home interfaces • Opať sa delia Home Local a Remote • Umožňujú klientovi vytvoriť, zrušiť, alebo nájsť komponenty daného typu • Bean musí implementovať Home interfaces: Local Home interface musí implementovať javax.ejb.EJBLocalHome: public interface SapServiceLocalHome extends javax.ejb.EJBLocalHome { public sk.regobsa.sap.applogic.ejb.SapServiceLocal create() throws javax.ejb.CreateException; }

Remote home interface musí implementovať javax.ejb.EJBHome, metódy na rozhraní musia deklarovať aj java.rmi.RemoteException: public interface SapServiceHome extends javax.ejb.EJBHome { public sk.regobsa.sap.applogic.ejb.SapService create() throws javax.ejb.CreateException,java.rmi.RemoteException; }

Deployment descriptor - interfaces Priradenie home a component interfaces ku bean triede je uvedené v deployment descriptore SapEJB SapService sk.regobsa.sap.applogic.ejb.SapServiceHome sk.regobsa.sap.applogic.ejb.SapService sk.regobsa.sap.applogic.ejb.SapServiceLocalHome sk.regobsa.sap.applogic.ejb.SapServiceLocal sk.regobsa.sap.applogic.ejb.SapServiceService sk.regobsa.sap.applogic.ejb.SapServiceBean Stateless ...

Získanie inštancie komponentu •

Klient používa JNDI lookup na získanie Home interface –

•

•

JNDI – Java naming direcotry interface http://docs.oracle.com/javase/jndi/tutorial/

ENC – environment naming context – klient používa alias ku skutočnej JNDI ceste, alias kontainer identifikuje cez ENC – Alias - ejb/SapService – ENC - java:comp/env Lookup string potom vyzera takto java:comp/env/ejb/SapService Skutočná JNDI cesta je uvedená až pri deploymente

Príklad získania Remote interface : InitialContext ic = new InitialContext(); Object oRef = ic.lookup( "java:comp/env/ejb/SapService" ); SapServiceHome SapServiceHome = (SapServiceHome)PortableRemoteObject.narrow( oRef, SapServiceHome.class ); // IOOP Idiom

Príklad získania Local interface: InitialContext ic = new InitialContext(); SapServiceLocalHome MyEJBHome = (SapServiceLocalHome)ic.lookup( " java:comp/env/ejb/SapService " );

J2EE špecifikácia: http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf

Referencie • Aliasy uvádzané v lookup metóde sú vlatne nazvy referencií • Každý resource, ktorý komponenta potrebuje referencuje vo svojom deployment deskriptore cez referenciu – EJB referencies • Local, alebo remote EJB referencia

– Service referencies • Web Service referencia

– Resource referencies • DataSource, URL, Queue, Topic, mail.Session, ConnectionFactory

– ...

• Referencie sa resolvujú vždy volaním new InitialContext().lookup(String)

JNDI Tree • Kontainer pri zavádzaní EAR registruje všetky komponenty (ich home rozhrania) do JNDI stromu •

Bean developer používa referencie na adresovanie beanov, ale aj iných resources java:comp/env/ejb/TidServiceHome • Deployer binduje aliasy na konkrétne cesty v JNDI strome ejb/TidServiceHome = java:comp/env/ ejb/TidServiceHome • System administrator definuje resources Definuje queue s jndi cestou jms/PATROSJADQueue

Deployment descriptor - referencie ejb/AppConfig Session sk.regob.ejb.appconfig.AppConfigLocalHome sk.regob.ejb.appconfig.AppConfigLocal InfrastructureBeans.jar#AppConfig jms/EVO2SAPQueue javax.jms.Queue Container Shareable jdbc/EVO javax.sql.DataSource Container Shareable url/EVOTimeOutConfig java.net Container Shareable

Deployment archív • Aplikácie a komponenty su balené do Java Archive JAR súborov. Rôzne prípony určujú ich presný účel – EAR Enterprise ARchive – súbor obsahuje celú aplikáciu – JAR - EJB komponenty a klient knižnice – WAR - Web ARchive – Web komponenty

• Deployment deskriptory sú obsiahnuté v JAR súboroch – Xml súbory, popisujú konfiguráciu komponentov – Deskriptor pre EJB súbor je ejb-jar.xml, ktorý sa nachádza v adresári META-INF – Deskriptor pre WEB komponenty je web.xml v adresári WEB-INF

EAR EJB JAR

WAR

State mamagment - Stateless vs. Statefull • Statefull – Stav medzi volaniami je udržiavaný v pamäti J2EE servra • Dáta ktoré sú predmetom volania • Pripojenia do DB, resp iných resources. • Teta odchadza na obed....

– Nutnost riešiť /réžia J2EE servra/

• Afinity • Session namagment • Recyklácia pamäte, memory to memory replikácia, persistencia sessions

– Nutnost riešiť /réžia J2EE vývojára/ • Dlho trvajúce transakcie, možnosť vzniku kolízii na DB úrovni • Vyššia pamäťová náročnosť, možné performance problémy • Nekompatibilita s WS (http://java.sun.com/blueprints/patterns/SessionFacade.html)

– Výhoda • Vývojár nemusí znovu získavať z DB údaje ktoré už pred tým získal

State mamagment - Stateless vs. Statefull • Stateless – Po ukončení volania nezostáva v aplikačnom servri žiaden údaj súvisiaci s transakciou – Kazdé volanie je samostatnou transakciou. Po ukončení volania je DB v konzistentnom stave. • Transakcia je buď committed, alebo rolled back

– Viackrokový proces je riešený ako sekvencia transakcií • Snaha vytvárať malé, krátko trvajúce transakcie.

– Volanie je možné vykonať na ľubovoľnom servri • „lahké“ clustrovanie

– WS je stateless by definition – Nevýhoda • Údaje s ktorými sa pracuje treba vždy získať z DB znova, keďže po ukonční volania sú dáta zabudnuté (sú len v DB)

State – dĺžka transakcie Stefull Client 5 Client 4 Client 3 Client 2 Client 1

5

4

3

5

Čas

Stateless Client 5 Client 4 Client 3 Client 2 Client 1

0

1

1

1

Čas

Transakcia a jej trvanie 5 Počet paralelne prebiehajúcich transakcií

Session Facade Kombinácia prístupu: http://java.sun.com/blueprints/patterns/SessionFacade.html

Transakcia • Základný mechanizmus na ktorom stavia J2EE ??Najdôležitejší?? • Potrebujete napríklad zapísať narodenie osoby a zaslať správu o narodení do centrálneho registra. Operácie sa musia udiať buď obe, alebo žiadna z nich tak aby boli oba zdroje aktualizované konzistentne – Jednoduchšie: zapisujem osobu a jej mená, dve tabulky, kardinalita 1..N.

• ACID - atomicity, consistency, isolation, durability • Zložitosť transakcií implementuje kontainer v spolupráci s resource adapeters (JDBC, JMS, SAP, ...) • Kontainer je transakčný koordinátor • Pre distribuované transakcie sa používa 2PC –two phase commit protocol (XA Transakcie)

Transakčnosť • Beany podporujú dva typy spravovania transakcií – Container-Managed Transactions – Bean-Managed Transactions

• Container-Managed – Kontainer štartuje transakciu pred volaním metódy a comituje po ukončení volania – To ako sa má transakcia vytvoriť, alebo priradiť metóde definujeme transakčnými atribútmi na úrovni metódy. Metóda nemusí mať transakčný kontext – Developer nevolá comit, alebo rollback (nemôže). Ak chce rollbacknut transakciu môže: • Throw unchecked exception • Alebo hlasovat za rollback transakcie volaním setRollbackOnly

Transakčné atribúty Required

Metóda sa vykoná v kontexte klientovej transakcie. Ak transakcia neexistuje kontainer vytvorí novú.

RequiresNew

Metóda je vždy vykonaná v novej transakcii. Ak existuje klient transakcia kontainer su suspendne.

Mandatory

Metóda musí byť vykonaná v klientskej transakcii. Ak klientska transakcia neexistuje kontainer vytvorí výnimku

NotSupported

Metóda nevyžaduje beh v transakcii. Ak existuje klient transakcia, kontainer ju pred volaním suspendne.

Supports

Ak transakcia existuje metóda sa vykoná v nej. Ak nie kontainer nevytvára novú transakciu

Never

Klient transakcia nesmie existovať pri volaní metódy. Ak existuje kontainer vytvorí výnimku

Prakticky najčastejšie sa používa Requires, alebo RequiresNew

Bean-managed transactions • JDBC transactions asi len ak treba wrapnuť starý Java kód. Používa transaction manager priamo v ovládači pre danú DB • JTA transactions: Java Transaction API. V J2EE implementovaný transaction provider. Nezávisle od ovládača pre danú DB. • V zodpovednosti vývojára volať begin, commit, rollback na rozhraní javax.transaction.UserTransaction. • Nesmie volať setRollBackOnly/getRollbackOnly • Pred ukončením volania musí stateless bean resolvnúť transackiu

EJB Exception handling • Dva typy výnimiek – Checked • • • •

Application exception Odvodené od java.lang.Exception Musia sa deklarovať v throws klauzuje Klient môže zareagovať

– Unchecked • • • •

System exceptions (nullpoiner, arraybounds) Odvodené od java.lang.RuntimeException Považované za bug Kontainer robí automaticky rollback transakcie, pretože nie je dôvod reagovať na takúto výnimku

– Checked to Unchecked thow javax.ejb.EJBException

Multithreading • Prečo? – Paralelnost • využitie výkonu viac procesorov, využitie pri čakaniach, rozvetvenie výpočtu, resp. paralelná obsluha requestov • Veľmi zjednodušené pri stateless princípe • Avsak veľmi zložité, preto:

• Thready striktne managuje kontainer – Ejb komponenenty nesmú vytvárať thready! Je zakázané používať akékoľvek synchronizačné objekty. – Java thread napr. nemá „j2ee“ kontext, je vlastne obyčajným java klientom.

Multithreading • Nemožnosť vytvoriť thread však znemožňuje – Asynchrónnosť – Background processing

• Našťastie existuje – MDB (od verzie 2) – TimerBean (od verzie 3)

• Obe riešenia však nevyžadujú použitie synchronizačných objektov a teda zachovávajú jednoduchý implementačný model.

Declarative security • Role based – Na urovni EAR deployment descriptora definujeme role a ich väzbu na používateľov a skupiny, – Mapovanie na na reálnych používateľov definuje administrator J2EE servra. – Prístup ku metódam riadený v deployment deskriptore EJB komponenety • Riadenie prístupu, – Vývojár môže volať isCallerInRole/isUserInRole a getCallerPrincipal().getName()

• Riadenie spúšťania pod účtom

• Pozor definícia rolí je úplne statická

Session Bean public class ExtServiceBean implements javax.ejb.SessionBean { private javax.ejb.SessionContext mySessionCtx; public javax.ejb.SessionContext getSessionContext() { return mySessionCtx; } public void setSessionContext(javax.ejb.SessionContext ctx) { mySessionCtx = ctx; } public void ejbCreate() throws javax.ejb.CreateException { } public void ejbActivate() { } public void ejbPassivate() { } public void ejbRemove() { }

public String hello(String hello) { return hello + " EXT"; } }

Stateless Session Bean • Obsahuje state len počas vykonávania metódy • Kontainer nerieši pasiváciu, po vykonaní metódy je instancia pripravená na ďalšie pouzitie • Najjednoduchší typ beanu, najlepšie škálovateľný = najlepší výkon. • Z pohľadu klienta sa môže tváriť ako knižnica funkcií – Môže obsahovať lokálne premenné avšak nesmú obsahov dáta špecifické pre konkrétneho klienta

• Knižničnému pohľadu treba podriadiť aj analýzu aplikácie – viac na seba nadväzujúcich transakcií namiesto jednej veľkej

Stateless Session Bean - lifecycle

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html

Statefull Session Bean • Obsahuje state aj medzi volaniami business metód • Kontainer sa môže rozhodnúť, že bean deaktivuje, tj. uvoľní pamäť a uloží bean na nejaké úložisko • Ak príde požiadavka na vykonanie metódy a bean je deaktivovaný kontaner ho aktivuje a vykoná volanie

Statefull Session Bean - lifecycle

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html

Message Driven Bean - MDB • Priniesli do EJB možnosť asynchrónneho spracovania správ • Správy pochádzajú z queue, alebo topic • MDB musí implementovat rozhranie javax.jms.MessageListener – onMessage(javax.jms.Message msg)

• MDB je stateless • Samozrejme možnosť paralelného spracovania správ

MDB - spoľahlivosť • Nutnosť definovat spoľahlivost doručovania – Od non persistent non reliable až po assured persistent reliable

• Vačšina business problémov požaduje maximal reliability v doručovaní správ – Garantované doručenie správy -> Správa sa nesmie za žiadnych okolností stratiť -> striktne transakčné spracovanie – Veľmi často vyžadovaná garancia poradia doručovania správ – Poison message problem

Table 1. The five levels of reliability Messages:

Best effort Nonpersistent No, individual nonpersistent messages can be discarded Express™ Nonpersistent Yes: messages nonpersistent are not discarded and never survive server restart Reliable Nonpersistent Yes: messages nonpersistent are not discarded and never survive server restart Reliable persistent

Persistent

Yes

Assured persistent

Persistent

Yes

No

Messages survive:

Yes

Possibly: No when messages build up on a destination Possibly: No when messages build up on a destination Yes: No asynchrono usly

No

No

No

No

No

No

Possibly: state No data can be lost on server crash resulting in duplication

No

Yes

No

No

Possibly: state No data can be lost on server crash resulting in duplication

Yes

Yes

No

No

Yes: hardened Yes messages are recovered, planned shutdown hardens cached messages

Yes

Possibl y: harden ed messag es are recover ed

Possibly: hardened messages can be backed up and recovered

Possibly: as deletion from the database is asynchronous with respect to user requests

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/cjj9000_.html

MDB – poison message problem • Správa nie je procesnuteľná, jej spracovanie padá s chybou – Rôzne systémy riešia rôzne. • Vo všeobecnost rôzne retry politiky (Retry delivery count, retry delay, maximal retry cycles, ...) pred tým ako je message označená ako poison. Následne napr.: death letter queue.

– Problém hlavne ak je požadované poradie doručenia. • Nespracovateľná správa nemuože byť automaticky odsmerovaná do Exception queue, pretože by sa porušilo poradie

MDB – ďalšie scenáre použitia • Zdrojový systém vykonáva zmenu. Tá musí byť transkačne vykonaná aj vo vzdialenom systéme, ale – Zdrojovy systém nechce/nemuože byť zdržovaný vzdialeným systémom – Pravdepodobne treba dodržiavať poradie správ ! Transactional & Not Parallel

• Zber metrík – minimal reliability – Príklad netransakčného spracovania – výpadok vzorky nie je dôležitý ! Not Transactional & Parallel

• Zasielanie log správ z aplikácie – Centrálna aplikácia – príjemca – musí z dôvodu veľkej priepustnosti paralelne spracovávať správy. Nezáleží však na poradí ! Transactional & Parallel

MDB – ďalšie scenáre použitia • Sync 2 Async – Cez WS prichádza správa, ktorá má veľa operácií rovnakého typu. Správa musí byt spracovaná transakčne. Jej business spracovanie by bolo náročné (čas, DB locking). – Riešením je „rozobrať“ správu na N malých operácií a v transakcii 1 (jedna transakcia ) ich vložiť do queue. Po vložení kontainer aktivuje N inštancii MDB a v N samostatných menších transakciách vykoná spracovanie. – Samozrejme je možnosť paraleleného spracovania ak netreba garantovať poradie správ

Transaction 1

EJB methodN

methodN - metóda vie prijať správu obsahujúcu N operácií. Metóda je exponovaná na klienta method1 - metóda vie prijať správu obsahujúcu 1 operáciu. Metóda je interná.

Transaction N

QUEUE

MDB MDB MDB onMessage MDB onMessage onMessage onMessage EJB EJB EJB method1 EJB method1 method1 method1

... ... ...

MDB onMessage

EJB method1

MDB - lifecycle

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html

Entity Bean • Slúži na prístup k dátam • Inštancia EntityBeanu reprezentuje „riadok“ tabuľky • V Home rozhraní môže deklarovať – viac create metód. Sú určené na vytvorenie inštancie s rôzným iniciálnym stavom. Všetky začínajú slovom create a vracajú component rozhranie – Viac find metód. Sú určené na vyhľadanie inštancie. Všetky začínajú slovom find a tiež vracajú component rozhranie – Možno deklarovať aj business metódu, ak treba vykonať business operáaciu, ktorá sa týka triedy a nie konkrétnej inštancie

• Entity bean je z povahy statefull beanom • Aktuálne existujú alternatívy, ktoré sa považujú za efektívnejšie riešenie pre prístup k dátam – Pozri napr. Hibernate, DAO, resp ORM.

Entity Beam - lifecycle

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html

Timer Bean • Umožňuje naplánovať spustenie v špecificky čas, po určitom čase, alebo v intervaloch • Timer je – perzistentný: ak je server down a timer ma timeoutnúť, kontainer zavolá timeout aspoň raz po štarte – transankčný –kontainer garantuje pri zlyhaní opakované spustenie

• Bean implemenetuje rozhranie javax.ejb.TimedObject • Timer sa síce plánuje v milisekundách, ale nie je presný.

Praktická ukážka

Demo projekt • Websphere application server • Entrerprise application project DemoEAR • EJB projet DemoEJB – Stateless session EJB bean – DemoService

• DynamicWebProject DemoWeb – Servlet - DemoServlet

• Datasource referencia – DefaultDatasource

• Methods – createTables, dropTables – insertEntry – getEntries

Code snippets JSP Bean reference lookup

DataSource resource lookup DataSource ds=(DataSource) mySessionCtx.lookup("java:comp/env/DefaultDatasource"); Connection conn=ds.getConnection(); PreparedStatement ps=conn.prepareStatement("create table KEYTABLE (ID INT PRIMARY KEY, VALUE VARCHAR(12))"); ps.close();conn.close(); Connection conn= ds.getConnection(); CallableStatement cst=conn.prepareCall("insert into KEYTABLE values(?,?)"); cst.setInt(1,key); cst.setString(2,value);

Code snippets JMS message sending javax.jms.ConnectionFactory cf=(ConnectionFactory) mySessionCtx.lookup("java:comp/env/jms/QueueCF"); javax.jms.Connection conn=cf.createConnection(); conn.start(); javax.jms.Session session=conn.createSession(true, AcknowledgeMode.AUTO_ACKNOWLEDGE); javax.jms.Destination dest=(Destination) mySessionCtx.lookup("java:comp/env/jms/Queue"); javax.jms.MessageProducer queueSender=session.createProducer(dest); javax.jms.TextMessage tm=session.createTextMessage(); tm.setText(message+i); queueSender.send(tm); queueSender.close(); conn.close(); session.close();