Enterprise JavaBeans

Calea spre aplicaii Java distribuite, tranzacionale, sigure i portabile

Java Enterprise Edition (JEE) definete o platform Java realizat n mod special pentru a susine
necesitile riguroase ale informaticii de ntreprindere.
Pito Peter

Elementul cheie al platformei JEE este, fr ndoial, tehnologia Enterprise JavaBeans (EJB), care definete un
model de componente care ruleaz pe partea de server i un API independent de furnizor pentru servere de aplicaii
Java.
EBJ permite o dezvoltare rapid i simplificat a aplicaiilor Java distribuite, tranzacionale, sigure i portabile.
Apariia EJB
La nceputul anilor '90, furnizorii tradiionali de sisteme informatice pentru ntreprinderi au nceput s treac de la
arhitectura aplicaiilor client-server pe dou niveluri la modele mai flexibile, pe trei sau mai multe niveluri. Noile
modele au separat logica aplicaiei de serviciile sistemului i interfaa utilizator, introducnd un nivel de mijloc
(middle tier) ntre cele dou. Evoluia noilor servicii middleware - monitoarele de tranzacii, midleware-urile
orientate pe mesaje, ORB (object request broker) - au dat un avnt i mai mare acestui nou tip de arhitectur.
Folosirea pe scar tot mai larg a Internetului i a intraneturilor a condus la crearea de clieni mici i uor de
executat.
Proiectarea multi-tier (arhitectur pe mai multe niveluri) simplific mult dezvoltarea, folosirea i rularea aplicaiilor
de ntreprindere. Acesta permite proiectanilor s se concentreze pe realizarea logicii aplicaiei (business logic),
bazndu-se pe o serie de servicii backend pentru a furniza infrastructura i aplicaiile client n scopul interaciunii cu
utilizatorii. Odat logica aplicaiei realizat, ea poate fi rulat pe un server pentru a satisface necesitile unei
organizaii. ns faptul c modelul multi-tier a fost implementat ntr-o varietate mare de standarde divergente a
limitat mult abilitatea proiectanilor de realiza aplicaii folosind componente standardizate, de a realiza o singur
aplicaie care s ruleze pe o varietate mare de platforme i de a putea scala cu uurin aplicaiile pentru a satisface
condiiile n schimbare.
Calea ctre apariia tehnologiei EJB a fost lung. Primul pas a fost fcut prin apariia servlet-urilor, tehnologie
destinat realizrii de aplicaii CGI, care puteau rula pe orice server web cu suport pentru platforma Java. Mai apoi,
tehnologia JDBC a permis unificarea sintagmei limbajului Java ("Write Once, Run Anywhere") cu sistemele de baze
de date existente. n final, arhitectura JavaBeans a demonstrat utilitatea folosirii componentelor software pe partea
client. Convergena acestor trei concepte - aplicaii scrise n Java pe partea server, comportament de componente,
conectarea acestora cu sistemele existente - a dus la apariia standardului EJB.
Specificaiile EJB
n martie 1998, Sun Microsystems a lansat prima versiune a specificaiei Enterprise JavaBean. Scopul declarat al
acestei tehnologii era de a crea o arhitectur bazat pe componente pentru dezvoltarea i realizarea de aplicaii
obiectuale distribuite pentru ntreprinderi. Specificaia EJB definete dou concepte importante:
- bean-urile Enterprise - componente care ruleaz pe un server de aplicaii
- mediul runtime, numit server EJB - furnizeaz mediul de execuie mpreun cu serviciile de tranzacii, serviciile de
distribuie, serviciile de administrare a obiectelor persistente i securitatea.
Anul acesta, Sun a lansat versiunea 1.1 a specificaiei EJB, care aduce o serie de mbuntiri versiunii anterioare n
trei domenii importante: dezvoltare i execuie, persistena obiectelor i compatibilitate.
Arhitectura Enterprise JavaBeans definete un model standard pentru aplicaiile server Java, astfel nct acestea s se
conformeze principiului "Write Once, Run Anywhere" (WORA). WORA este unul dintre elementele cheie ale
tehnologiei Java. Maina virtuala Java (JVM) permite aplicaiilor Java s ruleze pe orice sistem de operare care
suport Java. ns componentele server necesit servicii adiionale pentru a putea funciona, servicii care nu sunt
suportate direct de ctre JVM. Aceste servicii sunt suportate de ctre aplicaii server sau de ctre infrastructuri
obiectuale distribuite cum ar fi CORBA sau DCOM. n mod tradiional, fiecare server furnizeaz un API propriu
pentru a accesa aceste servicii. Astfel, portarea componentelor server de pe un server pe altul este practic imposibil.
Modelul EJB definete un set standard de interfee independente de furnizor, pentru toate aplicaiile server. Astfel,
arhitectura EJB devine o arhitectura independent att de platform i sistem de operare, ct i de platforma EJB.
n continuare voi trece n revista modelul componentelor Enterprise JavaBeans i a serverelor EJB.
Componente Enterprise JavaBeans
Modelul componentelor EJB extinde modelul componentelor JavaBeans. Modelul componentelor JavaBeans
definete un mecanism standard pentru dezvoltarea de componente Java portabile i reutilizabile. Componentele

