3.

Tehnologii Java– prezentare,

compara]ii, avantaje

3.1 Evolu]ia tehnologiilor ce genereaz@

con]inut dinamic

Cele mai simple interac]iuni browser–server presupun

c@ browser-ul cere un document HTML, iar serverul web
g@se}te fi}ierul corespunz@tor }i-l returneaz@. Acest gen
de cerere adreseaz@ fi}iere statice, adic@ documentele
care sunt cerute nu se schimb@ niciodat@, nedepinz$nd de
cine le solicit@, de momentul c$nd au fost solicitate,
sau de existen]a unor eventuali parametri ^n cerere.
Versiuni noi ale documentului pot fi plasate pe server, dar la
un moment dat orice cerere va returna exact acela}i
rezultat.
Cea mai mare parte a informa]iilor transmise ast@zi pe
web sunt dinamice prin natur@. De exemplu, pre]urile
ac]iunilor ]inute la minut, ultimele rapoarte metereologice
pot fi consultate. Sau consumatorii pot ad@uga obiecte la
co}ul de cump@r@turi pe un site de comer] electronic
printr-un simplu click pe imaginea obiectului dorit. Toate
aceste informa]ii sunt efemere, vremelnice prin natur@, fie
pentru c@ datele se bazeaz@ pe modificarea lor constant@,
fie pentru c@ trebuie personalizate pentru un anumit individ.
Con]inutul dinamic al paginilor web face necesar ca
serverul web s@ execute opera]ii de procesare suplimentare
pentru a putea furniza un r@spuns adaptat. Forma acestui
r@spuns adaptat poate s@ depind@ de URL-ul (Universal
Resource Locator) de unde provine cererea, de parametrii
suplimentari inclu}i ^n cerere, de identitatea utilizatorului

30
ce a emis cererea, sau poate s@ se bazeze pe data sau
timpul cererii.
Forma exact@ a r@spunsului va fi func]ie de unul sau mai
mul]i dintre ace}ti factori.

3.2 Avantajele limbajului Java pentru

dezvoltarea aplica]iilor client-server

Succesul aplica]iilor Java pe partea de server este una

dintre cele mai recente consecin]e ale puterii inerente a
limbajului. Java este un limbaj ideal pentru dezvoltarea
aplica]iilor pe partea de server. Afacerile ^n particular, au
recunoscut poten]ialul limbajului ^n aceast@ direc]ie,
deoarece Java este prin natur@ potrivit pentru aplica]iile
client-server complexe. Java are o platform@ hibrid@ care-l
face foarte folositor pentru organiza]iile care au o colec]ie de
servere eterogene, rul$nd pe sisteme de operare diverse
cum ar fi Unix, Windows, Solaris, etc.
De asemenea, faptul c@ Java este un limbaj orientat-
obiect, proiectat cu ideea de protec]ie a memoriei, permite
dezvoltatorilor s@ reduc@ ciclurile de realizare a produselor
program }i s@ sporeasc@ fiabilitatea.
%n plus, suportul integrat ^n Java pentru API-uri de
re]ea }i enterprise ofer@ acces la datele mo}tenite, u}ur$nd
tranzi]ia de la sistemele client-server mo}tenite.
Una dintre tehnologiile Java care constituie o component@
cheie a dezvolt@rii aplica]iilor pe partea de server sunt
servlet-urile. Un servlet poate fi privit ca o extensie mic@,
ata}abil@ unui server care spore}te func]ionalitatea
serverului. Servlet-urile permit dezvoltatorilor s@ extind@ }i
s@ individualizeze orice server cu suport Java, cum ar fi un
server web, un server de mail, un server de aplica]ie, sau
orice alt gen de server, cu un anumit grad de portabilitate,
flexibilitate }i u}urin]@ ^n utilizare.

31
 %n timp ce servlet-urile pot fi folosite s@ extind@
func]ionalitatea oric@rui server cu suport Java, cel mai
adesea tind s@ ^mbun@t@]easc@ serverele web,
dovedindu-se un ^nlocuitor puternic }i eficient pentru
scripturile CGI. Atunci c$nd este folosit un servlet pentru a
crea dinamic con]inutul unui pagini web sau pentru a extinde
func]ionalitatea unui server, de fapt este creat@ o aplica]ie
web. O pagin@ web afi}eaz@ con]inut static. O aplica]ie
web ofera mai mult@ interactivitate. Ea poate fi at$t foarte
simpl@, ^n genul unui motor de c@utare ^ntr-un document,
c$t }i complex@, cum ar fi un magazin virtual.
Aplica]iile web se de}f@}oar@ pe Internet, sau ^n
intranet-urile }i extranet-urile unor corpora]ii, unde au
posibilitatea s@ creasc@ productivitatea }i s@ modifice
modul ^n care companiile, mici sau mari, fac afaceri.
Pentru a ^n]elege puterea tehnologiilor Java, este necesar
s@ avem o privire de ansamblu asupra altor modalit@]i care
pot fi folosite pentru a crea aplica]ii web.

Common Gateway Interface

Common Gateway Interface, referit@ pe scurt ca CGI, a

fost una dintre primele tehnici de creare a con]inutului
dinamic. Cu CGI, un server web trimite anumite cereri unui
program extern. Outputul acestui program este apoi trimis
clientului (browser-ului) ^n locul fi}ierului static.
Apari]ia CGI-ului, a f@cut posibil@ implementarea unor
func]ionalit@]i ^n paginile web inexistente p$n@ atunci,
astfel ^nc$t CGI a devenit repede standardul de facto,
implementat ^ntr-o duzin@ de servere. Este interesant de
men]ionat c@ abilitatea programelor CGI de a crea pagini
web dinamice este un efect colateral al scopului ini]ial: s@
defineasc@ o metod@ pentru ca un server de informa]ii s@
comunice cu aplica]ii externe. Acest@ origine explic@ de ce
CGI are probabil unul din cele mai proaste cicluri de via]@.
Atunci c$nd un server prime}te o cerere care acceseaz@ un
program CGI, el trebuie s@ creeze un nou proces ^n care
s@ ruleze programul CGI }i apoi s@ transmit@ prin variabile
de mediu }i intrarea standard fiecare bit de informa]ie care

32
poate fi necesar pentru generarea unui r@spuns. Crearea
unui proces pentru fiecare astfel de cerere solicit@ timp }i
resurse semnificative din partea serverului, ceea ce
limiteaz@ num@rul de cereri pe care un server le poate
trata concuren]ial. %n cazul unui server care are de f@cut
fa]@ la c$teva mii de solicit@ri concomitent (lucru comun
ast@zi pe web) este evident c@ aceast@ modalitate CGI nu
ar fi deloc viabil@.
Figura de mai jos ilustreaz@ ciclul de via]@ CGI. Se
observ@ c@ dou@ cereri pentru acela}i program CGI
genereaz@ doua procese, deoarece orice program CGI se
^ncheie odat@ ce a ^naintat outputul pentru o cerere.

