UNIVERSITATEA DIN CRAIOVA

Facultatea de Matematic - Informatic

Specializarea Informatic

WEBSITE CU INFORMAII MEDICALE

INDRUMTOR TIINIFIC:
Lect. dr. PETRE BZVAN
ABSOLVENT:
BOLCU SORIN

Craiova
2006

CUPRINS

CAPITOLUL I..............................................................................................................................................................5
DEZVOLTAREA APLICAIILOR PENTRU INTERNET.....................................................................................5
1.1 Sisteme de gestiune a bazelor de date..............................................................................................................5
1.1.1 Istoria sistemelor de gestiune a bazelor de date............................................................................................5
1.1.2 Arhitectura global a sistemelor de gestiune a bazelor de date....................................................................7
1.1.3 Obiective.......................................................................................................................................................9
1.1.3.1 Abstractizarea i structurarea datelor.....................................................................................................9
1.1.3.2 Independena fizic i logic................................................................................................................10
1.1.3.3 Reducerea redundanei i inconsistenei..............................................................................................10
1.1.3.4 Optimizarea accesului la date..............................................................................................................10
1.1.3.5 Securitatea i confidenialitatea datelor...............................................................................................10
1.1.3.6 Partajabilitatea datelor..........................................................................................................................11
1.1.4 Scheme i instanieri...................................................................................................................................11
1.1.5 Interfee.......................................................................................................................................................11
1.1.5.1 Interfee meniu.....................................................................................................................................12
1.1.5.2 Interfee grafice....................................................................................................................................12
1.1.5.3 Interfee bazate pe forme.....................................................................................................................12
1.1.5.4 Interfee n limbaj natural.....................................................................................................................12
1.1.5.5 Interfee pentru utilizatorii parametrici................................................................................................12
1.1.5.6 Interfee pentru administratorul BD.....................................................................................................13
1.2 Miniservere (servleturi)...................................................................................................................................14
1.2.1 Introducere..................................................................................................................................................14
1.2.2 Comparaie CGI Servlet...........................................................................................................................15
1.2.3 Cteva din capabilitile servlet-urilor........................................................................................................15
1.2.4 Avantajele servlet-urilor..............................................................................................................................16
1.2.5 Manipularea cererilor fcute de utilizatori..................................................................................................16
1.2.6 Anatomia unui servlet HTTP......................................................................................................................17
1.2.7 Arhitectura pachetelor javax.servlet i javax.servlet.http...........................................................................18
1.2.8 Interaciunea cu clienii...............................................................................................................................19
2

1.2.8.1 Cereri i rspunsuri..............................................................................................................................19

1.2.8.2 Deservirea clienilor.............................................................................................................................20
1.3 Java Database Connectivity - JDBC..............................................................................................................21
1.3.1 Drivere JDBC..............................................................................................................................................21
1.3.2 Accesarea unei baze de date folosind JDBC...............................................................................................22
1.3.2.1 nregistrarea driver-ului JDBC............................................................................................................22
1.3.2.2 Stabilirea conexiunii ctre baza de date...............................................................................................23
1.3.2.3 Execuia unei instruciuni SQL............................................................................................................23
1.3.2.4 Procesarea rezultatelor.........................................................................................................................24
1.3.2.5 nchiderea conexiunii la baza de date..................................................................................................24
CAPITOLUL II...........................................................................................................................................................26
TEHNOLOGII FOLOSITE.......................................................................................................................................26
2.1 Tehnologia Java Server Pages.........................................................................................................................26
2.1.1 Pagini Web generate dinamic - un posibil rspuns.....................................................................................26
2.1.2 Ce este JSP?................................................................................................................................................28
2.1.3 Pagini JSP...................................................................................................................................................30
2.1.4 Tipuri de aplicaii pentru JavaServer Pages................................................................................................33
2.1.5 ASP sau JSP ?..............................................................................................................................................34
2.1.6 Diferena dintre servlet, scriptlet i pagina JSP..........................................................................................34
2.1.7 Concluzii.....................................................................................................................................................34
2.2 MySQL..............................................................................................................................................................35
2.2.1 Introducere..................................................................................................................................................35
2.2.2 De ce s optez pentru MySQL?..................................................................................................................37
2.2.3 Instrumente furnizate cu MySQL...............................................................................................................40
2.2.4 MySQL este gratuit?...................................................................................................................................40
2.2.5 O not despre licena Windows...................................................................................................................41
CAPITOLUL III.........................................................................................................................................................43
PREZENTAREA APLICAIEI................................................................................................................................43
3.1 Descrierea aplicaiei.........................................................................................................................................43
3.1.1 Descrierea tabelelor folosite.......................................................................................................................43
3.1.2 Operaiile efectuate pe tabele......................................................................................................................46
3.1.2.1 Adugarea unui nou pacient.................................................................................................................46
3.1.2.2 tergerea unui pacient..........................................................................................................................46
3.1.2.3 Cutarea unui pacient...........................................................................................................................47
3.1.2.4 Modificarea datelor unui pacient.........................................................................................................48
3

3.1.2.5 Actualizarea registrului unui pacient...................................................................................................48

3.1.2.6 Vizualizarea listei pacienilor...............................................................................................................49
3.2 Structura site-ului............................................................................................................................................50
3.3 Rularea aplicaiei.............................................................................................................................................50

Capitolul I
Dezvoltarea aplicaiilor pentru internet

1.1 Sisteme de gestiune a bazelor de date

O baz de date (BD) este o mulime structurat de elemente de date i de legturi logice
dintre ele ce descriu un univers real sau conceptual (o ntreprindere, o organizaie, o societate de
asigurri, eveniment etc.), ce pot fi accesate simultan de mai muli utilizatori.
Un sistem de gestiune al unei baze de date (SGBD) este un software utilizat pentru
crearea, ntreinerea si exploatarea unei baze de date i care d posibilitatea mai multor utilizatori
s aib acces simultan la datele care o compun.

1.1.1 Istoria sistemelor de gestiune a bazelor de date

Sistemele de gestiune a bazelor de date (SGBD) au o vechime de aproape patru decenii. n
anul 1960 s-a realizat prima dezvoltare a sistemelor de gestiune ale fiierelor (SGF) pentru
memoriile secundare direct accesibile i partajabile, care a constituit inima unui SGBD. Prima
generare a unui SGBD a fost marcat de separarea descrierii datelor de programele de aplicaii i
de apariia limbajelor de manipulare. Aceste SGBD permit s se caute date grupate n articole, n
structuri arborescente i au ca obiectiv optimizarea memorrii datelor pe suport i reducerea
timpului de acces. Din aceast generaie fac parte IMS, DBMS elaborate de IBM, SOCRATE
elaborat de CII etc.
A doua generaie de SGBD care a aprut dup anul 1970 se bazeaz pe modelul relaional
dat de E.Codd vizeaz simplificarea nelegerii, optimizarea structurilor de date i optimizarea
accesului la date pentru utilizatorii externi. Ele ofer limbaje aserionale bazate pe logic care
specific datele pe care dorim s le obinem. Acest sistem d un mod eficient de structurare bazat
pe teoria normalizrii i determin cel mai bun plan de acces la informaiile pe care dorim s le
obinem. La nceputul deceniului al IX-lea al secolului XX, termenii de model relaional, baz
relaional de date, calcul relaional, au devenit uzuali n metodologia proiectrii i utilizrii
bazelor de date. Aceast generaie, a crei fundamentare teoretic se bazeaz pe teoria relaional
a cunoscut cea mai rapid dezvoltare. Primele sisteme din aceast generaie au fost
comercializate dup anul 1980. Pentru crearea modelului relaional al bazelor de date E.F.Codd a
5

primit n anul 1981 premiul Turing pentru informatic.

La rspndirea rapid a modelului relaional au contribuit factorii urmtori :

omogenitatea reliefat de structurile de date i de memorare
bazele de date relaionale pot fi imaginate independent de structura sistemului de

calcul. Mulimile utilizate cel mai mult n practic sunt tabelele bidimensionale. n
acest caz cutarea i prelucrarea datelor nu depind de modul de organizare i
memorare a datelor n calculator
din punct de vedere matematic, bazele relaionale de date sunt instanieri distincte
de scheme de relaii definite anterior din mulimi de atribute (elemente de date)

Cu alte cuvinte, o baz relaional de date este un model finit n sensul logicii elementare.
Modelul relaional permite realizarea de diferite operaii algebrice. Teoria bazelor relaionale de
date devine domeniul de aplicare a logicii matematice i al algebrei moderne, care opereaz cu
un formalism exact.
O a treia generaie care s-a preconizat dup anul 1990 este aceea a bazelor de date
obiectuale ( orientate obiect). Sistemele de gestiune a bazelor de date obiectuale (SGBDOO)
permit administrarea datelor complexe din domeniile: ingineria software, sisteme multimedia,
gestiunea documentelor, CAD etc. Aceste sisteme trebuie s integreze sistemele relaionale de
baze de date existente. SGBD-urile relaionale au fost dezvoltate pentru aplicaii de gestiune n
care datele sunt separate de programe. Acestea nu cuprind noiunile de obiect i clas. Limbajele
de interogare ale SGBD-urilor furnizeaz mulimi de tupluri programelor de aplicaii care sunt
apoi transformate n structuri complexe.
SGBDOO-urile din generaia a III-a au fost realizate pe dou ci. Prima const n
extinderea modelului relaional. Extensia se face prin introducerea de noi concepte ca: obiect,
clas, operaor ataat unei proceduri, integrare i generalizare. Operaorii sunt considerai ca
atribute ale unei relaii i permit definirea de noi atribute. Operaorii pot fi coninui n cererile
de interogare exprimate prin procedurile asociate. n acest caz, majoritatea SGBDOO concep
atributele ca obiecte ne aparinnd tipurilor elementare de baz, ceea ce face ca bazele de date
orientate pe obiect s nu respecte restricia impus de prima form normal, deoarece atributele
nu mai sunt atomice. ns dependenele multivoce permit introducerea de forme normale
adecvate.
A doua abordare, se bazeaz pe modele obiectuale n care un obiect este definit fie de o
relaie, fie definit recursiv. Atributele unui obiect pot fi alte obiecte. De exemplu, sintaxa lui
6

Gem Stone integreaz majoritatea funciilor SGBDR i un limbaj orientat pe obiecte pentru a
putea defini schema bazei de date, pentru a manipula obiecte i a codifica aplicaii. Legtura
dintre baza de date i limbajul de programare permite combinarea avantajelor programrii
orientat pe obiecte a BDOO, cu proprietile de integritate i partajare. Legturile dintre obiecte
sunt conservate la nivelul BDOO i permit luarea n considerare a dinamicii obiectelor din lumea
real, stocnd o dat cu obiectele i operaiile pe care le suport.

1.1.2 Arhitectura global a sistemelor de gestiune a bazelor de date

Un sistem de gestiune a bazelor de date (SGBD) este compus din module, fiecare avnd n
cadrul sistemului sarcini specifice. Anumite funcii pentru sistemul de baze de date sunt asigurate
de nucleul su i de nucleul sistemului de operare. Cele mai multe SGBD asigur un minim de
funcii de baz cu ajutorul crora sunt dezvoltate alte funcii. Astfel la conceperea unei baze de
date trebuie s se in seama de interfeele dintre diverse module. Schema din figura de mai jos
schieaz structura unui SGBD.
n continuare se prezint pe scurt funciile fiecrui modul din structura SGBD.
- Gestionarul bazei de date realizeaz interfaa dintre programele de aplicaii sau de
consultare i datele fizice ale bazei de date .
- Gestionarul de fiiere specific alocrile de memorie pe disc i structurile de memorare
care servesc la reprezentarea informaiilor pe disc.
- Procesorul de consultare traduce instruciunile limbajului de consultare n instruciuni
nelese de gestionarul bazei de date. Transpune interogrile utilizatorului ntr-o forma
echivalent optimizat, n vederea determinrii celor mai bune strategii de cutare.
- Definirea schemelor bazei de date (schemei conceptuale) i a legturilor dintre ele se
efectueaz de administratorul BD, cu ajutorul unui limbaj de definire a datelor (LDD) prevzut
cu un compilator ce permite crearea dicionarului de date. Structura de date este o mulime de
elemente de date, de legturi care exist ntre ele i de operaii efectuate cu ele.
- Precompilatorul LMD (limbaj pentru manipularea datelor) genereaz coduri obiect ale
programelor realizate cu ajutorul LMD. LMD permite ca programatorii de aplicaii i
neinformaticienii s manipuleze date puse n eviden de scheme de orice nivel.
Dicionarul de date este dat de o mulime de scheme i de legturi dintre schemele asociate
ale bazei de date, de descrierile semnificaiilor datelor i a restriciilor pe care acestea trebuie s
le satisfac. Dicionarul de date poate fi el nsui implementat ca o baz de date. El constituie
7