JavaBeans pot fi folosite n orice IDE (Integrated Development Environment) Java, cum ar fi Symantec Visual Cafe,
IBM Visual Age, Inprise JBuilder etc. O component JavaBeans este o clas Java specializat, care poate fi adugat
ntr-un proiect i poate fi manipulat de IDE-ul Java. Un bean are un comportament mai aparte fa de o clas Java
obinuit, care permite mediului de dezvoltare Java s-l examineze i s-i modifice proprietile i comportamentul
fr a accesa codul surs a componentei.
Modelul componentelor EJB extinde modelul JavaBeans pentru a realiza componente server. Componentele server
sunt componente reutilizabile, piese prempachetate ale funcionalitii aplicaiei i care sunt proiectate pentru a rula
pe un server de aplicaii. Componentele server sunt similare componentelor client, ns de obicei sunt mult mai
ample i mai complexe. Componentele Enterprise JavaBeans nu pot fi manipulate de un IDE Java n acelai mod n
care sunt manipulate componentele JavaBeans. n schimb, ele pot fi asamblate i modificate (n sensul
comportamentului acestora) n momentul rulrii folosind unelte furnizate de ctre servere compatibile EJB.
Arhitectura EJB ajut la simplificarea procesului de dezvoltare a sistemelor informatice de ntreprindere. Un server
EJB rezolv automat un numr de servicii middleware complexe necesare componentelor EJB. Astfel, proiectanii
de componente EJB se pot concentra asupra logicii aplicaiei n loc s-i bat capul cu servicii complexe
middleware.
Servicii implicite
Modelul EJB suport un numr de servicii implicite, incluznd managementul ciclului de via al obiectelor,
administrarea strilor, securitatea, tranzaciile i persistena.
Lifecycle. Bean-urile enterprise nu trebuie s-i gestioneze n mod explicit procesul de alocare, administrarea firelor
de execuie, activarea sau distrugerea obiectelor. Containerul EJB administreaz automat ciclul de via al obiectelor
pentru componenta EJB.
Administrarea strilor. Bean-urile enterprise nu trebuie s-i salveze sau s-i refac n mod explicit starea
obiectelor. Containerul EJB administreaz automat starea obiectele EJB.
Securitatea. Bean-urile enterprise nu trebuie s autentifice utilizatorii sau s le verifice nivelurile se autorizare n
mod explicit. Containerul EJB va face automat aceste verificri pentru bean.
Tranzaciile. Bean-urile enterprise nu trebuie s-i marcheze n mod explicit codul pentru a participa n tranzacii
distribuite. Containerul EJB poate realiza n mod automat nceperea, ntreruperea sau terminarea tranzaciilor.
Persistena. Bean-urile enterprise nu trebuie s-i stocheze sau s-i ncarce n mod explicit datele obiectelor din
baza de date. Containerul EJB poate s fac automat i acest serviciu obiectului EJB.
Modelul EJB definete interoperabilitatea dintre un obiect enterprise bean i un container enterprise bean.
Componentele EJB nu trebuie s se foloseasc de nici o caracteristic sau funcionalitate specific a unui anumit
container. Un furnizor poate s-i adapteze orice aplicaie server pentru a suporta tehnologia EJB adugnd un
suport pentru serviciile definite n specificaie. Serviciile definesc un contract ntre enterprise bean i container, prin
implementarea unui strat de portabilitate. Orice component enterprise bean poate rula n orice server de aplicaii
care suport contracte Enterprise JavaBeans.
Un server de aplicaii compatibil Enterprise JavaBeans, numit server EJB, trebuie s furnizeze un set standard de
servicii pentru a suporta componentele EJB. Spre exemplu, componentele EJB sunt tranzacionale, drept urmare un
server EJB trebuie s furnizeze componentei acces la un serviciu distribuit de tranzacii. Serverul EJB trebuie s
furnizeze un container componentei enterprise bean, numit container EJB. Containerul EJB implementeaz
managementul i controlul serviciilor pentru unul sau mai multe clase de obiecte EJB. De asemenea, containerul
EJB trebuie s administreze ciclul de via al obiectelor, s asigure un control implicit al tranzaciilor, s se ocupe de
administrarea persistenei obiectelor, s ofere o distribuie transparent a serviciilor precum i securitatea acestora.
n cele mai multe situaii, un productor va furniza att serverul EJB ct i un container EJB asociat, cu toate c
specificaia permite separarea acestora.
Arhitectura EJB
Serverul Enterprise JavaBeans furnizeaz un mediu care suport execuia aplicaiilor dezvoltate folosind
tehnologia EJB. Acesta administreaz i coordoneaz alocarea resurselor aplicaiei.
Containerul EJB. Serverul EJB trebuie s furnizeze unul sau mai multe containere EJB, care vor oferi "o casa"
pentru componentele EJB. Un container EJB administreaz bean-ul coninut n el. Pentru fiecare bean enterprise,
containerul este responsabil de nregistrarea obiectului, de furnizarea unei interfee remote pentru obiect, de crearea
i distrugerea instanelor obiectului. De asemenea, containerul efectueaz validrile de securitate, administreaz
strile obiectului i coordoneaz tranzaciile distribuite. Opional, containerul poate administra toate datele
persistente n cadrul unui obiect.
ntr-un container EJB pot fi instalate un numr nedefinit de clase EJB. O anumit clas EJB este asignat unui
singur container EJB, ns un container nu reprezint neaprat o locaie fizic. Comportamentul fizic al unui
container EJB nu este definit n specificaia Enterprise JavaBeans. Un container EJB poate fi implementat ca o

