Introducere in tehnologia Enterprise JavaBeans (EJB)

Introducere în tehnologia Enterprise JavaBeans (EJB)

2.3.1. Enterprise JavaBeans (EJB) privita din perspectiva obiectelor de business

Într-o aplicatie J2EE multi tier, Middle Tier este divizat în doua alte subtiers: Web Tier si Enterprise JavaBeans Tier. Web Tier este cel care gazduieste componentele Web (pagini JSP si servlets). Enterprise JavaBeans Tier este cel care gazduieste componentele enterprise, cele care contin logica de business, serviciile la nivel de sistem ca si managementul tranzactiilor, controlul concurentei si securitatea. Tehnologia Enterprise JavaBeans furnizeaza un model de componenta distribuita, care permite utilizatorilor sa se focalizeze pe rezolvarea problemelor de business, iar restul de probleme la nivel de sistem sunt lasate în seama platformei J2EE. Aceasta separare de roluri permite dezvoltarea rapida a unor aplicatii scalabile, accesibile si foarte sigure. În modelul de programare J2EE, componentele Enterprise JavaBeans constituie legatura fundamentala dintre componentele gazduite de Web Tier si datele sau sistemele critice aflate în Enterprise Information Tier.

Probabil ca termenul care înca a ramas pâna acum o necunoscuta si fara de care nu poate fi înteles rolul EJB, este logica de business (Business Logic). O definitie ar putea fi aceasta: "Logica de business, într-un sens foarte larg, este un set de reguli utilizate pentru a realiza o anume functie de business (functie necesara pentru întreprindere)". (Blueprints, 2000)

Folosind o abordare obiectuala, utilizatorul poate sa descompuna o functie de business într-un set de componente numite business objects (obiecte de business).Ca orice alte obiecte, aceste obiecte de business vor avea caracteristici (stare sau date) si comportare. De exemplu, un obiect de tipul angajat va avea date ca nume, prenume, adresa, data angajarii, data nasterii etc. Va avea, însa, si metode de asignare la un nou departament sau de schimbare a salariului cu un anume procentaj. Pentru a rezolva aceasta problema de business, va trebui sa reprezentam modul de functionare al acestor obiecte si de interactiune între ele pentru a obtine functionalitatea dorita. Regulile de business specifice, care ne ajuta în a identifica structura si comportamentul acestor obiecte de business, împreuna cu pre conditiile si post conditiile care trebuie sa fie îndeplinite atunci când obiectul îsi expune comportarea celorlalte obiecte din sistem, poarta numele de logica de business.

2.3.2. Cerintele generale impuse obiectelor de business

Prima cerinta impusa unui obiect de business este de a mentine starea reprezentata de variabilele instantiate între apelurile metodelor. Starea poate fi conversationala sau persistenta.

Pentru a întelege starea conversationala, se considera exemplul unui cos de cumparaturi virtual. Starea cosului este reprezentata de lucrurile luate si cantitatea lor. Cosul este initial gol si va avea vreo stare care sa însemne ceva atunci când cumparatorul (evident si el virtual) va adauga ceva în el. Atunci când cumparatorul adauga un alt lucru în cos, el va trebui sa contina ambele lucruri. La fel, atunci când sterge ceva din cos, acesta trebuie sa reflecte schimbarea din starea sa. Atunci când utilizatorul paraseste aplicatia, obiectul cos trebuie sa fie reinitializat. Atunci când un obiect câstiga, mentine si apoi îsi pierde starea ca rezultat al interactiunilor repetate cu acelasi client, se spune ca obiectul îsi mentine starea conversationala.

Pentru a întelege starea persistenta, se va lua exemplul unui cont într-o aplicatie. Atunci când utilizatorul creeaza un cont, informatia trebuie sa fie stocata permanent, pentru ca, atunci când utilizatorul paraseste aplicatia si apoi reintra, sa poata regasi informatia legata de contul sau. Starea unui obiect cont trebuie sa fie mentinuta pe un mediu persistent, pe o baza de date. În mod obisnuit, obiectele de business care opereaza asupra datelor care nu sunt legate de sesiunea cu clientul, vor prezenta stare persistenta.

O alta cerinta pe care trebuie sa o îndeplineasca obiectele de business este sa opereze asupra unor date partajate. În acest caz, trebuie luate masuri pentru a avea control concurent si diferite nivele de izolare a datelor partajate. Un exemplu este situatia când mai multi utilizatori modifica aceleasi informatii concomitent.

