Referat Interfata Javax
Mai jos puteti citi fragmente din
Referat Interfata Javax si de asemenea puteti face
Download Referat Interfata javaxCiteste fragmente din Referat Interfata Javax
nu este plasata metoda ejbCreate() in interfata
javax.ejb.SessionBean.Trebuie oservat ca este necesara implementarea a
cel putin o metoda ejbCreate() in session bean pentru ca sa existe cel
putin o metoda de initializare a bean-ului.
Metoda ejbCreate() implementata in codul bean-ului trebuie sa
realizeze toate initializarile de care are acesta nevoie,ca de exemplu
setarea variabilelor membru cu valorile primite prni apelul
metodei.Aceasta reiese din exemplul 2.1
Exemplu 2.1. O metoda ejbCreate
Import java.ejb.* ;
public class FirstBean implements SessionBean {
private int memberVariable ;
public void ejbCreate(int initailValue) {
this.memberVariable = initialValue ;
}
…
}
Metodele de tipul ejbCreate() sunt invocate de container si
niciodata direct de clienti.Dar clientii trebuie sa dispuna de metode de
atrmite parametrii la metodele ejbCreate() fiindca ei sunt aceia care
furnizeaza valorile de initializare.
Interfata home este cea pe care o apeleaza clientii la initializarea
bean-ului.Din acest motiv,trebuie ca fiecare metoda de tipul ejbCreate()
din bean sa aiba un corespondent in interfata home.
De exemplu,daca in cadrul bean-ului este declarata metoda:
Public void ejbCreate() ( int I )
trebuie sa fie pusa in interfata Home urmatoarea metoda:
public void create ( int I )
Trebuie observat ca in interfata Home nu mai apare prefixul
,,ejb’’.Cand un cleint apeleaza metoda create(int I) asupra
interfetei Home,parametrii sunt pasati metodei ejbCreate() din bean.
Metoda ejbPassive este apelata de cantainer atunci cand sunt
instantiate prea multe bean-uri si apare pericolul de a a avea putine
resurse.Cand se ajunge in aceasta stare,containerul poate pasiva
(passivate) unele dintre bean-uri,in sensul ca le salveaza temporar
intr-un mediu de stocare,ca de exemplu o baza de date sau un sistem de
fisiere.Aceasta este posibila datorita faptului ca bean-urile
suntserializabile.Inainte de pasivizare,containerul apeleaza metoda
ejbPassivate () ,astfel anuntand bean-ul sa elibereze orice resurse
sistem pe care le detine,ca de exemplu socket-urisau conexiuni la baze
de date.Observati exemplul 2.2
Exemplul 2.2. O metoda ejbPassive
Import java.ejb.* ;
Public class FirstBean implements SessionBean {
Public void ejbPassive() {
}
…
}
De remarcat ca in cazul stateless session beans nu se
aplica pasivizarea,pentru ca aceste bean-uri nu pasteraza starea si pot
fi create/distruse pur si simplu.neffind cencesar mecanismus de
activare/pasivizare.
Atunci cand un client are nevoie sa utilizeze un bean
care a fost pasivizat,apare procesul invers: containeruladuce bean-ul
din mediul de stocare inapoi in memorie si apoi il activeaza.Imediat ce
bean-ul a fost activat,acesta va apela metoda ejbActivate() la apelul
careia bean-ul obtine toate resursele de care are nevoie.Aceste resurse
sunt,de obicei ,cele care au fost eliberate la pasivizare .Un exemplu
pentru activarea unuei bean este exemplul 2.3
Exemplu 2.3. O metoda ejbActive
import javax.ejb.* ;
public class FirstBean implemets SessionBean
public void ejbActive{}{
}
…
}
Ca si in cazul pasivizarii , nu este necesara implementarea
mecanismului de activare pentru stateless session beans ,deoarece se
foloseste mecanismul de create/distrugere.
Atunci cand containerul este pe punctul de a distruge o
instanta a unui bean, el va apela metoda ejbRemove() a
bean-ului.ejbRemove este o metoda de a anunta bean-ul ca este pe punctul
de a fi distrus si de a-I permite sa-si incheie existenta asa cum
considera.Aceasta metoda este necesara pentru toate bean-urile si nu
primeste parametrii,motiv pentru care este doar un per bean ,spre
deosebire de ejbCreate() care sunt mai multe.Implementarea metodei
ejbCreate() trebuie sa pregateasca bean-ul pentru distrugere,eliberand
toate resursele pe care
le-a ocupat.Containerul poate apela metoda ejbRemove() in orice
moment,inclusiv in cazurile in care containerul decide ca timpul de
viata al bean-ului a expirat.
Pe langa metodele pe care le-am descris pana acum si care
sunt apelate doar de container pentru a gestiona bean-ul,mai exista
metode de business (business methods).Aceste metode sunt cele care
rezolva,de fapt, problemele de business,ca in exemplul 2.4
Exemplul 2.4. O metoda de business
import java.ejb.*;
public class FirstBean SessionBean
public int add (int i,int j){
return (i+j) ;
}
…
}
Pentru ca un client sa poata invoca o anume metoda de
business,aceasta
trebuie sa fie declarata in interfata Remote.
2.4.3 Cum se utilizeaza un session bean
Privind si din partea clientului,acesta incearca sa rezolve
probleme concrete prin utilizarea unuia sau mai multor beans.Un client
trebuie sa urmeze mai multi pasi in rezolvarea unei probleme,folosind un
bean.In primul rand el trebuie sa obtina obiectul Home,apoi sa creeze un
obiect EJB,sa apeleze ce metode are nevoie folosind interfata Remote si
la urma sa il distruga.
2.4.3.1 Obtinerea obiectivului Home
Pentru a obtine obiectul Home ,trebuie ca, in codul
clientului,sa se utilizeze Java Naming and Directory Interface (JNDI)
Im proiectarea J2EE, s-a avut in vedere transparenta locatiei (location
transparency).Aceats inseamna ca modul in care este scrios codulnu
trebuie sa depinda de modul in care sunt distribuite bean-urile pe
nivele (tiers)sau pe ce masini sunt acestea plasate.Aceasta
transparenta este castigata prin intermediul serviciului de naming and
directory.Acest serviciu are rolul de a stoca si gasi resurse in
retea.Exemple de servicii de naming and rirectory sunt Active Directory
de la Microsoft sau Lotus de la IBM.
Im mod traditional , corporatiile au folosit serviciile de
directory pentru a stoca numeleutilizatorilor si parolele,locatia unde
gasesc masinile sau imprimantele etc.
Produsele J2EE exploateaza serviciile de directory pentru a stoca
informatii in legatura cu rsursele pe care aplicatia le foloseste.Aceste
resurse pot fi obiecte EJB,proprietati ale mediului enterprise bean,
drivere de baze de date sau orice alte resurse ce folosesc
bean-ul.Acestea toate fac codul EJB independent de configuratia
resurselor ,fiindca mai tarziu ,daca una dintre resurse este mutata nu
este nevoie sa se efectueze vreo modificare in cod,pentru ca se
poate,pur si simplu modificarea directory service ca sa arate noua
locatie a resurselor .Aceasta trasatura ,transparenta locatiei,este
foarte importanta atunci cand se fac modificari in privinta locatiei
resrselor ,dar este necesara mai ales cand se cumpara componente gata
realizate.
Pentru a putea gasi o resursa n cazul unei aplizatii J2EE,este
necesara parcurgerea a doi pasi.:
fiecareiresurse sa I se asocieze un identificator,iar containerul va
asocia identificatorul cu resursa;
clientii vor folosi identificatorul asociat resursei di JNDI pentru a
gasi resursa respectiva
Pentru a avea transparenta locatiei in cazul obiectelor Home,
containerele EJB mascheaza locatia efectiva a obiectelor Home in codul
clientului.Clientii nu vor utiliza numele masinii pe care rezida
obiectele ,ci vor utiliza serviciile JNDI pentru a gasi acele obiecte
.Obiectele Home sun localizate undeva pe retea cel care dezvolta un
bean nu se preocupa ed locatia ce o va avea bean-ul.
Pentru ca utilizatorii sa poata localiza un obiect Home
,acesta trebuie sa aiba un identificator pe care containerul il va
asocia,in mod automat cu obiectul Home.
De exemplu,pentru un bean numit FirstBean se poate specifica un
identificator ,,firstBeanIdentifâ€Â.Acesta va fi asociat automat de
container pentru obiectul Home al bean-ului.In spatele scenelor,JNDI
cauta,in cadrul mai multor directory services,obiectul Home care are
asociart acel identificator.Daca obiectul Home este gasit,se va returna
clientului o referinta la el.
In cazul aplicatiilor,contextul initial (obiectul de tip
InitialContext),care este furnizat de container cand apeleaza metoda
bean-ului setinitialContext() ,dispune de toate configurarile necesare
pentru a beneficia deserviciul de naming and directory.Pentru a gasi
interfata Home a bean-lui,folosind contextul initial,nu este necesar
decat apelul metodei lookup.
In exemplul 2.5 s-a obtinut o referinta la obiectul Home al
bean-ului de tipul FirstBeancu identificatorul ,,firstBeanIdentif†in
interiorul bean-ului SecondBean.
Exemplul 2.5. Utilizarea unui bean in cadrul altui bean
Import javax.ejb*;
Public class SecondBean implements SessionBean {
InitailContext second Ctx
//set the initial context for SecondBean
public void setinitialContext(Initial Context ctx){
this.secondCtx = ctx ;
}
//a method that user other bean
named,,firstBeanIdentifâ€Â
public void businessMethod(){
//lookup for the home object of MyBean
FirstHome home = (First)
secondCtx.lookup(,,firstBeanIndetifâ€Â)
//create an EJB object
FirstRemote ejbObject = home.create () ;
//use a method of FirstBean
int result ejbObject.add (2,3);
//destory the bean instance
ejbObject.remnove ();
}
…
}
Creearea obiectului EJB
Dupa ce s-a obtinut obiectul Home ,acesta se poate folosi
pentru a crea obiecte EJB.Aceasta se face prin intermediul unei metode
de create expuse de obiectul Home (si bineteles ca aceasta este
implementata in codul bean-ului prin metoda ejbCreate() In cazul de
fata,FirstBean este de tipul stateless session bean
(aceasta se va specifica la deployment),deoarece stateless session bean
nu contin nici un fel de stare,nici nu primesc parametrii de
initializare.
2.4.3.3 Apelul unei metode
Obiectul EJB odata obtinut poate fi utilizat pentru a apela
metodele pe care bean-ul le expune prin intermediul acestui
obiect.Atunci cand un client apeleaza o metoda asupra obiectului
EJB,acesta trebuie sa aleaga o instanta de tipul bean-ului care sa duca
la indeplinire cererea.Obiectul EJB s-ar putea sa fie nevoit sa
instantieze un nou bean sau sa reutilizeze o instanta deja
existenta.Modul in care este implementat de pooling este lasat la
latitudinea constructorului containerului.
2.4.3.4. Distrugearea unui obiect EJB.
Ultimus pas este distrugerea obiectului EJB in momentul in
care acesta nu mia este necesar.Aceasta se realizeaza prin apelul
metodei remove() prevazuta in interfata sa.La apelul acestei metode se
anunta containerul ca obiectul poate fi distrus.Containerul poate sa-l
distruga literalmente din memorie sau poate sa-l “goleasca de
informatia ce o contine†si sa-l puna in pool (bazin),de unde va putea
fi luat si refolosit penru un alt client.Aceasta este,de
fapt,implementarea mecanismului de pooling pentru obiectele EJB si
care, ca si in cazul anterior,tine de constructorul containerului.
2.4.3.5. Exemplu de utilizare a unui bean
Un exemplu cat se poate de simplu,care ilustreaza toti pasii in
utilizarea unui bean discutati anterior,este exercitiul 2.5.Acesta
reprezinta utilizarea bean-lui FirstBean (descris in alta parte,atat cat
este nevoie in exemplele anterioare)pentru a aduna numarul 2 cu 3.Acesta
este utilizat in cadrul metodei denumita metoda 1 a altui bean denumit
SeconBean
La creearea bean-ului SecondBean containerul va furniza
contextul lui SecondBean prin apelul metodei acestuia
setinitialContext.Contextuleste salvat in variabila secondCtx.
In cadrul metodei businessMethod1 a bean-ului FirstBean se obtine o
referinta la obiectul Home al bean-ului de tipul FirstBean cu
identificatorul ,,firstBeanIndetif†folosind contextul initial al lui
SecondBean
Asupra obiectului Home se aplica metoda create pentru a obtine
obiectul EJB pentru bean-ul FirstBean.Dupa ce obiectul EJB este
obtinut,se apeleaza metoda add a acestuia pe care acetsa o expune.
Cand obiectul EJB pentru FirstBean nu mai este necesar,se
apeleaza metoda remove() pe care aecsta o expune ,comunicnad astfel
containerului ca obiectul poate fi distrus sau pus in bazin(pool)pentru
a implementa mecanismul de pooling.
Sinteza a tot ceea ce s-a spus despre utilizarea unui
session bean este prezentata in Figura 2.18.Aici sunt ilustrati toti
pasii care trebuie urmati,dar in cazul putin mai complex al apelului
unui bean din alta parte (nu din interiorul unui bean).Tot ce se
modifica in acest caz este faptul ca gasirea obiectului Home este putin
mai complicata, deoarece trebuie utilizat serviciul JNDI direct,nu prin
intermediul contextului initial care a usurat aceasta gasire in cazul
nostru.
2.2.4. Stateless Session Beans
Statsless session beans sunt, dupa cum s-a mai amintit mai sus bean-uri
care reprezinta logica de business a aplicatiilor,inca nu mentin o
conversatie cu clientul,deci datele despre client sunt utilizate doar pe
parcursul unui apel de metoda a acestuia.In continuare,sunt prezentate
alte caracteristici ale acestora.
2.4.4.1. Caracteristici particulare ale stateless session beans
Statsless session beans,desi au o stare interna nu mentin
nici o stare regata de un anume client,deci nus unt particularizate
pentru un anume client.Aceasta inseamna ca toate statsless session beans
apar ca fiind identice cand sunt privite de un anume client.Pentru ca
un statsless session beans sa poata fi utilizat de un client,acesta
trebuie sa trimita la apelul metodei toti parametrii necesari pentru
logica de business.Eventual bean-ul poate incarca date si dintr-o sursa
externa,ca de exemplu o baza de date.
Deoarece statsless session beans nu pot mentine starea de la
un apel al unei metode la alt apel al ei, nu sunt necesare mai multe
metode de ejbCreate(),ba chiar si singura metoda necesara nu primeste
niic un parametru.Aceasta in contrast cu statsless session beans care au
mai multe metode de create ,deoarece ele pot menitne starea de la un
apel de metoda la altul.Evident ca interfata Home va expune nmetoda
create() fara nici un parametru si sigur,fara prefixul ,,ejbâ€Â,dupa cum
a fost prezentat in paragrafele anterioare.
Statsless session beans permit implementrarea relativ usoara
a mecanismului de pooling in interiorul containerului.Aceste bean-uri
nu contin informatii legate de client,decat pe durata executiei metodei
cerute de acesta ,apoi nici macar nu mentin date cu privire la ce
client au deservit.Aceasta permite ca un bean sa deserveasca un
client,apoi sa poata fi reutilizat pentru alti clienti.Adica containerul
poate sa aleaga dinamic care bean sa-l foloseasca pentru apelul unei
metode venite de la un client.Castigul sta in faptul ca bazibul (pool)
poate fi mult mai mic decat numarul de clienti care se
conecteaza.Aceasta din cauza ca nu toti clientii care au nevoie de
servicii de la aceste beans tot timpul.In vreme ce clientul sta sa se
gandeasca ,containerul poare reutiliza unbean pentru a deservi orice alt
client si astfel se consuma mai putine resurse.Oricum,deci
interesante,aceste mecanisme sunt lasate pe seama constructorului
containerului.
Un alt aspect demn de luat in seama este ca statsless session
beans sunt independente de obiectele EJB.Cu alte cuvinte,un obiect EJB
poate utilia orice bean care este disponibil.De accea nu este necesar ca
sa fie creat un nou bean atunci cand este creat un nou obiect EJB.
2.4.4.2. Un exemplu de stateless session bean ,, Hello,Worldâ€Â
Exemplul de fata este,posibil,cel mai simplu posibil folosind
tehnologia EJB.El isi propune sa creeze o componenta statsless session
beans care sa dispuna de o metoda la al care apel se raturneze un
Stting: ,,Hello Worldâ€Â.
Primul pas il constituie definirea interfetei Remote.Conform cu
ceea ce s-a mentionat in capitolele anterioare,interfata Remote trebuie
sa prezinte orice metoda de business pe care o are si obiectul
EJB.Obiectul EJB va delega toate cererile clientului la bean.De remarcat
ca interfata aceasta extinde javax.ejb.EJBObject, adica obiectul
EJB,care este geenrat automat de conainer,vaimplementa aceasta
interfata..Va trebui ca in aceasta interfata sa apara si metoda pe care
dorim sa o apelam asupra bean-ului,adica hello().Codul acestei interfete
este prezentat in continuare.
Exemplul 2.6.1 Interfata Remote pentru bean-ul hello world
Import java.ejb.*;
Import javax.rmi.remoteException;
Import javax.rmi.Remote;
Public interface Hello extends EJBObject{
public String hello()throwsjava.rmi.RemoteException;
}
Urmatorul pas este crearea bean-ului propriu-zis.Trebuie
implementata metoda de business hello() si metodele interfetei
javax.ejb.SessionBean pe care bean-ul de fata le implementeaza pentru a
deveni session bean.
Exemplul 2.6.2 Beanul HelloBean
Import java.ejb.* ;
public class HelloBean implements SessionBean{
public void ejbCreate () {
System.out.println(,,ejbCreate ()“ ) ;
}
public void ejbRemote(){
System.out.println(,,ejbRemove()â€Â);
}
public void ejbActive(){
System.out.println(,,ejbActive()â€Â);
}
public void ejbPassivate(){
System.out.println(,,ejbPassivate()â€Â);
}
public void setSessionContext(SessionContext ctx){
System.out.println(,,setSessionContext()â€Â);
}
public String hello(){
System.out.println(,,hello()â€Â);
Return ,,Hello,World!â€Â;
}
}
De remarcat ca bean-ul nu implementeaza interfata Remote din cauza ca
interfata Remote extinde java.ejb.EJBObject,care ar aduce noi
metode.Deci,nu este logic ca bean-ul sa le implementeze.In plus,estesi
un motiv mai subtil.Acesta apare cand se doreste transferul unei
referinte la un bean .Problema care poate apareaeste ca obiectul EJB ar
putea fi confundat cu bean-ul insusi de catre un programator
neatent,deoarece ambele implementeaza acceasi interfata.In acest
caz,compilatorul nu va da nici o eroare,totusi greseala ar fi
majora,deoarece niciodata nu trebuie sa se poata ajunge la un bean decat
prin intermediul obiectului EJB corespunzator.Daca totusi se doreste
utilizarea interfetelor,pentru a evita acest caz,se recomanda sa se
utilizeze o interfata care sa continadoar metodele de business.Aceasta
interfata va fi implementata de bean si extinsa de interfata Remote.
Bean-ul este statelss si nu contine nici un fel de stare de
legatura de client,care sa se extinda de la un apel al unei metode la
altul.Metoda ejbCreate() nu primeste nici un parametru.La distrugerea
bean-ului nu este nimic care trrebuie distrus,asa ca metoda ejbRemove()
este si ea goala.La fel este si metoda setSessionContext(0,care asociaza
bean-ului contextul in care el se afla si pe care il poate interoga cu
privire la starea sa.Desi contextul este foarte util,in acest exemplu
extrem de simplu,nu s-a utilizat,deci nu a fost stocat intr-un membru a
clasei.
Metodele ejbActive() si ejbPassivate() sunt folosite pentru a anunta
bean-ul cand este pasivizat,respectiv activat.Deoarece aceste concepte
nu sunt aplicate asupra stateless session beans,vom lasa aceste metode
fara implementare.In schimb,ele sunt folosite de catre statefull session
beans.
Interfata Home specifica mecanismul de creare si distrugere a obiectelor
EJB.Aceasta interfata extinde java.ejbEJBHome si trebuie sa expuna unica
metoda de create de care dispune si care nu primeste nici un
parametru,deoarece este pentru un statelss session bean.
Exemplul 2.6.3. Interfata home pentru bean-ul hello bean
Import java.ejb.*;
Import javax.rmi.RemoteException;
Public interface Hello extends EJBHome{
Hello create() throws RemoteException,CreateException;
}
Metoda create() expusa in interfata poate lansa doua tipuri de
exceptii.Exceptia de tipul RemoteException este legata de faptul ca se
foloseste RMI pentru a comunica in retea intre obiectele distribuite si
pot aparea erori legate de comunicare,ca de exemplu caderea retelei sau
a masinii distante sau orice alta eroare ce tine de comunicarea cu
obietele distante intr-un mediu
distribuit.In schimb,eroarea CreateException este legata de o problema
care apare la nivelul aplicatiei si care are cu siguranta o mare
insemnatate pentru client.
O intrebare care reiese de aici este aceasta:
De ce se face o diferenta intre cele doua tipuri de exceptii?
Motivul este ca,in general,este util sa se faca o diferenta intre
exceptiile care apar la nivelul aplicatiei si cele care apar la nivelul
sistemului.In general,exceptiile la nivelul sistemului nu sunt de
interes pentru client.Unele aplicatii profesionale vor prinde aceste
exceptii si vor incerca sa realizeze aceeasi cerere de apel de metoda
poate la un alt server.Exceptiile de la nivelul aplicatiei sunt,in
schimb,intotdeauna de interes pentru client.De exemplu,pentru o
aplicatie bancara,aca un client nu are suficienti bani in cont
si,toturi,doreste sa extraga o anumita suma,se va lansa o exceptie de
nivel aplicatiei,pentru a marca faptul ca operatiunea bancara nu a
reusit din cauza insuficientei banilor din cont.
Pentru a vedea cum functioneaza acest bean,este nevoie de un client
care sa utilizeze statelesS session bean-ul HelloBean. Un astfel de
client este prezentat in
Exemplul 2.6.4 :
Exemplul 2.6.4. Client care utilizeqaza bean-ul HelloBean
Import java.ejb.*;
Import javax.naming.*
Import javax.rmi.*;
Import javax.util.Properties
Import javax.rmi.RemoteException;
Public class HelloClient {
try{
//get System properties for JNDI initialization
Properties props = System.getProperties():
//from an initial context
Context ctx = new InitialContext(props);
//get a reference to the home object
Hello hello = (HelloHome) ctx.lookup(,,HelloHomeâ€Â)
//use the factory co create an EJB object
Hello hello = HYPERLINK http://home.create(); home.create();
//call the hello method and print the String
System.out.println(hello.hello());
//remote the EJB object beacause don’t need it any
more
hello.remove();
}catch(Exception ex){
ex.printStackTrace()
}
}
Pentru a putea rula acest exemplu,este nevoie sa se realizeze
deployment-ul lui HelloBean se un server J2EE,ca de exemplu j2sdkee,care
poate fi gasit pe sit-ul firmei Sun la adresa
HYPERLINK http://java.sun.com/j2ee/j2dkee
http://java.sun.com/j2ee/j2dkee
Trebuie acordata atentie la identificatorul atasat bean-ului ca aecsta
sa fie exact ,,HelloHomeâ€Â.
Instructiunile de instalare pot fi gasite la adresa:
HYPERLINK http://java.sun.com/j2ee/j2sdkee/install.html
http://java.sun.com/j2ee/j2sdkee/install.html
Exemple de aplicatii cu deplaoyment-ul lor pot fi gasite la adresa:
HYPERLINK
http://java.sun.com/j2ee/j2sdkee/techdocs/guides/ejb/html/DevGuideTOC.ht
ml
http://java.sun.com/j2ee/j2sdkee/techdocs/guides/ejb/html/DevGuideTOC.ht
ml
sau pentru download in format PDF la adresa
HYPERLINK http://java.sun.com/j2ee/j2sdkee/devgiude1_2_1.pdf
http://java.sun.com/j2ee/j2sdkee/devgiude1_2_1.pdf
La rularea programului client,vor aparea in consola servarului
urmatoarele mesaje:
setSessionContext()
ejbCreate()
hello()
ejbRemove()
iar la client va aparea mesajul dorit: Hello,World!.
Dupa cum se poate observa,in prima faza,containerul a asociat
bean-ului un session context,apoi a apelat metoda create().Apelul
metodei hello() asupra obiectului EJB a fost delegat metodei hello() a
bean-ului .Prin distrugerea obiectului EJB s-a realizat si distrugerea
bean-ului .Oricum este foarte important de remarcat ca implementarea
mecanismului de poolong este lasata pe seama constructorului
containerului care poate implementa orice algoritm considera el
potrivit,de accea mesajele din consola servarului vor varia de la un
container la altul.Este importanta retinerea acetui fapt mai ales la
debugging.
2.4.5 Statefull Session Beans
Statefull session beans sunt bean-uri care realizaeazalogica de
business pentru clienti,insa sprea deosebire de stateless session beans,
ele pasteraza o informatie legata de conversatia cu clientul pe durata
mai multor apeluri de metode.Starea conventionala este mentinuta in
interiosrul ibean-iului si este specifica pentru un anume client.
2.4.5.1 Caracteristici particulare ale statefull session beans
Statefull session beans sunt ,dupa cum s-a precizat mai
sus,particularizate pentru un anume client, deci starea pe care ele o
mentin poate fi utilizata si are sens doar pentru un anume client.
Important la statefull session beans este ca ele trebuie sa
implementeze metodele ejbPassivate() si ejbActivate().Im plus,toatea
tributele care mentin starea
Bean-ului trebuie sa poata fi serializate.Motivele care stau in spatele
acestor necesitati sunt explicate in continuare.
Se presupune un caz in care mii de clienti au conversatii cu
diferite statefull session beans din cadrul unui container.O
caracteristica generala a utilizatorilor umani este ca ei actioneaza
relativ lent si izolat unii de altii.Aceasta inseamna ca bean-urile sunt
accesate aleatorsi nu foarte multiin acelasi timp.Totusi mii de clienti
inseamna mii de statefull session beans iar resursele containerului sunt
limitate (memorie,conexiuni la baze de date,conexiuni prin sockets
).Daca starea pastrata de un statefull session beans este reprezentata
de un volum mare de date,atunci servarul ar putea sa ramana fara
resurse.Pentru a preintampina aceasta situatie at trebui limitat numarul
de instante de statefull session beans aflat in memorie.Pentru aceasta
containerul poate sa realizeze operatiunea de pasivizare (passivatiohn)
asupra unor bean-uri .Atunci cand clientul lanseaza o cerere pentru un
bean care este pasivizat,acesta este readus in memorie,proces denumit
activare(activation)
Pasivizarea presupune,in primul rand, ca bean-ul sa elibereze
toate resursele pe care le detine, neputand fi serializate conexiunile
la bazele de date sau socket-urile deschise.Eliberarea aecstor resurse
se face la comanda containerului care apeleaza metoda ejbPassivate() a
bean-ului.Dupa ce aceasta a eliberat resursele,containerul il
serializeaza si il stocheaza (de obicei sub forma de blob)intr-un mediu
persistent(de obiceio baza de date).Acum este aproape evident de ce este
necesar ca atributele de stare sa poata fi serializate.Daca ele nu pot
fi serializate,atunci prin procesul de pasivizare/activare s-ar perde
starea conventionala cu clientul,care,in cele mai multe cazuri,ar face
bean-ul inutilizabil.Procesul de pasivizare este prezent in Figura 2.19
Pasivizarea asupra unui bean poate fi invocata in orice moment de
catre container,iar algoritmii folositi de container pentru a decide
care bean sa fie pasivizat sunt lasati pe seama constructorului
containerului.De acceas,bean-ul trebuie sa fie pregatit pentru
pasivizarea in orice moment.Totusi exista o exceptie de la regula
aceasta:
Orice bean care este implicat intr-o tranzactie nu poate fi
pasivizat pana cand tranzactia nu este incheiata.
Activarea bean-urilor presupune procesul invers pasivizarii,adica
acestea sunt aduse din mediul de stocare si recostruite in memorie,apoi
se apeleaza metoda ejbActivate() care va castiga resursele de care are
nevoie bean-ul.Procesul de activare este prezentat in Figura 2.20
2.4.5.2 Un exemplu de starefull session bean: CountBean
Cel mai simplu bean care trebuie sa mentina starea de la un apel
de metoda la altul este unul care numarade cate ori a fost apelata acea
metoda .El va realiza aceasta prin intermediul unei metode count() care
atunci cand este apelata incrementeaza pur si simplu un atribut de stare
al bean-ului.
Interfata Remote a acestui bean este de o simpliatate
dezarmanta,deoaree expune doar metoda count() a carei implementare din
bean va incrementa variabila val.Aceasta variabila reprezinta starea
conversationala a acestui bean.
Exemplul 2.7.1 Interfata Remote pentru bean-ul CountBean
Import java.ejb.*;
Import javax.rmi.RemoteException;
Import javax.rmi.Remote;
Public interface Count extends EJBObject{
public int count() throws RemoteException
}
Implementarea propriu-zia a acestui bean are o unica metoda de business:
count().Ea va incrementa atributul de stare val.Bean-ul trebuie sa
implementeze interfata javax.ejb.SessionBean.Metoda utilizata pentru
crearea bean-ului ejbCreate() primeste un parametru cu care se
initializaeaza starea bean-ului.Desi ,evident trebuie mentionat ca val
este serializabil fiindca este tipul primitiv int.Acesta esra necesar
pentru activarea si pasivizarea starii bean-ului.
Exemplul 2.7.2. Bean-ul CountBean
Import java.ejb.*;
public class CountBean implements SessionBean{
public int val;
public void ejbCreate(int val)throws CreateException
this.val – val;
System.out.println(,,ejbCreat()’’);
}
public void.ejbRemove(){
System.out.println(,,ejbRemove()’’);
}
public void ejbActivate(){
System.out.println(,,ejbActivate();
}
public void ejbPassivate(){
System.out.println(,,ejbPassivate();
}
public void setSessionContext(SessionContext ctx) {
this.ctx = ctx ;
System.out.println(,,setSessionContext()’’);
}
//business method
public int count(){
System.out.println(,,count()’’);
rReturn ++val ;
}
Interfata Home pentru obiectul Home atasat acestui bean va detalia
crearea si distrugerea bean-urilor.Deoarece se extinde interfata
javax.ejbHome metoda remove() este deja disponibila.
Exemplul 2.7.3 Interfata home pentru bean-ul CountBean
Import javax.ejb.*;
Import javax.rmi.RemoteException;
Public interface CountHome extends EJBHome{
Count create(int val)throws RemoteException,CreateException;
}
Clientul pentru acest bean realizeaza urmatoarele: obtine contextul
intil,localizeaza obiectul Home folosind JHDI.Folosind obiectul Home, se
creeaza un obiect asupra caruia se apeleaza metoda count(),iar apoi
obiectul EJB este distrus
Exemplul 2.7.4. Client pentru bean-ul CountBean
Import javax.ejb.*;
Import javax.naming.*;
Import java.util.Properties;
Public class CountClient{
Public static void main (String[]args{
Try
Properties props = System.getProperties();
Context ctx = new InitialContext(props);
CountHome home = (CountHome)
Ctx.lookup (,,CountHome’’);
Int countVal = 0
Count count = HYPERLINK http://home.create(countVal
home.create(countVal )
CountVal = count.count();
System.out.println(,,new coount = ‘’+countVal);
Count.renmove();
}catch(Exception ex){
ex.printStackTrace();
}
}
}
Pentru a putea rula acest exemplu ,este nevoie sa se realizeze
deployment-ul lui CountBean pe un server J2EE ca de exemplu un j2sdkee
care poate fi gasit pe situl firmei Sun la adresa
HYPERLINK http://java.sun.com/j2ee/j2sdkee
http://java.sun.com/j2ee/j2sdkee .
Trebuie acordata atentie la identificatorul atasat bean-ului ca acesta
sa fie exact ,,CountHome’’.
Instructiunile de instalare pot si gasite la adresa
HYPERLINK http://java.sun.com/j2ee/j2sdkee/install.html
http://java.sun.com/j2ee/j2sdkee/install.html
Exemple de aplicatii si deployment-ul lor pot fi gasite la adresa:
HYPERLINK
http://java.sun.com/j2ee/j2sdkee/techdocs/guides/ejb/html/DevGuideTOC.ht
ml
http://java.sun.com/j2ee/j2sdkee/techdocs/guides/ejb/html/DevGuideTOC.ht
ml
sau pentru download in format PDF la adresa:
HYPERLINK http://java.cun.com/j2ee/j2sdkee/devguide1_2_1.pdf
http://java.cun.com/j2ee/j2sdkee/devguide1_2_1.pdf
2.4.6 Utilizarea statefull si stateless sessions beans
Deja s-au parcurs cate un exemplu de statefull si unul de i session
beans,urmand a fi prezentate considerentele care trebuie luate in seama
la proiectarea unei aplicatii folosind statefull si stateless session
beans.Intreabrea care se pune este:
Care dintre acele doua tipuri de bean-uri sunt potrivite in diferite
situatii?
Cu alte cuvinte,
Care sunt avantajele si dezavantajele celod doau tipuri de bean-uri?
Statelss sessions beanes au avantajul de a fi refolosite cu
usurinta de catre containerul EJB pentru mai multi clienti.Daca se
incearca acceasi strategie la statefull sessions beans, din pacate, este
mai complicat,deoarece apar pasivizarea si activarea care vor consuma
resurve in plus putand duce chair la gaturi in sistemul de
intrare/iesire (I/O)bottlenecks.Deci un mare avantaj al stateless
session beans este ca ele pot fi reutilizate fara a consuna resurse in
plus aproape deloc.
Deoarece statefull sessions beans pasteraza satrea conversatiei cu
clientul in memorie o eroare aparauta ar putea duce la pierderea
intregii conversatii cu clientul.Acest fenomen neplacut poate fi evitat
fie prin proiectarea aplicatiei fie prin utilizarea unui container care
permite refacerea statefull sessions bean-urilor.
Cel mai mare dezavantaj al stateless sessions beans este ca nu pot
mentine nici un fel de informatii de stare.Totusi cele mai multe
stateless sessions beans au nevoie de date legate de client ca de
exemplu numarul contului bancar.Aceasta informatie trebuie furnizata la
fiecare apel de metoda deoarece stateless sessions beans nu pastreaza
aceasta stare.
O metoda de a furniza bean-ului date specifice clientului este de
a furniza datele prin intermediul parametrilor utilizati la apelul
metodelor beanu-lui.Aceasta insa poate duce la scaderea performanetei
sau chiar la congestie in retea daca nu cel putin la reducerea benzii
disponibile pentru alte procese.
Alta metoda de a evita aceaste neplaceri este ca bean-ul sa
stocheze date specifice clientului intr-o structura de directoare
folosind JNDI.Clientul va putea fi identificat prin intermediul unui
identificator care va fi utilizat si pentru localizarea datelor in
structura de directoare.
La alegerea dintre statefull si stateless pe langa considerentele
legate de conversatia cu clientul trebuie luate in considerare si
aspectele de mai sus.
2.5 Entity Beans
Entity Beans sunt Enterprise beans care stiu cum sa se salveze
pe ele insele intr0un mediu permanet de stocare.entity beans stocheaza
date cum ar fi numarul contului bancar,numeralul din cont etc.Ele au
asociate metode ca: getBan() s-au getAccountBalance().Entity beans pot
fi foloste si pentru integrarea aplicatiilor mai vechi (legacy systems).
Spre deosebire de sessions beans care modeleaza procesele
actiunile pornite de utilizatori entity beans contin datele legate de
aplicatie ca de exemplu conturi bancare ,comenzi,informatii legate de
utilizatori etc.Un entiry bean nu realizeaza sarcini complicate cum e de
exemplu realizarea platilor de la client.
Entity beans potfi privite astfel:
( Reprezentare in memorie a datelor sub forma de obiect Java
( obiecte dcapabile sa ses citeasca din mediul de stocare si sa-si
populese campurile cu aceste date.
( un obiect care poate fi modificat in memorie si care va schimba
datele din mediul de stocare.
2.5.1. Caracteristici ale entity beans
Entity beans au durata de viata egala cu cea a datelor pe care
le reprezinta.De exemplu un entity bean poate reprezenta contul unui
client.
Entity beans supravietuiesc in cazul unor caderi
accidentale.Deoarece entity beans sunt parte dintr-un mediu persistent ,
o cadere a JVM (Java Virtual Machine) sau a bazei de date nu va afecta
ciclul de viata al unui entity bean.De indata ce lucrurile intra in
normal instantele entity beans pot fi recreate prin simpla citire a
datelor din baza de date si creearea unor instante care sa le
reprezinte in memorie.
2.5.1.1. Legatura dintre entity beans si datele pe care le reprezinta
Entity beans au semnificaria unui zoom asupra datelor din baza
de date pe care le reprezinta.Cu alte cuvinte datele din baza de date si
obiectul din memorie care le reprezinta (instanta bean-ului asociata
lor) trebuie privite ca fiind uni si acelasi lucru.Aceasta inseamna ca,
daca datele din memorie adica din bean sunt modificate atunci automat
sunt modificate si datele din baza de date.Desigur ca in realitate
obiectul din memorie,instanta entity bean-ului nu este unui si acelasi
cu datele din baza de date.Din acest motiv trebuie sa existe un mecanism
prin care sa poata fi transferata informatia dintre obiectul din memorie
si baza de date.
Acest transfer este realziat prin intermediul a doua metode speciale pe
care orice entity bean trebuie sa le implementeze:ejbLoad() si
ejbStrore.Metoda ejbLoad() are rolul de a citi datele din mediul
permanet de stocare si de ale plasa in campurile bean-ului.Metoda
ejbStore este complementara realizand salvarea datelor din bean in baza
de date.
Intrebarea care se pune este:
Cine decide momentele in care sa fie transferate datele intre
obiectele din
memorie si cele din baza de date?
Cu alte cuvinte cine apeleaza metodele ejbLoad() si ejbStore() ?
Dupa cum s-a vazut deja este vorba despre containerul EJB.El este cel
care alege momentele in care sa transfere datele din memorie in mediul
persistent si invers.Bean-ul trebuie sa fie pregatit sa acepte metodele
ejbLoad() si ejbStore() aproape in orice moment, dar nu in decursul
metodelod de business.Acesta este unui dintre avanatjele
EJB:programatorul nu trebuie sa se preocupe de sincronizarea dintre
datele din bean-ul din memorie si datele din baza de date.
2.5.1.2 Mai multe entity beans pot reprezenta simultan aceleasi date
din baza de date
Sa consideram cazul in care mai multe fire de executie
(threaths) doresc sa acceseze simultan aceleasi date.De exemplu se
poate intampla ca simultan mai multi clienti ai unui magazin virtual sa
acceseze un catalog de produse.
Pentru a facilita accesul simultan al mai multor clienti la
aceleasi date trebuie sa exiet un mecanism de aces la entity beans.O
posibilitate ar fi sa se permita clientilor sa partajeze acceasi
isntanta a unui entity beans.Aceasta este inadecvata din doua motive.
( codul din interiorul bean-ului ar trebui sa fie thread-safe.
( ar aparea o gatuire la accesul de date.
Codul thread-save este un cod care permite executarea mai multor
fire de executie folosind aceleasi date.Daca pentru entity beans ar fi
mai multe dire de executie tranzactiile ar fi aproape imposibile.Din
acest motiv in specificare EJB se spuen ca in interiorul unei instante a
unui bean poate rula doar un thread.Acelasi lucru este adevarat si
pentru sessions beans.
Gatuirea in accesul la date ar aparea atunci cand mai multi
clienti acceseaza un bean fiindca trebuie ca fiecare sa astepte dupa cei
dinaintea lui.Pentru a evita aceasta se permite containerului sa creeze
mai multe insatnte ale aceluiasi entity bean (adica mai multe instante
sa reprezinte exact aceleasi date).Aceasta va permite clientilor sa aiba
acces concurent la date.
PAGE 1
PAGE 4
ì¥Â@