atunci o metabaz, adic o baz care descrie o alt baz.

Arhitectura SGBD

Utilizatorul este o persoan, care de la un terminal are acces la baza de date folosindu-se de
o mulime de programe de aplicaii sau de comenzile unui limbaj de consultare. Accesul la baza
de date se realizeaz fie pornind de la un program de aplicaii redactat ntr-un limbaj (C, java
,Pascal etc.) care accept primitive (secvene de instruciuni de program) ce permit accesul la
baza de date, fie de la un terminal utiliznd un limbaj specific LMD. Pe de alt parte dac LMD
de nivel nalt este utilizat ntr-o manier interactiv atunci acesta se numete limbaj de
interogare ( LI).
Administratorul BD rspunde pe lng activitatea de definire a schemei BD, de creare i
manipulare. Pentru aceasta administratorul BD dispune de un software specializat i are
urmtoarele sarcini:
- concepe schema bazei de date ( o descriere prin intermediul LDD). Schema trebuie s fie
8

independent de structura de memorare (stocarea fizic) i de limbajul n care se descriu

aplicaiile. El odat cu schema asociaz i restriciile de integritate i ce garantez consitena
datelor ce sunt nregistrate n BD
- decide tehnicile de acces i de implementare fizic
- stabilete legturile SGBD-utilizator prin descrierea subschemelor care sunt
derivate din schema BD. Subschema permite definirea autorizaiilor de acces
- definete strategiile de reluare n caz de incident
- realizeaz n consecin modificarea structurii BD
SGBD trebuie s permit utilizatorului s genereze versiuni de BD performante innd cont
de nmulirea utilizatorilor. El dispune de un software care i restituie descrierea schemei BD ce
este nregistrat n dicionarul BD.

1.1.3 Obiective
1.1.3.1 Abstractizarea i structurarea datelor
Prezentarea sub o form abstract i structurat a datelor consituie un important obiectiv al
unui SGBD. Elaborarea de structuri complexe de date nainte de memorarea lor n fiierele bazei
de date este necesar pentru mrirea eficienei acesteia. Structura bazei de date este determinat
de o mulime de scheme (tipuri de date), relaii, legturi ntre date, restricii pe care datele trebuie
s le satisfac i de semantici. Descrierea unei baze de date trebuie judecat pe baza unei
modelri. Un model const dintr-o mulime de concepte ce permit descrierea corect a structurii
bazei de date. Cele mai multe din modele includ i operatori specifici de cutare i actualizare
ntr-o baz de date. Modelele de date bazate pe tipuri de concepte ce descriu baza se clasific n:
modele de date fizice sau de nivel inferior ce cuprind concepte ce descriu datele aa

cum sunt memorate (ordinea nregistrrilor etc.)

modele logice (conceptuale) sau de nivel nalt orientate pe "nregistrri" sau pe
"obiecte" descriu datele pentru clase mari de utilizatori

Ele se caracterizeaz prin flexibilitatea descrierii i explicitrii structurilor i restriciilor de

date. Modele de date de nivel nalt utilizeaz concepte de: atribute, relaii, entiti i obiecte.
Entitatea este un obiect fizic sau conceptual care este reprezentat ntr-o baz de date. Legturile
9

dintre obiecte sunt uor de reprezentat cu ajutorul modelelor de nivel nalt numite modele
orientate-obiect. Dintre modelele implementate pn n prezent amintim: modele ierarhice,
modele reea, modele relaionale, modele orientate obiect. Primele trei reprezint datele utiliznd
structura de nregistrare, de aceea sunt frecvent numite modele bazate pe nregistrri.
1.1.3.2 Independena fizic i logic
Independena structurilor fizice permite stocarea structurilor de memorare dintr-un univers
real sau conceptual, independent de structurile de date cu scopul realizrii unui acces simplu la
date. Independena logic se refer la posibilitatea de a aduga i a modifica nregistrrii i
scheme fr a rescrie programele existente.
1.1.3.3 Reducerea redundanei i inconsistenei
Crearea fiierelor se face n general n perioade de timp diferite. Aceasta face ca aceleai
informaii s fie replicate n mai multe fiiere. Aceste redundane cresc inutil volumul global al
bazei de date. Timpul de acces crete. Crete i riscul de a avea inconsisten n datele memorate.
Faptul c, copiile ale acelorai date stocate n diverse locuri nu concord ntre ele, deoarece ele
nu au fost actualizate n acelai timp determin inconsistena.
1.1.3.4 Optimizarea accesului la date
SGBD-ul trebuie s fie prevzut cu un procesor de optimizare a operaiilor exprimate de
informaticieni cu ajutorul unui limbaj de manipulare i de neinformaticieni cu ajutorul unui
limbaj neprocedural. Limbajele neprocedurale permit utilizatorilor s descrie ceea ce vor s
obin fr a indica modul cum se obine. Posibilitatea de a manipula date cu ajutorul unor
limbaje neprocedurale i de neinformaticieni, independent de implementarea lor constituie o
generalizare a manipularii datelor.
1.1.3.5 Securitatea i confidenialitatea datelor
Datele trebuie protejate de accese neautorizate i ru intenionate. SGBD-ul trebuie s
gestioneze accesul la informaii i la tipurile de operaii pe care fiecare utilizator le poate efectua
i s valideze aceste operaii. De asemenea se realizeaz o protejare prin parolare i criptare
mpotriva accesului neautorizat.

10

1.1.3.6 Partajabilitatea datelor

Partajabilitatea datelor determin folosirea bazei simultan de mai multe aplicaii. Asigur
gestiunea tranzaciilor i a prelucrrilor concurente. Tranzacia este o unitate de prelucrare care
transform o instan consistent a bazei n alt instan consitent. SGBD-ul trebuie s
paralelizeze sau s detecteze cazurile de interblocare (cnd o tranzacie ateapt date deinute de
alte tranzacii).

1.1.4 Scheme i instanieri

n orice model este important s se fac o distincie ntre descrierea unei BD i BD nsi.
Descrierea bazei de date formeaz schema bazei de date. O schem a BD este specificat n
timpul proiectrii. Cele mai multe modele cuprind anumite convenii i metareguli pe baza crora
se construiesc schemele bazei de date care sunt numite diagrame schem. Fiecare element din
diagrama schemei se numete component constructiv (constructor de schem ) a schemei.
O diagram a schemei afieaz numai anumite aspecte ale schemei ca: numele relaiei,
elementele de date i anumite tipuri de restricii. Totui n diagrama schemei BD nu sunt
specificate tipul fiecrui element de date i alte tipuri de restricii. Datele actuale dintr-o BD pot
fi schimbate relativ frecvent.
Datele dintr-o BD la un anumit moment de timp formeaz o instaniere a BD (ocuren sau
stare), care corespunde unei scheme.
n orice moment cnd vom insera sau terge valori, vom schimba o instaniere a BD cu o
alt instaniere. Distincia ntre schema bazei de date i instanierea bazei de date este foarte
important. Cnd definim o nou BD noi vom specifica schema BD. n acest moment BD este
vid deoarece nu are nici o dat. Vom numi instaniere iniial a BD cnd datele sunt prima dat
ncrcate.

1.1.5 Interfee
SGBD-ul trebuie s suporte interfee i limbaje apropiate pentru fiecare categorie de
utilizatori. n acest paragraf se prezint pe scurt diverse tipuri de interfee pentru un SGBD. n
mod frecvent, exist interfee prietenoase cu utilizatorii pentru interacionare cu baza de date.
Interfeele prietenoase cu utilizatorii pot fi mprite n urmtoarele categorii:

11

1.1.5.1 Interfee meniu

Aceste interfee prezint utilizatorului o list de opiuni numit meniu, pe baza cruia
utilizatorul i formuleaz cererea. Meniurile conduc pe de o parte la nevoia de a memora
comenzile specifice i a sintaxei limbajului, pe de alt parte. ntrebarea este compus pas cu pas
prin precizarea opiunilor din lista meniului care este afiat de sistem.
1.1.5.2 Interfee grafice
O interfa grafic va afia o schem pentru utilizator sub forma unei diagrame.
Utilizatorul poate specifica ntrebarea prin manipularea diagramei. n multe cazuri, interfaa
grafic poate fi combinat cu o interfa bazat pe meniu. Cele mai multe interfee grafice vor
utiliza un dispozitiv de punctare cum ar fi mouse-ul sau stiloul luminos, pentru a puncta anumite
pri ale afirii diagramei schemelor.
1.1.5.3 Interfee bazate pe forme
O interfa bazat pe forme afieaz o form pentru utilizator. Utilizatorul poate s obin
sub o anumit form toate nregistrrile sau noi date. Multe din SGBD-uri au limbaje speciale
numite limbaje de specificare a formelor care ajut programatorii s-i specifice cererile.
1.1.5.4 Interfee n limbaj natural
Aceste interfee accept cererile scrise n limba englez sau ntr-un alt limbaj care este
neles. Interfaa ntr-un limbaj natural, n mod obinuit are o schem proprie care este ca o
schem conceptual a bazei de date. Interfaa face referin la cuvintele schemei care fac parte
dintr-o mulime de cuvinte standard ce compun ntrebarea. Dac interpretarea este realizat,
interfaa genereaz o ntrebare la nivel nalt care corespunde cererii n limbaj natural admis de
SGBD pentru prelucrare; n caz contrar dialogul este nceput cu utilizatorul pentru a clarifica
ntrebarea.
1.1.5.5 Interfee pentru utilizatorii parametrici
Utilizatorii parametrici, ca de pild funcionarii de banc au la dispoziie o mulime de
aplicaii care sunt repetate de multe ori. Analitii de sistem i programatorii, n mod frecvent,
proiecteaz i implementeaz o interfa special pentru o clas cunoscut de utilizatori. Frecvent
se utilizeaz o mulime mic de abrevieri ale comenzilor cu scopul de a minimiza numrul de
taste apsate la fiecare cerere. Astfel de interfee pot fi numite limbaje de comand.
12

1.1.5.6 Interfee pentru administratorul BD

Cele mai multe SGBD-uri au posibilitatea de a crea comenzi privilegiate care vor fi
utilizate numai de administratorul BD. Aceste interfee includ comenzi pentru creare, setarea
parametrilor sistemului; de asemenea garanteaz autorizarea, schimb schema i organizeaz
structura de memorare a fiierelor BD.

13

1.2 Miniservere (servleturi)

1.2.1 Introducere
WEB-ul a trecut printr-o transformare rapid. Paginile statice HTML au fost schimbate cu
pagini generate n mod dinamic. Avantajul acestor pagini este c informaia coninut n ele poate
reflecta de exemplu coninutul unei magazii cu stocul n continu schimbare. Crearea acestor
pagini

necesit

ns

mult

munc

de

programare.

Java cu ajutorul apleturilor ajut la crearea aplicaiilor pe partea clientilor. Pe partea

serverelor s-au introdus servleturile. Servletul este un mecanism de generare a acestor pagini
dinamice

HTML,

oferind

deservirea

rapid

eficient

clienilor.

naintea servleturilor partea de server a aplicaiilor client/server era ajutat de scripturi

CGI (Common Gateway Interface). CGI permitea i evaluarea formularelor trimise de ctre
clieni.
Servleturile sunt tehnologie Java care rspund programrii CGI. Servlet-urile sunt
programe care ruleaz pe servere WEB, fiind poziionate ntre cererile care vin de la browser sau
de la un client HTTP i bazele de date sau aplicaii de pe serverul de HTTP.
Un servlet reprezint o component web, gestionat de un container, care genereaz
coninut dinamic. Servlet-urile sunt clase Java, ce ofer independen de platform i sunt
ncrcate i executate dinamic de ctre server. Servlet-urile comunic cu clienii pe baza
paradigmei cerere rspuns. Acest model cerere rspuns se bazeaz de obicei pe protocolul
Hypertext Transport Protocol (HTTP).
Containerul de servleturi este o component ce ofer servicii de reea prin intermediul
crora servleturile primesc i transmit cereri i rspunsuri de la i ctre clieni. Containerul de
servleturi nmagazineaz servleturile i este responsabil pentru gestionarea acestora. Un
container poate exista n cadrul unui server web sau poate fi adugat ulterior utiliznd
mecanismul de extensie al serverului.
Exemplu: Un program client (web browser) acceseaz un server web i transmite o cerere
HTTP (poate fi de exemplu un form completat cu datele unei persoane).
Aceast cerere este preluat de ctre serverul de web i n cazul n care este destinat unui
servlet, este transmis mai departe ctre containerul de servleturi. Containerul determin crui
14