Una dintre cele mai importante cerinte impuse obiectelor de business este sa poata participa în tranzactii. Mai întâi însa, ar trebui sa definim termenul de tranzactie. O tranzactie este un set de taskuri care trebuie executate ori toate împreuna, ori nici unul. Daca unul dintre taskuri nu este executat, toate taskurile vor fi rolled back (derulate înapoi) si se revine la starea din care s-a plecat înainte de executarea primului task. Daca, însa, reusesc toate taskurile, atunci se spune ca tranzactia este committed (realizata) si se salveaza noua stare.

Obiectele de business trebuie sa participe în tranzactii. De exemplu, realizarea unei comenzi de materiale la o firma trebuie sa fie tranzactionala, deoarece exista un set de taskuri care este necesar sa fie realizate pentru ca respectiva comanda sa reuseasca (decrementarea cantitatii de produse ce au mai ramas în magazie, stocarea detaliilor comenzii, trimiterea unei confirmari de preluare a comenzii la clientul solicitant ). Daca oricare dintre aceste taskuri nu reuseste atunci modificarile realizate de taskurile anterioare devin incorecte, motiv pentru care trebuie sa fie derulate înapoi.

În multe operatii de business, tranzactiile se pot întinde pe mai mult de o sursa de date distanta. Asemenea tranzactii, denumite tranzactii distribuite, au nevoie de protocoale speciale pentru a asigura integritatea datelor.

O alta cerinta importanta, care se impune obiectelor de business, este sa deserveasca un numar mare de clienti în acelasi timp. Aceasta se traduce în necesitatea, de exemplu, de a se utiliza algoritmi care vor da fiecarui client impresia ca un anume obiect de business dedicat este disponibil sa-i execute cererea. Fara un asemenea mecanism, sistemul ar putea sa se blocheze, deci nu va mai fi capabil sa serveasca alti clienti.

Este necesar, de asemenea, ca EJB sa furnizeze acces distant la date. Un client trebuie sa fie capabil sa acceseze de la distanta serviciile oferite de un anume obiect de business. Aceasta înseamna ca obiectul de business ar trebui sa aiba o infrastructura care sa-i permita sa deserveasca clientii prin retea. Aceasta, în schimb, implica faptul ca un obiect de business trebuie sa fie parte dintr-un mediu distribuit, care sa se ocupe de chestiuni fundamentale legate de sistemele distribuite, ca de exemplu localizarea.

O alta cerinta ce se impune obiectelor de business este controlul accesului. Serviciile oferite de obiectele de business de multe ori necesita un mecanism de autentificare si de autorizare pentru a permite unui anume set de clienti sa acceseze serviciile protejate. De exemplu, un obiect de business care reprezinta contul bancar al unui client trebuie neaparat sa faca autentificarea clientului, înainte de a permite clientului sa modifice informatia din contul bancar. În multe scenarii de aplicatii enterprise, sunt necesare mai multe nivele de control al accesului. De exemplu, oricarui angajat i se permite doar sa poata citi datele din obiectele de business de tip salariu, pe când unui administrator al departamentului economic i se permite si sa modifice obiectele de tip salariu.

Ultima, dar nu cea mai neînsemnata cerinta ce se impune obiectelor de business, este ca trebuie sa poata fi reutilizate în acea aplicatie de la o versiune la alta a ei sau de catre alte aplicatii. De exemplu, o aplicatie a departamentului de contabilitate poate sa stocheze datele referitoare la salariile angajatilor folosind doua obiecte : angajat si salariu. Obiectul de business de tip angajat va utiliza obiectul de business de tip salariu pentru a afla care este valoarea salariului acelui angajat. O aplicatie care va gestiona posibilitatile de a pleca în concediu ale angajatilor va utiliza obiectul de tip angajat pentru a obtine numele si prenumele angajatului. Pentru ca obiectele de business sa fie componente utilizabile inter si intra aplicatii, ele au nevoie sa fie dezvoltate în maniera standard si sa ruleze în medii unde se dispun tot de facilitati standard. Daca standardele sunt bine definite si acceptate pe piata, atunci se va ajunge la realizarea de aplicatii, folosind componente cumparate de la mai multi providers, iar munca necesara va fi doar de asamblare a diferitelor componente în cadrul aplicatiei. Aceasta va permite dezvoltarea foarte rapida a aplicatiilor.

2.3.3. Enterprise JavaBeans ca obiecte de business