entitate fizic, cum ar fi un proces multi-fir n cadrul unui server EJB, sau poate fi implementat ca o entitate logic
ce poate fi replicat i distribuit peste oricte sisteme i procese.
Obiecte tranziente i persistente. Tehnologia Enterprise JavaBeans suport att obiecte tranziente ct i obiecte
persistente. Un obiect tranzient este numit "bean sesiune" (session bean), iar un obiect persistent este numit "bean
entitate" (entity bean).
Un bean sesiune este creat de ctre un client i n cele mai multe cazuri exist numai pe durata unei singure sesiuni
client/server. Un bean sesiune execut operaii pentru client, cum ar fi accesarea unei baze de date sau efectuarea
unor calcule. Un bean sesiune poate fi tranzacional, ns n mod normal nu poate fi recuperat n cazul unei cderi a
sistemului. Un asemenea bean poate s aib sau nu stri. n cazul n care are stri, atunci acestea sunt gestionate de
ctre container. Un bean sesiune trebuie s-i administreze singur propriile sale date persistente.
Un bean entitate este un obiect format din date persistente care sunt stocate pe sisteme de gestiune permanente, cum
ar fi bazele de date. O cheie primar identific fiecare instan a unui bean entitate. Bean-urile entitate pot fi create
fie prin inserarea de date direct n baza de date, fie prin crearea unui obiect. Aceste bean-uri sunt tranzacionale i
sunt recuperabile n cazul unei cderi de sistem.
Bean-ul entitate poate s-i administreze singur persistena sau poate delega acest serviciu containerului su. Dac
bean-ul las n seama containerului administrarea persistenei, atunci containerul execut automat operaiile de
salvare i restaurare a datelor.
Contracte standard. Un bean enterprise poate rula n orice server EJB, chiar dac diferite servere i
implementeaz serviciile n diferite moduri. Modelul EJB asigur portabilitatea peste diferite servere EJB folosind
un set standard de contracte ntre containerul EJB i bean-ul enterprise. Fiecare bean enterprise trebuie s
implementeze un set de interfee care permite containerului EJB s administreze i s controleze obiectul.
Containerul EJB va apela aceste interfee implementate de ctre obiect.
Intercepie i wrapping. Un container EJB i administreaz bean-urile enterprise care ruleaz n cadrul sau.
Aplicaiile client nu interacioneaz direct cu bean-urile EJB, ci prin intermediul a dou interfee wrapper care sunt
generate de ctre container: interfaa EJB Home i interfaa EJB Object. Cnd un client invoc operaiile bean-ului
folosind aceste interfee wrapper, containerul intercepteaz fiecare apel de metod i apeleaz serviciile de
administrare ale serverului. Interfaa EJB Home furnizeaz accesul ctre serviciile care se ocup cu ciclul de via al
componentelor. Clienii pot folosi interfaa Home pentru a crea i distruge instane de obiecte EJB. Pentru bean-urile
entitate, interfaa Home furnizeaz de asemenea mai multe metode de cutare care permit clienilor regsirea i
restaurarea unei instane de bean existente.
Pentru fiecare clas instalat n container, acesta nregistreaz automat interfaa EJB Home ntr-un director folosind
API-ul Java Naming and Directory Interface (JNDI). Folosind JNDI, orice client poate localiza interfaa EJB Home
pentru a crea o nou instana a bean-ului sau pentru a cuta un bean entitate existent. n momentul n care clientul
creeaz sau gsete un bean, containerul returneaz o interfa de tip EJB Object.
Interfaa EJB Object permite accesarea metodelor care in de logica bean-ului. Un EJB Object reprezint
vizualizarea bean-ului de ctre client. Interfaa EJB Object expune toate interfeele bean-ului legate de aplicaie, dar
nu i pe acelea pe care containerul EJB le folosete pentru administrarea i controlul bean-ului. De fiecare dat cnd
un client apeleaz o metod a interfeei EJB Object, cererea trece prin containerul EJB nainte s ajung la bean-ul
enterprise. Containerul EJB implementeaz administrarea strilor, controlul tranzaciilor, securitatea i persistena
ntr-un mod transparent att clientului ct i bean-ului enterprise.
Regulile asociate unui EJB privind ciclul de via, tranzaciile, securitatea i persistena sunt definite ntr-un obiect
asociat numit Deployment Descriptor. Aceste reguli sunt definite n mod declarativ n timpul execuiei, deci nu sunt
"cablate" n timpul dezvoltrii bean-ului. n timpul execuiei, containerul EJB execut n mod automat serviciile n
conformitate cu valorile specificate n obiectul descriptor asociat bean-ului enterprise.
Pentru fiecare instan a unui bean enterprise, containerul EJB genereaz un obiect context pentru a menine
informaiile relative la regulile de administrare i starea curenta a bean-ului. Un bean sesiune va folosi un obiect
SessionContext, iar un bean entitate va folosi un obiect EntityContext. Obiectul context este folosit att de ctre
bean-ul enterprise ct i de ctre alte servicii sistem. De asemenea, fiecare bean enterprise are asociat i o tabel de
proprieti numit Environment, care conine valorile proprietilor setate n timpul asamblrii i execuiei
programului.
Serverul EJB
Al doilea concept important al specificaiei EJB se refer la mediul runtime n care ruleaz un bean enterprise, numit
server EJB. Serverul EJB furnizeaz mediul de execuie mpreuna cu serviciile de tranzacii, serviciile de distribuire,
serviciile de administrare a obiectelor persistente, managementul strilor i securitatea.

