Arhitectura Enterprise JavaBeans reprezinta parte a arhitecturii Java 2 Enterprise Edition (J2EE) devenind standard acceptat pentru dezvoltarea aplicatiilor distribuite.

EJB este un standard pentru arhitectura componentelor pe parte de server.

Enterprise JavaBeans sunt componente Java pe care un programator Java le scrie si le instaleaza intr-o aplicatie server si care asigura servicii de denumire, de securitate, de efectuare a tranzactiilor si alte servicii de intreprindere pentru componente.

Aceste componente instalate pot fi utilizate de o maniera distribuita intr-o retea.

O componenta software este o unitate de compozitie care are interfete specificate contractual si doar dependente explicite de context. O componenta software poate fi desfasurata independent si poate fi subiect de compozitie pentru terte parti.

Indiferent de serviciile pe care le ofera o componenta, acestea vor fi furnizate prin intermediul unei interfete specificate public.

Acest lucru inseamna ca unui client ce interactioneaza cu o componenta nu-i vor fi prezentate detalii interne ale componentei, ci doar rezultatul solicitarii adresate de client componentei. Acest lucru este denumit si incapsulare.

O structura cadru (framework) este o biblioteca de alte componente ce pot fi utilizate in mai multe aplicatii si care economisesc timp de programare prin furnizarea unor servicii si functii testate.

Arhitectura j2ee reprezinta o arhitectura multi-start. Scopul utilizarii straturilor este posibilitatea de distribuire a componentelor software si a serviciilor pe mai multe calculatoare, pentru scalabilitate si securitate.

Ce este o componenta enterprise bean?

Enterprise beans sunt componente care fac parte dintr-o aplicatie de intreprindere distribuita, orientata pe tranzactii. Ele au urmatoarele caracteristici:

depind de un mediu container care le asigura servicii pe ciclul de viata;
contin algoritmi de lucru efectiv care opereaza cu datele intreprinderii;
instantele EJB sunt create si mentinute de container;
pot fi particularizate la momentul desfasurarii prin editarea unui descriptor de desfasurare bazat pe XML;
serviciile de nivel sistem, cum ar fi gestionarea tranzactiilor si securitatea, sunt descrise separat de componentele enterprie bean;
un client nu va accesa niciodata direct o componenta enterprise bean, accesul clientului este mediat de mediul container;
componenta enterprise bean este proiectata astfel incat sa fie portabila pe servere EJB furnizate de producatori diferiti.

Incepand cu specificatiile EJB 2.0, exista trei tipuri de componente enterprise bean:

componenta entitate (entity bean);
componenta sesiune (session bean);
componenta bazata pe mesaj (message-dreaven bean).

3.2 Componenta entitate (entity bean)

O componenta entitate reprezinta de obicei o linie dintr-o baza de date relationala.

Asa cum intr-un tabel dintr-o baza de date exista o linie pentru fiecare inregistrare, se poate creia o singura instanta de componenta entitate pentru fiecare linie. Toti clientii care acceseaza aceeasi linie dintr-o baza de date vor face acest lucru prin intermediul aceleiasi instante de componente entitate. O componenta entitate este considerata a fi persistenta deoarece supravietuieste blocarii serverului. La pornirea serverului, componenta entitate este regasita in acelasi loc, deoarece starea reprezentata de ea a ramas in baza de date. Nu este obligatoriu ca fiecare tabela din schema de persistenta sa fie mapat la o singura componenta entitate. Putem avea componente entitate formate din mai multe tabele.

Atunci cand mai multi clienti acceseaza un anumit obiect de lucru care a fost implementat folosindu-se o componenta entitate, containerul impune accesul secvential la respectivul obiect. Acest lucru inseamna ca doi clienti nu pot modifica in acelasi timp starea unui astfel de obiect.

Componentele entitate au o caracteristica unica printre celelalte elemente EJB, si anume: ele trebuie sa aiba asociata o clasa de cheie primara. Utilizarea versiunii EJB 2.0 si a componentelor sesiune integrate in acelasi container permite limitarea folosirii componentelor entitate doar de catre clientii locali.

In privinta gestionarii persistentei, exista posibilitatea de a scrie pentru o componenta entitate codul de acces la baza de date, sau de a declara mapari ale bazei de date si de a lasa containerul sa interactioneze cu baza de date.

Modul in care un client vede o componenta entitate sau de sesiune este definit de interfata de componenta, care consta fie dintr-o interfata locala, fie dintr-o interfata la distanta, fie din ambele. Clientii nu acceseaza in mod direct clasele EJB. Orice functii ce se doresc a fi facute disponibile trebuiesc expuse prin intermediul interfetei de componenta. Metodele declarate intr-o interfata locala sau la distanta se numesc metode de lucru ale componentei. Cand se declara o interfata la distanta, trebuie facut acest lucru prin extinderea interfetei javax.ejb.EJBobject. In mod asemanator, o interfata locala trebuie sa extinda interfata javax.ejb.EJBLocalObject. Desi clasa componentei trebuie sa implementeze metodele de lucru ce sunt declarate in interfata ei de componenta, nu este obligatoriu ca respectiva clasa sa implementeze toata interfata.