Obiectele de business furnizeaza clientilor unele servicii generice, ca de exemplu suport pentru tranzactii, securitate si acces la distanta. Aceste servicii comune sunt, de fapt, în natura lor, foarte complicate, dar sunt implementate la nivel de platforma, iar utilizatorul nu trebuie sa implementeze nimic pentru a dispune de acele servicii. Pentru a simplifica dezvoltarea aplicatiilor enterprise, componentele au nevoie de o infrastructura standard de partea serverului care sa le furnizeze serviciile.

EJB Tier, din platforma standard J2EE, furnizeaza un model de componenta distribuita standard de partea serverului, care simplifica mult taskul de a scrie logica de business. În arhitectura EJB, expertii sistemului furnizeaza un cadru pentru a oferi servicii la nivel de sistem, iar expertii în domeniul aplicatiei vor furniza componente care vor contine doar informatii legate de partea de business a aplicatiei. Platforma J2EE permite programatorilor enterprise sa se concentreze pe rezolvarea problemelor întreprinderii, în loc sa se lupte cu probleme de nivel de sistem.

Pentru a utiliza serviciile furnizate de platforma J2EE, obiectele de business sunt implementate ca si componente EJB sau enterprise beans. Exista doua tipuri majore de enterprise beans: entity beans si session beans. Session beans sunt destinate sa fie resurse private, folosite doar de clientii care le-au creat. Din acest motiv, session beans, privite din perspectiva clientului, apar ca anonime. În contrast, fiecare entity bean are o identitate unica, care este expusa sub forma de cheie primara.

În plus fata de componentele enterprise beans, arhitectura EJB defineste alte trei entitati: servere, containere, si clienti. Enterprise JavaBeans traiesc în interiorul unor containere EJB care furnizeaza o multime de servicii, inclusiv gestiunea ciclului de viata. Un container EJB este o parte a unui server EJB care furnizeaza serviciile de naming and directory, email, tranzactii, securitate, etc. Atunci când un client invoca o operatie asupra unei enterprise bean, apelul este interceptat de catre container. Prin intercalarea containerului între client si componente la nivelul apelului, containerul poate realiza servicii care se propaga dincolo de apelurile metodelor componentelor si chiar dincolo de containerele care functioneaza pe diferite servere sau pe masini diferite. Acest mecanism simplifica dezvoltarea atât a aplicatiilor, cât si a clientilor.

2.3.4. Enterprise Beans si containerele EJB

Arhitectura EJB înzestreaza enterprise beans si containerele EJB cu multe trasaturi unice care vor permite portabilitatea si reutilizarea:

Instantele enterprise beans sunt create si gestionate de catre container la runtime. Daca un enterprise bean foloseste doar servicii definite în specificatiile EJB, atunci acel enterprise bean poate fi utilizat în cadrul oricarui container care respecta standardul EJB. Containere specializate pot furniza servicii aditionale fata de cele specificate în specificatia EJB. Un enterprise bean care depinde de asemenea servicii poate fi utilizat în cadrul oricarui container care furnizeaza acele servicii.

Comportarea unui enterprise bean nu este continuta în totalitate în implementarea sa. Serviciul de tranzactii si serviciul de securitate sunt separate de implementarea enterprise bean. Aceasta permite ca serviciile acestea sa fie configurate la deployment (faza în care se adapteaza aplicatia la platforma si se configureaza anumiti descriptori utilizati de platforma). Aceasta face posibila includerea de enterprise beans într-o aplicatie gata asamblata, fara a fi necesara modificarea codului sursa sau recompilarea.

Providerul de componente defineste o vedere a clientului asupra enterprise beans. Aceasta vedere a clientului asupra enterprise beans nu este afectata în nici un fel de container sau de serverul în care aplicatia este plasata. Aceasta asigura ca atât enterprise beans, cât si clientii lor pot fi plasati în mai multe medii de executie, fara a necesita recompilare. Perspectiva clientului asupra unei enterprise bean este concretizata în doua interfete. Aceste interfete sunt implementate prin clase construite de catre container la deployment - ul bean - ului, bazat pe informatiile furnizate de catre bean. Tocmai prin implementarea acestor interfete, se realizeaza intercalarea containerului între componenta si clientul ei la apelul de functii.

Cele doua interfete care trebuie implementate se numesc Home si Remote interfaces, iar componenta este clasa enterprise bean. Acestea trei vor fi detaliate în continuare.