Servicii de distribuie. Tehnologia Enterprise JavaBeans folosete API-ul Java Remote Method Invocation pentru a
accesa bean-ul enterprise. Proiectantul EJB trebuie s defineasc o interfa RMI Remote pentru fiecare bean
enterprise. Containerul EJB genereaz interfaa EJB Object pe baza definiiei interfeei Remote.
RMI este o tehnologie care face ca locaia serverului s fie transparent clientului. Compilatorul RMI genereaz un
obiect stub pentru fiecare interfa remote. Obiectul stub este instalat pe sistemul clientului i furnizeaz un obiect
proxy local. Stub-ul implementeaz toate metodele remote i realizeaz apelul metodelor obiectului remote prin reea
ntr-un mod transparent.
Specificaia Enterprise JavaBeans nu face referire la nici un fel de protocol distribuit. RMI poate suporta multiple
protocoale de comunicaie. Protocolul nativ al RMI-ului este Java Remote Method Protocol. ncepnd cu Java 2,
este posibil interoperabilitatea obiectelor RMI cu obiectele CORBA prin introducerea protocolului RMI-IIOP.
Folosind protocolul IIOP (Internet InterORB Protocol), bean-urile enterprise pot interopera cu clieni i servere
scrise n limbaje native. IIOP permite integrarea sistemelor CORBA cu cele EJB. Bean-urile enterprise pot accesa
severe CORBA iar clienii CORBA pot accesa bean-uri enterprise. Folosind serviciul COM/CORBA
Internetworking, clienii ActiveX pot de asemenea accesa bean-uri enterprise i bean-urile enterprise pot accesa
servere COM. Teoretic, ar putea exista o implementare a tehnologiei Enterprise JavaBeans folosind tehnologia
DCOM.
Administrarea strilor. Serverele EJB i pot implementa n mod diferit politica de administrarea a resurselor
critice, cum ar fi memoria i firele de execuie. Unele servere EJB ar putea s-i menin toate obiectele n memorie,
n timp ce altele ar putea evacua fiecare obiect dup fiecare apel de metod. Alte servere EJB ar putea s foloseasc
o politica LRU (least recently used) pentru a evacua obiectele cel mai puin folosite n momentul n care intra n
criza de resurse. Indiferent de politica folosit, serverul EJB trebuie s furnizeze un serviciu de administrare a
strilor obiectelor.
Un bean sesiune reprezint munca realizat de ctre un anumit client. n unele cazuri, ntreaga munc se poate
rezuma la un singur apel de metod. n alte cazuri, pot exista mai multe apeluri de metode. n cazul apelurilor
multiple, trebuie meninut starea obiectului ntre dou apeluri distincte. De exemplu, ntr-o aplicaie de comer
electronic, metoda de validare a crii de credit este realizat printr-un singur apel de metod. n schimb, obiectul
"co de cumprturi" trebuie s in minte toate produsele selectate de ctre client n timpul navigrii, pn n
momentul plii. Opiunile pentru administrarea strilor pentru un bean sesiune sunt definite n atributul
StateManagementType din obiectul Deployment Descriptor. Toate bean-urile entitate au stri.
Dac un obiect nu are stare, atunci containerul i reseteaz starea dup fiecare apel de metod. Dac obiectul are
stare, atunci containerul i pstreaz automat starea atta timp ct obiectul sesiune este nc valid, chiar dac obiectul
a fost evacuat temporar din memorie. Arhitectura Enterprise JavaBeans furnizeaz un model simplu de programare
pentru a permite proiectanilor s-i poat realiza funciile indiferent dac obiectele sunt ncrcate n memorie sau
sunt evacuate temporar din memorie.
Administrarea obiectelor persistente. n cadrul administrrii persistenei obiectelor avem dou cazuri:
administrarea obiectelor de tip entitate i administrarea obiectelor de tip sesiune.
Un bean entitate reprezint date persistente. Un astfel de obiect exist n general pe o perioad mai ndelungat de
timp i poate fi folosit de ctre mai muli clieni.
Tehnologia Enterprise JavaBeans furnizeaz un model simplu de programare pentru administrarea obiectelor
persistente. Funciile persistente trebuie executate indiferent dac obiectele sunt create sau distruse, dac sunt
ncrcate sau evacuate din memorie. Modelul Enterprise JavaBeans izoleaz aceste funcii n fiecare clas enterprise
bean n metodele ejbCreate, ejbPostCreate, ejbRemove, ejbLoad, ejbStore, ejbActivate i ejbPassivate.
Un obiect entitate i poate administra singur persistena sau poate delega aceast funcie containerului. Opiunea
persistenei bean-ului entitate este definit n atributul ContainerManagedFields al obiectului descriptor. Dac
obiectul entitate i administreaz singur aceasta funcie, atunci bean-ul enterprise trebuie s implementeze nite
funcii direct n clasa enterprise bean. Aceast funcie poate fi realizat spre exemplu folosind JDBC. n cazul n care
bean-ul ncredineaz aceasta funcie serverului, containerul EJB administreaz n mod automat i transparent
persistena obiectului. Proiectantul bean-ului nu trebuie s scrie nici o linie de cod n bean pentru a accesa o baz de
date n scopul salvrii i restaurrii obiectului.
Implementarea serializrii de ctre containerul EJB este la latitudinea furnizorului serverului EJB. Unii furnizori pot
implementa serviciul de persistena printr-un mecanism mai simplu, realizat prin simpla serializare a obiectelor i
stocarea acestora pe un suport persistent. Ali furnizori pot implementa serviciul folosind un mecanism mai complex,
cum ar fi maparea transparent a cmpurilor persistente ale obiectelor ntr-o baz de date relaional.
Obiectele sesiune nu sunt persistente prin definiie, ns ele pot conine informaii care trebuie s fie persistente. n
acest caz, obiectele sesiune pot s implementeze singure operaiile necesare, direct n bean-ul enterprise. Obiectele
sesiune pstreaz de multe ori informaii din baza de date ntr-un cache local, date care trebuie sincronizate cu baza