Fig. 3.2.1 Server web bazat pe CGI

Un program CGI poate fi scris aproape ^n orice limbaj,

^ns@ predominant sunt folosite Perl }i C/C++. Asta duce la
un alt dezavantaj major, anume lipsa portabilit@]ii.
O alt@ problem@ important@ este aceea c@ un program
CGI nu poate interac]iona cu serverul web sau s@
beneficieze de capacit@]ile serverului odat@ ce execu]ia sa
a ^nceput, deoarece ruleaz@ ^ntr-un proces separat. De
exemplu, un script CGI nu poate s@ scrie ^n fisierul jurnal al
serverului.
Abordarea tradi]ional@ CGI are a}adar ni}te deficien]e
majore inerente.

33
FastCGI

O companie numit@ Open Market a dezvoltat o

alternativ@ ^mbun@t@]it@ a standardului CGI, numit@
FastCGI. Diferen]a semnificativ@ este c@ FastCGI creaza un
singur proces persistent pentru fiecare program FastCGI.
Aceasta ^nl@tur@ necesitatea cre@rii unui nou proces
pentru fiecare cerere, dup@ cum se vede din figura de mai
jos. Chiar dac@ aceasta ^nseamn@ un progres, celelalte
probleme r@m$n.

Fig. 3.2.2 Server web bazat pe FastCGI

Ca urmare a deficien]elor solu]iei CGI, mai mul]i

v$nz@tori au introdus noi sisteme pentru generarea
dinamic@ a con]inutului paginilor web. Aceste sisteme se
prezint@ sub forma unor module de cod ad@ugabile, ce
influen]eaz@ API-urile specifice serverelor, cu scopul de a
interac]iona direct cu procesele serverului web.
Fiind ata}ate ca un subproces al serverului web, aceste
sisteme previn neajunsurile asociate cu programele CGI
conven]ionale }i ofer@
un con]inut dinamic cu capacit@]i de scalare mult mai bune
dec$t abordarea tradi]ional@.
Dup@ cum a fost men]ionat anterior, generarea dinamic@
a con]inutului necesit@ ca serverul s@ proceseze cereri la
momentul execu]iei pentru a elabora un r@spuns adecvat.
Pentru a realiza aceast@ procesare sunt necesare anumite
instruc]iuni, a}adar este evident c@ programarea este

34
necesar@. Ca un rezultat, multe dintre cele mai populare
sisteme de con]inut dinamic, permit con]inutului dinamic s@
fie referit prin limbaje de script. Aceast@ alegere este cea
mai potrivit@ ^n acest caz deoarece dezvoltatorii web sunt
obi}nui]i cu schimb@ri rapide atunci c$nd testeaz@ paginile
web: atunci c$nd HTML-ul dintr-o pagin@ static@ a fost
modificat, efectul schimb@rii poate fi vizualizat
^ntr-un browser web. Utilizarea limbajelor de script care nu
necesit@ un ciclu ^ndelungat de editare-compilare-legare
pentru a putea rula codul, permite acestor sisteme de
con]inut dinamic s@ ofere un feedback rapid.
Scripturile pot fi introduse direct ^n paginle web.
Elementele statice ale paginii, ce precizeaz@ forma }i
aranjamentul ^n pagin@, pot s@ fie exprimate ^n HTML ca
de obicei. Atunci c$nd documentul este solicitat de un
utilizator, serverul web va trimite elementele HTML statice,
neschimbate. %n schimb, scripturile vor fi executate }i
transformate ^n con]inut dinamic, aceste rezultate fiind
plasate ^n pagin@ ^n locul codului surs@ script original.
Deoarece elementele statice de HTML constituie cadrul ^n
care con]inutul dinamic generat de scripturi va fi plasat,
aceste sisteme sunt ^n mod obi}nuit numite sisteme
template.
Principala diferen]@ ^ntre sistemurile template const@
^n limbajul de script }i ^n capacit@]ile aferente acestuia.

ColdFusion

ColdFusion este realizat de Allaire; ofer@ un set de taguri

asem@n@toare cu cele HTML prin care suport@ o varietate
de surse de date pentru generarea dinamic@ a con]inutului.
Adoptarea stilului de taguri asem@n@tore cu cele HTML are
avantajul c@ exist@ un singur fel de sintax@ ^n cadrul
paginii, iar tagurile ColdFusion sunt “prietenoase” pentru
web designeri deoarece arat@ la fel ca celelate taguri
prezente ^ntr-un document.
ColdFusion suport@ at$t platforma Unix c$t }i Windows.

35
Active Server Pages

Active Server Pages provine de la Microsoft, fiind

abreviat@ ASP; suport@ mai multe limbaje de script printre
care PerlScript, Jscript, si VBScript. Limbajul implicit este
VBScript, care este un subset al limbajului de programare de
la Microsoft, Visual Basic. VBScript include suport pentru
accesarea componentelor ActiveX, care reprezint@ obiecte
ce pot ^ncapsula practic orice func]ionalitate, inclusiv acces
la baze de date }i manipularea fi}ierelor.
Limitarea major@ a ASP-ului este faptul c@ este disponibil
doar cu serverul Microsoft Internet Information Server (IIS)
care ruleaz@ sub sistemul de operare Windows NT.
Beneficiile ASP-ului constau ^n suportul pentru
componentele ActiveX, care }i ele sunt disponibile doar pe
platforma Microsoft.

Server-Side JavaScript

Server-Side JavaScript (SSJS) utilizeaz@ JavaScript drept

limbaj de script. JavaScript este un limbaj orientat obiect cu
o sintax@ asem@n@toare C-ului, dar ^n ciuda asem@n@rii
de nume, nu este Java.
Ca }i ASP, SSJS permite ca buc@]i de cod s@ fie incluse ^n
pagile web pentru a genera dinamic con]inutul. %n SSJS,
paginile web sunt precompilate pentru a ^mbun@]i
performan]a.
SSJS adaug@ suport pentru baze de date }i email, pentru
managementul sesiunii }i pentru interoperabilitatea claselor
server-side Java utiliz$nd tehnologia Netscape LiveWire.
Ca }i codul Java compilat, codul SSJS nu este specific unei
platforme, software sau hardware, dar este specific
serverelor HTTP Netscape.

Toate aceste solu]ii sunt private, adic@ lucreaz@ doar ^n

cadrul unor servere specifice, ca extensii ale acestora, dup@
cum se poate vedea ^n figura de mai jos.

36
 Fig. 3.2.3 Extensii API ale serverelor web

PHP

Un alt sistem pentru generarea dinamic@ a con]inutului