2.3.5 Alcatuirea unui Enterprise JavaBean

2.3.5.1. Clasa Enterprise Bean

Clasa Enterprise Bean contine detaliile de implementare ale componentei. In aceasta clasa sunt, de fapt, implementate metodele de business ale bean - ului. Aceasta este o clasa Java obisnuita, care se conformeaza unei interfete bine definite si respecta anumite reguli. Aceasta clasa trebuie sa implementeze interfata javax.ejb.EntityBean, daca componenta este de tipul entity bean sau javax.ejb.SessionBean, daca este de tipul session bean.

Orice trebuie sa implementeze interfata javax.ejb.EnterpriseBean, deoarece ambele interfete de mai sus o extind pe aceasta. Interfata aceasta este prezentata în continuare. Aceasta interfata are rolul de a arata ca respectiva clasa care o implementeaza este un enterprise bean. Interesant este ca ea extinde java.io.Serializable, aceasta însemnând ca orice enterprise bean poate fi serializat, adica poate fi stocat si transmis prin retea ca un sir de biti din care poate fi refacut.

2.3.5.2. EJB Object

Atunci când un client doreste sa foloseasca o instanta a unei clase enterprise bean, el nu va invoca niciodata în mod direct instanta clasei, ci apelul este interceptat de containerul EJB si este delegat apoi instantei clasei enterprise bean. Aceasta se face în acest fel din mai multe motive:

Clasa enterprise bean nu poate fi invocata direct prin retea, deoarece ea nu este prevazuta cu mecanisme de acces la retea. Containerul EJB este cel care se ocupa de interactiunea cu reteaua, înfasurând clasa bean cu un obiect care este prevazut cu mecanisme de acces la retea (network enabled). Acest obiect network enabled primeste apelurile de la clienti si le deleaga instantei clasei enterprise bean. Din acest motiv, programatorul nu trebuie sa se mai preocupe de legarea la retea si sa scrie cod RMI sau RMI-IIOP. Serviciul de networking este pus la dispozitie de catre container.

Prin interceptarea cererilor containerul EJB poate realiza în mod automat unele operati de management cum ar fi: tranzactiile, securitatea, implementarea mecanismului de pooling s.a.

Figura 2.15. Obiectul EJB si apelul unei metode a Enterprise Bean

Astfel, containerul EJB actioneaza ca un indirection layer (nivel de redirectare) între codul clientului si bean. Acest nivel se concretizeaza într-un singur obiect, care dispune de mecanisme de acces la retea si este denumit EJB object. Obiectul EJB este un obiect inteligent care, în plus, este capabil de tranzactii, securitate si realizarea logicii intermediare pe care o necesita containerul EJB înainte de a realiza apelul metodelor obiectului enterprise bean. Un obiect EJB actioneaza ca o punte între client si bean si expune fiecare metoda pe care o pune la dispozitie obiectul enterprise bean. Obiectele EJB deleaga toate cererile clientului la obiectele enterprise beans.

2.3.5.3. Remote interface

Asa cum s-a mentionat mai devreme, clientii unui bean invoca metode asupra obiectelor EJB si nu asupra obiectelor enterprise beans. Pentru ca sa realizeze aceasta, obiectele EJB trebuie sa cloneze fiecare metoda pe care o expune bean - ul si sa o expuna si el. Dar de unde stiu uneltele care genereaza automat obiectele EJB ce metode sa cloneze? Raspunsul este ca exista o interfata speciala pe care programatorul trebuie sa o scrie, în care se specifica metodele pe care le expune enterprise bean - ul. Aceasta interfata este denumita Remote interface.

Interfetele Remote trebuie sa respecte anumite reguli pe care le defineste specificarea EJB. De exemplu, fiecare interfata Remote extinde interfata javax.ejb.EJBObject pusa la dispozitie de Sun Microsystems. Explicarea metodelor din aceasta interfata se poate observa în Tabelul 2.1.

Pe lânga aceste metode din Tabelul 2.1., interfata Remote trebuie sa contina si metodele de business ale bean - ului. Codul clientului care doreste sa lucreze cu enterprise bean - ul va lucra, de fapt, cu un obiect ce implementeaza interfata javax.ejb.EJBObject.

Tabelul 2.1. Metodele pe care trebuie sa le expuna toate obiectele EJB

2.3.5.4. Home Object