servlet i este adresat cererea i va invoca respectivul servlet, transmindu-i ca parametri dou
obiecte cerere (request) i rspuns (response).
Servletul va utiliza obiectul request pentru a determina cererea fcut de clientul web.
Dup realizarea operaiilor necesare (de exemplu scrierea sau citirea unor date dintr-o baz de
date), servletul va tansmite ctre client un rspuns prin intermediul obiectului response.
Servlet-urile ruleaz pe server.

1.2.2 Comparaie CGI Servlet

Scripturile CGI sunt mai puin eficiente dect servleturile. n cazul utilizrii CGI pentru
deservirea unui client se creaz un proces nou n care se execut scriptul CGI. Scriptul genereaz
pagina HTML i trimite clientului. Crearea unui proces nou este o operaie costisitoare din
punctul de vedere al sistemului de operare.
Servletul face acelai lucru ca un script CGI, ns servletul se ruleaz pe un fir de
execuie separat al procesului web server. Crearea unui fir de execuie este mult mai eficient
dect crearea unui proces nou. Pe lng eficien servleturile mai au o caracteristic important,
securitatea. Firele de execuie sunt create de ctre maina virtual Java i posed toate facilitiile
oferite de aceasta din punctul de vedere al securitii.

1.2.3 Cteva din capabilitile servlet-urilor

Principalele capabiliti ale servlet-urilor sunt:
1. pot citi datele trimise de useri: aceste date sunt, de obicei, introduse ntr-un
formular WEB sau pot proveni dintr-un applet Java sau de la un program client de
HTTP
2. pot formata rezultatele ntr-un document: n cele mai multe cazuri, aceasta
implic inserarea informaiei ntr-o pagin HTML
3. pot seta parametrii HTTP de rspuns: se informeaz browser-ul ce tip de
document este returnat (HTML, de exemplu), se seteaz cookies etc.
4. trimit documentul inapoi la client: documentul poate fi trimis n format Text
(HTML), n format binar (imagini GIF), sau chiar n format compresat

15

Servlet-urile nu sunt restricionate numai la WEB sau aplicaii server care manipuleaz
cereri HTTP; de asemenea pot fi folosite i pentru alte tipuri de servere. De exemplu, servleturile pot fi inserate n servere de email sau FTP.

1.2.4 Avantajele servlet-urilor

1. Eficiena
n programarea CGI, pentru fiecare cerere HTTP se ncepe un nou proces. n cazul
servlet-urilor, maina virtual Java rmne n execuie i fiecare cerere este rezolvat printr-un
thread, nu printr-un proces al sistemul de operare ca n cazul CGI. n CGI, rezolvarea a N cereri
simultane pentru acelai program se realizeaz prin ncrcarea codului programului CGI de N
ori. n cazul servlet-urilor exist N thread-uri, dar o singur copie a clasei servlet.
Cnd un program CGI a terminat manipularea unei cereri, programul se termin.
Servleturile rmn n memorie chiar i dup ce rspunsul a fost complet.
2. Putere
Servlet-urile pot comunica direct cu serverul WEB. Mai multe servlet-uri pot mpri
date, fcnd mult mai uoar conectarea cu baza de date.
3. Portabilitate
Servlet-urile sunt scrise n Java i pot rula pe servere ca Apache, Microsoft Internet
Information Server (IIS), IBM WebSphere sau StarNine WebStar, fr vreo schimabare a
codului.
Servlet-urile sunt acum parte din Java 2 Platform, Enterprise Edition (J2EE).

1.2.5 Manipularea cererilor fcute de utilizatori

Una dintre motivaiile pentru crearea paginilor WEB dinamice este ca rezultatul s se
bazeze pe datele introduse de user. De exemplu ntr-un URL de forma http://localhost/path?
user=Mihai&student=yes&bursier=no, partea dup semnul ntrebarii este cunoscut ca date
formular sau date interogare i este folosit pentru a duce informaia dintr-o pagin WEB la
un program de pe server. Datele formularului pot fi ataate la sfritul URL-ului dup semnul
16

ntrebrii pentru cereri GET, sau pot fi trimise la server ntr-o linie separat, pentru cererile
POST.
Citirea datelor formularului din servlet-uri: se poate face simplu prin apelarea metodei
getParameter din clasa HttpServletRequest, furniznd numele parametrului ca argument al
metodei. Metoda getParameter se folosete n acelai mod att pentru date trimise prin GET,
ct i pentru cele trimise prin POST. Servletul tie ce metod pentru cerere a fost folosit.
Valoarea returnat este de tipul String corespunztoare valorii din URL a primei apariii a
numelui parametrului. Stringul este gol dac parametrul nu are nici o valoare i null dac nu
exist un astfel de parametru. Dac parametrul are mai multe valori se apeleaz metoda
getParameterValues care returneaz un vector de stringuri.
Numele parametrilor sunt case sensitive, deci request.getParameter("Param1") i
request.getParameter("param1") nu pot fi interschimbate.

1.2.6 Anatomia unui servlet HTTP

Pachetul javax.servlet ofer un cadru generic pentru crearea serverelor. Conine API-uri
pentru prelucrarea cererilor i deservirea clienilor. Un alt pachet, javax.servlet.http conine
implementarea servleturilor utilizate n cazul webserverelor pentru generarea paginilor HTML.

17

Un servlet HTTP pentru a putea realiza o anumit sarcin trebuie sa redefineasc metoda
doGet(). Metoda este apelat de ctre webserver ori de cte ori serverului i este adresat o
cerere HTTP care conine un GET <url>. Metoda este definit n clasa HttpServlet pe lng
metodele: doDelete(), doOptions(), doPost(), doTrace(). Aceste metode doXXX() au doi
parametri, unul de tip ServletRequest i unul de tip ServletResponse. Cele dou clase conin
metode i variabile care permit comunicarea servletului cu webserverul i pot genera excepiile
ServletException i IOException:
publicvoiddoGet(HttpServletRequestreq,HttpServletResponse
res)throwsServletException,IOException{...}

Clasa ServletRequest conine toate informaiile necesare servletului pentru a nelege

cererea i a putea rspunde la aceasta. Conine informaii referitoare la calculatorul cruia trebuie
sa rspund.
Clasa ServletResponse conine metode care permit crearea i trimiterea rspunsului.
Astfel cu ajutorul metodei setContentType( String) se stabilete tipul datelor care se trimit
napoi. Dintre tipurile posibile: text/html, text/plain. O alt metod important este getWriter().
Metoda returneaz o referin de tip PrintWriter, care este un flux de ieire prin care se trimite
rspunsul. Aceast metod se utilizeaz dac servletul trebuie s trimit un coninut de tip text i
metoda getOutputStream() se utilizeaz dac se trimit date binare.

1.2.7 Arhitectura pachetelor javax.servlet i javax.servlet.http

Pachetul javax.servlet ofer clase i interfee pentru scrierea servleturilor. Principala
interfa definit n acest pachet este interfaa Servlet. Toate servleturile implementeaz aceast
interfa,

cel

mai

des

prin

extinderea

clasei

HttpServlet.

Interfaa Servlet declar metode care gestioneaz comunicrile cu toi clienii. n

momentul cnd un servlet accept conexiunea cu un client, primete i dou obiecte:

18

un obiect ServletRequest, care este responsabil pentru comunicarea client server

un obiect ServletResponse, care este responsabil pentru comunicarea invers

server - client

Interfaa ServletRequest permite servletului urmtoarele:

informaii despre parametrii primii de la client, protocolul utilizat de ctre client,

numele hostului de la care s-a acceptat cererea

un flux de intrare ServletInputStream. Servletul utilizeaz acest flux de intrare

pentru citirea datelor de la clieni . Clienii utilizeaz metode ca PUT i POST ale
protocolului HTTP

Interfaa ServletResponse declar metode prin care servletul poate trimite

rspunsuri la cererile clientilor.

permite stabilirea lungimii rspunsului precum i tipul MIME al acestuia

un flux de iesire ServletOutputStream i unul Writer prin care servletul va trimite

raspunsul la cerere

1.2.8 Interaciunea cu clienii

Un servlet HTTP trateaz cererile clienilor cu ajutorul metodei service(). Metoda
service() este cea care apeleaz metoda doGet() pentru prelucrarea cererii.

1.2.8.1 Cereri i rspunsuri

Tratarea cererilor GET i POST se face cu ajutorul urmtoarelor metode:

doGet - pentru tratarea cererilor GET, GET condiionat i HEAD

doPost - pentru tratarea cererilor POST

doPut - pentru tratarea cererilor PUT

19

doDelete - pentru tratarea cererilor DELETE

Implicit aceste metode returneaz eroarea BAD_REQUEST (400) afiat de ctre

aplicaia client (programul de navigare).

1.2.8.2 Deservirea clienilor

Servleturile sunt capabile pentru deservirea clienilor n mod concurent. Dac deservirea
clienilor necesit accesul unor resurse partajate atunci accesul acestor resurse trebuie
sincronizate.
Dac dorim deservirea unui singur client la un moment dat, atunci servletul nostru trebuie
s implementeze interfaa SingleThreadModel pe lng extinderea clasei

HttpServlet.

Implementarea acestei interfee nu necesit scrierea unor metode suplimentare i asigur

deservirea unui singur client la un moment dat.

20

1.3 Java Database Connectivity - JDBC

1.3.1 Drivere JDBC
JDBC (Java DataBase Connectivity) reprezint API-ul oferit de Sun Microsystems pentru
dezvoltarea de aplicaii Java care acceseaz bazele de date gestionate de diverse DBMS-uri
(Sisteme de gestiune a bazelor de date). O funcie foarte important a JDBC este faptul c
lucreaz cu instruciuni SQL. Pentru a utiliza API-ul JDBC cu un DBMS particular este nevoie
de un driver JDBC care s medieze ntre tehnologia JDBC i baza de date. Driverul poate fi scris
numai n Java sau ntr-o combinaie de Java i metode native JNI (Java Native Interface).
Ultima specificaie JDBC existent are vers. 3.0 i conine dou pachete:
1. java.sql
2. javax.sql care ofer capabiliti adiionale pe partea de server
Observaie:
Aplicaiile care utilizeaz baze de date trebuie s includ pachetul java.sql, i nu pachetul
care conine implementarea driver-ului particular folosit. Totui calea spre pachetul coninnd
driverul trebuie s fie prezent n CLASSPATH.
Exist patru tipuri de drivere JDBC:
1. Puntea JDBC-ODBC:
Este reprezentat de clasa sun.jdbc.odbc.JdbcOdbcDriver. Puntea traduce metodele
JDBC n apeluri de funcii ODBC, i necesit ca bibliotecile ODBC native i driverele ODBC s
fie instalate i configurate pentru fiecare client ce utilizeaz un driver de acest tip. Funcioneaz
doar pentru sitemele de operare Microsoft Windows i Sun Solaris.
2. Java-API nativ:
Folosesc interfaa JNI pentru a face apeluri direct la API-ul unei baze de date locale. Sunt
mai rapide dect tipul 1. Dar, de asemenea, necesit instalarea i configurarea bibliotecilor client
baz de date native pe maina client.
21

3. Java-protocol de reea.
Folosesc un protocol de reea (de obicei, TCP/IP) pentru a comunica cu aplicaia JDBC
middleware. Aplicaia JDBC middleware traduce cererile JDBC folosind protocolul de reea n
apeluri de funcii specifice bazelor de date. Sunt cele mai flexibile, deoarece nu necesit
biblioteci de baze de date native pe client i se pot conecta la mai multe baze de date.
4. Java-protocol baz de date.
Implementeaz un protocol de baz de date pentru a comunica direct cu baza de date.
Sunt cele mai rapide. De asemenea, nu necesit biblioteci de baze de date native pe client Sunt
specifice unui singur DBMS.
Pentru gestiunea driverelor folosite ntr-o aplicaie, JDBC API folosete un manager de
drivere reprezentat de o instan a clasei DriverManager.

1.3.2 Accesarea unei baze de date folosind JDBC

n ODBC, bazele de date sunt reprezentate ca surse de date, identificate printr-un nume
(DSN Data Source Name) i accesibile printr-un driver ODBC corespunztor.
Pentru a ne conecta la o baza de date trebuie urmai paii:
1.

nregistrarea

driver-ului

JDBC

folosind

gestionarul

de

drivere

DriverManager
2.

stabilirea unei conexiuni ctre baza de date

3.

execuia unei instruciuni SQL

4.

procesarea rezultatelor

5.

nchiderea conexiunii ctre baza de date

1.3.2.1 nregistrarea driver-ului JDBC