Implementarea interfetei de componenta cade in sarcina containerului, care realizeaza si transmiterea apelurilor la metodele de lucru catre o instanta a clasei de componenta.

Acest lucru inseamna ca atunci cand se face implementarea unei componente entitate nu trebuie sa ne facem probleme pentru scrierea codului metodelor EJBobject si EJBLocalObject, ca de exemplu getPrimaryKey sau remove.

Cel mai adesea, clientii unei entitati sunt componente de sesiune, dar pot fi de asemenea componente bazate pe mesaj sau alte componente entitate.

Dupa ce un client obtine o referinta catre interfata locala sau la distanta a unei entitati, el poate manipula obiectul entitate pe mai multe cai. In particular, un client poate:

sa apeleze metodele de lucru ale obiectului entitate;
sa apeleze metoda remove pentru a elimina o instanta din container si a sterge entitatea din baza de date;
sa obtina cheia primara a obiectului entitate (utilizand metoda getPrimaryKey);
sa obtina obiectul Handle al entitatii;
sa obtina o referinta catre interfata de baza a entitatii (utilizand metodele getEJBLocalHome sau getEJBHome);
sa treaca referinta ca parametru sau sa returneze valoarea unui apel de metoda.

In particular, metodele utilizate intr-o interfata de componenta trebuie sa respecte urmatoarele reguli:

nici un nume de metoda nu poate incepe cu ejb;
toate metodele vor fi declarate ca public;
nici o metoda nu poate fi declarata ca static sau final;
toate metodele dintr-o interfata la distanta trebuie sa includa java.rmi.RemoteException in clauza throws. (Acestea sunt apeluri la distanta care pot esua din cauza unor probleme de infrastructura sau comunicare).

3.2.1 Definirea clasei cheii primare

Unui obiect entitate trebuie sa-i fie asociat un obiect cheie primara. Acest lucru este necesar containerului pentru a tine evidenta entitatilor. Identificarea clasei cheii primare pentru o componenta entitate se face in descriptorul sau de integrare.

Similar tabelelor de baza de date pe care le reprezinta, componentele entitate trebuie sa accepte chei primare ce sunt definite fie printr-un singur camp, fie printr-o combinatie de campuri. Clasa cheii primare poate avea orice tip de valoare valida RMI-IIOP, ceea ce, in esenta, inseamna ca trebuie sa implementeze clasa Serializable si nu trebuie sa implemeteze java.rmi.Remote. De exemplu se pot utiliza drept cheie primara tipuri de valori Java standard, cum ar fi String, Integer si Long.

In cazul utilizarii persistentei gestionate de container (CMP – Container-Managed-Persistance) cu o cheie cu camp unic se identifica campul componentei entitate ce corespunde cheii primare utilizand elementul primkey-field:

...

<prim-key-class>java.lang.Integer</prim-key-class>

<primkey-field>id</primkey-field>

…

3.2.2 Declararea interfetei de baza

Orice componenta entitate sau de sesiune trebuie sa aiba o interfata de baza care extinde javax.ejb.EJBHome, sau o interfata de baza locala care extinde javax.ejb.EJBLocalHome sau pe amandoua. Interfata de baza asigura operatii de constructie care le permit clientilor sa creeze si sa elimine instante EJB. In cazul componentelor entitate, aceasta interfata le permite de asemenea clientilor sa obtina referinte catre componentele entitate existente si sa execute metode de lucru efectiv care nu sunt specifice unui anumit obiect entitate.

3.2.3 Crearea unei componente entitate

Pentru ca un client sa poata crea o noua entitate, trebuie definita cel putin o metoda create in interfata de baza a componentei.

Trebuie declarata cate o metoda create pentru fiecare mod in care se doreste a se crea o entitate. In particular, fiecare dintre metodele create dintr-o interfata de baza locala trebuie:

sa aiba un nume care incepe cu cuvantul create;
sa fie declarata astfel incat sa returneze tipul de interfata locala;
sa includa javax.ejb.CreateException in clauza throws.

Cerintele pentru o interfata de baza la distanta sunt similare, prin faptul ca fiecare metoda create declarata aici trebuie:

sa aiba un nume care incepe cu cuvantul create;
sa fie declarata astfel incat sa returneze tipul de interfata la distanta;
sa includa javax.ejb.CreateException si java.rmi.RemoteException in clauza throws.

Fiecarei metode create declarate trebuie sa-i corespunda metode ejbCreate si ejbPostCreate in clasa de implementare a componentei.

3.2.4 Gasirea unei componente entitate