Dupa cum s-a vazut deja, codul clientului acceseaza obiecte EJB si nu ajunge niciodata sa acceseze direct bean - urile. Urmatoarea întrebare logica este cum obtin atunci clientii referinte la obiectele EJB?

Clientul nu poate instantia direct un obiect EJB, deoarece obiectele EJB s-ar putea sa se afle pe alta masina decât cea pe care se afla clientul. Pe de alta parte, tehnologia EJB propune transparenta fata de locul unde se afla obiectele EJB, astfel încât clientii sa nu fie nevoiti sa stie unde rezida obiectele EJB.

Pentru a obtine o referinta la un obiect EJB, clientul este nevoit sa îl solicite de la un EJB object factory. Aceast object factory este responsabil de instantierea si distrugerea obiectelor EJB. În specificarea EJB, acest object factory este denumit home object. Îndatoririle cele mai importante ale obiectelor home sunt urmatoarele:

Sa creeze obiecte EJB

Sa permita gasirea obiectelor EJB existente (aceasta se întâlneste la entity beans si va deveni mai clar în curând)

Sa stearga obiectele EJB

La fel ca obiectele EJB, obiectele home sunt specifice fiecarui container, fac parte din acesta si sunt generate folosind uneltele specifice acelui container.

2.3.5.5. Home Interface

Acum ca s-a vazut ca obiectul Home este factory pentru obiectul EJB, se pune întrebarea de unde stie obiectul Home cum sa initializeze obiectul EJB ? De exemplu, un obiect EJB s-ar putea sa expuna o metoda de initializare care primeste un întreg ca parametru, în vreme ce alt obiect EJB s-ar putea sa ia un String. Containerul are nevoie sa cunoasca aceste informatii pentru a genera obiectele home. Aceste infrmatii sunt furnizate containerului prin intermediul home interface. Interfetele home definesc metode de creare, distrugere si gasire a obiectelor EJB. Obiectul Home a containerului implementeaza interfata home specificata de programator. Aceasta se poate observa si în Figura 2.16.

Figura 2.16. Obiectul Home

Specificatia EJB defineste câteva metode pe care trebuie sa le suporte orice interfata home. Aceste metode sunt definite de interfata javax.ejb.EJBHome pe care toate interfetele trebuie sa o extinda. Continutul acestei interfete este:

Se poate observa ca javax.ejb.EJBHome deriva din java.rmi.Remote. Aceasta înseamna ca home objects sunt prevazute cu posibilitati de acces la retea, folosind Java RMI care poate realiza comunicarea între masini virtuale diferite. De aceea, tipurile parametrilor metodelor specificate în home interface trebuie sa fie valide pentru Java RMI. De fapt, este suficient sa implementeze interfata java.io.Serializable.

2.3.5.6. Deployment descriptors

Deployment descriptors permit containerelor sa furnizeze middleware services pentru componentele EJB. Un middleware service este un serviciu de care bean - urile pot beneficia în mod automat, fara ca programatorul sa fie nevoit sa scrie cod.

Pentru ca sa poata fi informat containerul de serviciile de care are nevoie componenta, trebuie sa se specifice cererile de middleware services în fisierul deployment descriptor. De exemplu, se poate utiliza un deployment descriptor pentru a specifica cum trebuie sa gestioneze containerul ciclul de viata, persistenta, controlul tranzactiilor, serviciile de securitate. Containerul va utiliza acesti descriptori pentru a configura serviciile dorite.

În specificarea EJB 1.0, un deployment descriptor este un obiect serializabil. Crearea deployment descriptors este automatizata de catre EJB container tools sau Java Development Environment tools. De exemplu, s-ar putea ca într-un IDE sa se parcurga pur si simplu un wizard cu câteva întrebari, iar apoi IDE sa genereze singur deployment descriptor. Din acest motiv, nici nu vom insista pe acesti descriptori. Ceea ce trebuie retinut este ca, pentru a beneficia de un serviciu middleware de la platforma J2EE, este nevoie ca acesta sa fie configurat corespunzator. Aceasta configurare se poate face usor folosind uneltele puse la dispozitie de server, container sau IDE.

2.3.6 Tipuri de Enterprise JavaBeans

Specificarile EJB 1.0 si EJB 1.1 definesc doua tipuri diferite de enterprise beans: session beans si entity beans.

