Aplicații distribuite bazate pe componente software în tehnologia JAVA:

Enterprise Java Beans (EJB)

Perfecţiunea se măsoară in imperfecţiune. Perfect este atunci când

sunt cele mai puţine imperfecţiuni.

citat din Nicky Sereteanu

Obiective: Studiul componentelor EJB care sunt obiecte distribuite (un

obiect ale cărei metode pot fi apelate dintr-un alt obiect aflat la

distantă.) (“remote objects”) din platforma JavaEE (JEE).

Cuprins: 1. Componente EJB în aplicatii JEE6

1.1. Evolutia de la Java RMI la EJB

1.2. Evolutia componentelor EJB în JavaEE

1.3. Rolul componentelor EJB în arhitectura aplicatiilor JEE

1.4. Componente EJB Sesiune în JEE6

1.6. Exemple JEE6 care folosesc componente EJB sesiune

Introducere

Ce este Java? Java este un mediu de programare lansat şi susţinut în continuare de

firma Sun Microsystems. Java este un limbaj de programare 100% orientat pe obiecte

şi oferă suport dezvoltării de aplicaţii distribuite, independete de platformă. Ceea ce

avantajează acest limbaj, comparativ cu alte limbaje este conexiunea sa stransă cu

tehnologia Internet (aşa numitele applet-uri Java. Applet-urile Java sunt programe

Java ce se execută în cadrul browser-elor World Wide Web (WWW). Cea mai mare

parte a sintaxei de programare Java este mostenită de la C++, dar multe dintre

conceptele de programare obiectuală prezente în Java îşi au rădăcinile în SmallTalk,

Lisp etc. Firma Sun a inclus în acest limbaj cele mai noi concepte de programare

făcându-l o unealtă puternică şi uşor de manevrat. În noiembrie 1995 este disponibilă

prima versiune Beta a limbajului Java şi de aici încolo limbajul va fi într-o continuă

dezvoltare.

1. Componente EJB în aplicatii JEE6

1.1. Evolutia de la Java RMI la EJB

Componentele EJB sunt obiecte distribuite (“remote objects”) din platforma

JavaEE (JEE). Un obiect distribuit este un obiect ale cărei metode pot fi apelate dintr-un

alt obiect aflat la distantă. Obiectele distribuite Java se află în masini virtuale diferite, deci

în spatii de adresare diferite.

In cazul obiectelor aflate în aceeasi masină virtuală JVM- Java Virtual Machine

referințele dintre obiecte diferite sunt rezolvate de compilatorul Java care generează

secventa de transmitere a parametrilor si instructiunea de salt la metoda apelată (folosind si

adresa obiectului cu metoda apelată).

In cazul unor obiecte distribuite în masini diferite referintele de la un obiect la altul

nu mai pot fi rezolvate de compilator si se foloseste un mecanism numit RMI (Remote

Method Invocation) care poate fi schematizat astfel:

Interfata “RemoteInterface” defineste metodele obiectului “RemoteObject” care vor

fi apelate de client. Clasa “RemoteObject” si clasa “Stub” implementează această interfată

iar clasa “Client” apelează metode din interfata comună. Obiectele intermediare “Stub” si

“Skeleton” sunt generate automat; ele realizează serializarea parametrilor de apel si

respectiv deserializarea lor (operatii care se mai numesc “marshalling” si

“unmarshalling”).

In esentă RMI creează aparenta că obiectul client foloseste obiectul “remote” ca si

cum ar fi un obiect local si “ascunde” existenta si rolul obiectelor “Stub” si “Skeleton”

(crearea si utilizarea acestora este transparentă pentru cel care programează aplicatia

client).

Initial mecanismul Java RMI folosea un protocol propriu de comunicatie între

“Stub” si “Skeleton” dar acesta a fost modificat astfel încât să folosească un protocol

CORBA standard iar acum se numeste RMI-IIOP (Internet Inter-ORB Protocol).

Componentelor EJB din JavaEE sunt obiecte distribuite care au evoluat continuu

astfel încât în prezent programatorul aproape că nu mai sesizează diferenta dintre folosirea

unui EJB local (din aceeeasi JVM) si folosirea unui obiect EJB la distantă.

Componentele EJB au fost de la început si au rămas principala caracteristică a

platformei JEE ca suport pentru dezvoltarea de aplicatii distribuite.

Utilizarea componentelor EJB se face prin intermediul unui container EJB, care

gestionează aceste componente pe baza unor fisiere xml numite “deployment descriptor”

ce contin optiuni asupra serviciilor oferite de container. Containerul mai oferă servicii

privind utilizarea de tranzactii, privind securizarea accesului la componente EJB s.a. prin

interceptarea apelurilor între obiectul “skeleton” si obiectul “remote”.

Un EJB este un obiect distribuit JEE si poate fi:

un obiect din server apelat direct de un client al aplicatiei;

un obiect din server apelat de o altă componentă din acelasi server

(alt EJB sau un servlet);

un obiect dintr-un server apelat din alt server, ambele din aceeasi

aplicatie JEE distribuită pe mai multe masini (pentru a realiza un

timp de răspuns bun la un număr mare de clienti).

Intr-o aplicatie distribuită pot exista si alte obiecte distribuite care nu sunt de tip

EJB si care oferă diferite “servicii” unei aplicatii: obiect “driver” pentru baze de date,

pentru gestiune mesaje.

Localizarea acestor obiecte distribuite s-a făcut initial printr-un serviciu de nume si

directoare JNDI (Java Naming and Directory Interface) integrat în orice server de aplicatii

JEE, dar în prezent se folosesc adnotări pentru “injectarea” adreselor obiectelor “remote”

în obiectele care le folosesc (clienti de EJB, de ex.).

Gestiunea de către container înseamnă, printre altele, că instantierea unei clase EJB se

face de către container si nu de către programator si că apelarea metodelor unui EJB se

face prin intermediul acestui container (sunt interceptate de container), care poate insera

operatii legate de concurentă si sincronizarea firelor de executie, de gestiunea stării

obiectelor din aplicatie, de utilizarea în comun a unor grupuri de resurse (“resource

pooling”), de accesul securizat (sigur) la obiectele EJB si de gruparea în tranzactii.

In plus, containerul asigură transparenta utilizării obiectelor ejb ca obiecte din aceeasi

masină virtuală Java JVM (din acelasi spatiu de adresare), desi un ejb se poate afla într-o

altă masină decât obiectul “client” care apelează metode din ejb. Altfel spus, clientul unui

ejb trebuie să obtină o referintă la acel ejb; localizarea unui ejb dintr-o altă masină prin

numele său este o altă problemă rezolvată de container fie prin utilizarea unui server JNDI,

fie prin “injectarea” dependentelor (CDI=Container Dependency Injection).

Containerul de componente EJB este cel care face diferenta dintre un server de

aplicatii JEE (Glassfish, JBoss, Geronimo, WebSphere s.a.) si un container de servleti

(Tomcat, Jetty, s.a.).

Containerul EJB trebuie să respecte specificatiile JEE pentru un astfel de container.

Accesul unui client (o altă componentă software) la o componentă EJB se face

numai prin intermediul containerului. Deoarece componentele EJB se pot folosi numai

într-un container nici testarea lor nu se poate face în absenta unui container sau a unui

surogat de container.

1.2. Evolutia componentelor EJB în JavaEE

Un obiect distribuit RMI trebuie să implementeze interfata “java.rmi.Remote” pentru a

putea fi apelat dintr-o altă masină JVM si nu este utilizat direct ci prin intermediul altui

obiect. Această schemă de utilizare a fost preluată în EJB2 si arată astfel:

Operatiile ce trebuie realizate de un client al unui ejb sunt:

Obtinerea unei referinte la un obiect “Home”;

Utilizarea obiectului “Home” pentu a crea obiectul EJB;

Apelare metode utile din obiectul EJB (“business methods”);

Eliminarea obiectului EJB atunci când nu mai este necesar.

Clientul foloseste metode din obiectul intermediar EJBObject (care implementează

interfata “javax.ejb.EJBObject”) pentru apelarea metodelor din clasa EJB : public interface javax.ejb.EJBObject extends java.rmi.Remote {

public abstract javax.ejb.EJBHome getEJBHome() throws java.rmi.RemoteException;

… // alte metode

}

Obiectul EJBObject care implementează această interfată face parte din container si

este creat de obiectul EJBHome, obtinut prin intermediul JNDI după schema următoare:

Exemplu de utilizare JNDI: /* Get System properties for JNDI initialization */ Properties props = System.getProperties();

/* Form an initial context */ Context ctx = new InitialContext(props);

/* Get a reference to the home object - the factory for EJB objects */

MyHome home = (MyHome) ctx.lookup("MyHome"); /* Create an EJBObject */

MyRemoteInterface ejbObject = home.create(); /* Calling a EJB business method */

ejbObject.add();

Inainte de versiunea actuală (EJB3.1) o componentă EJB era o clasă Java care

trebuia să implementeze o anumită interfată, cu metode apelate de container. Exemplu de

interfată pentru orice ejb-sesiune:

public interface javax.ejb.SessionBean extends javax.ejb.EnterpriseBean {

public abstract void setSessionContext(SessionContext ctx) throws java.rmi.RemoteException;

public abstract void ejbPassivate() throws java.rmi.RemoteException; public abstract void ejbActivate() throws java.rmi.RemoteException;

public abstract void ejbRemove() throws java.rmi.RemoteException; }

1.3. Rolul componentelor EJB în arhitectura aplicatiilor JEE

Componentele EJB (“Enterprise Beans”) fac parte din nivelul numit “Business

Tier” al unei aplicatii JEE si pot fi utilizate direct de clientii aplicatiei care nu folosesc un

browser sau sunt utilizate de alte componente din nivelul “Web Tier” sau din nivelul

“Business Tier”.

Motivele introducerii unui nou tip de componente în aplicatiile distribuite ar fi:

Modularizarea aplicatiilor JEE si reutilizarea unor componente în

mai multe aplicatii;

Simplificarea programării aplicatiilor distribuite scalabile, care pot

evolua în timp ca număr de clienti si ca număr de servere de aplicatii

folosite de aplicatii.

Spre deosebire de clasele Java obisnuite clasele marcate ca fiind componente EJB

pot fi instalate (“deployed”) si executate numai într-un container dintr-un server de

aplicatii compatibil JEE, fiind gestionate de acest container. Containerul EJB este un

intermediar între componenta EJB si utilizatorul (clientul) acestei componente.

In primele versiuni JEE existau trei tipuri de componente EJB: ejb-sesiune (Session

Enterprise Bean), ejb-entitate (Entity Enterprise Bean) si ejb-mesaj (Message-Driven

Bean). Componentele de tip entitate din JEE6 sunt clase adnotate cu @Entity si pot fi

considerate sau nu ca fiind componente EJB; ele au un ciclu de viată (se pot afla în diferite

stări) dar nu sunt gestionate de containerul EJB, nu sunt cuprinse în specificatiile EJB, iar

clasele utilizate nu sunt în pachetul “javax.ejb”.

Un EJB este o clasă Java care trebuie să respecte anumite conventii astfel ca să

poată fi gestionată de container; exprimarea acestor conventii s-a simplificat în evolutia

JEE după introducerea de adnotări în Java (de la EJB2 la EJB3).

Cele mai folosite sunt componentele EJB sesiune care definesc o actiune bine

definită în cadrul unei aplicatii si pot fi eventual refolosite în alte aplicatii care necesită

operatiile realizate.

Este posibilă si programarea de aplicatii distribuite (chiar JEE) fără a folosi

componente EJB folosind de exemplu Spring, un container care poate fi integrat în orice

aplicatie. După toate simplificările aduse în EJB3 s-a reactivat disputa privind programarea

cu sau fără EJB.

Impachetarea aplicatiilor care contin componente EJB se face într-o arhivă de tip

“ear” (Enterprise Archive”), cu structura următoare:

Fig. Structura Enterprise Archive (EAR)

Un modul EJB contine clase ejb plus descriptori de instalare pentru ejb; este o arhivă

“jar”. Un modul Web contine servleti, fisiere HTML, imagini si descriptori de instalare

web; este o arhivă “war”. Un modul client aplicatie este o arhivă “jar” cu clase client si

descriptori de instalare client. Un modul adaptor este o arhivă “rar” (“resource adapter

archive”) cu fisierele necesare pentru implementarea “Java EE Connector Architecture”,

atunci când se folosesc module “străine”.

1.4. Componente EJB Sesiune în JEE6

Un ejb-sesiune corespunde unei sesiuni de interactiune dintre un client si aplicatie;

el poate avea un singur client asa cum un servlet are un singur client si are durata unei

sesiuni.

Clientii unui ejb-sesiune pot fi:

Un alt ejb aflat în acelasi container (“local ejb”), caz în care comunicarea dintre

componente nu se face prin retea (printr-un protocol de comunicatie) ci prin referinte

directe (prin adrese);

Un alt ejb aflat într-un alt container (“remote ejb”), comunicarea fiind prin RMI-IIOP

dar localizarea se poate face prin adnotări.

Un servlet aflat în acelasi server cu componenta ejb, dar având un client Web;

O componentă “managed bean” folosită de taguri dintr-o pagină JSF (xhtml) cu un

client Web.

Un client de serviciu Web al cărui “endpoint” este un EJB; comunicarea dintre client si

ejb se face prin protocolul SOAP/HTTP sau prin HTTP (serviciu de tip REST).

Un client Java aflat în afara containerului EJB dar care nu e găzduit de un alt server

JEE (“standalone client”); acest client trebuie să localizeze componenta ejb prin JNDI

si foloseste protocolul RMI-IIOP.

In general modul de comunicare între un ejb si clientii săi este transparent, desi

programarea clientului poate fi diferită.

Un ejb cu un client local nu are nevoie de o interfată definită explicit, dar poate

implementa o astfel de interfată (“business interface”) marcată cu adnotarea @Local; cele

două cazuri se numesc “local no-interface view” si “local interface view”.

Un ejb cu un client aflat în afara containerului său are nevoie de o interfată marcată cu

adnotarea @Remote (“remote interface view”).

Un ejb furnizor de servicii Web trebuie marcat cu adnotarea @WebMethod.

Un “stateless-ejb” nu mentine o conversatie cu clientul său, deci nu păstrează

informatii despre client; containerul mentine un grup de ejb-uri de acelasi fel (“ejb pool”)

pe care le poate atribui la diversi clienti care solicită aceleasi operatii.

Un “statefull-ejb” păstrează în variabilele sale informatii despre client, cu care

poate mentine o conversatie, dar nu poate fi folosit în comun de mai multi clienti.

Un “singleton-ejb” este instantiat la pornirea unei aplicatii si există pe toată durata

aplicatiei, spre deosebire de celelalte două tipuri care sunt active numai pe durata unei

sesiuni client.

Componentele “stateless” si “singleton” pot fi folosite pentru a implementa servicii

Web; în acest caz trebuie adăugate clasei ejb adnotările @Stateless (sau @Singleton) si

@WebService sau @WebServiceProvider. Metodele expuse de serviciu trebuie adnotate

cu @WebMethod.

Implementarea unui client de ejb diferă după cum clientul se află în acelasi server

JEE cu obiectul ejb sau este în afara acestui server (o aplicatie Java desktop, de ex.).

Un client exterior trebuie să obtină adresa obiectului ejb prin intermediul

servicului JNDI, care asociază un nume (un identificator) cu adresa unui obiect aflat într-o

altă masină Java. Asocierea dintre nume si adresă se face la instalarea aplicatiei pe server,

fie printr-un fisier descriptor xml, fie printr-o interfată grafică într-un IDE.

1.6. Exemple JEE6 care folosesc componente EJB sesiune Pasul 1: Creați un nou proiect

1.1. Din meniul principal, selectați File> New. Extindeți categoria General și selectați Aplicații, apoi Custom Application și apoi OK.

1.2. introduceți numele aplicației LabSessionEJB.

1.3. Acceptați valorile implicite și faceți clic pe Finish. Panoul de Navigare proiecte ar trebui să arate:

Pasul 2: Crearea unui EJB Sesiunea Bean. O sesiune bean este un obiect de scurtă durată care conțin metode de bussiness care pot fi executate de către un client. Când un client dorește să execute o metodă într-o sesiune bean, containerul EJB creează o instanță a acesteia. Durata de viață este echivalentă cu sesiunea clientului. Numele EJB specificat va deveni numele sesiunii bean. 2.1. În Navigatorul de aplicații, selectați proiectul pe care tocmai l-ați creat și în meniul File> New > Business Tier > EJB > Sesiunea Bean pentru a lansa wizardul Creare Sesiunea Bean, apoi OK.

2.2. La pasul 1, selectați Enterprise JavaBeans 3.1 (Java EE 6.0), și faceți clic pe Următorul.

2.3. La pasul 2, General, introduceți SalutareSession ca nume EJB, asigurați-vă că stateless și container sunt selectate. Verificați că Generate Session Facade Methods nu este selectată.

2.4. La pasul 3, Definitii clasa, introduceți acme.ejb.session.HelloWorldSessionBean ca nume de clasă bean, și faceți clic pe Următorul. Acest pachet va pune toate informațiile sesiune bean în propriul pachet. Partiționarea EJB-uri în pachete diferite poate fi mai puțin confuz atunci când există mai multe componente într-un proiect.

2.5. La pasul 4, Interfete, selectați Implement a Remote Interface și deselectați Implement a Local Interface, apoi clic pe Finish.

2.6. Faceți clic pe pictograma pentru a salva aplicația. JDeveloper a generat următoarele fișiere în pachetul acme.ejb.session:

Pasul 3: Adăugați o metoda Bean 3.1 O sesiune de bean contine metode de business care pot fi executate de către un client . În acest pas, se va folosi editorul sursă pentru a adăuga o metodă de clasa beans generate de Jdeveloper. 3.2. Deschideți fișierul în editor sursă, adăugați cod pentru a crea o metodă de "Hello world", după:

public HelloWorldSessionBean ( ) { }

Copiați și inserați codul de mai jos:

public String sayHello (String name) { return "Salut " + name; }

3.3. În fereastra Structura de HelloWorldSessionBean.java, faceți clic dreapta pe pictograma

din dreptul metodei sayHello(String) și în meniul contextual alegeți Enterprise JavaBeans (EJB) > Properties.

3.4. În Bean metoda Detalii de dialog , selectați Expose through Remote interface, și apoi OK. Interfața este locală, în cazul în care clientul va rula în același JVM ca EJB 3.0 container. În cazul în care clientul se execută pe o VM separată, este necesară o interfață de la distanță. Interfața de la distanță expune servicii clientilor Java. Când bifați caseta de selectare pentru a expune metoda sayHello() prin intermediul interfeței de la distanță, potrivit semnătura metodă va fi adăugat la interfeței remote.

3.5. Faceți clic pe pictograma pentru a salva munca ta. Când ați terminat pașii pentru adăugarea unei metode bean și expune metoda printr-o interfață de la distanță, editorul sursă ar trebui să arate similar cu aceasta:

Aplicația are acum o sesiune de bean cu o metodă business, precum și o interfață remote

care expune metoda business. Când ați selectat caseta de selecție pentru a expune metoda sayHello() prin interfața de la distanță, semnătura metodei a fost adăugată la interfața la distanță. Dacă faceți dublu clic pe SalutareSession.java pentru a deschide în editor, veți vedea metoda sayHello():

Adnotarea @Remote semnifică că interfața SalutareSession este

interfață remote. Pasul 4: crearea și rularea unui client Java

4.1. În Applicațion Navigator, faceți clic dreapta pe pictograma HelloWorldSessionBean.java și alegeți New Sample Java Client. (în meniul contextual) JDeveloper include un utilitar de client Java pentru testarea serviciilor bussiness.

4.2. În caseta de dialog Create Sample Client Java, introduceti acme.client.SalutareSessionClient în câmpul Client class name pentru a crea clientul într-un pachet separat în cadrul proiectului. Asigurați-vă că serverul IntegratedWebLogicServer integrat este selectat în lista Application Server Connection, apoi clic pe OK. Când creați un client Java de probă , puteți alege pentru a crea clientului în același pachet ca bean sesiune, sau specifica un pachet diferit.

4.3. În editorul sursă SalutareSessionClient.java, adăugați cod care apelează metoda creată anterior, după:

SalutareSession salutareSession = (SalutareSession) context.lookup("LabSessionEJB-Project1-SalutareSession#acme.ejb.session.SalutareSession");

Copiați și inserați următoarea linie :

System.out.println ( salutareSession.sayHello( " la toti colegii" ) ) ;

4.4. Compilați proiectul prin alegerea Build > Compile <project_name> din meniul principal . Ar trebui să vedeți un mesaj compilație de succes în fereastra de Log Mesaje .

4.5. În Navigator aplicație, porniți serverul integrat prin clic-dreapta pe pictograma HelloWorldSessionBean.java și alege Run. În cazul în care folosiți Domain-ul implicit, introduceți parola implicită, de exemplu weblogic1, în câmpul Password și câmpul Confirm parolă, apoi faceți clic pe OK . Dacă se ruleaza pentru prima dată se crează domeniul. 4.6. Când executați o sesiune bean, JDeveloper afișează câteva mesaje în fereastra Running Log, și apoi afișează un mesaj pentru a indica starea WebLogic Server integrat: În cazul în care cererea a fost implementatâ pe serverul integrat, în Application Navigator, clic-

dreapta pe pictograma SalutareSessionClient.java și alege Run. Când executați clientul Java, ieșirea Salut la toți colegii apare în fereastra Project1.jpr

Pentru a opri sesiunea bean, faceți clic pe pictograma Termină din bara de instrumente

principală și alegeți instanță aplicației SessionEJB din meniul.

Teme.

1. Realizați și rulați aplicația. 2. Modificați clientul astfel încât acesta să citească de la consolă numele unei persoane,

să transmită această informție serverului iar serveul să răspundă cu mesajul Hello, nume!

3. Creați o aplicație EJB folosind o componentă de sesiune cu stare care să contorizeze numărul de cereri ale clienților. Componenta se va numi Count și va conține o variabilă de stare care va fi incrementată la fiecare apel al unui client.

Valoarea acesteia este returnată clientului, care o afișează.

Bibliografie

1. Oracle: JavaEE6 Tutorial

2. Ch.14 : Enterprise Beans

3. Ch.15 : Getting Started with Enterprise Beans

4. http://ejbvn.wordpress.com/category/week-1-enterprise-java-architecture/

5. EJB3.1 Expert Group: JSR-318 Enterprise JavaBeans(tm) ("Specification"), Nov.2009;

6. http://soabpel.wordpress.com/2009/03/01/j2ee-enterprise-archive-ear-web-application-

war-webservices-war-file-structure/

7. Ed Roman s.a.: Mastering Enterprise JavaBeans, Third edition, Wiley, 2006;

Anexa =============== HelloWorldSessionBean.java================================

package acme.ejb.session;

import javax.annotation.Resource;

import javax.ejb.Local;

import javax.ejb.SessionContext;

import javax.ejb.Stateless;

@Stateless(name = "SalutareSession", mappedName = "LabSessionEJB-Project1-SalutareSession")

@Local

public class HelloWorldSessionBean implements SalutareSession {

@Resource

SessionContext sessionContext;

public HelloWorldSessionBean() {

}

public String sayHello(String name) {

return "Salut " + name;

}

}

================== SalutareSession.java===========================

package acme.ejb.session;

import javax.ejb.Remote;

@Remote

public interface SalutareSession {

String sayHello(String name);

}

===================== SalutareSessionClient.java======================

package acme.client;

import acme.ejb.session.SalutareSession;

import java.util.Hashtable;

import javax.naming.CommunicationException;

import javax.naming.Context;

import javax.naming.InitialContext;

import javax.naming.NamingException;

public class SalutareSessionClient {

public static void main(String[] args) {

try {

final Context context = getInitialContext();

SalutareSession salutareSession =

(SalutareSession) context.lookup("LabSessionEJB-Project1-

SalutareSession#acme.ejb.session.SalutareSession");

System.out.println ( salutareSession.sayHello( " la toti colegii" ) ) ;

} catch (CommunicationException ex) {

System.out.println(ex.getClass().getName());

System.out.println(ex.getRootCause().getLocalizedMessage());

System.out.println("\n*** A CommunicationException was raised. This typically\n*** occurs when

the target WebLogic server is not running.\n");

} catch (Exception ex) {

ex.printStackTrace();

}

}

private static Context getInitialContext() throws NamingException {

Hashtable env = new Hashtable();

// WebLogic Server 10.x/12.x connection details

env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");

env.put(Context.PROVIDER_URL, "t3://127.0.0.1:7101");

return new InitialContext(env);

}

}

===========================================================.