Un driver JDBC este nregistrat automat de managerul de drivere atunci cnd clasa driver
este ncrcat dinamic prin meoda Class.forName(). Metoda este static i permite mainii

22

virtuale Java s aloce dinamic, s ncarce i s fac o legtur la clasa specificat ca argument al
metodei. n cazul n care clasa nu este gsit, se arunc o excepie ClassNotFoundException.
Iat un exemplu pentru nregistrarea driver-ului punte JDBC-ODBC:
Class.forName(sun.jdbc.odbc.JdbcOdbcDriver);

1.3.2.2 Stabilirea conexiunii ctre baza de date

O conexiune este identificat printr-un URL specific. Sintaxa standard pentru URL-ul
unei baze de date este: jdbc<subprotocol>:<nume>
Prima parte arat c se folosete JDBC pentru stabilirea conexiunii, <subprotocol> este
un nume de driver valid, iar <nume> este un nume logic sau alias care corespunde bazei de date
fizice. Dac baza de date este accesat prin Internet, atunci seciunea <nume> va fi de forma
//numeHost:port/numeDB

Pentru stabilirea unei conexiuni la o baz de date, se folosete metoda static

getConnection() din clasa DriverManager:
Connection con = DriverManager.getConnection(jdbc:odbc:myMessages);

sau dac baza de date necesit autentificare:

Connectioncon=DriverManager.getConnection(jdbc:odbc:myMessages,
numeUtilizator,Parola);

1.3.2.3 Execuia unei instruciuni SQL

Pentru

execuia

unei

instruciuni

SQL neparametrizate,

se folosete metoda

createStatement() aplicat unui obiect Connection.

Statementinstructiune=con.createStatement();

Se poate aplica apoi una din urmtoarele metode:

o

executeQuery() pentru interogrile care returneaz mulimi

rezultat (instane ale clasei ResultSet). Este cazul instruciunilor SELECT
23

executeUpdate() pentru operaiile de actualizare INSERT,

UPDATE, DELETE, ct i pentru interogrile SQL DDL de genul CREATE

TABLE, DROP TABLE, ALTER TABLE. Metoda returneaz un ntreg care
reprezint fie numrul nregistrrii afectate, fie este 0
execute() se utilizeaz atunci cnd se obine mai mult de o

mulime rezultat
ResultSetrs=instructiune.executeQuery(select*frommyMessages);
Stringsql=insertintomyMessagesvalues(Popescu,Ion,
Craiova);
intraspuns=instructiune.executeUpdate(sql);

Dac se dorete realizarea de apeluri SQL avnd date variabile drept intrare, se va folosi
clasa PreparedStatement care motenete clasa Statement.
PreparedStatementinstructiune=con.prepareStatament(updatemyMessages
setnume=?Whereprenumelike?);

instructiune.setString(1,Popescu);
instructiune.setString(2,Ion);
instructiune.executeUpdate();

1.3.2.4 Procesarea rezultatelor

Pentru parcurgerea simpl a nregistrrilor unui obiect din clasa ResultSet putem folosi
metoda next().
while(rs.next()){
System.out.println(rs.getString(nume)
+,+rs.getString(prenume)+,+rs.getString(oras));
}

24

1.3.2.5 nchiderea conexiunii la baza de date

Se recomand ca dup procesarea datelor, s se nchid explicit conexiunea ctre baza de
date. nti se vor nchide obiectele Statement i ResultSet folosind metodelor lor close(), apoi se
va nchide obiecul Connection prin apelarea metodei close() a acestuia:

try{
//
rs.close();
instructiune.close();
}
catch(SQLExceptione){
System.out.println(Eroarelainchidereinterogare:
+e.toString());
}
finally{
try{
if(conexiuneBazadate!=null){
conexiuneBazadate.close();
}
}
catch(SQLExceptione){
System.out.println(Eroarelainchidereconexiune:
+e.toString());
}
}

25

Capitolul II
Tehnologii folosite

2.1 Tehnologia Java Server Pages

2.1.1 Pagini Web generate dinamic - un posibil rspuns
La nceput a fost Web-ul. i Web-ul era static i ntunecat. Apoi a aprut CGI-ul i
ISAPI-ul. i Microsoft a zis: "S fie IDC!"; i aa a fost! i alii au adugat: "S fie APIuri, SSI-uri i plug-in-uri!"; i aa a fost! Apoi Microsoft a zis: "S fie ASP!"; i aa a fost!
i aplicaiile au prins via. Apoi Duke a zis: "S fie Servlet-uri!"; i aa a fost! i a luat
Duke Servlet API a vorbit cu IBM, Oracle, Netscape, Weblogic i alii i a fcut JSP. i s-a
fcut lumin!...?..."
Programarea CGI (Common Gateway Interface), aprut la nceputul anului 1995, a
transformat Web-ul dintr-un simplu sistem de aducere de fiiere ntr-o platform n care diferitele
organizaii pot instala aplicaii Web de mare utilitate. nainte de introducerea CGI Web-ul era, de
fapt, folosit pentru distribuirea de documente statice: text i imagini. Odat cu apariia acestuia,
serverele de Web au putut fi conectate pentru a procesa informaia n mod dinamic.
26

Aproape c nu exist limite pentru posibilitile de folosire de clieni Web n diverse

aplicaii. Proiectele ce folosesc clieni de tip browser au cteva avantaje asupra modelului
tradiional client/server. Acestea includ accesul nelimitat al clienilor, instalarea i meninerea
facil a aplicaiilor (pentru a face modificri, programatorul trebuie doar s schimbe un program
aflat pe server i nu cteva sute de aplicaii client instalate). Ca urmare, industria de software se
ndreapt rapid ctre construirea de aplicaii multi-tier folosind clieni de tip browser.
Soluia incipient reprezentat de CGI avea serioase probleme de scalabilitate: fiecare
cerere CGI lansa un nou proces pe server, iar dac mai muli utilizatori fceau acest lucru
simultan, mare parte din resursele serverului Web erau astfel epuizate. Efectul imediat:
ncetinirea aplicaiei cu efecte deosebit de neplcute pentru utilizator.
Productorii de servere Web au ncercat s simplifice dezvoltarea de aplicaii Web prin
furnizarea de "plug-in"-uri i API-uri pentru servere. Aceste soluii sunt specifice fiecrui server
i nu rezolv problema n cazul unor platforme diferite. De exemplu, tehnologia Active Server
Pages (ASP) faciliteaz crearea de pagini de Web dinamice, ns funcioneaz doar cu servere
Microsoft: Internet Information Server sau Personal Web Server. Conform statisticilor recente
22% din serverele Web sunt bazate pe NT - ceea ce nseamn c restul de 78% are nevoie de
altceva.
Alte soluii exist, dar nu sunt uor de folosit de ctre proiectantul obinuit de pagini de
Web. Tehnologia Java Servlets (specificat de API-ul Servlet de la Sun), de exemplu, permite
folosirea limbajului Java ca mediu de dezvoltare pentru crearea dinamic a paginilor Web, pentru
execuia unor calcule n funcie de specificul aplicaiei sau pentru comunicarea cu surse de date
de nivel third-tier. Aceste trei activiti difer foarte mult una de cealalt i necesit diverse
aptitudini de programare. Un servlet Java este un program ce ruleaz pe server (spre deosebire de
applet-uri ce ruleaz n browser); el preia cereri HTTP de la browser-ul Web i genereaz
dinamic un rspuns HTML (sau XML). ntreaga pagin Web trebuie astfel s fie coninut n
servlet-ul Java. Dac un Web designer sau un Web master dorete s schimbe look-ul paginii
respective, ar trebui s editeze i s recompileze servlet-ul chiar dac modul de funcionare ce st
n spatele acestuia rmne acelai.
Proiectanii Web sunt preocupai n special de aspectele estetice ale paginii (amplasarea i
aspectul imaginilor, al fundalului i al frame-urilor) i mai puin de sursa i de manipularea
datelor dinamice necesare pentru a aduce pagina n forma cerut de client. Uneori sunt necesare
27

informaii despre cererea browser-ului client (cum ar fi tipul acestuia) pentru a se returna un
coninut adecvat care s beneficieze de toate avantajele acestuia. Ar fi deci foarte util s se
permit proiectanilor Web accesul la aceste informaii fr a trebui s nvee s scrie servlet-uri,
s le compileze i s le instaleze pe serverele de Web respective.
Pentru a oferi proiectanilor acces la API-ul Servlet fr a trece prin cele trei faze
menionate anterior ct i pentru a veni cu o soluie pentru problemele deja existente, Sun a
definit specificaia JavaServer Pages ce permite ca Java s devin limbaj de scripting pe partea
de server i mai mult dect att.

2.1.2 Ce este JSP?

Java Server Pages (JSP) este una dintre cele mai puternice tehnologii Web i este uor de
utilizat. JSP combin HTML i XML cu servleturile i tehnologia JavaBeans pentru a crea un
mediu destul de productiv pentru dezvoltarea de situri Web independente de platforma i de o
nalt performan.
Tehnologia JSP faciliteaz crearea coninutului dinamic pe partea de server a paginilor
Web. Este asemntoare cu ASP (Active Server Pages) de pe platforma Microsoft Windows i cu
PHP (PHP:Hypertext Processor), care este independent de platforma. JSP este o soluie Java
pentru programarea pe partea de server, fiind o alternativ la CGI-urile clasice (Common
Gateway Interface). JSP integreaz numeroase tehnologii Java cum ar fi servleturile, JavaBeans
i JDBC.
JSP extinde limbajul HTML oferind posibilitatea inserrii de secvene de cod Java prin
intermediul unor taguri speciale. Programatorul are posibilitatea de a crea noi taguri i
componente Java Beans cu semnificaiile indicate de acesta. Astfel, se pot crea noi faciliti
pentru cei care se ocup de partea de web design.
n acelai timp, JSP este o extensie a servleturilor. n loc s scriem cod Java care s
genereze pagini Web,vom crea pagini Web care s conin elemente dinamice.Atunci cnd se
primete o cerere de pagina JSP, se creeaz un servlet din respectiva pagin i acesta se execut,
iar rezultatul este trimis ca raspuns la cererea primita. Un avantaj important al JSP-urilor fa de
servleturi este faptul c se separ continutul HTML static de cel dinamic. n cazul servleturilor,
orice modificare minor referitoare la designul paginii Web implic recompilarea respectivului
servlet.
28

La JSP-uri, partea de generare a coninutului dinamic este pstrat separat de cea static
prin utilizarea componentelor JavaBeans externe. Orice modificare a parii statice va fi vizibil
celor ce acceseaz respectivul JSP, ntruct la primirea cererii se recompileaz automat i foarte
repede pagina JSP apoi se execut i rezultatul este trimis.
O data scris, o pagina JSP poate fi stocat pe orice server Web (care are suport pentru
JSP), oricare ar fi platforma pe care se afl acesta, fr a suferi modificari.
Nu exist limitri referitoare la tipul coninutului generat de parile dinamice ale JSPurilor. Acesta poate fi text obisnuit, HTML/DHTML, XML, WML, VRML etc.
JSP-urile sunt mai uor de creat i pot avea functionalitatea aproape a oricrui servlet.
Servleturile sunt utilizate pentru a extinde funcionalitatea serverului Web (servicii de
autentificare, validarea bazelor de date etc.) i pentru comunicarea cu appleturi sau alte aplicaii
Web.
JavaServer Pages este tehnologia platformei Java pentru construirea de aplicaii ce
cuprind pagini de Web cu coninut dinamic precum HTML, DHTML, XHTML i XML. Sun a
ncercat s depeasc limitrile soluiilor actuale pentru generarea de pagini cu coninut dinamic
prin dezvoltarea unei tehnologii care:

s funcioneze pe orice server Web sau de aplicaii

s separe logica ce st n spatele aplicaiei de aspectul paginii

s permit dezvoltare i testare rapid

s simplifice procesul de dezvoltare de aplicaii interactive Web

Tehnologia JSP a fost creat s satisfac aceste cerine, fiind rezultatul unei cooperri la
nivelul industriei software dintre productorii de servere Web, servere de aplicaii, sisteme
tranzacionale i unelte de dezvoltare. Astfel, procesul dezvoltrii de pagini de Web dinamice
este accelerat de ctre JSP din urmtoarele considerente:
Separarea generrii coninutului de prezentare
Prin tehnologia JavaServer Pages, proiectanii de pagini folosesc tag-uri obinuite HTML
sau XML pentru formatarea rezultatului i tag-uri JSP sau scriplet-uri pentru generarea
coninutului dinamic al paginii. Logica ce st n spatele generrii coninutului este cuprins n
29