Session beans sunt componente care au durata de viata egala cu cea a sesiunii cu clientul care o utilizeaza. De exemplu, daca un client contacteaza un session bean pentru a realiza functia de bussiness de introducere a unei noi comenzi, serverul EJB este responsabil de crearea unei instante a acelei componente session bean. Atunci când clientul se va deconecta, serverul EJB va distruge acea instanta a session bean - ului. Session beans sunt utilizabile de catre un singur client la un moment dat, cu alte cuvinte session beans nu sunt partajate de mai multi clienti.

La rândul lor, session beans sunt de doua tipuri: statefull session beans si stateless session beans.

Un statefull session bean este proiectat sa deserveasca procese de business care se întind pe mai multe apeluri de metode sau chiar tranzactii. Pentru a realiza aceasta, statefull session beans vor mentine starea de partea clientului. Daca starea unui statefull session bean se modifica în timpul apelului unei metode, aceeasi stare va fi disponibila clientului la urmatorul apel de metoda.

Un exemplu de statefull session bean este cazul unui magazin pe Web. Pe masura ce clientul se "plimba" prin magazin, va adauga produse în cosul de produse, va scoate unele si va pune altele etc. Acesta este un exemplu de proces de business care se întinde pe durata mai multor apeluri de metode. Componenta cos de produse trebuie sa îsi pastreze ultima stare de la un apel de metoda la altul, de aceea ea va fi modelata ca session bean.

Unele procese de business, în mod natural, pot fi modelate dupa paradigma unei singure cereri. În cadrul unui asemenea proces, nu este nevoie ca sa se pastraze starea de la un apel de metoda la altul. Aceste procese sunt modelate cu stateless session beans. Acestea sunt furnizori anonimi de metode, deoarece nu cunosc istoria clientului.

Un exemplu de stateless session bean este cel al unei componente care realizeaza operatii matematice complexe asupra intrarii, ca de exemplu compresia datelor audio sau video. Clientul poate furniza datelele necomprimate într-un buffer, împreuna cu factorul de compresie dorit. Componenta va realiza compresia si va returna tot un buffer, dar cu datele comprimate. Dupa aceasta, componenta poate deservi si orice alt client, deoarece nu are nevoie sa retina nici un fel de date referitoare la clientul pe care tocmai l-a deservit, cu alte cuvinte nu are nevoie sa retina informatii legate de starea clientului.

Entity beans sunt componente care reprezinta date persistente, ca de exemplu conturi bancare, stocuri, etc. Datele prezentate de entity beans sunt, de obicei, stocate în baze de date. Entity beans sunt utilizate pentru a modela datele si nu sunt proiectate pentru a contine logica de business. Session beans sunt cele care vor realiza logica de business. Entity beans furnizeaza o vedere obiectuala asupra datelor aflate într-un mediu de stocare, ca de exemplu o baza de date. Metoda traditionala, în care aplicatiile manipuleaza datele, este de a citi si scrie dupa nevoie datele din tabelele unei baze de date relationale. Entity beans sunt o reprezentare obiectuala a acestor date.

Un exemplu de entity bean ar putea fi cel al unui cont bancar. Toate datele din baza de date care tin de contul bancar al unui anume client sunt reprezentate de un entity bean. Acest bean poate fi manipulat prin apelul metodelor pe care le expune. De exemplu, se poate realiza operatia de retragere de numerar folosind metoda withdraw(), care va modifica o variabila numita balance (sold). Când se solicita bean - ului sa stocheze datele în baza de date, se va realiza modificarea si în tabelele bazei de date, astfel încât aceasta sa contina noul sold.

Deoarece entity bean modeleaza date permanente, ele au o durata mare de viata. Ele supravietuiesc în cazul unor caderi majore, ca de exemplu caderea serverului sau defectarea unei masini, datorita faptului ca pot fi reconstruite prin simpla citire a datelor din baza de date. Deoarece baza de date supravietuieste caderilor, si aceste componente vor supravietui. Aceasta este cea mai mare diferenta între session beans si entity beans. Entity beans au un ciclu de viata mult mai mare decât durata session beans, deoarece session beans au durata de viata egala cu durata sesiunii cu clientul, pe când entity beans pot dura ani de zile, durata lor de viata fiind egala cu cea a datelor pe care le reprezinta din baza de date.

O alta diferenta majora între entity beans si session beans este ca entity beans pot fi utilizate de mai multi clienti în mod simultan. Cu alte cuvinte, mai multi clienti pot manipula datele din baza de date simultan. Aceasta se realizeaza prin intermediul tranzactiilor, aspect care va deveni mai clar în subcapitolele care urmeaza.