Pentru localizarea unui obiect entitate trebuiesc declarate in interfata de baza metode cunoscute sub numele de metode de cautare. O metoda de cautare raspunde de localizarea tuturor obiectelor care indeplinesc anumite criterii. Ca cerinta minima, orice interfata de baza suporta gasirea unei entitati prin cheia primara, utilizand o declaratie a metodei similara cu:

public persoana findByPrimaryKey(integer primaryKey) throws finderException;

Metoda findByPrimaryKey trebuie sa aiba exact acest nume, sa returneze tipul de interfata locala (sau la distanta) si sa accepte un singur parametru de tipul cheii primare.

Orice metoda de cautare declarata in interfata de baza locala trebuie:

sa aiba un nume care incepe cu find;
sa fie declarata incat sa returneze tipul de interfata locala sau o colectie de obiecte care implementeaza interfata locala;
sa includa exceptia javax.ejb.FinderException in clauza throws;

Cerintele pentru o interfata de baza la distanta sunt similare, prin faptul ca fiecare dintre aceste metode de cautare trebuie:

sa aiba un nume care incepe cu find;
sa fie astfel declarata incat sa returneze tipul de interfata la distanta sau o colectie de obiecte care implementeaza interfata la distanta;
sa includa exceptiile java.rmi.remoteException si javax.ejb.FinderException in clauza throws.

3.2.5 Eliminarea unei componente entitate

Interfata EJBHome declara doua metode ce pot fi utilizate pentru eliminarea instantelor componentei de intreprindere:

void remove(Handle handle) throws RemoteException, RemoveException;

void remove(Object primaryKey) throws EJBException, RemoveException;

Pentru clientii locali interfata EJBLocalHome declara o singura metoda remove:

void remove(Object primaryKey) throws EJBException, RemoveException.

Containerul implementeaza aceste metode, programatorul ne mai avand grija cu definirea lor.

3.2.6 Declararea metodelor de lucru in interfata de baza

O metoda de baza este o metoda de lucru care a fost declarata in interfata de baza, in loc sa fie declarata in interfata la distanta. Scopul metodelor de baza este asigurarea suportului pentru algoritmii de lucru efectiv, care sunt strans legati de o clasa de componenta entitate, dar nu de o singura instanta. Datorita faptului ca interfata de baza este un atelier care nu este niciodata asociat cu o singura instanta, metodele de baza nu pot accesa la executie nici un fel de date de instanta. In general, o metoda de baza poate avea orice nume, dar aceasta nu poate incepe cu cuvintele create, find sau remove. Parametrii si tipul de date returnat de o metoda de baza declarata intr-o interfata de baza la distanta trebuie sa fie tipuri valide de date RMI-IIOP. Clauza throws a unei metode de baza poate include exceptii de aplicatie, dupa necesitati. Cand este declarata o interfata de baza la distanta, clauza throws este obligatoriu sa includa exceptia java.rmi.RemoteException.

3.2.7 Implementarea unei componente entitate

Clasele de componente trebuie sa implementeze intotdeauna, direct sau indirect, interfata javax.ejb.EntityBean. Aceasta interfata este o extindere a interfetei de marcare EnterpriseBean si ea defineste mai multe metode de apelare inversa utilizate de container pentru interactiunea cu clasele componente. Interfata este compusa din urmatoarele declaratii:

public interface EntityBean extends EnterpriseBean {

public void ejbActivate() throws EjbException, RemoteException;

public void ejbPassivate() throws EjbException, RemoteException;

public void ejbLoad() throws EjbException, RemoteException;

public void ejbStore() throws EjbException, RemoteException;

public void ejbRemove() throws RemoveException, EjbException, RemoteException;

public void setEntityContext(EntityContext ctx) throws EjbException, RemoteException;

public void unsetEtityContext() throws EjbException, RemoteException;

}

Exceptia RemoteException este utilizata de metodele declarate intr-o interfata la distanta sau intr-o interfata de baza la distanta pentru a raporta erorile de sistem. In cazul in care este utilizat EJB 2.0, in locul exceptiei RemoteException trebuie folosit EJBException pentru a raporta erorile de sistem.

Interfata EntityContext extinde interfata EJBContext este utilizata pentru a defini o interfata catre contextul de rulare al unei componente entitate furnizat de container.

3.2.8 Metode de lucru

Fiecarei metode de lucru definite intr-o interfata de componenta trebuie sa-i corespunda o implementare in clasa componentei. La fel ca la orice implementare de metode de interfata, o metoda dintr-o clasa de componenta trebuie sa aiba acelasi nume, aceeasi lista de parametri si sa returneze acelasi tip de valori, ca in declaratia de interfata.

Daca la implementarea metodei se declara generarea unor exceptii, acestea trebuie incluse in declaratia din interfata. Acest lucru apare de obicei cand au loc definiri de exceptii specifice aplicatiei, pentru raportarea erorilor in algoritmii de lucru efectiv.

Chiar daca declaratiile din interfata la distanta trebuie sa includa intotdeauna <