tag-uri i componente JavaBean, legtura dintre acestea fcndu-se n scriplet-uri i totul fiind
executat pe server. Astfel, proiectanii de pagini sau Web master-ii pot edita i lucra cu pagini
JSP fr a afecta generarea coninutului dinamic.
Pe partea de server, un engine (motor) JSP interpreteaz scriplet-urile i tag-urile JSP,
genereaz coninutul cerut (accesnd componente JavaBean, baze de date folosind JDBC sau
prin includerea de fiiere) i trimite rezultatele napoi sub forma unei pagini HTML (sau XML)
ctre browser.
Reutilizarea componentelor i a tag-urilor
Tehnologia JSP permite reutilizarea componentelor precum JavaBeans, Enterprise
JavaBeans sau a tag-urilor att independent, ct i n cadrul unor unelte interactive de dezvoltare
a componentelor i paginilor de Web. Creatorii de pagini Web nu sunt ntotdeauna programatori
familiarizai cu limbaje de scripting. JSP ncapsuleaz funcionalitile necesare pentru crearea de
coninut dinamic n tag-uri de tip XML specifice JSP. Tag-urile JSP standard pot accesa i
instania componente JavaBean, pot seta sau obine atribute ale bean-urilor, pot face download la
applet-uri i pot executa funcii ce ar fi dificil de implementat. Tehnologia JSP este extensibil
prin dezvoltarea de biblioteci de tag-uri definite de utilizator. Cu timpul vor fi create biblioteci
proprii de tag-uri pentru funciile folosite cel mai frecvent.
"Write once, run anywhere"
Tehnologia JSP este complet independent de platform att n ceea ce privete paginile
de Web dinamice, ct i serverele de Web i componentele acestora. Aceasta este explicabil
deoarece limbajul de scripting pentru paginile JSP se bazeaz pe Java i n special pe modul de
manipulare a obiectelor n acest limbaj.

2.1.3 Pagini JSP

O pagin JSP (*.jsp) este o pagin HTML sau XML ce cuprinde elemente adiionale (taguri, declaraii, scriplet-uri) pe care motorul JSP le proceseaz i le elimin returnnd o pagin
standard HTML/XML. Ea corespunde unui document ce descrie procesarea unei cereri pentru a
crea un rspuns.
30

O pagin JSP cuprinde n structura sa:

cod HTML/XML standard - cod ce rmne neinterpretat de motorul JSP

directive JSP - directive ce furnizeaz informaii globale independente conceptual

de o anumit cerere adresat paginii JSP

tag-uri JSP - spre deosebire de directive, tag-urile depind de fiecare cerere n parte
adresat paginii JSP

elemente de scripting - acestea putnd fi: declaraii, scriplet-uri i expresii

Directive, tag-uri, obiecte i domenii de vizibilitate

Paginile JSP folosesc directive JSP pentru a transmite instruciuni motorului JSP. n
specificaia 1.0 aceste directive sunt:

<%@ include ...%> - folosit pentru a insera n pagin un document extern ce poate
fi i un alt document JSP

<%@ page ...%> - folosit pentru a transmite informaii referitoare la pagin precum
limbajul de scripting, buffer-ul, informaii despre thread-uri, "pachete importate",
modul de tratare al excepiilor etc

<%@ taglib ...%> - indic o bibliotec de tag-uri pe care pagina respectiv le poate
invoca. Nu este disponibil n implementrile actuale

JSP include o serie de tag-uri standard. Sintaxa lor este cea a tag-urilor XML (< tag attr1
= "valoare atribut" ...> corp </tag> sau < tag attr1="valoare atribut" .../>). Acestea sunt:

<jsp:forward> - nainteaz cererea ctre un alt fiier HTML, fiier JSP sau servlet

<jsp:include> - include n etapa de procesare a cererii fiierul specificat n tag

<jsp:plugin> - face download ctre browser-ul clientului la un plugin Java pentru

executarea unui applet sau a unui Bean. Nu este disponibil n implementrile actuale

<jsp:useBean> - declar folosirea unei instane, a unei componente JavaBean. Dac

aceasta nu exist atunci componenta JavaBean instaniaz i nregistreaz tag-ul

<jsp:setProperty> - seteaz valoarea unei anumite proprieti a unui Bean

31

<jsp:getProperty> - obine valoarea unei instane a unui Bean, o convertete la String

i o depune n obiectul implicit de ieire out

O pagin JSP poate crea i/sau accesa, la procesarea unei cereri, anumite obiecte Java.
Obiectele astfel create pot deveni vizibile elementelor de scripting prin variabile n limbajul de
scripting. Acestea vor conine, n timpul etapei de procesare a cererilor, referine ctre obiectul
respectiv. Obiectele create au un atribut numit scope ce definete domeniul de vizibilitate al
acestora: cnd exist o referin la acest obiect i cnd aceasta va fi nlturat. Valorile pe care le
poate avea atributul scope sunt:

page - accesibil doar n cadrul paginii n care a fost creat obiectul

request - accesibil din paginile ce proceseaz aceeai cerere n care a fost creat
obiectul

session - accesibil din paginile ce se sunt n aceeai sesiune n care a fost creat
obiectul

application - accesibil din paginile de proceseaz aceeai aplicaie n care a fost creat
obiectul. Toate referinele la acesta sunt eliberate cnd mediul runtime solicit
ServletContext-ul

Numele ataat unui obiect este unic pe tot timpul execuiei, toate domeniile de vizibilitate
comportndu-se ca unul singur n cadrul unei secvene cerere/ rspuns. Lipsa transmiterii
variabilelor de stare prin HTTP este suplinit n mod automat de ctre motorul JSP prin cele dou
modaliti cunoscute: cookie-uri, respectiv rescrierea URL-urilor. Ct timp sunt fcute cereri
procesate de ctre motorul JSP, rescrierea URL-urilor este fcut n mod automat.
Orice pagin JSP conine o serie de obiecte create implicit :

request - cererea ce a solicitat pagina respectiv

response - rspunsul la cerere

pageContext - contextul paginii curente

session - obiect de tip sesiune pentru clientul solicitat (valabil doar pentru HTTP)

application - contextul servlet-ului generat (getServletConfig().get Context())

32

config - obiect de tip ServletConfig pentru aceast pagin

page - instan a clasei create pentru aceast pagin (pentru Java: this)

exception - excepia declanat anterior putnd fi folosit doar n pagina de eroare

invocat

config - obiect de tip JspWriter ce scrie n stream-ul de ieire

2.1.4 Tipuri de aplicaii pentru JavaServer Pages

Modelul de aplicaie flexibil folosind servlet-uri Java
Un client Web poate face o cerere direct ctre un servlet Java, care genereaz coninutul
dinamic, stocheaz rezultatul ntr-un Bean i invoc pagina JSP. Pagina JSP acceseaz coninutul
dinamic din Bean i trimite rspunsul (HTML) browser-ului.
Aplicaii de tip "two-tier"
Modelul de aplicaii "two-tier" presupune ca browser-ul s invoce n mod direct pagina
JSP i aceasta s genereze coninutul solicitat (apelnd eventual la JDBC pentru a obine
informaia direct dintr-o baza de date). Pagina JSP poate apela JDBC sau o component
JavaBean pentru a genera rezultatele dorite i a crea HTML standard ce va fi trimis browser-ului.
Acest model de fapt nlocuiete conceptul CGI-BIN cu pagina JSP (compilat ca servlet
Java). Avantajele acestei abordri sunt uurina de a programa i posibilitatea autorului paginii de
a genera coninut dinamic bazat pe cererea clientului i starea resursei solicitate.
Procesare scalabil folosind tehnologia Enterprise JavaBeans (aplicaii de tip N-tier)

33

Pagina JSP poate aciona ca "middle-tier" n cadrul unei arhitecturi de tip Enterprise
JavaBeans (EJB). n acest caz, pagina JSP interacioneaz cu resursele aflate pe server printr-o
component de tip Enterprise JavaBean.
Componenta de tip EJB controleaz accesul la resursele de pe server, ceea ce furnizeaz
performan scalabil pentru un numr mare de utilizatori concureni. Pentru comer electronic
sau alte tipuri de aplicaii, EJB controleaz tranzaciile i problemele de securitate aferente.
Aceasta simplific pagina JSP. Modelul acesta va fi suportat de ctre platforma Java 2
Enterprise Edition.

2.1.5 ASP sau JSP ?

Acesta e un subiect ce constituie o disput foarte aprins ntre susintorii celor dou
tehnologii. Muli sunt cei ce consider c JavaSoft are avantajul tacticii "wait and see", putnd
astfel aprecia mai bine ce va funciona corect i ce nu.
Tehnologia JSP este relativ nou. ASP a fost propus de Microsoft n 1996 i putem spune
c este o tehnologie deja impus ca standard pe platformele Microsoft. Dei aceast tehnologie
este foarte complex, ea suport limbaje de scripting multiple i modelul ActiveX al Microsoft.
Suportul pentru bibliotecile ActiveX, ce i dau adevrata putere, o fac ns disponibil numai
pentru platforma NT.

2.1.6 Diferena dintre servlet, scriptlet i pagina JSP

Un program scris n limbajul Java este un fiier de tip text cu extensia .java.
Pagina JSP este tot un program scris conform regulilor sintactice ale limbajului JSP. i ea
este tot un fiier de tip text dar are extensia .jsp.
n corpul paginii JSP se pot ntlni i instruciuni Java. Sunt aa-zisele scenarii, scriptlets.
Comenzile din limbajul JSP mpreun poriuni de cod Java pur din aceste scenarii sunt
transformate de ctre motorul servlet (Tomcat, Caucho, JRun etc.) n fiiere cu extensia .java.
34

Deci motorul este un programator automat, care va genera cod surs Java. Tot acesta comand
compilarea n cod de octei.

2.1.7 Concluzii
Explozia Internet-ului face ca cerinele pentru aplicaii Web s creasc vertiginos. n
aceste condiii o tehnologie precum JavaServer Pages este mai mult dect binevenit. Sprijinul
de care se bucur din partea industriei software precum i faptul c se bazeaz pe platforma Java
pot face din JSP soluia pentru aplicaii Web. n sprijinul acestei afirmaii nu vin doar declaraiile
din partea unor nume celebre precum Oracle, Netscape, Weblogic, IBM, Fujitsu .a., ci i
integrarea n viitoarea platform Java 2 Enterprise Edition i tehnologii precum JavaBeans sau
Enterprise JavaBeans.

2.2 MySQL
2.2.1 Introducere
Un sistem de gestiune a bazelor de date relaionale (SGBDR) este un instrument esenial
n numeroase medii, de la utilizrile mai tradiionale n contexte de afaceri, cercetare si
nvmnt i pn la aplicaiile mai recente, cum ar fi operarea motoarelor de cutare din
Internet. Totui, n ciuda importanei unei baze de date performante pentru gestiunea i accesul la
resursele informaionale, aceasta s-a dovedit a fi dincolo de resursele financiare a numeroase
instituii. Din punct de vedere istoric, sistemele de baze de date au constituit o propunere
costisitoare, firmele distribuitoare percepnd onorarii substaniale, att pentru program ct i
pentru asistena necesar, iar deoarece motoarele de baze de date prezentau frecvent cerine
hardware substaniale pentru a putea rula cu performane ct de ct rezonabile, costurile erau si
mai mari.
n anii din urm, situaia s-a schimbat, att din punct de vedere al echipamentelor, ct si
din acela al programelor. Calculatoarele personale au devenit necostisitoare, dar puternice; pe de
alt parte, a aprut o ntreag micare n direcia scrierii unor sisteme de operare cu performane
ridicate pentru aceste calculatoare, sisteme disponibile la preul unui compact disc ieftin, sau
35