este PHP. la fel ca }i JavaScript, PHP introduce o sintax@
bazat@ pe C }i ofer@ un important suport pentru accesul la
baze de date.
Spre deosebire de celelate sisteme template prezentate
mai sus, PHP este un produs Open Source. Adic@ la fel ca }i
alte produse Open Source, cum ar fi sistemul de operare
Linux }i serverul HTTP Apache, PHP nu este un produs
comercial. El reprezint@ rezultatul contribu]iei unei
comunita]i de dezvoltatori, care au contribuit pe gratis la
realizarea codului s@u de baz@.
O consecin]@ important@ a acestui aspect este c@ PHP
este disponibil pe un num@r mare de platforme }i poate
lucra de asemenea pe multe servere web.

Toate aceste solu]ii prezentate pentru generarea

dinamic@ a con]inutului paginii web prezint@ anumite
deficien]e majore, provenind uneori din modul de construc]ie
al modelului, alteori din scopul cu care au fost create, pentru
a rula doar ^n cadrul unor platforme specifice.
Platforma Java vine cu un num@r de tehnologii care s@
suplineasc@ aceste dezavantaje }i s@ ofere performan]e
remarcabile, asigur$nd ^n acela}i timp portabilitate,
securitate, u}urin]a }i elegan]a specifice limbajului Java ^n
dezvoltarea aplica]iilor. Este vorba de servlet-uri }i Java

37
Server Pages. Vom prezenta ^n continuare, detaliat, aceste
tehnologii Java.

3.3 Servlet-urile Java

Un servlet reprezint@ o extensie generic@ a unui server,

mai exact o clas@ Java care poate fi ^nc@rcat@ dinamic
pentru a extinde func]ionalitatea unui server. Servlet-urile
sunt ^n mod obi}nuit folosite cu serverele web, unde iau
locul scripturilor CGI. Servlet-ul este similar unei extensii
private a unui server, cu excep]ia faptului c@ ruleaz@ ^ntr-o
ma}in@ virtual@ Java pe server, deci este sigur }i portabil.

Fig. 3.3.1 Rularea servlet-urilor ^n cadrul unui server

Servlet-urile opereaz@ doar pe server, astfel ^nc$t spre
deosebire de applet-uri, ele nu necesit@ suport pentru Java
^n browser-ul web.
Spre deosebire de CGI care utilizeaz@ procese multiple
pentru a manipula programe separate }i/sau cereri separate,
sevlet-urile sunt gestionate de fire de execu]ie separate ^n
cadrul procesului serverului web. Aceasta ^nseamn@ c@
servlet-urile sunt nu numai eficiente, dar }i scalabile.
Deoarece servlet-urile ruleaz@ ^n cadrul serverului, ele
pot interac]iona foarte bine cu serverul pentru a realiza
lucruri imposibile pentru scripturile CGI.
Alt avantaj al servlet-urilor este faptul c@ ele sunt
portabile, at$t pe sistemele de operare c$t }i pe serverele

38
web. Probabil, servlet-urile Java ofer@ cea mai bun@ solu]ie
pentru dezvoltarea de aplica]ii web.
Chiar dac@ servlet-urile sunt cel mai adesea folosite ca
^nlocuitori pentru CGI pe serverele web, ele pot extinde
orice gen de server, cum ar fi un server FTP, un server de
mail, etc.
Analog cu modul ^n care au introdus applet-urile ca
aplica]ii
Java pentru a spori interactivitatea browser-elor web, Sun au
introdus servlet-urile drept mici aplica]ii Java care adaug@ o
func]ionalitate dinamic@ serverelor.
Spre deosebire de programarea CGI tradi]ional@ care
necesit@ generarea unui nou proces pentru a trata fiecare
cerere, toate servlet-urile asociate unui server web ruleaz@
^n cadrul unui singur proces. Acest proces execut@
ma}ina virtual@ Java, care creaz@ un fir de execu]ie pentru
fiecare cerere. Firele de execu]ie nu necesit@ at$tea resurse
ca procesele de sine st@t@toare, }i se execut@ ^n cadrul
memoriei deja alocate de JVM, f@c$nd execu]ia servlet-urilor
mult mai eficient@ dec$t procesarea CGI. Cum JVM
persist@ }i dup@ terminarea satisfacerii unei cereri, servlet-
urile pot s@ evite multe opera]ii consumatoare de timp, cum
ar fi conectarea la o baz@ de date, prin partajarea resurselor
^ntre solicitan]i.
Deoarece sunt scrise ^n Java, servlet-urile beneficiaz@ de
toate atuurile platformei Java: un model de programare
orientat obiect, management automat al memoriei,
portabilitate, acces la o colec]ie numeroas@ de API-uri
(pentru acces la baze de date, la resurse din re]ea, la
directoarele serverului). Reduse la esen]a lor, servlet-urile
asigur@ o metodologie Java pentru maparea cererilor HTTP
la r@spunsuri HTTP. Generarea dinamic@ a con]inutului
paginii web este realizat@ de c@tre codul Java care
returneaz@ HTML. %n cazul datelor HTML un mod de
abordare pentru realizarea acestui deziderarat, este
construirea unui string ce va con]ine textul HTML potrivit }i
apoi scrierea acestui string ^n stream-ul de output asociat
r@spunsului HTTP.

39
 O alt@ modalitate este o modelare orientat@ obiect a
datelor ce vor constitui r@spunsul, construindu-se mai ^nt$i
un model al paginii drept o colec]ie de obiecte Java. Astfel,
multe pagini web pot fi privite ca o ierarhie de elemente
textuale, printre care titluri, diverse niveluri de subtitluri,
paragrafe, ce con]in informa]ia pentru fiecare sec]iune. Pot fi
construite clase Java care s@ reprezinte at$t aceste
elemente, c$t }i pagina ^n sine.

Fig. 3.3.2 Tratarea unei cereri de c@tre un servlet

Clasele pentru elementele textuale vor asigura metode

pentru accesarea }i modificarea con]inutului. Clasa
corespunz@toare paginii va oferi metode pentru
ad@ugarea }i eliminarea elementelor textuale. Atunci c$nd
se va genera con]inutul dinamic, o instan]@ a clasei pagin@

40
va fi creat@, la care vor fi apoi ad@ugate instan]e
corespunz@toare elementelor textuale.
Figura de mai sus exemplific@ modul de tratare a
cererilor de c@tre servlet-uri.
Unul dintre avantajele cheie ale abord@rii orientate obiect
este faptul c@ se pot suporta multiple forme de output
pentru document, de exemplu HTML }i XML.
Pe de alt@ parte, dezavantajul acestei modalit@]i este c@
toate p@r]ile din document, at$t statice c$t }i dinamice,
sunt reflectate ^n codul surs@. Aceasta ^nseamn@ c@
orice modificare a documentului necesit@ interven]ia unui
programator. Un web designer nu ar putea schimba formatul
paginii, f@r@ s@ schimbe codul surs@ asociat.

Vom prezenta ^n continuare detaliat avantajele

tehnologiei Java servlet-uri, pentru generarea unui con]inut
dinamic.

Portabilitate

Deoarece servlet-urile sunt scrise ^n Java }i se