de date n momentul n care o tranzacie este nceput, terminat sau anulat. Pentru a rezolva aceast problem,
proiectanii de bean-uri pot s implementeze direct n EBJ metode pentru tranzacii sincronizate, folosind interfaa
opional SessionSynchronization. Evenimentele afterBegin, beforeCompletion i afterCompletion generate de ctre
server permit obiectelor s scrie sau s citeasc la nevoie date n i din baza de date.
Administrarea tranzaciilor. Cu toate c tehnologia Enterprise JavaBeans poate fi folosit pentru a implementa
sisteme netranzacionale, modelul a fost conceput astfel nct s suporte tranzacii distribuite.
Specificaia Enterprise JavaBeans sugereaz, dar nu impune, folosirea tranzaciilor folosind API-ul Java
Transaction Service (JTS). JTS suport tranzacii distribuite peste baze de date multiple, pe sisteme multiple
coordonate de ctre manageri multipli de tranzacii. Folosind JTS, un server Enterprise JavaBeans asigur faptul c
tranzaciile pot avea loc i folosind mai multe servere EJB.
Aplicaiile Enterprise JavaBeans comunic cu un serviciu de tranzacii folosind API-ul Java Transaction API (JTA).
JTA furnizeaz o interfa de programare pentru a lansa o tranzacie, pentru a intra ntr-o tranzacie, pentru a termina
o tranzacie sau pentru anula o tranzacie.
Cu toate c separarea tranzaciilor ntr-o aplicaie centralizat este necesar, acest lucru devine mai dificil cnd
aplicaia este format dintr-un numr variabil de componente, care mai i interopereaz ntre ele. Tehnologia
Enterprise JavaBeans simplific n mod sensibil dezvoltarea aplicaiilor prin folosirea automat a tranzaciilor
distribuite. Toate funciile relative la tranzacii sunt executate implicit de ctre containerul i serverul EJB. Beanurile enterprise nu trebuie s-i fac demarcaii speciale n cod pentru efectuarea tranzaciilor. Deoarece codul surs
al EJB-ului nu trebuie modificat pentru a suporta tranzacii, scrierea unui bean se simplific mult i acesta devine n
acelai timp portabil, putnd fi folosit de ctre mai muli manageri de tranzacii.
Semantica tranzaciilor pentru un EJB este definit declarativ i nu nglobat direct n codul surs al bean-ului. n
timpul execuiei, containerul EJB implementeaz automat serviciile de tranzacii necesare, n funcie de atributul
TransactionAttribute definit n obiectul descriptor.
Securitatea. Modelul Enterprise JavaBeans utilizeaz serviciile de securitate ale platformei Java. Securitatea
platformei Java suport autentificarea i autorizarea pentru a restriciona accesul la obiecte i metode sigure.
Tehnologia Enterprise JavaBeans folosete automat securitatea platformei Java, deci bean-urile enterprise nu au
nevoie s apeleze n mod explicit rutine de securitate Java. Regulile de securitate pentru fiecare bean n parte sunt
definite declarativ, ntr-un set de obiecte AccessControlEntry n cadrul obiectului descriptor. Un obiect
AccessControlEntry asociaz o metod cu o list de utilizatori ce au drepturi pentru a invoca metoda. Containerul
EJB folosete clasa AccessControlEntry pentru a efectua n mod automat verificrile de securitate.
Viitorul pentru EJB
Specificaia EJB are potenialul de a deveni calea n care se vor realiza sisteme distribuite n urmtorii ani. Cu toate
c este o tehnologie foarte tnr, este una dintre cele mai flexibile i moderne tehnologii de dezvoltare a aplicaiilor
distribuite, fiind adoptat de o serie de firme puternice, cum ar fi IBM, Oracle, NovaSoft Novation, Athena Design
Integer.
Enterprise JavaBeans este nc o tehnologie foarte tnra, aa c mai are lipsuri i mai are mult pn la maturizare.
Cu certitudine ns este o tehnologie care merit urmrit i studiat cu atenie, deoarece are anse foarte mari de a
se impune ca un standard de realizare a aplicaiilor distribuite i portabile.