chiar gratuit, prin Internet. Acestea includ numeroase sisteme derivate din BSD UNIX
(FreeBSD, NetBSD, OpenBSD), precum si diferite forme de Linux (RedHat, Caldera,
LinuxPPC, pentru a numi doar cteva).
Producia de sisteme de operare gratuite care s permit utilizarea calculatoarelor personale la maximum de capacitate s-a desfurat n mod concertat cu dezvoltarea unor
instrumente disponibile gratuit, cum ar fi gcc, compilatorul GNU de C, fiind n mare msur
posibil datorit acestora din urm. Aceste eforturi de a pune programele la dispoziia oricrui
doritor au avut ca rezultat ceea ce se numete acum micarea Open Source si au generat multe
programe importante. Cel mai solicitat site FTP din lume, i anume ftp.cdrom.com, ruleaz
FreeBSD. Apache este cel mai folosit server Web din Internet. Alte succese ale iniiativei Open
Source sunt limbajul de scripting de uz general Perl si PHP, un limbaj a crui popularitate este
ntr-o cretere rapid, datorit uurinei cu care permite scrierea paginilor Web dinamice. Toate
acestea contrasteaz cu soluiile de firm", care v oblig s folosii produse costisitoare, create
de fabricani care nici mcar nu furnizeaz codul surs.
Programele de baze de date au devenit si ele mai accesibile. Sistemele de baze de date
precum Postgres i mSQL au devenit disponibile gratuit sau la un pre sczut. Mai recent,
productorii comerciali, precum Informix i Oracle, au nceput s-i ofere programele gratuit
pentru sisteme de operare precum Linux. Totui, aceste din urm produse sunt livrate, n general,
numai n form binar, fr suport, ceea ce le limiteaz utilitatea.
Unul din noii venii n domeniul bazelor de date cu pre sczut sau gratuite este MySQL,
un sistem client/server de gestiune a bazelor de date relaionale originar din Scandinavia.
MySQL include un server SQL, programe client pentru accesul la server, instrumente
administrative i o interfa de programare pentru scrierea propriilor dumneavoastr programe.
Bazele sistemului MySQL au fost puse n 1979, o dat cu instrumentul pentru baze de
date UNIREG, creat de Michael "Monty" Widenius pentru compania suedez TcX. n 1994, TcX
a nceput s caute un server SQL pentru a-l utiliza la dezvoltarea aplicaiilor Web. Compania a
testat unele servere comerciale, dar toate s-au dovedit a fi prea lente pentru tabelele de mari
dimensiuni ale firmei. De asemenea, compania a examinat mSQL, dar acestuia i lipseau anumite
caracteristici obligatorii pentru TcX. n consecin, Monty a nceput s programeze un server
nou. Interfaa de programare era proiectat n mod explicit pentru a fi similar celei folosite de
mSQL, deoarece pentru mSQL erau disponibile numeroase instrumente gratuite, iar prin
36

utilizarea unei interfee similare aceleai instrumente puteau fi folosite pentru MySQL, cu un
efort de portare minim.
n 1995, David Axmark de la Detron HB a nceput s fac presiuni pentru ca TcX s
lanseze MySQL pe Internet. De asemenea, David lucra la documentaie i la a determina MySQL
s construiasc folosind utilitarul GNU configure. MySQL 3.11.1 a fost dat lumii ntregi n 1996,
sub forma de distribuie binar pentru Linux si Solaris, n prezent, MySQL funcioneaz pe mult
mai multe platforme si este disponibil att n form binar, ct i surs.
MySQL nu este un proiect Open Source, deoarece este necesar o licen n anumite
condiii. Totui, MySQL se bucur de o ampl popularitate n comunitatea Open Source,
deoarece termenii de licen nu sunt foarte restrictivi (n esen, MySQL este n general gratuit,
dac nu se dorete s se obin profit prin vnzarea sistemului sau a unor servicii care necesit
utilizarea acestuia).
Popularitatea sistemului MySQL nu este limitat la comunitatea Open Source. Da,
ruleaz pe calculatoare personale (ntr-adevr, o bun parte din programarea cu MySQL are loc
pe sisteme Linux ieftine). Dar MySQL este portabil si ruleaz pe sisteme de operare comerciale
(precum Solaris, Irix si Windows) i pe echipamente care merg pn la servere de ntreprindere.
n plus, performanele sale rivalizeaz cu acelea ale oricrui sistem de baze de date cu care dorii
s l comparai i poate manipula baze de date de mari dimensiuni, cu milioane de nregistrri.
MySQL apare foarte clar n imaginea care se desfoar dinaintea ochilor notri : sisteme
de operare disponibile gratuit, care ruleaz pe echipamente puternice, dar necostisitoare, punnd
la dispoziia unui numr de oameni mai mare ca oricnd o putere substanial de prelucrare a
datelor i alte caracteristici, pe o varietate de sisteme mai larg ca oricnd. Aceast coborre" a
barierelor economice n ceea ce privete prelucrarea automat a datelor pune soluii puternice
pentru baze de date la dispoziia unui numr fr precedent de mare de persoane i instituii.
Instituii care n trecut se mrgineau s viseze la a exploata n folos propriu puterea unui SGBDR
cu performane ridicate au acum aceast posibilitate, la un pre foarte redus.
Utilizarea bazelor de date este tot mai frecvent si la nivel individual. Oameni care nu se
gndeau niciodat c vor folosi baze de date ncep s ia n considerare tot felul de utilizri ale
acestora, din moment ce procurarea unui sistem de baze de date este facil - de exemplu, stocarea
si accesul la rezultatele unor cercetri genealogice, urmrirea si ntreinerea coleciilor de diferite
tipuri (fluturi, mrci potale, cri de joc cu juctori de baseball etc.), asisten n demararea unei
37

afaceri sau furnizarea de posibiliti de cutare pentru situri Web personale.

2.2.2 De ce s optez pentru MySQL?

Dac suntei n cutarea unui sistem gratuit sau necostisitor de gestiune a bazelor de date,
putei alege din mai multe opiuni: MySQL, mSQL, Postgres, unul din motoarele gratuite (dar
fr suport) furnizate de productorii comerciali i aa mai departe. Cnd comparai MySQL cu
alte sisteme de baze de date, gndii-v la ceea ce este cel mai important pentru dumneavoastr.
Performan, suport, caracteristici (conformant cu SQL, extensii etc.), condiii si restricii de
liceniere, pre; toate acestea constituie factori care trebuie luai n considerare.
Date fiind aceste consideraii, MySQL are de oferit numeroase caracteristici atractive:

Vitez. MySQL este rapid. Programatorii pretind c MySQL este cel mai rapid
sistem de baze de date pe care l putei gsi

Uurin n utilizare. MySQL este un sistem de baze de date cu performane

ridicate, dar relativ simplu, a crui configurare i administrare sunt mult mai
simple dect n cazul sistemelor mai mari

Cost. MySQL este gratuit pentru majoritatea utilizrilor interne

Suport pentru limbaje de interogare. MySQL nelege SQL (Structured Query

Language - limbaj de interogare structurat), limbajul preferat al tuturor sistemelor
moderne de baze de date. De asemenea, putei avea acces la MySQL folosind
aplicaii care accept ODBC (Open Database Connectivity), un protocol de
comunicaie cu bazele de date creat de Microsoft

Caracteristici. La server se pot conecta mai muli clieni simultan. Clienii pot
folosi mai multe baze de date simultan. Putei obine acces la MySQL n mod
interactiv, folosind numeroase interfee care v permit s introducei interogri i
s vizualizai rezultate: clieni n linie de comand, browsere Web sau clieni X
Window System. De asemenea, este disponibil o varietate de interfee de
programare pentru limbaje precum C, Perl, Java, PHP i Python. Astfel,
utilizatorul poate opta pentru folosirea unor programe client preambalate sau
pentru scrierea propriilor programe client pentru aplicaii personalizate
38

Conectivitate i securitate. MySQL poate fi folosit integral n reele, iar bazele de

date sunt accesibile de oriunde din Internet, deci datele pot fi partajate cu oricine,
oriunde. Dar MySQL are controlul accesului, astfel nct persoanele care nu au
dreptul s citeasc anumite date nu vor avea aceast posibilitate

Portabilitate. MySQL ruleaz pe numeroase varieti de UNIX, precum i pe alte

sisteme non-UNIX, ca Windows i OS/2. MySQL ruleaz pe echipamente de la
calculatoare de birou la servere cu performane ridicate

Distribuie liber. MySQL este uor de obinut. Dac nu se nelege funcionarea

unei componente sau utilizatorul este curios cu privire la un algoritm, i poate
procura codul surs i l poate examina

Dar suportul? Bun ntrebare; o baz de date nu este de prea mare folos dac nu se poate
obine asisten n raport cu ea. MySQL este dotat cu un sistem de asisten performant:

MySQL include un manual de referin de mari dimensiuni

Sunt disponibile contracte de asisten tehnic de la dezvoltatorii MySQL, pentru cei

care prefer un acord formal

Exist o list de coresponden activ, la care se poate nscrie oricine. Aceast list
conine numeroi participani utili, inclusiv dezvoltatorii MySQL. Ca resurs pentru
asisten, muli o gsesc suficient pentru necesitile proprii

Comunitatea MySQL, programatori si ne-programatori, este extrem de cooperant.

Rspunsurile la ntrebrile din lista de coresponden sosesc, de regul, n cteva minute. La
semnalarea unor hibe, programatorii lanseaz un remediu n cteva zile (uneori ore!), iar
remediile sunt disponibile imediat prin Internet.
MySQL este un candidat ideal pentru evaluare dac v aflai n procesul de selectare a
sistemelor de baze de date. Putei ncerca MySQL fr nici un pericol de implicare financiar.
Totui, dac v ncurcai, putei folosi lista de coresponden pentru a fi ajutat. O evaluare cost o
parte din timpul dumneavoastr, dar acest lucru este valabil indiferent de sistemul de baze de
date pe care l avei n vedere - si este perfect adevrat c timpul de instalare si configurare
pentru MySQL este mai redus dect pentru multe alte sisteme.
Dac n prezent utilizez un alt sistem de baze de date, trebuie s trec la MySQL? Nu n
39

mod necesar. Dac suntei satisfcut de sistemul dumneavoastr actual, de ce s v deranjai cu o

atare tranziie? Dar dac v simii limitat de sistemul folosit, trebuie categoric s avei n vedere
MySQL. Poate c performanele sistemului dumneavoastr curent reprezint o problem, sau
poate c sistemul respectiv este de firm" i nu v place s fii blocat" de acesta. Poate ai
prefera s folosii componente hardware care nu sunt acceptate de sistemul dumneavoastr actual
sau poate c programul este furnizat n format binar, iar dumneavoastr preferai s avei la
dispoziie codul surs. Sau poate c pur i simplu e prea costisitor! Toate acestea reprezint
motive pentru a lua n considerare MySQL.

2.2.3 Instrumente furnizate cu MySQL

Distribuia MySQL include urmtoarele instrumente:

Un server SQL. Acesta este motorul care activeaz MySQL si care furnizeaz
accesul la bazele de date

Programe client pentru accesul la server. Un program interactiv care permite

introducerea interogrilor n mod direct i vizualizarea rezultatelor, iar
numeroasele programe administrative i utilitare ajut utilizatorul s i ruleze
situl. Un utilitar permite controlarea serverului. Altele permit importarea sau
exportarea datelor, verificarea permisiunilor de acces i multe altele

O bibliotec client pentru scrierea propriilor programe. Utilizatorul poate scrie

programe client n C, deoarece biblioteca este scris n C, dar biblioteca mai
furnizeaz i baza pentru tere asocieri pentru alte limbaje

In afara programelor furnizate cu MySQL, MySQL nsui este folosit de ctre numeroase
persoane talentate i capabile, crora le place s scrie programe pentru a-i mbunti
productivitatea i care doresc s pun la dispoziia publicului aceste programe. Rezultatul este c
utilizatorul are acces la o diversitate de instrumente produse de tere pri, care faciliteaz
utilizarea sistemului MySQL sau care extind aria de aciune a acestuia n domenii precum
dezvoltarea siturilor Web.
40

2.2.4 MySQL este gratuit?

MySQL nu este un produs Open Source, dar, n general, poate fi folosit gratuit. Trebuie
consultat manualul de referin MySQL pentru detalii privind licena, dar principiile de baz sunt
urmtoarele:

Programele client i biblioteca de programare a clienilor sunt gratuite, pe toate platformele

Pentru UNIX si alte platforme non-Windows, serverul MySQL poate fi folosit gratuit,
cu excepia situaiilor cnd se dorete vnzarea serverului sau a altor programe sau
servicii care impun utilizarea acestuia; n aceast situaie, trebuie obinut licen
pentru server. Ideea este c, dac se obine un profit din MySQL, este normal ca
dezvoltatorii sistemului s primeasc o parte din acesta (200 de dolari este o nimica
toat pentru un specialist SGBDR care ajut utilizatorul s obin un profit i exist o
mulime de programe gratuite care se pot procura pentru a folosi eficient sistemul)

Versiunea Windows a serverului MySQL impune obinerea unei licene

Versiunile mai vechi de MySQL sunt disponibile n condiiile licenei publice GNU
(GPL) i pot fi folosite n orice scopuri, fr nici o plat. MySQL 3.20.32a este
disponibil n condiiile GPL

2.2.5 O not despre licena Windows