conformeaz@ unui API bine definit }i acceptat sunt portabile
at$t pe platforme diverse c$t }i pe servere diverse.

Putere
Servlet-urile pot s@ valorifice ^ntreaga for]@ a API-urilor
Java: acces re]ea }i URL, fire de execu]ie multiple,
manipularea de imagini, compresia de date, conectare la
baze de date, interna]ionalizare, RMI (remote method
invocation), serializarea obiectelor. Astfel se poate scrie
foarte u}or o aplica]ie care s@ permit@ angaja]ilor s@
efectueze cereri de reg@sire pe o baz@ de date mo}tenit@,
sau o aplica]ie web care s@ exploreze directoare. De
asemenea, servlet-urile se pot folosi ^mpreun@ cu clase
Java }i componente JavaBeans scrise de ter]i pentru a realiza
sarcini precum c@ut@ri de expresii regulate sau prezentarea
datelor prin grafice.
Servlet-urile sunt potrivite }i pentru comunicarea
client/server.

41
Eficien]@ }i durat@

Invocarea servlet-urilor este foarte eficient@. Odat@ ce un

servlet este ^nc@rcat el r@m$ne ^n memoria serverului ca
o instan]@ a unui singur obiect. Apoi, serverul apeleaz@
servlet-ul pentru a ^ndeplini o sarcin@ printr-o simpl@
metod@ de invocare. Spre deosebire de CGI, nu are loc
generarea unui proces sau invocarea unui interpreter, a}a
c@ servlet-ul poate s@ ^nceap@ tratarea cererii aproape
imediat. Cererile concurente sunt tratate de fire de execu]ie
separate, a}a ^nc$t servlet-urile au un grad mare de
scalabilitate.
%n general, servlet-urile sunt obiecte care persist@.
Deoarece un servlet rezid@ ^n memoria serverului drept
instan]@ a unui singur obiect, el ^}i men]ine automat starea
}i poate s@ p@streze leg@tura la resurse externe cum ar fi
o conexiune la o baz@ de date, care altminteri ar dura
c$teva secunde pentru a se stabili.

Siguran]@
Servlet-urile suport@ un num@r de nivele la care se
asigur@ siguran]a ^n programare. Deoarece sunt scrise ^n
Java, servlet-urile mo}tenesc tipizarea strict@ a limbajului
Java. %n plus, API-ul Servlet este implementat astfel ^nc$t
s@ fie “type-safe”. %n timp ce cele mai multe valori dintr-un
program CGI, inclusiv numerice, cum ar fi num@rul unui
port, sunt tratate drept stringuri, valorile manipulate de API-
ul Servlet folosesc tipul lor nativ. Colectorul de reziduuri Java
}i lipsa pointerilor ^nseamn@ c@ servlet-urile sunt ^n
general imune la problemele de management al memoriei.
Servlet-urile pot s@ trateze ^ntr-un mod sigur erorile,
datorit@ mecanismului Java de tratare a excep]iilor. Astfel
dac@ un servlet realizeaz@ o ^mp@r]ire la zero, va arunca
o excep]ie care poate fi interceptat@ }i rezolvat@ de server,
care va jurnaliza eroarea }i va cere scuze utilizatorului
printr-un mesaj adecvat. Dac@ o extensie de server bazat@

42
pe C++ ar face aceea}i gre}eal@ ar exista posibiltatea
bloc@rii serverului.
Mai mult, un server se poate proteja de poten]iale erori
ale unui servlet printr-un manager de securitate Java. Astfel,
toate servlet-urile se vor executa sub o monotorizare strict@
a managerului de securitate, care de exemplu poate impune
o politic@ de securitate proiectat@ s@ previn@ afectarea
serverului de c@tre servlet-uri prost scrise sau r@u-
inten]ionate.

Elegan]@

Elegan]a codului unui servlet este izbitoare. Codul unui

servlet este clar, orientat obiect, modular }i foarte simplu. O
explica]ie a acestei simplit@]ii este API-ul Servlet ^n sine,
care include metode }i clase pentru tratarea multor rutine
de baz@ din programarea servlet. Chiar opera]ii avansate,
cum ar fi manipularea cookie-lor }i managementul sesiunii
sunt abstractizate ^n clase.

Integrare

Servlet-urile sunt integrate serverului. Aceast@ integrare

permite unui servlet s@ coopereze cu serverul ^nr-un mod
inaccesibil programelor CGI. De exemplu, un servlet poate
utiliza serverul pentru a translata calea unor fi}iere, s@ fac@
jurnalizare, s@ autorizeze accesul, s@ mapeze tipuri MIME.
Sistemele template (extensii ale unor servere) pot s@
asigure }i ele ^n mare aceste facilit@]i, dar procesul este de
obicei mai complex }i predispus la erori.

Extensibilitate }i flexibilitate

API-ul Servlet este proiectat s@ fie cu u}urin]@ extins. El

include multe clase optimizate pentru servlet-urile HTTP, la
acest moment.
Dar mai t$rziu, ar putea fi u}or extins pentru alte tipuri de
servlet-uri, ori de Sun ori de ter]i. Este de asemenea posibil

43
ca suportul pentru servlet-uri HTTP s@ fie ^n continuare
^mbun@t@]it.
Servlet-urile sunt de asemenea destul de flexibile. Un
servlet HTTP poate fi folosit pentru a genera complet o
pagin@ web, poate fi ad@ugat la o pagin@ static@ folosind
tagul <SERVLET>, poate fi folosit ^n cooperare cu alte
servlet-uri pentru a filtra con]inutul (lan] de servlet-uri).

3.4 Java Server Pages

Java Server Pages, JSP pe scurt, este o tehnologie Java

care simplific@ procesul de dezvoltare a site-urilor web
dinamice. Cu JSP, programatorii }i web designerii pot s@
incorporeze rapid elemente dinamice ^n pagini web,
utiliz$nd cod Java }i c$teva simple taguri. Aceste taguri
ofer@ designerului HTML un mod de a accesa datele }i
func]iile stocate ^ntr-un obiect Java, f@r@ a fi nevoit s@
st@p$neasc@ complexitatea limbajului Java.
Dintr-un punct de vedere simplist }i inexact, JSP poate fi
v@zut ca un limbaj de script destinat serverelor (ASP, PHP).
JSP-urile sunt fi}iere text, de obicei cu extensia .jsp, care
iau locul tradi]ionalelor pagini HTML. Fi}ierele JSP con]in
HTML tradi]ional ^mpreun@ cu cod inclus care ^ng@duie
designerului paginii s@ acceseze date printr-un cod Java ce
ruleaz@ pe server. Atunci c$nd pagina este solicitat@ de un
utilizator }i procesat@ de protocolul HTTP al serverului,
por]iunea de HTML a paginii este transmis@ ca atare.
Por]iunile de cod ale paginii sunt executate la momentul
primirii cererii, }i con]inutul generat de acest cod este
ad@ugat la pagin@ ^nainte de a fi transmis@ utilizatorului.
Acest lucru permite separarea aspectelor de prezentare
HTML (forma), de logica programului (fondul), con]inut@ ^n
cod.

