J2EE

dmasar@gratex.com

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

Database Tier Cluster

App Tier Cluster

Web Tier Cluster

Load balancer

Web Server

Web Server

Web Server

App Server

App Server

App Server

Client Client Client

Db Server

Db Server

Client Tier

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 <ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="ejb-jar_ID" version="2.1" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"> <display-name>SapEJB</display-name> <enterprise-beans> <session id="SapService"> <ejb-name>SapService</ejb-name> <home>sk.regobsa.sap.applogic.ejb.SapServiceHome</home> <remote>sk.regobsa.sap.applogic.ejb.SapService</remote> <local-home>sk.regobsa.sap.applogic.ejb.SapServiceLocalHome</local-home> <local>sk.regobsa.sap.applogic.ejb.SapServiceLocal</local> <service-endpoint>sk.regobsa.sap.applogic.ejb.SapServiceService</service-endpoint> <ejb-class>sk.regobsa.sap.applogic.ejb.SapServiceBean</ejb-class> <session-type>Stateless</session-type> ... </session>

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 " );

• 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

Získanie inštancie komponentu

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

<ejb-local-ref id="EJBLocalRef_1246448602354">

<ejb-ref-name>ejb/AppConfig</ejb-ref-name>

<ejb-ref-type>Session</ejb-ref-type>

<local-home>sk.regob.ejb.appconfig.AppConfigLocalHome</local-home>

<local>sk.regob.ejb.appconfig.AppConfigLocal</local>

<ejb-link>InfrastructureBeans.jar#AppConfig</ejb-link>

</ejb-local-ref>

<resource-ref id="ResourceRef_1246448649480">

<res-ref-name>jms/EVO2SAPQueue</res-ref-name>

<res-type>javax.jms.Queue</res-type>

<res-auth>Container</res-auth>

<res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

<resource-ref id="ResourceRef_1246450679373">

<res-ref-name>jdbc/EVO</res-ref-name>

<res-type>javax.sql.DataSource</res-type>

<res-auth>Container</res-auth>

<res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

<resource-ref id="ResourceRef_1246450736188">

<res-ref-name>url/EVOTimeOutConfig</res-ref-name>

<res-type>java.net</res-type>

<res-auth>Container</res-auth>

<res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

Deployment descriptor - referencie

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

EJB JAR

WAR

EAR

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

• 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 mamagment - Stateless vs. Statefull

5 4 3 5

0 1 1 1

Client 1

Client 2

Client 3

Client 4

Client 5

Client 1

Client 2

Client 3

Client 4

Client 5

Stefull

Stateless

State – dĺžka transakcie

Čas

Č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

• 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

MDB - spoľahlivosť

Table 1. The five levels of reliability

Messages: Messages survive:

Best effort nonpersistent

Nonpersistent No, individual messages can be discarded

No Yes No No No No No No

Express™ nonpersistent

Nonpersistent Yes: messages are not discarded and never survive server restart

Possibly: when messages build up on a destination

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

No No Yes No No

Reliable nonpersistent

Nonpersistent Yes: messages are not discarded and never survive server restart

Possibly: when messages build up on a destination

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

No Yes Yes No No

Reliable persistent

Persistent Yes Yes: asynchronously

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

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

Yes Yes Possibly: hardened messages are recovered

Possibly: hardened messages can be backed up and recovered

Assured persistent

Persistent Yes

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

• 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

MDB – ďalšie scenáre použitia

EJB methodN

QUEUE

EJB method1

...

...

...

Transaction 1 Transaction N

MDB onMessage

EJB method1

MDB onMessage

EJB method1

MDB onMessage

EJB method1

MDB onMessage

EJB method1

MDB onMessage 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á.

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 <%@page import="ejbs.DemoServiceLocalHome"%> <%@page import="ejbs.DemoServiceLocal"%> <% DemoServiceLocalHome home=(DemoServiceLocalHome)new javax.naming.InitialContext().lookup("java:comp/env/ejb/DemoService"); DemoServiceLocal sslocal=home.create(); String entries=sslocal.getEntries(); %> <pre><%=entries %></pre>

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();