Uneori se pune ntrebarea: Cum adic trebuie s obin licen pentru serverul MySQL
numai fiindc rulez Windows?". Aceasta este o ntrebare rezonabil, la care exist un rspuns
rezonabil. Gndii-v la aspectele economice ale problemei. Pentru a v angaja n dezvoltarea de
programe, avei nevoie de un sistem de operare si de unele instrumente de dezvoltare, cum ar fi
un editor i un compilator. Relativ la aceste cerine, exist o diferen fundamental ntre
dezvoltarea pentru UNIX si dezvoltarea pentru Windows. Sub UNIX, se poate obine gratuit cam
tot ceea ce avei nevoie:

Pentru sistemul de operare avei numeroase opiuni, cum sunt Linux sau una din
variantele BSD gratuite, cum sunt FreeBSD, NetBSD i OpenBSD

Pentru instrumentele de dezvoltare, toate aceste sisteme de operare sunt dotate cu

41

editoare i compilatoare ca gcc i egcs

Cnd sunt lansate actualizri ale sistemelor de operare sau ale instrumentelor de
dezvoltare, se pot descrca pur i simplu de pe Internet sau se poate procura un
compact disc necostisitor. Acest lucru este valabil chiar si pentru revizuirile
substaniale

Pe de alt parte, dezvoltarea programelor n Windows este relativ costisitoare:

Sistemul de operare nu este gratuit

Instrumentele de dezvoltare, precum compilatorul, nu sunt gratuite

Cnd sunt lansate actualizri ale sistemului de operare sau ale instrumentelor,
trebuie pltit din nou, chiar dac acestea nu sunt altceva dect remedii pentru hibe
sau actualizri incrementale de mic importan

Toate acestea nseamn c, n timp ce costurile pentru dezvoltarea programelor n UNIX

sunt, n esen, nule, pentru Windows acestea pot atinge valori considerabile. Se prea poate ca
dezvoltatorilor MySQL s le plac s lucreze cu MySQL, dar nu att de mult nct sa fie dispui
s plteasc pentru acest privilegiu. Costurile de dezvoltare sub Windows trebuie recuperate ntrun fel sau altul, iar taxa pentru licen este modul n care se produce aceast recuperare.
n plus, dezvoltatorii au descoperit c programarea sub Windows necesit mai mult timp
dect cea sub UNIX. Deoarece timpul dezvoltatorilor are o mrime fix, acesta este un cost care
trebuie suportat pe speele versiunii UNIX (care este, n fond, platforma primar de dezvoltare a
sistemului MySQL). Taxa de licen Windows furnizeaz un stimulent pentru orientarea timpului
i a eforturilor spre Windows.
Dac se dorete rularea Windows-ului, dar nu se dorete obinerea licenei pentru server,
exist unele opiuni:

Exist o versiune shareware a sistemului MySQL, care poate fi testata pentru

evaluare. Aceast versiune ofer utilizatorului 30 de zile pentru utilizarea serverului,
dup care acesta poate decide dac va plti licena pentru el
42

Dac se ruleaz serverul Windows n scopuri educaionale sau n instituii universitare

sau de cercetare guvernamentale, se poate cere dezvoltatorilor scutirea plii taxei de
licen

Programele client sunt gratuite n orice caz

Capitolul III
Prezentarea aplicaiei
3.1 Descrierea aplicaiei
3.1.1 Descrierea tabelelor folosite
Aplicaia mea este un site pe tema Website pentru informaii medicale. n acest sens am
implementat o gestiune a pacienilor medicilor de familie dintr-un ora (gestiunea este fcut de
medici fiecare medic i gestioneaz propriii pacieni). Pentru conceperea acestui site am
folosit pe lnga HTML i JavaScript, tehnologia JSP (Java Server Pages) i MySQL. Am ales
JSP pentru c paginile Web ale acestui site sunt dinamice (coninutul lor se modific dinamic) i
MySQL pentru c este cel mai popular server de baze de date la ora actual.
n spatele site-ului se afl o baz de date care conine 3 tabele:

medici

datePacient

registruPacient

Tabelul medici are urmtoarea structur:

idMedic - cmp de tip int care identific n mod unic un medic

username - pseudonim-ul cu care se logheaz medicul

43

parola - parola cu care medicul se logheaz

nume - numele medicului

prenume - prenumele medicului

Tabelul datePacient conine urmtoarele cmpuri:

idPacient - cmp de tip int care identific n mod unic un pacient

idMedic - cmp de tip int care identific medicul la care se afl pacientul

nume - numele pacientului

prenume - prenumele pacientului

CNP - codul numeric personal al pacientului

vrst - vrsta pacientului

adres - adresa pacientului

ocupaie - ocupaia pacientului

Tabelul registruPacient este structurat pe urmtoarele cmpuri:

dataConsultaiei - data fiecrei consultaii efectuat de un pacient

diagnostic - diagnosticul pus de medic

tratament - tratamentul prescris de medic

observaii - observaiile medicului n legtur cu pacientul respectiv

Principiul funcionrii site-ului este urmtorul: un medic se logheaz cu un username i o

parol. Dac logarea este corect, acesta are acces la pacienii si, putnd s-i manipuleze dupa
bunul plac. Un medic poate efectua 5 operaii asupra pacienilor si:

adugarea unui nou pacient

tergerea unui pacient

cutarea unui pacient

modificarea datelor personale ale unui pacient

actualizarea registrului unui pacient

44

vizualizarea tuturor pacienilor si

Dup efectuarea operaiei dorite, medicul se delogheaz.

Toi medicii de familie dintr-un ora sunt reinui n tabelul medici. Pentru fiecare medic
n parte sunt reinute username-ul, parola, numele i prenumele acestuia. Pe lng aceste date,
fiecarui medic i se ataeaz un numr unic (n limbajul bazelor de date acest numr se numete
cheie unic), prin intermediul cruia un medic poate fi identificat n mod unic din mulimea
tuturor medicilor, fr pericol de confuzie. Pentru a ma asigura c doi medici nu pot avea acelai
ID, am setat cmpul idMedic cheie primar. Astfel, chiar dac se ncearc atribuirea aceluiai ID
la 2 sau mai muli medici, sistemul MySQL va semnala o eroare. Oricum, ID-ul medicilor este
transparent utilizatorului (utilizatorul nu poate vedea acest ID). Singura posibilitate prin care se
poate modifica acest ID este modificnd baza de date, ori acest lucru nu l poate face dect
administratorul site-ului.
Datele coninute n tabelul medici sunt folosite n primul rnd atunci cnd un medic se
logheaz. Dac medicul tasteaz un username i o parol corecte, atunci el are acces la pacienii
si. Dac nu, se va semnal un mesaj de eroare (logare nereuit).
Pacienii sunt reinui n tabelul datePacient. Exist deci un singur tabel pentru toi
pacienii. Acest tabel poate conine 2 pacieni cu acelai nume i acelai prenume (un medic
poate avea 2 sau mai muli pacieni cu acelai nume i acelai prenume, sau pot exista doi
pacieni diferii cu acelai nume i acelai prenume la medici diferii). Avnd n vedere acest
lucru, un pacient trebuie identificat n mod unic pentru a nu exista pericol de confuzie. Pentru a
identifica n mod unic un pacient, am procedat la fel ca n cazul medicilor. Am introdus un numr
unic asociat fiecarui pacient. Astfel cmpul idPacient a devenit cheie primar. n unele pagini ale
site-ului am folosit acest ID pentru identificarea pacienilor, iar n altele am folosit codul numeric
personal pentru a evita confuziile (CNP-ul este cel mai indicat de folosit pe post de cheie primar
pentru c este unic nu pot exista 2 pacieni cu acelai CNP).
ntruct exist un singur tabel cu toi pacienii, a aprut urmtoarea problem: cum tiu eu
care sunt pacienii medicului X ?. Pentru soluionarea acestei probleme, fiecarui pacient i-am

45

ataat pe lng ID-ul su i ID-ul medicului la care aparine. Astfel, perechea (idPacient,
idMedic) identific n mod unic un pacient, mpreun cu medicul acestuia.
Tabelul datePacient conine datele generale ale fiecrui pacient (datele personale), n
timp ce tabelul registruPacient conine registrul fiecrui pacient. n registru medicul i noteaz
diagnosticul pacientului, tratamentul recomandat i eventual cteva observaii. Registrul unui
pacient este completat n urma fiecrei consultaii.
n mai toate paginile site-ului exist forme de introducere a datelor. Datele scrise n
aceste forme sunt validate cu ajutorul JavaScript-ului. Am introdus aceste validri pentru a m
asigura c orice modificare a bazei de date pstreaz consistena acesteia.

3.1.2 Operaiile efectuate pe tabele

3.1.2.1 Adugarea unui nou pacient
La adugarea unui nou pacient medicul trebuie s completeze datele personale ale
acestuia. nainte de inserarea noului pacient in baza de date, datele introduse sunt validate.
Corectitudinea datelor trebuie s respecte urmtoarele condiii: numele i prenumele pacientului
nu trebuie s conin spaii, codul numeric personal trebuie s aib 13 cifre dintre care prima s
fie cifra 1 sau 2, iar vrsta trebuie s aparin intervalului [1..100]. Dac datele noului pacient nu
respect toate aceste condiii, este semnalat un mesaj de eroare la ncercarea de a aduga
pacientul n baza de date.
Dup adugarea noului pacient n baz, pe ecran este afiat un mesaj de confirmare a
reuitei operaiei. Aceasta n cazul n care operaia de adugare se ncheie cu succes. Singurul
motiv pentru care o operaie de adugare poate eua, se datoreaz faptului c CNP-ul noului
pacient mai exist deja n baza de date. Ori acest lucru nu trebuie s se ntmple.
Adugarea propriu-zis a noului pacient n baz se face rulnd un JSP. Acesta se
conecteaz la baza de date i execut un query de inserare a unei noi nregistrri n baz.

3.1.2.2 tergerea unui pacient

Pentru a terge un pacient acesta trebuie mai nti gsit. Pentru acest lucru am introdus o
form de cutare n pagina de tergere. Medicul trebuie s completeze numele i prenumele
46

pacientului pe care dorete s l tearg. Dup ce ambele sunt completate i validate (validarea
const n faptul c nu trebuie s conin spaii), prin apsarea tastei ENTER sau prin apsarea
butonului Caut se execut cutarea respectivului pacient. Rezultatele cutrii sunt afiate ntro nou pagin, ntr-un tabel.
Dac cutarea nu ntoarce nici un rezultat (adic nu a fost gsit nici un pacient cu numele
i prenumele respective), se afieaz pe ecran un mesaj corespunztor. Dac a fost gsit cel puin
un pacient, se afieaz o nou pagin cu rezultatele cutrii (acestea sunt afiate ntr-un tabel).
Cutarea poate avea ca rezultat mai muli pacieni pentru c un medic poate avea mai muli
pacieni cu acelai nume i acelai prenume. n tabelul rezultatelor sunt afiate datele personale
ale pacienilor gsii.
Pentru a terge un pacient, medicul nu trebuie dect s fac click pe numele pacientului
pe care vrea s l tearg. nainte de tergerea propriu-zis medicul este ntrebat dac dorete
acest lucru (un pacient poate fi ters doar dac a murit sau dac a fost transferat). tergerea
propriu-zis se face prin intermediul unui JSP. Acesta se conecteaz la baza de date i execut un
query de tergere. Dup tergere, aplicaia se ntoarce la pagina cu rezultatele cutrii, dar de
aceast dat pacientul ters nu mai este afiat n tabelul rezultatelor (pagina i face refresh).
Dac cutarea ntoarce un singur rezultat, dup tergerea pacientului aplicaia se ntoarce la
pagina de cutare.

3.1.2.3 Cutarea unui pacient

Un medic poate cuta un pacient dup 2 criterii:

dup nume i prenume

dup codul numeric personal

Medicul are la dispozitie o list cu cele dou opiuni. n funcie de opiunea aleas,
medicul trebuie s scrie ntr-un textfield ceea ce caut. Dac cutarea se face dup nume i
prenume, medicul trebuie s tasteze numele pacientului sau numele i prenumele acestuia
separate printr-un spaiu. Dac cutarea se face dup cod numeric personal, medicul trebuie s
tasteze un CNP valid. Datele introduse de medic sunt validate. Dup validare, prin apsarea tastei

47

ENTER sau a butonului de cutare, se execut cutarea in baza de date. Cutarea se face de fapt
ntr-un JSP separat (se execut un SELECT).
Dac n urma cutrii nu a fost gsit nici un rezultat, se afieaz un mesaj corespunztor,
iar dac a fost gsit cel puin un pacient care s corespund criteriului dup care s-a efectuat
cutarea, rezultatele sunt afiate ntr-o nou pagin, ntr-un tabel. n acest tabel sunt afiate datele
personale ale pacienilor gsii. Sub acest tabel este un buton prin apsarea cruia medicul poate
efectua o alt cutare.