Incorporarea unui con]inut dinamic trebuie s@ presupun@

un anumit efort de programare care s@ descrie cum va fi
generat acel con]inut.

44
Din p@cate, codul program este scump de creat }i men]inut,
a}a c@ minimizarea nevoii de programare este un obiectiv
important. Combin$nd acest obiectiv cu obiectivul Sun
pentru un suport robust, cu capacit@]i complete pentru
servere, a rezultat un sistem template bazat pe Java, anume
JSP.
JSP constituie un hibrid ^n cadrul sistemelot template,
deoarece suport@ dou@ stiluri diferite de ad@ugare a
con]inutului dinamic la paginile web. La fel ca ASP, SSJS }i
PHP, ^n paginile JSP pot fi incluse scripturi care s@
con]in@ cod surs@. Pentru JSP, acest cod surs@ este de
obicei Java, dar poate fi aproape orice alt limbaj de script.
Asem@n@tor cu ColdFusion, JSP suport@ un set de
taguri care arat@ ca cele HTML }i care interac]ioneaz@
cu obiectele Java de pe server, f@r@ a fi nevoie s@ apar@
^n pagin@ cod Java brut.
Mai mult, dezvoltatorii au posibilitatea s@-}i creeze o
bibliotec@ de taguri personalizate care pot fi ^nc@rcate
^n pagini JSP, prin intermediul unui mecanism de extindere
a tagurilor. Aceste taguri personalizate pot fi folosite ^n
pagina JSP similar cu cele standard.
Tehnologiile sevlet }i JSP au ap@rut mai ^nt$i ca o parte
a Java Web Server de la Sun (un server HTTP scris ^n Java).
Apoi Java a publicat tehnologia servlet ca o extensie Java
standard. Cur$nd a urmat }i specifica]ia pentru JSP, anume
^n iunie 1999 a ap@rut JavaServer Pages 1.0 Specification.
Odat@ ce au existat aceste baze, alte companii au putut s@
adauge suport pentru arhitecura servlet produselor lor, }i
cum func]ionalitatea JSP ^n sine este implementat@ folosind
tehnologia servlet, o mul]ime de produse ter]e s-au
dezvoltat, cresc$nd popularitatea tehnologiilor.
%n plus, ^n iunie 1999 Sun MicroSystems }i funda]ia
Apache Software au anun]at proiectul Jakarta, al c@rui scop
este o implementare Open Source a servlet-urilor }i a JSP-
ului, urm$nd s@ rezulte o platform@ de referin]@.
JSP are condi]iile s@ joace un rol major ^n evolu]ia
tehnologiilor web.
%n figura de mai jos eviden]iem locul tehnologiei JSP ^n
cadrul unui server web.

45
Fig. 3.4.1 Rolul tehnologiei JSP ^n cadrul unui server

%n continuare vom eviden]ia beneficiile tehnologiei JSP.

3.5 Beneficiile tehnologiei JSP

Tehnologia JSP ofer@ c$teva beneficii ^n calitatea de

sistem pentru generarea dinamic@ a con]inutului. %n
primul r$nd, deoarece este o tehnologie bazat@ pe
Java, cuprinde toate avantajele pe care limbajul Java le
asigur@ pentru dezvoltare }i darea ^n exploatare. Limbaj
orientat obiect cu o tipizare strict@, ^ncapsulare, tratarea
excep]iilor }i management automat al memoriei, Java
determin@ cre}terea productivit@]ii muncii }i ob]inerea
unui cod mai robust.
Deoarece exist@ un API standard, f@cut public pentru JSP,
}i deoarece “bytecodes” Java sunt portabili pe toate
platformele care suport@ o JVM, utilizarea JSP-ului nu
conduce la dependen]a de o platform@ hardware, sistem de
operare sau server web particular. Dac@ este nevoie de

46
^nlocuirea unei astfel de componente, toate paginile JSP }i
clasele Java asociate pot migra a}a cum sunt.
%n plus, deoarece permite accesul complet la elementele
esen]iale ale platformei Java, JSP poate profita de celelalte
API-uri Java standard pentru acces la date de baze diferite,
programare distribuit@ sau criptografie.
Aceast@ calitate de a putea lucra cu o gam@ larg@ de
surse de date, resurse de sistem }i servicii de re]ea
^nseamn@ c@ JSP constituie o solu]ie flexibil@ pentru
crearea unor aplica]ii web cu facilit@]i bogate.
JSP ^n sine ofer@ un num@r de avantaje. Printre
aceste se num@r@ ^mbun@t@]irea performan]ei fa]@ de
CGI }i propunerea unui paradigme de programare care pune
accentul pe un model al aplica]iei centrat pe componente.
Acest model ^ng@duie dezvoltatorilor, c$nd folosesc JSP, s@
men]in@ o separare strict@ a elementelor de prezentare a
aplica]iei web, de implementarea intern@. Mai mult,
aceast@ separare faciliteaz@ diviziunea muncii ^n cadrul
unei echipe de dezvoltare web prin stabilirea unei interfa]e
bine definite ^ntre dezvoltarea aplica]iei }i designul paginii.

Performan]@

Codul CGI ia forma unor programe externe serverului

HTTP. C$nd serverul prime}te o solicitare care s@ fie
rezolvat@ de c@tre CGI, genereaz@ un proces nou pentru
fiecare cerere care s@ execute codul CGI. Acest lucru
faciliteaz@ serverelor web s@ gestioneze mai multe cereri
simultane ce solicit@ acela} program CGI, dar pentru cele
mai multe sisteme de operare, crearea unui proces este
costisitoare: memoria }i alte resurse de sistem trebuie s@
fie alocate iar datele }i codul programelor ^nc@rcate
^nainte de executarea codului.
Deoarece programele CGI sunt proiectate s@ genereze un
singur r@spuns petru o singur@ cerere, ele se execut@
rapid. Cu toate acestea, dup@ ce programul CGI s-a
^ncheiat, resurse de sistem suplimentare sunt consumate
c$nd procesul este distrus.

47
 JSP-urile sunt de obicei implementate prin servlet-uri.
C$nd un server web recep]ioneaz@ o cerere pentru o
pagin@ JSP, o ^nainteaz@ unui proces special destinat
gestiunii execu]iei servlet-urilor. Acest proces este cunoscut
drept containerul servlet. %n contextul JSP, ^i putem spune
^nc@ container JSP.
%n mod normal, containerul servlet este un proces
separat de serverul HTTP, ^n principal datorit@ faptului c@
este un proces Java ce ruleaz@ ^ntr-o JVM, ^n timp ce cele
mai multe servere sunt scrise ^n alte limbaje. A}adar unui
container servlet ^i este asociat un singur proces care
gestioneaz@ toate solicit@rile adresate servle-urilor sau JSP-
urilor. Acest proces este ini]iat atunci c$nd serverul HTTP
porne}te }i continu@ s@ ruleze p$n@ c$nd serverul este
^nchis. %n loc s@ creeze un proces nou pentru fiecare
cerere ce necesit@ generarea dinamic@ a con]inutului, toate
aceste cereri sunt ^naintate unui singur proces, containerul
servlet.
Containerul servlet gestioneaz@ concuren]ial cereri
multiple pentru un anumit servlet sau JSP, acest lucru fiind
realizat prin firele de execu]ie Java }i nu prin procese de sine
st@t@toare. Firele de execu]ie sunt similare proceselor ^n
sensul c@ mai multe fire de execu]ie pot rula simultan ^ntr-
o JVM. Ele necesit@ mult mai pu]in efort pentru creare }i
distrugere dec$t procesele, din acest motiv fiind numite
uneori “procese u}oare”. Deoarece folosesc mai pu]ine
resurse, sunt mai eficiente dec$t procesele. De exemplu,
procesele generate deseori copiaz@ memoria procesului
p@rinte, pe c$nd firele de execu]ie partajeaz@ memoria cu
firul de execu]ie p@rinte. Ca rezultat, servlet-urile }i JSP-urile
sunt mult mai eficiente dec$t programele CGI pentru
generarea dinamic@ a paginilor web.
Pentru o performan]@ sporit@, unele containere servlet
sunt capabile s@ ruleze ca o parte a procesului server HTTP
^n sine, chiar }i ^n cazul acelor servere care nu sunt scrise
^n Java. Astfel comunicarea dintre server }i container prin
cereri }i r@spunsuri devine mai eficient@, }i este realizat@
prin executarea containerului drept un fir de execu]ie ^n
cadrul serverului.

48
 Mai mult, deoarece toate servlet-urile }i JSP-urile sunt
gestionate de acela}i proces (JVM), este foarte u}or pentru
ele s@ partajeze resurse De exemplu utilizarea unui set de
conexiuni la baza de date reutilizabile, care r@m$n
disponibile JSP-urilor. Un program CGI deschide pentru
fiecare solicitare o conexiune la baza de date, }i apoi o
^nchide dup@ ce a r@spuns.

Componente reutilizabile

Chiar dac@ JSP ^ng@duie programatorilor s@

implementeze generarea dinamic@ a con]inutului prin
includerea de cod surs@ Java direct ^n paginile web, mai
ofer@ de asemenea un set de taguri asem@n@toare cu cele
HTML care pot intera]iona cu obiectele Java rezidente pe
server.
Specific, aceste taguri sunt proiectate pentru crearea,
interogarea }i modificarea componentelor JavaBeans de
pe server.
JavaBeans sunt obiecte scrise ^n Java, a c@ror
implemetare se conformeaz@ unui set de conven]ii de
proiectare care promoveaz@ modularitatea }i reutilizarea.
Componentele JavaBeans folosesc un stil de programare
care conduce la ob]inerea unor buc@]i de cod de program
care ^ncapsuleaz@ date, func]ionalit@]i }i comportamente
asem@n@toare, care ar putea fi folosite }i refolosite ^n
contexte multiple, f@r@ s@ fie necesar@ cunoa}terea
detaliilor opera]iilor interne.
Ca urmare, componentele JavaBeans pot cu u}urin]@
comunica }i s@ se combine pentru a oferi capacit@]i mai
sofisticate.
Termenul generic din tehnologia informa]iei pentru
obiectele care de]in un comportament interoperabil de tip
plug-and-play este component@. A}adar, JavaBeans este
un model de programare al componentelor, al@turi de alte
tehnologii, cum ar ActiveX de la Microsoft }i CORBA
dezvoltat de Object Management Group (OMG).
%n concluzie, o component@ este un obiect de sine
st@t@tor ce reprezint@ o colec]ie de propriet@]i }i

49
comportament. Deoarece aceste propriet@]i }i
comportamentul pot fi accesate f@r@ a ]ine seama de
implementarea intern@, este posibil s@ dispunem de
capacit@]ile unei componente independent de limbajul de
programare ^n care a fost scris@. Astfel ea ar putea fi
utilizat@ ^n alt limbaj de programare (de exemplu un limbaj
de script) sau chiar folosit@ de unelte vizuale, f@r@ a fi
necesar nici un fel de cod surs@.
%n cazul JSP-urilor, componetele JavaBeans sunt accesate
nu prin mijloace de programare ci printr-o sintax@
alternativ@. Mai exact, JSP ofer@ un set de taguri pentru
accesarea componentelor JavaBeans ^n pagin@ }i pentru
afi}area }i modificarea propriet@]ilor lor.
Principala calitate a proiect@rii axate pe componente este
reutilizarea. Deoarece componentele sunt de sine st@toare,
programatorii nu trebuie s@ ^n]eleag@ rela]iile complicate
dintre obiecte pentru a le putea folosi. O component@ poate
apela la alte obiecte, dar interfa]a abstract@ prin care
componenta este accessat@ }i manipulat@ va masca
complexitatea opera]iilor interne.
Deoarece componentele sunt proiectate pentru a servi
unei sarcini specifice (reprezentatea unui set particular de
date, realizarea unui comportament specific), este u}or s@
determin@m ce func]ionalitate ofer@ o component@ }i ^n
ce circumstan]e ar trebui folosit@.
Componentele sunt reutilizate deoarece sunt u}or de
folosit de la ^nceput. Beneficul acestei reutilizari este
^n mod evident productivitatea. Dac@ o component@
este disponibil@ pentru a ^ndeplini o sarcin@, atunci va fi o
bucat@ de cod surs@ mai pu]in de scris, testat }i men]inut.
Mai mult, componentele ^n general nu depind de context.
De exemplu, o component@ JavaBeans poate fi exploatat@
^ntr-un servlet, ^ntr-un applet sau ^ntr-o pagin@ JSP.

Separarea formei de implementare

Beneficiind de suportul integrat JSP pentru componente

JavaBeans, devine posibil@ men]inerea unei linii de
demarca]ie clare ^ntre prezentarea datelor- modul de