3.1.2.4 Modificarea datelor unui pacient

nainte de a modifica datele unui pacient, acesta trebuie cutat. Cutarea se face dup
CNP. Dup validarea CNP-ului introdus se face cutarea. Dac nu este gsit pacientul cu CNP-ul
introdus, se afieaz un mesaj corespunztor. Dac s-a gsit pacientul, se afieaz datele
personale ale acestuia ntr-o forma editabil.
Singurul cmp care nu poate fi modificat de medic este CNP-ul (am presupus c acesta a
fost introdus corect de la nceput). n rest, toate celelalte date personale ale pacientului pot fi
modificate. Dup modificarea uneia sau a mai multor date, medicul trebuie s apese butonul de
modificare pentru modificarea acestora n baza de date. Chiar dac medicul nu modific nici un
cmp al pacientului, prin apasarea butonului de modificare tot se execut modificarea (datele
sunt actualizate cu aceleai date adic rmn nemodificate).
Modificarea propriu-zis se face prin apelul unei pagini JSP, n care se execut un query
UPDATE.
Dup modificare, medicul poate efectua o alt modificare a aceluiai pacient, sau se poate
ntoarce la pagina de cutare, pentru a cuta un alt pacient ale crui date dorete s le modifice.

3.1.2.5 Actualizarea registrului unui pacient

Registrul unui pacient conine data consultaiei, diagnosticul, tratamentul i observaiile
notate de medic la fiecare consultaie a pacientului. Diagnosticul trebuie obligatoriu completat de
medic la finalul consultaiei. Tratamentul i observaiile eu am considerat c sunt opionale
(adic medicul poate s nu scrie nimic n aceste dou rubrici ale registrului).
48

La fiecare nou consultaie a unui pacient, medicul i actualizeaz registrul cu rezultatul

acestei noi consultaii.
n aplicaia mea, medicul trebuie mai nti s caute pacientul care vine la o nou
consultaie. Cutarea se face dup cod numeric personal pentru a identifica pacientul n mod
unic. Dac CNP-ul respectiv nu este gsit n baza de date se afieaz un mesaj corespunztor, iar
dac este gsit se afieaz datele personale ale pacientului care deine acel cod numeric personal.
Prin executarea unui click se deschide o alt fereastr n care medicul poate vedea
registrul pacientului. Consultaiile nregistrate n registru sunt afiate n ordine cresctoare a datei
la care au fost efectuate (ca i cum ar fi scrise ntr-un caiet). Ultima consultaie afiat va fi cea
mai recent.
n partea de jos a paginii registrului, medicul trebuie s completeze datele consultaiei din
ziua respectiv (am considerat c odat ce medicul a deschis pagina de actualizare a registrului
unui pacient, aceasta nseamn c respectivul pacient a venit la medic pentru o nou consultaie).
ntr-o celul este automat trecut data curent (aceasta reprezint de fapt data consultaiei care
tocmai s-a efectuat), medicul trebuind s completeze celelalte 3 rubrici: diagnostic, tratament i
observaii. Totui, completarea acestor rubrici nu este obligatorie. Medicul poate prsi fereastra
prin nchiderea acesteia, registrul pacientului rmnnd nemodificat.
Dup ce medicul completeaz registrul cu noile date, prin apsarea unui buton de
actualizare, acestea sunt memorate n baza de date. Actualizarea registrului pacientului se face cu
ajutorul unei pagini JSP, care se conecteaz la baza de date i execut o instruciune INSERT.
Dac medicul, din greeal, mai acceseaz odat pagina de actualizare n decursul
aceleiai zile, aplicaia semnaleaz un mesaj de eroare (un medic nu poate efectua dou
consultaii ale aceluiai pacient n aceeai zi). O alt explicaie a acestui lucru ar mai fi c data
sistemului poate fi greit. Punnd aceast restricie, chiar dac data calculatorului este greit,
medicul i va da seama, deoarece n mesajul de eroare afiat i se semnaleaz i posibilitatea
acestui lucru.

49

3.1.2.6 Vizualizarea listei pacienilor

Odat logat, un medic trebuie s-i poat vedea toi pacienii, dac dorete acest lucru.
Printr-un simplu click pe opiunea Vizualizare pacieni din meniul aplicaiei, medicul poate
vedea un tabel cu toi pacienii si.
ntruct exist posibilitatea ca numrul pacienilor unui medic s fie foarte mare, tabelul
n care acetia sunt afiai nu va avea loc pe ecran, medicul fiind obligat s foloseasc barele de
defilare pentru a cuprinde tot tabelul.
Eu am hotrt s nu folosesc barele de defilare. n schimb, am optat pentru dou link-uri
cu ajutorul crora medicul poate parcurge tabelul cu pacienii nainte i napoi. n urma mai
multor ncercri am convenit ca pe fiecare pagin s fie afiai cte 12 pacieni. Dac numrul
total al pacienilor depete 12, prin apsarea link-ului Pagina urmtoare se vor afia
urmtorii 12 i tot aa.
De asemenea, prin intermediul acestui tabel cu pacienii, medicul are acces i la registrul
unui pacient, prin executarea unui simplu click pe numele pacientului al crui registru dorete s
l vizualizeze.

3.2 Structura site-ului

Site-ul este structurat pe 3 directoare:

pages - conine paginile principale principale ale aplicaiei

actions - conine aciunile formelor existente n site

js - conine fiierele JavaScript

Fiierele directorului actions sunt paginile JSP care se conecteaz la baza de date i
execut diverse operaii.
Prin intermediul fiierelor JavaScript se valideaz diverse date introduse de medic.

50

3.3 Rularea aplicaiei

Pentru rularea aplicaiei (site-ului) trebuie n primul rnd instalat mediul Java pe
calculatorul pe care se dorete rularea. Trebuie instalat pachetul JDK (eu am folosit JDK
versiunea 1.5.0_02) i de asemenea JRE. Apoi ne trebuie un server care s suporte JSP. Eu am
optat pentru serverul Tomcat pentru c este gratuit i totodat este cel mai utilizat n acest
domeniu (acest server necesit o versiune de JRE instalat pentru c el utilizeaz Java).
Singurul instrument care mai trebuie pentru rularea corect a aplicaiei este serverul de
baze de date MySQL. i acesta este gratuit i este cel mai popular server de baze de date folosit
la ora actual.
Cteva cuvinte despre serverul Apache Tomcat
Apache Tomcat este cel mai simplu server i este i gratuit. Acesta este o parte a
proiectului Apache Jakarta i reprezint o implementare de referin oficial pentru servleturile
Java i pentru specificaiile JSP (eng. Java Server Pages). Poate fi obinut de la adresa:
http://jakarta.apache.org/tomcat/

Apoi, se instaleaz local dezarhivnd fiierele copiate. Urmeaz pornirea serverului

Tomcat prin comanda startup. Se poate verifica dac instalarea i pornirea serverului Tomcat sau fcut cu succes dac atunci cnd se solicit unui navigator Web adresa (URL-ul)
http://localhost:8080/, se obine pagina de lucru a serverului Tomcat. Se poate modifica

numrul portului (8080) editnd i schimbnd poriunea de cod corespunztoare din fiierul
/jakartatomcat/conf/server.xml.

Lucrurile se petrec similar pe platforma Unix/Linux.

Toate servleturile specifice standardului Servlet API 2.2 utilizeaz conceptul de aplicaie
Web (mai nou a aprut versiunea 3.0). O aplicaie Web este o ierarhie de directoare i fiiere care
formeaz mpreun o aplicaie. De obicei, acestea sunt distribuite ntr-un fiier de aplicaii Web
arhivate (n general cu extensia .war). Toate aplicaiile Web utilizeaz aceeai structur de
directoare referitoare la serverul utilizat. ns locul unde sunt instalate aplicaiile Web poate s
difere de la un server la altul. De exemplu, Tomcat pstreaz toate aplicaiile Web n directorul
/jakartatomcat/webapps.
51

n aceste subdirectoare ale directorului webapps va cuta serverul Tomcat fiiere HTML,
JSP i imaginile asociate unei aplicaii Web. n general, fiecrei aplicaii Web i se atribuie un
drum de context unic de ctre administratorul de sistem. Toate cererile ctre acest drum de
context vor fi direcionate ctre aplicaia Web corespunztoare.
Dac aplicaiei Web i se atribuie drumul de context /examples, atunci URL-ul
http://localhost:8080/examples/index.html va afia fiierul index.html aflat n

directorul jakartatomcat/webapps/examples.
Drumul de context pentru fiecare aplicaie Web este specificat n fiierul server.xml din
directorul jakartatomcat/conf/.
n plus, o aplicaie Web poate fi definit prin specificarea unui drum de context vid. De
exemplu, Tomcat instaleaz aplicaia ROOT ca aplicaie implicit prin asignarea contextului vid.
De exemplu, URL-ul http://localhost://8080/index.html va returna fiierul
index.html din directorul /jakartatomcat/webapps/ROOT.
Apelarea servleturilor utiliznd serverul Tomcat se realizeaz dup urmtorul format
pentru URL:
http://<server>:<port>/<drum_context>/servlet/<nume_servlet>[/<informa
?ii_drum>][?<ir_interogare>]

Identificatorii scrii ntre paranteze unghiulare (<, >) semnific faptul c acetia trebuie
nlocuii. <drum_context> reprezint locul unde se memoreaz aplicaia Web (acesta trebuie s
fie unic). Cuvntul servlet indic serverului Tomcat c este vorba de un servlet i nu o pagina
HTML sau JSP; <nume_servlet> reprezint numele clasei servletului sau numele servletului
(alias); <informa?ii_drum> i <ir_interogare> sunt componente suplimentare pentru un
URL. <informaii_drum> se refer la informaii suplimentare. Acestea pot fi obinute aplicnd
metoda getPathInfo() a obiectului HttpServletRequest. De exemplu, dac se apeleaz
un servlet numit ObineCaleServlet prin URL-ul:
http://localhost:8080/servlet/ObtineCaleServlet/html/public?
name=value

52

atunci valoarea returnat de metoda getPathInfo() este /html/public.

<ir_interogare> permite trimiterea de informaii suplimentare unui servlet

utiliznd formatul nume = valoare. irurile nume = valoare din interogare pot fi citite apelnd
pentru

un

obiect

HttpServletRequest

metodele

getParameterNames(),

getParameter() i/sau getParameterValue().

Configurarea i rularea aplicaiei

Dup instalarea MySQL-ului, trebuie creat baza de date folosit de aplicaie, mpreun
cu tabelele aferente acesteia. Eu am numit baza de date medicidefamilie. Pentru crearea ei am
folosit aplicaia EMS MySQL Manager (se poate folosi orice alt aplicaie de genul acesteia).
Dup ce baza de date este creat, mai rmne de fcut un singur pas i anume
nregistrarea bazei n Control Panel, pentru a fi accesibil aplicaiei.
Dac toate cele spuse mai sus s-au realizat corect, ar trebui s fie totul n regul.
Pentru rularea aplicaiei trebuie deschis un browser de Web i la adres trebuie scris:
http://localhost:8080/licenta

Cuvntul localhost specific faptul c aplicaia ruleaz pe calculatorul local. Dac se

dorete rularea de pe un alt calculator dect cel local, n locul cuvntului localhost trebuie scris
IP-ul mainii pe care se afl instalat aplicaia.
8080 este portul implicit al serverului Tomcat.
Cuvntul licenta reprezint directorul n care este stocat aplicaia. Acest director
trebuie

se

gseasc

directorul:

dir_instalare_Tomcat/webapps/ROOT,

unde

dir_instalare_Tomcat este directorul unde este instalat serverul Tomcat.

n momentul cnd scriem adresa de mai sus n browser, browser-ul va cuta n
dir_instalare_Tomcat/webapps/ROOT/licenta fisierul index.jsp (acest fiier reprezint prima
pagin a aplicaiei). Dac nu l gsete, se va semnala o eroare.

53

BIBLIOGRAFIE

1. tefan Tanas, Cristian Olaru, tefan Andrei Java de la 0 la expert

2. Bruce Eckel Thinking in Java
3. James Goodwill Pure JSP Java Server Pages: A Code - Intensive Premium Reference
4. Lon Marco EJB&JSP: Java On The Edge
5. OReilly Java Servlet Programming
6. OReilly Database Programming with JDBC and Java
7. Marty Hall- Core Servlets and Java Server Pages
8. Jay Greenspan and Brad Bulger- MySQL/PHP Database Applications
9. Detron HB and Monty Program KB- MySQL Reference Manual
10. Jim Hoffman- Introduction to Structured Query Language

54