50
afi}are al informa]iilor c@tre utilizatorul final- }i
implementarea programului- codul folosit pentru generarea
informa]iilor. Avantajul separ@rii acestor dou@ aspecte este
c@ schimb@rile efectuate asupra uneia nu vor necesita
modific@ri ^n cealalt@ parte.
Modul ^n care datele sunt afi}ate (de exemplu selectarea
fontului, paleta de culori, cadrul paginii) pot fi rev@zute
f@r@ a se efectua modific@ri ^n codul Java. Analog, at$t
timp c$t interfe]ele componentelor r@m$n neschimbate,
implementarea intern@ poate fi rescris@ (de exemplu
pentru a ^mbun@t@]i performan]a sau mentenan]a) f@r@ a
afecta nici una din paginile JSP care utilizeaz@ acele
componente.
JSP asigur@ un mijloc foarte elegant }i simplu pentru
separarea celor dou@ elemente ale unei aplica]ii web:
sintaxa. Folosind tagurile pentru accesarea componentelor
JavaBeans, se pot scrie pagini JSP care s@ nu con]in@ cod
Java. Dac@ nici unul dintre tagurile existente nu asigur@
func]ionalitatea dorit@, se poate scrie propria bibliotec@ de
taguri utiliz$nd mecanismul JSP de extensie a tagurilor.
Prima regul@ pentru realizarea separ@rii prezent@rii de
implementare este ca o pagin@ JSP s@ con]in@ doar taguri
}i nici o linie cod Java, adic@ codul aferent implement@rii
s@ nu fie mixat cu codul necesar prezent@rii datelor.
A doua regul@ spune c@ o component@ JavaBeans nu
trebuie s@ con]in@ cod HTML.
JSP nu include taguri predefinite pentru a parcurge
propriet@]ile unui Bean. Pentru a rezolva aceast@ dilem@,
la prima vedere se pare c@ trebuie ales ^ntre a include cod
Java ^n pagina JSP, or Bean-ul s@ asigure output HTML. Din
fericire, JSP permite alt@ alternativ@, care fundamenteaz@
separarea prezent@rii de implementare: prin mecanismul
JSP de extindere a tagurilor, care este ilustrat ^n figura de
mai jos. Programatorii ^}i pot crea astfel biblioteci,
destinate gener@rii de HTML prin programare Java, care pot
fi apoi importate ^n paginile JSP.

51
 Fig. 3.5.1 Separarea prezent@rii de implementare

Tagurile personalizate (custom tags) au neajunsul c@

pentru a schimba modul de afi}are a datelor controlate de
ele, necesit@ programare. Dar acest lucru este inexorabil
c$nd generarea programatic@ a HTML-ului este o cerin]@.
Avantajul este ^ns@ c@ pe de o parte ele evit@ prezen]a
codului Java ^n pagini JSP, iar pe de alt@ parte, generarea
de HTML este izolat@ ^n codul bibliotecii de taguri.
%n concluzie, tagurile personalizate asigur@ o interfa]@
bine definit@ pentru separarea prezent@rii de
implementare.

Realizarea diviziunii muncii

O consecin]@ important@ a separ@rii prezent@rii de

implementare este promovarea de c@tre JSP a unei diviziuni
clare a muncii ^n dezvoltarea }i men]inerea aplica]iilor web
pentru generare dinamic@ a con]inutului.
Echipa de dezvoltare a unei aplica]ii web necesit@ mai
multe specializ@ri. Pentru prezentare sunt responsabili
designeri, graficieni }i codori HTML. De implementare se
ocup@ programatori Java }i arhitec]i de sistem.
Eficien]a va fi o consecin]@ direct@ a gradului ^n care
membrii echipei pot lucra independent. Atunci c$nd o
diviziune clar@ a muncii poate fi stabilit@, mai multe p@r]i
ale implemet@rii pot fi tratate simultan. Studiile au ar@tat
c@ productivitatea este dependent@ de comunicare; dac@

52
nevoile de comunicare pot fi reduse ^n cadrul fazei critice
de implementare, sporurile de productivitate pot fi
substan]iale.
De asemenea, modific@rile ulterioare ale aplica]iei pot fi
f@cute mai rapid dac@ este nevoie de mai pu]ini oameni
pentru a le efectua.
De obicei, aspectele de prezentare sunt supuse unor
constante revizii pentru a atrage aten]ia clien]ilor, pentru a
satisface cerin]a de u}urin]@ ^n folosire. Implementarea
afacerii din spatele aplica]iei tinde s@ evolueze mult mai
^ncet. Dac@ responsabilii pentru aceste dou@ elemente pot
lucra independent, atunci at$ dezvoltarea ini]ial@ c$t }i
rafin@rile ulterioare pot fi tratate mult mai eficient.
Practic, aceasta ^nseamn@ c@ designeri se pot concentra
pe HTML, iar proiectan]ii de aplica]ie pe Java. Echipa ca
^ntreg define}te cerin]ele care vor contura modelul
aplica]iei web. Programatorii apoi translateaz@ aceste
cerin]e ^ntr-un set de propriet@]i }i comportament care va
vor fi implementate drept componente JavaBeans. Aceste
componente vor asigura funda]ia pentru generarea
dinamic@ a con]inutului de c@tre echipa de prezentare prin
intermediul paginilor JSP. Astfel, odat@ acest@ funda]ie
construit@, ambele echipe pot lucra independent pentru a
rafina contribu]iile lor la aplica]ie (de exemplu ^nfrumuse]a
look-ul aplica]iei sau spori eficien]a la momentul execu]iei),
f@r@ a se afecta negativ performan]a celeilate echipe.

3.6 Compara]ie ^ntre JSP }i ASP

Vom realiza ^n continuare o compara]ie ^ntre tehnologiile

JSP }i ASP de la Microsoft.

JSP ASP
Suport Cele mai populare Suportat numai de
servere web servere web, inclusiv c@tre Microsoft IIS

53
 Apache, Netscape }i sau Personal Web
Microsoft IIS Server
Suport Independent de Suport complet pe
platforme platform@, ruleaz@ pe Windows.
toate platformele ce Exploatarea pe alte
suport@ JVM platforme este
dificil@ din cauza
modelului de
componente
Model de Se bazeaz@ pe Folose}te modelul
componente componente pe componente
reutilizabile, COM bazat pe
independente de WIN32
platform@ (JavaBeans,
Enterprise JavaBeans }i
biblioteci de taguri
personalizate)
Scripting Poate folosi limbajul Java Suport@ VBScript }i
sau JavaScript JScript
Securitate Se bazeaz@ pe modelul Poate lucra cu
de securitate Java arhitectura de
securitate a lui
Windows NT
Acces la Folose}te JDBC pentru Folose}te Active
baze de accesul la baze de date Data Objects
date
Extensibilita Este extensibil cu Nu poate folosi
te ajutorul bibliotecilor de biblioteci de
taguri personalizate taguri }i nu poate fi
extins

3.7 JSP sau servlet-uri?

Este adev@rat c@ at$t servlet-urile c$t }i JSP au multe

tr@s@turi comune }i pot fi folosite pentru a genera pagini
web dinamice. %n mod firesc, acest lucru d@ na}tere la
^ntrebarea c$nd se folose}te o tehnologie }i c$nd alta. %n

54
aceast@ privin]@ Sun ofer@ o serie de preciz@ri }i
recomand@ri.
Servlet-urile se folosesc strict numai ca extensii ale unui
server.
Acestea ar putea implementa componente specializate
pentru controlul autenticit@]ii, valid@ri asupra bazei de
date, etc. Este interesant de precizat c@ ceea ce este numit
container JSP (“JSP engine”) este de fapt un servlet
specializat ce ruleaz@ sub controlul containerului servlet.
Deoarece JSP lucrez@ doar cu date textuale, servlet-urile vor
fi folosite pentru comunicarea cu applet-uri }i alte aplica]ii.
Tehnologia JSP se utilizeaz@ pentru a dezvolta aplica]ii web
care au la baz@ con]inut dinamic. De asemenea el va fi
folosit ^n locul extensiilor de servere web particulare,
deoarece ofer@ mijloace deosebite pentru tratarea
con]inutului repetitiv.
Acestea sunt liniile mari de ghidare. Alte sugestii propuse:
- a nu se exagera cu folosirea codului Java ^n pagini
HTML- pentru aplica]ii simple aceast@ abordare este
corect@, dar pentru aplica]ii complexe ar da na}tere la mari
deficien]e: productivitate sc@zut@, dependen]@ ridicat@,
cod greu de ^nteles }i men]inut;
- alegerea mecanismului corect de includere- datele
statice sunt p@strate ^n fi}iere separate ce nu vor fi
regenerate }i care vor fi incluse ^n alte pagini;
- s@ nu se amestece prezentarea cu logica aplica]iei-
acest lucru este realizat prin componentele JavaBeans sau
Enterprise JavaBeans;
– este recomandat@ utilizarea tagurilor personalizate-
pentru asigurarea separ@rii prezent@rii de implementare;
- folosirea unui model de securitate portabil- pentru
ca dezvoltatorii
de aplica]ii s@ nu fie dependen]i de un server particular;
- folosirea unei baze de date pentru informa]iile
persistente;
- depozitarea con]inutului- con]inutul care nu se schimb@
^ntre dou@ cereri nu trebuie regenerat dinamic, el va fi
stocat pe ma}ina clientului;
- utilizarea unui set de conexiuni- pentru a putea partaja

55
eficient conexiunile la baza de date ^ntre solicit@ri;
- depozitarea rezultatelor interog@rilor pe baza de
date- este recomandat@ a nu se face cu un obiect JDBC
ResultSet ci cu un JavaBeans specific aplica]iei;

3.8 Componentele JavaBeans

A}a cum am v@zut deja, JavaBeans sunt componente

software scrise ^n Java. Componentele ^n sine se cheam@
Beans }i trebuie s@ se conformeze la specifica]iile descrise
^n API-ul JavaBeans. API-ul JavaBeans a fost creat de Sun }i
specific@ regulile pe care trebuie s@ le urmeze dezvoltatorii
de software pentru a crea componente software de sine
st@t@toare }i reutilizabile.

Containere Bean

Un container Bean este o aplica]ie, un mediu sau un

limbaj de programare care permite dezvoltatorilor s@
apeleze Bean-uri, s@ le cofigureze }i s@ le acceseze
informa]iile }i func]iile. Aplica]iile care folosesc Bean-uri sunt
compuse din cod Java pur, dar containerele Bean permit
programatorilor s@ lucreze cu ele la un nivel mai elevat.
Acest lucru este posibil deoare componentele JavaBeans
pun la dispozi]ie containerullui Bean caracteristicile }i
func]iile lor, facilit$nd programatorilor lucrul cu ele ^ntr-o
manier@ mai intuitiv@. Astfel, containerul Bean define}te
propria modalitate de prezentare }i interac]iune cu Bean-
ul }i scrie codul Java rezultat singur.
Containerele JSP faciliteaz@ dezvoltatorilor s@ creeze
aplica]ii web Java f@r@ a scrie cod surs@. %n JSP
interac]iunea cu Bean-uri se face printr-o colec]ie de taguri
care pot fi integrate ^n HTML.

Proprit@]ile Bean-urilor

56
 Lucrul cu Bean-uri se face prin intermediul propriet@]ilor
lor.
Propriet@]ile sunt numele atributelor Bean-ului care men]in
starea lui }i care ^i controleaz@ comportamentul. Un Bean
este definit de propriet@]ile sale. Ele pot fi modificate la
momentul execu]iei de c@tre containerul Bean. Valorile
acestor propriet@]i constituie singurul mecanism pe care
containerul Bean ^l folose}te pentru a “etala” Bean-ul
programatorului.
Fiecare Bean va avea un set diferit de propriet@]i
depinz$nd de tipul informa]iei pe care o con]ine. Se poate
adapta un Bean prin setarea valorilor propriet@]ilor.
Creatorul unui Bean va impune restric]ii pe fiecare
proprietate pentru a controla accesul la ea. O proprietate
poate fi doar citit@, doar modificabil@, sau citit@ }i
modificabil@. Conceptul de accesibilitate permite
proiectantului Bean-ului s@ impun@ limite ^n privin]a
folosirii lui.
Unele propriet@]i sunt folosite pentru a declan}a
comportamentul }i sunt numite propriet@]i
declan}atoare. Citirea sau scierea unei propriet@]i
declan}atoare semnaleaz@ Bean-ului s@ execute o ac]iune.
Dou@ propriet@]i care au caracteristica c@ modificarea
uneia atrage dup@ sine modificarea celeilalte se numes
propriet@]i legate.
Proprietatea care stocheaz@ o colec]ie de valori se
nume}te proprieate indexat@, deoarece o valoare
stocat@ este accesat@ printr-un index ce specific@ care
valoare particular@ este solicitat@.
Propriet@]ile unui Bean pot s@ ]in@ o gam@ larg@ de
tipuri de informa]ie. O proprietate poate stoca un singur tip:
numeric, string, obiecte predefinite sau definite de
utilizator }i chiar alte Bean-uri.
Containerul Bean va determina cum se lucreaz@ cu
propriet@]ile unui Bean. Astfel, buc@]ile de cod Java vor
referi valoarea prin tipul Java. %n schimb, tagurile Bean
trateaz@ fiecare valoare drept text, containerul JSP realiz$nd
toate conversiile necesare.

57
 Capacit@]ile unui Bean sunt documentate ^ntr-un tabel
numit foaia de propriet@]i, care cuprinde toate
propriet@]ile disponibile pentru un Bean, precum }i nivelul
lor de acces pentru utilizator }i tipul Java aferent.
Prin aceste foi de propriet@]i, proiectan]ii de Bean-uri
descriu tr@s@turile unui Bean celor care le utilizeaz@:
dezvoltatori JSP, programatori de servlet-uri, etc.

Exist@ mai multe categorii de Bean-uri. Generic ele se pot

^ncadra ^n trei categorii:
- componente Bean visuale- sunt folosite ca elemente
^n programarea GUI (graphical user interfaces);
- Bean-uri de date- ofer@ acces la o colec]ie de
informa]ii;
- Bean-uri lucr@tori (servicii Bean)- care pot executa
sarcini sau
calcule specifice.
Bine^n]eles, unele Bean-uri pot avea caracteristici
specifice mai multor categorii.

58