UNIVERSITATEA DIN CRAIOVA

Aplicatie Web De Licitatii On-Line

Cuvant Inainte

Aplicatiile distribuite snt de o buna perioada de timp o prezenta uzuala n peisajul IT chiar si din tara noastra. Ultimii ani au nsemnat, de asemenea, si pasi semnificativi si concreti n impunerea Internetului n ntreaga economie si societate. Odata cu acesta, aplicatiile distribuite care au ca suport Internetul si tehnologiile dezvoltate pentru acesta si mpreuna cu el, au trecut de la stadiul de noutati tehnologice la cel de prezenta reala n comunitatea IT.

Comertul electronic a devenit foarte cunoscut in societatea informationala care se dezvolta continuu din 1990. Internetul a facut comertul electronic sa fie disponibil unui larg grup de utilizatori, in principal mici intreprinderi si utilizatori caznici. In cadrul comunitatii de afaceri, indreptarea catre eficienta si productivitate crescuta este de asteptat sa duca catre o mai mare acceptare a comertului electronic catre intreprinderi ca fiind o cale de a face afaceri in viitor. Dezvoltarea tehnologica a infrastructurii si a mecanismelor de acces si costurile in scadere vor ajuta dezvoltarea acestuia. Totusi temerile de securitate si lipsa de instruire pot fi un obstacol in dezvoltarea comertului electronic.

Comertul electronic ofera o serie de avantaje majore. Principale avantaje sunt si cele mai cunoscute atuuri din lume: timpul si banii. In ceea ce priveste timpul, se face o foarte mare economie. Utilizatorul poate sa vada o lista de produse si preturi in cateva minute din confortul propriului fotoliu. Nu mai sunt necasare deplasari sau alte actiuni care consuma timp inutil. Aceasta economie de timp rezulta astfel intr-o crestere a rentabilitatii, de unde reiese si o economie de bani. Tehnologia JSP (Java Server Pages)

Tehnologia JSP permite crearea rapida si usoara de continut Web ce are componente atat statice cat si dinamice. La baza aceasta tehnologie proiecteaza toate capacitatile dinamice a tehnologiei Java Servlet dar ofera un unghi mai natural in ceea ce priveste creare de continut static. Principalele trasaturi ale tehnologiei JSP sunt:

Este un limbaj pentru dezvoltarea de pagini JSP, care sunt documete text ce descriu modul de procesare a unei cereri si de construire a unui raspuns

Posibilitatea de a accesa obiecte ce ruleaza pe server

Existenta de mecanisme ce permit definirea de extensii pentru limbajul JSP

Ce este o pagina JSP ?

O pagina JSP este un document text ce contine 2 tipuri de text: static, ce poate fi exprimat in orice tip de format bazat pe text (HTML,SVG,WML, si XML), si continutul JSP propriu-zis altfel spus dinamic.

Ciclul de viata al unei pagini JSP

O pagina JSP deserveste cererile asemenea unui servlet. Din acest motiv ciclul de viata al unei pagini JSP si multe din capacitatile sale (in special cele dinamice) sunt determinate de Tehnologia JavaServlet.

Cand o cerere este mapata pe o pagina JSP, de managementul ei se ocupa un servlet special care verifica mai intai daca servletul paginii JSP este mai vechi decat pagina JSP. Daca da, traduce pagina JSP intr-o clasa servlet si compileaza clasa. In timpul operatiei de dezvoltare unul dintre principalele avantaje ale paginii JSP este ca procesul de constructie (build process) este facut automat.

Traducere si Compilare

In timpul fazei de traducere fiecare tip de date dintr-o pagina JSP este tratata in mod diferit. Elementele JSP sunt tratate dupa cum urmeaza:

Directivele sunt utilizate pentru a controla cum va fi translatata si executata pagina JSP de catre containerul Web

Elemetele de scripting sunt inserate in clasa servlet a pagini JSP

Elemente de forma sunt convertite in apeluri catre metode ale componentelor JavaBeans

Atat faza de traducere cat si cea de compilare pot genera erori care nu se observa decat in momentul in care pagina este apelata pentru prima oara. Daca apare o eroare in timp ce o pagina JSP este tradusa, spre exemplu translatorul intalneste un element JSP eronat, serverul va returna o exceptie de tip ParseException si clasa servlet a paginii va fi goala sau incompleta. Ultima linie incompleta va returna un pointer catre linia ce contine eroarea.

Daca apaere o eroare in timp ce pagina este compilata, spre exemplu exista o eroare de sintaxa intr-un scriplet, serverul va returna o eroare de tip JasperException si un mesaj catre numele servletului pentru pagina respectiva si linia la care a aparut eroarea.

Odata ce pagina a fost tradusa si compilata servletul paginii JSP urmeaza in linii mari acelasi ciclu de viata ca un servlet, si anume:

Daca nu exista o instanta a servletului paginii JSP atunci containerul:

1. Incarca clasa servlet a paginii JSP

2. Instantiaza o instanta a clasei servlet

3. Initializeaza instanta servlet apeland metoda jspInit

Invoca metoda _jspService pasand o cerere si un obiect de raspuns

In momentul in care containerul trebuie sa elimine servletul unei pagini JSP va apela metoda jspDestroy

Executie

Diversi parametri de executie ai unei pagini JSP pot fi controlati prin intermediul directivelor de pagina. In continuare se vor prezenta directivele ce tin de output buffering si managementul erorilor.

Buffering. Cand o pagina JSP este executata iesirea catre obiectul de raspuns este automat buffrat. Dimensiunea bufferului utilizat se poate fixa utilizand urmatoarea directiva de pagina;

Un buffer mai mare permite ca un continut mai mare de informatie sa fie scris inainte de a se trimite ceva catre client acordand mai mult timp JSP-ului de a realiza anumite operatii specifice. Pe de alta parte un buffer mai mic scade gradul de incarcare a memoriei serverului si permite clientului sa primeasca date mai rapid.

Managementul Erorilor. In timpul executiei unei pagini JSP poate aparea o gama variata de erori. Pentru a specifica containerului Web sa redirecteze controlul catre o pagina de eroare se include urmatoarea directiva la inceputul paginii JSP:

De asemenea trebuie specificat la inceputul paginii de eroarea ca aceasta serveste ca pagina de erori si acest lucru se realizeaza prin intermediul directivei

Aceasta directiva face accesibil in pagina obiectul exceptie de tip javax.servlet.jsp.JspException astfel incat acesta sa poate fi interpretat si chiar sa se afiseze informatii despre cauza exceptiei in interiorul paginii de eroare.

Crearea de continut static si dinamic

In cadrul JSP crearea continutului static se realizeaza ca si cum intreaga pagina ar fi constituita numai din astfel de continut. Continutul static poate fi exprimat in orice limbaj de acest gen cum ar fi HTML, WML si XML. Formatul implicit este HTML. Pentru a putea folosi un alt format decat HTML trebuie inclusa la inceputul paginii o directiva de pagina cu atributul contentType setat la valaorea formatului respectiv. Spre exemplu daca se doreste utilizarea formatului WML (Wireless Markup Language) este obligatorie includerea unei directive de genul:

Crearea de continut dinamic Acest tip de format este creat prin accesarea limbajului de programare JAVA prin elemetele de scripting.

Utilizarea de obiecte in paginile JSP

Obiecte Implicite. Anumite obiecte sunt create implicit de catre containerul Web impreuna cu informatii ce se refera la o anumita cerere, pagina sau aplicatie. Marea majoritate a acestor elemente sunt definite de catre tehnologia JavaServlet care sta la baza tehnologiei JSP. In tabelul de mai jos sunt prezentate pe scurt obiectele implicite

VariablaClasaDescriere

applicationjavax.servlet. ServletContextContextul pentru servletul paginii JSP si pentru orice componenta Web continuta in aceeasi aplicatie

configjavax.servlet. ServletConfigInformatii de initializare pentru servletul paginii JSP.

exceptionjava.lang. ThrowableAccesibila numai intr-o pagina de eroare

outjavax.servlet. jsp.JspWriterStreamul de iesire

pagejava.lang. ObjectInstanta serveltului paginii JSP ce proceseaza cererea curenta

pageContextjavax.servlet.jsp.PageContextContextul paginii JSP

requestSubtip al javax.servlet. ServletRequestCererea ce porneste executia unei pagini JSP

responsesubtype of javax.servlet. ServletResponseRaspunsul ce trebuie returnat clientului

sessionjavax.servlet. http.HttpSessionObiectul sesiune pentru client

Obiecte specifice aplicatiei. De cate ori este posibil trebuie ca partile ce tin de comportametul aplicatiei sa fie incapsulate in obiecte, usurand astfel munca designerilor. Astfel de obiecte pot fi create de catre developeri ce au mai multa experienta si sunt versati in utilizarea limbajului de programare JAVA sau in accesarea de baze de date si alte servicii. Exista 4 metode in care se pot creea si utiliza obiecte in interiorul paginilor JSP:

Instante si variabile ale clasei servlet corespunzatoare paginii JSP sunt create in declaratii si apoi accesate in scripleti si expresii

Variabile locale ale clasei servlet sunt create si utilizate in scripleti si expresii

Atribute ale obiectelor sunt create si utilizate in scripleti si expresii

Componente JavaBeans pot si create si accesate utilizand elemente JSP.

Nota: Notiunile de declaratie, scriplet si expresie vor fi prezentate in cele ce urmeaza.

Obiecte Partajate. Modul in care un container Web trateaza cereri multiple din partea clientilor poate fi indicat perin intermediul directivei

Cand isThreadSafe este setat pe TRUE containerul Web poate opta pentru transmiterea de cereri multiple concurente catre pagina JSP, aceasta fiind si setarea implicita. Daca se foloseste setarea TRUE developerul trebuie sa realizele sincronizarea corecta in ceea ce priveste accesul la elemetele partajate ce exista la nivel de pagina. Daca isThreadSafe este setat la valoarea FALSE cererile sunt livrate una cate una in ordinea sosirii lor, si accesul la obiectele partajate ce exista la nivelul paginii nu trebuie controlat de catre developer.

Elemente de Scripting JSP

Acest tip de elemente sunt utilizate pentru a accesa obiecte, a definii metode si pentru mamagementul fluxului de control. Avand in vedere faptul ca unul dintre scopurile principale ale JSP este acela de a separa datele statice de cele dinamice, se recomanda utlizare destul de restransa a scriptingului JSP .

Tehnologia JSP permite unui container sa utilizeze orice limbaj de scription care poate apela obiecte JAVA. Daca se doreste utilizarea altui limbaj de scripting decat cel implicit trebuie inclusa la incepului paginii JSP directiva de pagina

Avand in vedere ca elementele de scrption sunt convertite in expresii ale limbajului de programare JAVA, trebuie importate toate clasele si pachete utilizate de catre pagina JSP. Daca limbajul este JAVA un pachet sau o clasa poate fi importat/ importata prin intermediul urmatoarei directive de pagina

Declaratii. O declaratie JSP este utilzata pentru declararea de variabile si metode in limbajul de scripting utilizat de pagina respectiva. Sintaxa unei declaratii este urmatoarea:

Cand limbajul de scripting este limbajul de programare JAVA declaratiile de variabile si metode din pagina JSP devin declaratii in clasa servlet a paginii.

Scripleti. Un scriplet este utilizat pentru a incapsula orice fragment de cod valabil pentru limbajul de scription utilizat in pagina respectiva. Sintaxa unui scriplet este urmataorea:

Cand limbajul de scripting al paginii JSP este JAVA un scriptiong este transformat intr-o bucata de cod JAVA si este inserat in metodele din servletul paginii JSP. O variabila creata cu un scriplet este accesibila de oriunde din interiorul paginii.

Expresii. O expresie JSP este utilizata pentru a insera valoarea unei expresii din limbajul de scriptiong al paginii respective, convertita la String, in streamul intors clientului. Cand limbajul de scription este JAVA o expresie este transformata intr-un statement ce converteste valoarea expresiei la un obiect String si o insereaza in obiectul out implicit. Sintaxa pentru o expresie este urmatoarea :

Includerea de continut intr-o pagina JSP

Exista 2 mecanisme pentru includerea unei alte resurse Web in interiorul unei paginii JSP si anume directiva include si elementul jsp:include.

Directiva include este procesata pagina JSP este tradusa intr-o clasa servlet. Efectul este acela de includere a continutului unei pagini statice, de exempul un fisier HTML sau a unei alte pagini JSP in pagina ce utilizeaza directiva include. Aceasta directiva este utila in situatiile in care exista o bucata de cod sau informatii ce trebuie reutilizata in mai multe pagini si care se schimba destul de des. Astfel este necesara modificarea respectivului cod numai o singura data. Sintaxa directivei de include este urmataorea:

Elementul jsp:include este procesat cand pagina JSP este executata. Actiunea include permite includerea fie a unui continut static fie a unui continut dinamic in pagina apelanta. Trebuie insa avut in vedere ca rezultatele includerii de continut dinamic difera destul de mult fata de cele ale includerii de continut static. Daca resursa este statica continutul sau este inserat in fisierul JSP ce contine elementul jsp:include. Daca resursa inclusa este de tip dinamic, cererea este trimisa catre resursa inclusa, pagina inclusa este executata si rezultatul este inclus in raspunsul de la pagina JSP apelanta. Sintaxa pentru elemetul jsp:include este urmataorea:

Transferarea controlului catre o alta componenta Web

Mencanismul pentru transferarea controlului catre o alta componenta web foloseste mecanismul pus la dispozitie de catre API-ul JAVA Servlet. Sintaxa pentru acest mecanism este :

Trebuie luat in considerare faptul ca, executia directivei forward se face in momentul returnarii de date catre client, atunci directiva va genera o eroare de tipul IllegalStateException.

Elementul jsp:param. Cand un element include sau forward este invocat, obiectul de tip cerere original este furnizat paginii tinta. Daca se doreste, se pot furniza si alte date aditionale paginii tinta prin atasare de parametrii la obiectul de tip cerere prin intermediul elementului jsp:param. Sintaxa pentru acest element este urmatoarea:

Includerea unui Applet

Includerea unui aplet sau a unei componente JavaBean in interiorul unei pagini se poate realiza prin intermediul elementului jsp:plugin. Acest element genereaza codul HTML ce contine constructorii specifici dependenti de browser ( sau ) care vor rezulta in downloadul plugin-ului JAVA (daca este necesar acest lucru) si a componentelor client si apoi executia acestor componente. Sintaxa pentru elementul jsp:plugin este urmatoarea:

{

{ }+

}

{ arbitrary_text }

Acest tag jsp:param este inlocuit fie de un tag fie dupa cum este cazul. Atributele tagului ofera date de configurare in ceea ce priveste configurarea elementului precum si versiunea de plug-in necesara. Dintre acestea atributele nspluginurl si iepluginurl specifica URL-ul de unde se poate downlada plug-in-ul in cauza.

Elementele jsp:param specifica parametrii pentru applet sau componentele JavaBeans. Elemetul jsp:fallback indica continutul ce trebuie folosit de catre clinet in cazul in care plug-in-ul nu poate fi pornit.

Daca plug-in-ul porneste dar appletul sau componenta JavaBean nu este gasita sau pornita utilizatorului i se va returna un mesaj ce indica o exceptie de tipul ClassNotFoundException.

Structura programelor

Pachete de clase

Clasele Java sunt organizate pe pachete. Aceste pachete pot avea nume ierarhice. Numele de pachete au forma urmatoare:

[NumePachet.]* NumeComponentaPachet Numele de pachete si de componente ale acestora sunt identificatori Java. De obicei, aceste nume urmeaza structura de directoare n care sunt memorate clasele compilate. Radacina arborelui de directoare n care sunt memorate clasele este indicata de o variabila sistem CLASSPATH. n DOS aceasta se seteaza n felul urmator: set CLASSPATH=.;c:\java\lib n Unix se poate seta cu comanda:

CLASSPATH=.:/usr/local/lib/java ; export CLASSPATH daca lucrati cu bash . Din aceasta radacina, fiecare pachet are propriul director. n director exista codul binar pentru componentele pachetului respectiv. Daca pachetul contine subpachete, atunci acestea sunt memorate ntr-un subdirector n interiorul directorului pachetului.

Creatorii Java recomanda folosirea unei reguli unice de numire a pachetelor, astfel nct sa nu apara conflicte. Conventia recomandata de ei este aceea de a folosi numele domeniului Internet apartinnd producatorului claselor. Astfel, numele de pachete ar putea arata ca n:

COM.Microsoft.OLE

COM.Apple.quicktime.v2

si asa mai departe.

Importul claselor

Desigur, este nevoie ca o clasa sa poata folosi obiecte apartinnd unei alte clase. Pentru aceasta, definitia clasei respective trebuie sa importe codul binar al celeilalte clase pentru a sti care sunt variabilele si metodele clasei respective. Importul se face cu o instructiune speciala:

import numeClasa ;

unde numele clasei include si pachetul din care aceasta face parte. De exemplu:

import java.awt.Graphics;

import java.applet.Applet;

Se poate importa si un pachet ntreg, adica toate clasele apartinnd acelui pachet, printr-o instructiune de forma:

import numePachet.*;

De exemplu:

import java.awt.*;

Fisiere sursa

Codul sursa Java trebuie introdus cu un editor ntr-un fisier text pe care l vom numi n continuare fisier sursa. Un fisier sursa poate sa contina declaratia mai multor clase si interfete, dar doar una dintre acestea poate fi declarata publica. Utilizarea celorlalte clase este limitata la fisierul respectiv. Mai mult, nu putem avea n acelasi timp o interfata publica si o clasa publica declarate n acelasi fisier sursa.

Daca dorim sa nregistram codul clasei ntr-un anumit pachet, putem sa includem la nceputul fisierului sursa o declaratie de forma:

package numePachet;

daca aceasta declaratie lipseste, clasa va fi plasata n pachetul implicit, care nu are nume.

Structura generala a unui fisier sursa este urmatoarea:

[ DeclaratiePachet ][ InstructiuneImport ]*[ DeclaratieDeTip ]*

unde declaratia de tip poate fi o declaratie de clasa sau de interfata.

Compilare si executie

Fisierele sursa Java au obligatoriu extensia .java . Numele lor este identic cu numele clasei sau interfetei publice declarate n interior. n urma compilarii rezulta fisiere cu nume identice cu numele claselor dar cu extensia .class indiferent daca este vorba de o clasa sau o interfata. Fisierul .class este generat n directorul local si nu direct la locatia pachetului.

Compilarea se face cu o comanda de forma:

javac FisierSursa .java Comanda aceasta, ca si celelalte descrise n acest paragraf este specifica mediului de dezvoltare Java pus la dispozitie de Sun, numit JDK (Java Development Kit). n viitor este probabil sa apara multe alte medii de dezvoltare care vor avea propriile lor compilatoare si interpretoare si, posibil, propriile linii de comanda.

La compilare, variabila sistem CLASSPATH trebuie sa fie deja setata pentru ca nsusi compilatorul Java actual este scris n Java.

Pentru lansarea n executie a unei aplicatii Java, trebuie sa introduceti comanda:

java NumeClasa

unde numele clasei este numele aplicatiei care contine metoda main . Interpretorul va cauta un fisier cu numele NumeClasa.class si va ncerca sa instantieze clasa respectiva.

Pentru lansarea unui aplet veti avea nevoie de un document HTML care contine tagul APPLET si ca parametru al acesteia

name=NumeClasa.class

La lansarea unui aplet, clasele care sunt apelate de clasa principala sunt mai nti cautate pe sistemul pe care ruleaza navigatorul. Daca nu sunt acolo, ele vor fi transferate n retea. Asta nseamna ca transferul de cod este relativ mic, trebuie transferat doar codul specific aplicatiei.

ServletiServleturile permit interactiunea in ambele sensuri intre client si server. O parte dintre posibilitatile furnizate de servleturi sunt:

construiesc dinamic si returneaza un document HTML pe baza cererii clientului;

proceseaza datele completate de utilizatori printr-un formular HTML si returneaza un raspuns;

furnizeaza suport pentru autentificarea utilizatorului si alte mecanisme de securitate;

interactioneaza cu resursele serverului, cum ar fi baze de date, fisiere cu informatii

utile pentru clienti;

proceseaza intrarile de la mai multi clienti pentru aplicatii, cum ar fi jocuri in retea;

permite serverului sa comunice cu un applet client printr-un protocol specific

si pastreaza conexiunea in timpul conversatiei;

- ataseaza automat elemente de design pentru pagini Web, cum ar fi antete sau note

de subsol, pentru toate paginile returnate de server;

redirecteaza cereri de la un server la altul in scop de echilibrare a incarcarii

(eng. load-balancing);

- partitioneaza un serviciu logic intre servere sau intre servleturi pentru a procesaeficient o problema.

Poate cea mai important component a unui servlet, fr de care funcionalitatea acestuia s-ar pierde, este reprezentat de interaciunea cu clientul. La primirea unei cereri de la un client, programul primete dou obiecte: ServletRequest si Servlet Response. Primul obiect este cel care realizeaz "ncapsularea" comunicaiei dinspre client ctre server, iar al doilea este responsabil de comunicaia n sens invers de la server, napoi ctre client. Cele dou interfee (ServletRequest, ServletResponse) sunt incluse n pachetul javax.servlet.

Structura de baza a unui servlet

Cel mai usor mod de definire a servleturilor este prin extinderea uneia dintre cele doua clase de baza referitoare la servleturi: GenericServlet si HttpServlet. De fapt, nu este obligatorie mostenirea acestor clase, ci este suficienta implementarea interfetei Servlet.

Toate servleturile suprascriu cel putin o metoda necesara functionalitatii lor. Metoda care este automat apelata ca raspuns la cererea fiecarui client se numeste service(). Aceasta metoda poate fi suprascrisa pentru a furniza o functionalitate implicita. Cu toate acestea, servleturile care extind HttpServlet pot sa nu suprascrie metoda service(). In acest caz, implementarea implicita a acestei metode va apela automat alta metoda pentru a raspunde cererii clientului.

Mai exista inca doua metode implementate de majoritatea servleturilor: init() si destroy().

Metoda init() se afla acolo unde incepe un servletul. Ea este apelata de catre server cand este incarcat servletul (similar cu un constructor). Se apeleaza o singura data. In metoda init(), servletul creeaza si initializa orice resursa, inclusiv datele membre.

Prototipul metodei init() este:

public void init(ServletConfig config) throws ServletException;

Metoda init() ia ca paramentru un obiect din ServletConfig. Acest obiect trebuie salvat astfel incat sa se poate face referire la el mai tarziu. Cel mai utilizat mod de a face acest lucru este de a avea apelata metoda super.ini() trecuta in obiectul ServletConfig. Metoda ini() arunca o exceptie ServletException. Daca, din vreun motiv, servetul nu poate initia resursele necesare, metoda ini() va arunca o exceptie.

Metoda destroy() este apelata cand servletul este descarcat, eliberand resursele servletului. Metoda destroy() semnifica sfarsitul vietii unui servlet. Cand un serviciu urmeaza sa fie inchis, este apelata metoda destroy(). Aici orice resursa care a fost creata in metoda init() este curatata. Daca exista o conexiune la baza de date, ea se poate inchide aici. Tot aici poate fi salvata orice informatie persistenta care va fi folosita data viitoare cand un servlet va fi incarcat. Prototipul metodei este foarte simplu:

public void destroy();

Un schelet pentru servleturi poate fi (fara a preciza parametrii si exceptiile):

public class ScheletServlet extends HttpServlet

{

public void init() {

// codul de initializare

}

public void service() {

// partea efectiva de lucru a servletului

}

public void destroy() {

// eliberarea resurselor

} // sfarsitul clasei ScheletServlet

Daca servletul extinde HttpServlet, dezvoltatorul servletului poate sa nu suprascrie metoda service(), ci sa implementeze alta metoda care va fi automat apelata de metoda mostenita service(). Metoda automat apelata de service() depinde de tipul cererii HTTP (de exemplu, doGet () este apelata pentru cererile GET si doPost () este apelata pentru cererile POST).

Un servlet HTTP gestioneaz cererile clienilor cu ajutorul metodei service. In funcie de metoda (GET sau POST) cu care a fost formulat cererea clientului, metoda service transmite cererea spre procesare, unor metode precum doGet sau doPost.

Metodele din clasa HttpServlet, care proceseaz cererile clienilor, au dou argumente:

a) Un obiect HttpServletRequest care ncapsuleaz datele transmise de la client

b) Un obiect HttpServletResponse care ncapsuleaz rspunsul serverului spre clieni

a) Pentru accesarea datelor transmise de la client

se apeleaz metodele getParameter (getParameterValues) care au ca argumente numele unui (unor) parametri i returneaz valoarea (valorile) acestora.

pentru cereri de tipul HTTP GET, metoda getQueryString returneaz un obiect String care conine datele transmise de la client sub forma:

URL?num_param1=val1+ num_param2=val2+...

pentru cereri de tipul HTTP POST, PUT sau DELETE:

dac se ateapt date de tip text, se folosete metoda getReader, care returneaz un obiect BufferedReader din care se vor citi datele transmise

dac se ateapt date binare, se apeleaz metoda getInputStream care returneaz un obiect de tipul ServletInputStream

b) Un obiect HttpServletResponse ofer dou moduri de a transmite date utilizatorului:

cu ajutorul metodei getWriter, care returneaz un obiect Writer, n care se scriu date de tip text

cu ajutorul metodei getOutputStream, care returneaz un obiect ServletOutputStream, n care se scriu date binare

nainte de accesarea obiectelor Writer i ServletOutputStream, servlet-ul are sarcina de a seta header-ul HTTP al mesajului de rspuns. De exemplu, metoda setContentType seteaz tipul coninutului. Metodele, crora metoda service le transmite sarcina de a procesa cererile HTTP, sunt urmtoarele:

doGet pentru cereri GET, GET condiional, HEAD.

doPut pentru cereri POST sau PUT.

doDelete pentru cereri DELETE.

Servlet-urile sunt capabile s deserveasc simultan mai muli clieni. Dac n metoda de procesare a cererii se acceseaz o resurs partajat, atunci se vor include mecanisme de sincronizare. O alternativ ar fi s se proceseze o singur cerere la un moment dat. Pentru aceasta, servlet-ul trebuie s implementeze interfaa SingleThreadModel, care nu presupune scrierea unor metode suplimentare.

La terminarea ciclului de via a unui servlet, de exemplu la cererea administratorului serverului, se apeleaz metoda destroy. Aceast funcie este oferit de clasa HttpServlet i este suprascris n servlet-ul curent, pentru a distruge resurse specifice servlet-ului i pentru a realiza alte operaii de clean-up.

Inainte de terminarea servlet-ului, se impune restricia ca toate instanele acestuia, care deservesc cereri ale clienilor, s se ncheie. Serverul asigur aceast condiie apelnd metoda destroy numai dup ce toate metodele service, de procesare ale cererilor, s-au ncheiat sau dup ce o anumit perioad de timp a expirat. In cazul unor cereri care necesit un timp mai mare de procesare, se pot folosi urmtoarele tehnici:

serverul menine un contor care indic cte thread-uri ruleaz metoda service n mod curent. Metoda destroy este apelat cnd acest contor ajunge la valoarea 0.

metoda destroy anun thread-urile, care proceseaz aceste cereri, c trebuie s-i ncheie activitatea, dup care ateapt terminarea lor.

thread-urile de procesare de lung durat verific periodic dac serverul a primit o cerere de shut-down, iar n caz afirmativ i ncheie activitatea i returneaz.

Cnd un server ncarc un servlet, serverul apeleaz metoda init, pentru a realiza diferite operaii de iniializare specifice acestuia. Aceast metod este oferit de clasa HttpServlet i suprascris n servlet-ul curent. Dac apare o eroare de iniializare, de exemplu dac nu se poate stabili conexiunea de reea cerut, metoda init genereaz eroarea UnavailableException. Iniializarea se termin nainte ca servlet-ul s rspund la cererile clienilor i nainte ca servlet-ul s fie distrus.

Dac pentru servlet au fost specificai parametri de iniializare, numele acestora poate fi obinut apelnd n funcia init metoda getParameterNames(). Pentru a obine valoarea unui anumit parametru se apeleaz metoda getInitParameter, cu argument numele parametrului.

Un servlet poate fi rencrcat numai dup ce a fost distrus cu ajutorul funciei destroy.

HTTPServlet

Servleturile HTTP (cele care extind clasa HttpServlet) sunt utilizate pentru con-struirea de aplicatii Web care de obicei intorc documente Web (HTML, XHTML, WML, XML etc.) ca raspuns la cererile navigatorului.

Clasa HttpServlet extinde clasa GenericServlet, deci mosteneste toate functio-nalitatile acesteia. In plus, HttpServlet adauga functionalitatea specifica protocolului HTTP si furnizeaza un cadru in care putem construi aplicatii HTTP.

HttpServlet este o clasa abstracta prezenta in pachetul javax.servlet.http. Pentru ca este abstracta, ea nu poate fi instantiata. Cand se construieste un servlet HTTP, trebuie extinsa clasa HttpServlet. Un servlet HTTP functional trebuie sa implementeze una din metodele: service(), doGet(), doHead(), doPost(), doPut(), doDelete() corespunzatoare metodelor protocolului HTTP.

Metodele init(), destroy() si getServletlnfo() apartin clasei Generic Servlet, din care se deriveaza clasa HttpServlet.

Metoda service() are prototipul:

Public void service(HttpServletRequest cerere, HttpServle Response raspuns)throws ServletException, Java.io.lOException;

Primul argument al metodei service () este un obiect care implementeaza interfata HttpServletRequest si este reprezentarea cererii clientului. Toate datele relevante din cerere (cum ar fi antetele HTTP) sunt incapsulate intr-un obiect Http Servlet Request. Al doilea parametru este un obiect care implementeaza interfata HttpServletResponse si este reprezentarea raspunsului serverului catre client.

Cand se utilizeaza servleturi HTTP, este recomandata utilizarea metodelor de cerere specifice HTTP, cum ar fi doGet()sau doPost(), in locul suprascrierii metodei service().

In general, metoda service() nu se suprascrie. Asta, deoarece clasa HttpServlet defineste metode care se apeleaza pentru a raspunde diferitelor tipuri specifice de cereri HTTP. Daca metoda service() nu este suprascrisa, atunci implementarea implicita este sa se apeleze o metoda doXxx() care corespunde tipului cererii realizate. Daca metoda service() este suprascrisa si sunt implementate anumite metode doXxx(), este sarcina dezvoltatorului de servlet sa evalueze cererea HTTP si sa apeleze metoda doXxx() corespunzatoare. Un container de servleturi nu apeleaza direct metodele doXxx(), ci metoda service(), care poate la randul ei sa apeleze o metoda doXxx().

Daca se incearca apelarea unei metode doXxx(), care insa nu este suprascrisa, atunci se primeste la client un mesaj de eroare: HTTP 400 "Bad Request".

Metoda doGet() are prototipul:

Protected void doGet(HttpServletRequest cerere, HttpServletResponse raspuns)throws ServletException, Java.io.lOException;

Metoda doGet() este apelata de implementarea implicita a metodei service() ca raspuns la o cerere HTTP de tip GET. Ca si alte metode de tip doXxx(), metoda doGet() are ca parametri o reprezentare a cererii clientului si un raspuns al serverului. Citirea obiectului cerere si formarea (trimiterea) obiectului raspuns este functia principala a unui servlet. Metoda GET este folosita in principal pentru a primi informatii, iar cererea este transmisa serverului sub forma unui URL.

Procesarea unei cereri prin metoda GET:

import javax.servlet.http.*;

import javax.servlet.ServletException;

import java.io.*;

public class GetUnu extends HttpServlet {

/** Returnam un mesaj scurt catre client */

protected void doGet(HttpServletRequest cerere, HttpServletResponse raspuns) throws ServletException, lOException

{ // setam tipul MIME pentru antetul HTTP raspuns.setContentType("text/html");

// obtinem o referinta la fluxul de iesire PrintWriter iesire = raspuns.getWriter();

// determinam tipul cererii

iesire.printIn("0 cerere GET rezolvata prin metoda doGet()");

iesire.close (); // inchidem fluxul de iesire

} }

Metoda doHead() a fost eliminata din Servlet API 2.2 si reintrodusa in Servlet API 2.3 pentru a rezolva cererile HTTP de tip HEAD. Daca metoda doHead() nu este suprascrisa de servlet, implementarea implicita va apela metoda doGet() pentru a genera campuri antet corespunzatoare. Apoi, se va returna catre client un raspuns ce contine doar antetul HTTP (nu si continutul documentului generat).

Prezentarea metodei doPost() are prototipul:

protected void doPost(HttpServletRequest cerere, HttpServletResponse raspuns) throwsServletException,Java.io.lOException;

Metoda doPost() este apelata de fiecare data cand apare o cerere HTTP de tip POST primita de servlet. Aceasta metoda este de obicei utilizata pentru procesarea informatiilor colectate dintr-un formular Web. Informatia introdusa de utilizator intr-un formular HTML este incapsulata intr-un obiect HttpServletRequest si trimisa metodei doPost(). Daca nu este gasita implementarea metodei doPost(), atunci se trimite catre client un mesaj de eroare: HTTP 400 "Bad Request". Metoda POST este folosita pentru a trimite date catre server; datele sunt incapsulate intr-un pachet si trimise catre server.

In cazul metodei GET, valorile parametrilor sunt atasate la sfarsitul URL-ului dupa semnul intrebarii, iar in cazul metodei POST valorile parametrilor sunt trimise pe o linie separata.

Pentru preluarea unor date de pe formular trebuie invocata metoda getParameter, avand numele parametrului ca argument. Numele parametrilor sunt senzitive. Acelasi lucru se face indiferent daca transmiterea se face prin metoda GET sau POST.

Deci, pentru a fi un servlet o clasa trebuie sa extinda HttpServlet si sa suprascrie metodele doGet() sau doPost(), sau amandoua, depinzand daca datele sunt trimise folosind metoda GET sau POST.

Aceste metode preiau doua argumente : HttpServletRequest si HttpServletResponse.

HttpServletRequest are metode care iti permit sa obtii datele dintr-un formular HTML. Acest argument permite accesul servletului la informaii cum ar fi numele parametrilor trimii de client, numele host-ului care face cererea ctre servlet, etc dar i la fluxul de intrare (stream) de la client, prin care sunt transmise variabile prin metodele POST i GET. Interfeele care extind ServletRequest permit structurarea datelor de intrare n funcie de protocolul folosit. Un exemplu de interfa de acest gen: HttpServletRequest conine metode care prelucreaz date ce vin prin intermediul protocolului HTTP.HttpServletResponse are metode care iti permit sa specifici linia de raspuns HTTP, headerele raspuns (Content-Type, Set-Cookie, etc.) si, cel mai important, te lasa sa obtii un obiect PrintWriter folosit pentru a trimite inapoi documente clientului (in fomatul MIME specificat).

Metodele doGet() si doPost() arunca 2 exceptii, asa ca este necesar sa fie incluse in declaratia clasei. De retinut este ca trebuie sa se importe java.io (pentru PrintWriter), javax.servlet (pentru HttpSevlet) si javax.servlet.http (pentru HttpServleRequest si HttpServletResponse). Metodele doPost() si doGet() sunt chemate de metoda service(), si uneori trebuie suprascrisa direct metoda service(), de exemplu, pentru servleturile care intercepteaza in acelasi timp cereri GET si POST.

SesiuniObiectele HTTPSession au fost introduse pentru a permite, prin intermediul servleturilor, s se asigure comunicare statefull ntre clieni i serverul Web. Formal, un obiect de tip HTTPSession poate reine informaii ntre dou invocri succesive ale servletui din cadrul aceleiai lansri a browserului.

Informaiile sunt pstrate la server sub forma unor perechi (nume , obiect). Un obiect HTTPSession poate desfura, printre altele, aciunile:

rspunde dac este un obiect nou sau nu (metoda isNew),

se pot depune obiecte crora li se asociaz nume (metoda setAttribute),

se opt extrage obiecte din el invocndu-se numele asociat (metoda getAttribute)

etc.

Pentru detalii se poate consulta API HTTPSession.

Modalitile prin care se obinuiete asigurarea comunicrii Web statefull:

Intreinerea unui mecanism cookies cu fiecare navigator.

Simularea unei sesiuni prin intermediul construciilor ascunse la client, sub forma: Aceste informaii ajung la server care le poate interpreta ca i obiecte de tip session.

Adugarea la URL de ctre client a unor cmpuri cu rol de informaii de tip session.

Obiecte HTTPSession

Este evident c ultima soluie este cea veritabil, toate celelalte fiind, ntr-un fel sau altul dependente de client.

Ciclul de viata al unei sesiuni:

Ciclul de viata al unei sesiuni este foarte simplu.Sesiunea este creata pe server ca raspuns al unei crereri a cientului si i se asigneaza un sessionId iar acest Id este trimis clinetului. Sesiunea insasi, este cumva considerata ca noua pana cand clientul returneaza sessionId-ul la server indicand ca sesiunea a fost stabilita. Aceasta asociaza clientul cu un anumit obiect sesiune. O sesiune exista pe server pana cand este ori oprita ori invalidata.

Fire de executie si sincronizare

O aplicatie Java ruleaza n interiorul unui proces al sistemului de operare. Acest proces consta din segmente de cod si segmente de date mapate ntr-un spatiu virtual de adresare. Fiecare proces detine un numar de resurse alocate de catre sistemul de operare, cum ar fi fisiere deschise, regiuni de memorie alocate dinamic, sau fire de executie. Toate aceste resurse detinute de catre un proces sunt eliberate la terminarea procesului de catre sistemul de operare.

Un fir de executie este unitatea de executie a unui proces. Fiecare fir de executie are asociate o secventa de instructiuni, un set de regisitri CPU si o stiva. Un proces nu executa nici un fel de instructiuni. El este de fapt un spatiu de adresare comun pentru unul sau mai multe fire de executie. Executia instructiunilor cade n responsabilitatea firelor de executie. n cazul aplicatiilor Java interpretate, procesul detine n principal codul interpretorului iar codul binar Java este tratat ca o zona de date de catre interpretor. Dar, chiar si n aceasta situatie, o aplicatie Java poate avea mai multe fire de executie, create de catre interpretor si care executa, seturi distincte de instructiuni binare Java.

Fiecare dintre aceste fire de executie poate rula n paralel pe un procesor separat daca masina pe care ruleaza aplicatia este o masina cu mai multe procesoare. Pe masinile monoprocesor, senzatia de executie n paralel a firelor de executie este creata prin rotirea acestora pe rnd la controlul unitatii centrale, cte o cuanta de timp fiecare. Algoritmul de rotire al firelor de executie este de tip round-robin.

Mediul de executie Java executa propriul sau control asupra firelor de executie. Algoritmul pentru planificarea firelor de executie, prioritatile si starile n care se pot afla acestea sunt specifice aplicatiilor Java si implementate identic pe toate platformele pe care a fost portat mediul de executie Java. Totusi, acest mediu stie sa profite de resursele sistemului pe care lucreaza. Daca sistemul gazda lucreaza cu mai multe procesoare, Java va folosi toate aceste procesoare pentru a-si planifica firele de executie. Daca sistemul ofera multitasking preemptiv, multitaskingul Java va fi de asemenea preemptiv, etc.

n cazul masinilor multiprocesor, mediul de executie Java si sistemul de operare sunt responsabile cu repartizarea firelor de executie pe un procesor sau altul. Pentru programator, acest mecanism este complet transparent, neexistnd nici o diferenta ntre scrierea unei aplicatii cu mai multe fire pentru o masina cu un singur procesor sau cu mai multe. Desigur, exista nsa diferente n cazul scrierii aplicatiilor pe mai multe fire de executie fata de acelea cu un singur fir de executie, diferente care provin n principal din cauza necesitatii de sincronizare ntre firele de executie apartinnd aceluiasi proces.

Sincronizarea firelor de executie nseamna ca acestea se asteapta unul pe celalalt pentru completarea anumitor operatii care nu se pot executa n paralel sau care trebuie executate ntr-o anumita ordine. Java ofera si n acest caz mecanismele sale proprii de sincronizare, extrem de usor de utilizat si nglobate n chiar sintaxa de baza a limbajului.

La lansarea n executie a unei aplicatii Java este creat automat si un prim fir de executie, numit firul principal. Acesta poate ulterior sa creeze alte fire de executie care la rndul lor pot crea alte fire, si asa mai departe. Firele de executie dintr-o aplicatie Java pot fi grupate n grupuri pentru a fi manipulate n comun.

n afara de firele normale de executie, Java ofera si fire de executie cu prioritate mica care lucreaza n fundalul aplicatiei atunci cnd nici un alt fir de executie nu poate fi rulat. Aceste fire de fundal se numesc demoni si executa operatii costisitoare n timp si independente de celelalte fire de executie. De exemplu, n Java colectorul de gunoaie lucreaza pe un fir de executie separat, cu proprietati de demon. n acelasi fel poate fi gndit un fir de executie care executa operatii de ncarcare a unor imagini din retea.

O aplicatie Java se termina atunci cnd se termina toate firele de executie din interiorul ei sau cnd nu mai exista dect fire demon. Terminarea firului principal de executie nu duce la terminarea automata a aplicatiei.

Crearea firelor de executie

Exista doua cai de definire de noi fire de executie: derivarea din clasa Thread a noi clase si implementarea ntr-o clasa a interfetei Runnable .

n primul caz, noua clasa mosteneste toate metodele si variabilele clasei Thread care implementeaza n mod standard, n Java, functionalitatea de lucru cu fire de executie. Singurul lucru pe care trebuie sa-l faca noua clasa este sa reimplementeze metoda run care este apelata automat de catre mediul de executie la lansarea unui nou fir. n plus, noua clasa ar putea avea nevoie sa implementeze un constructor care sa permita atribuirea unei denumiri firului de executie.

Daca firul are un nume, acesta poate fi obtinut cu metoda getName care returneaza un obiect de tip String .

Iata un exemplu de definire a unui nou tip de fir de executie:

class FirNou extends Thread {

public FirNou( String nume ) {

// apeleaza constructorul din Thread

super( nume );

public void run() {

while( true ) { // fara sfrsit

System.out.println( getName() +

" Tastati ^C" );

}

}

}

Daca vom crea un nou obiect de tip FirNou si l lansam n executie acesta va afisa la infinit mesajul "Tastati ^C". ntreruperea executiei se poate face ntr-adevar prin tastarea caracterului ^C, caz n care ntreaga aplicatie este terminata. Atta timp nsa ct noul obiect nu va fi ntrerupt din exterior, aplicatia va continua sa se execute pentru ca mai exista nca fire de executie active si indiferent de faptul ca firul de executie principal s-a terminat sau nu.

Iata si un exemplu de aplicatie care foloseste aceasta clasa:

public TestFirNou {

public static void main( String[] ) {

new FirNou( "Primul" ).start();

}

}

Metoda start , predefinita n obiectul Thread lanseaza executia propriu-zisa a firului. Desigur exista si cai de a opri executia la nesfrsit a firului creat fie prin apelul metodei stop, prezentata mai jos, fie prin rescrierea functiei run n asa fel nct executia sa sa se termine dupa un interval finit de timp.

A doua cale de definitie a unui fir de executie este implementarea interfetei Runnable ntr-o anumita clasa de obiecte. Aceasta cale este cea care trebuie aleasa atunci cnd clasa pe care o cream nu se poate deriva din clasa Thread pentru ca este important sa fie derivata din alta clasa. Desigur, mostenirea multipla ar rezolva aceasta problema, dar Java nu are mostenire multipla.

Aceasta noua cale se poate folosi n modul urmator:

class Oclasa {

?

}

class FirNou extends Oclasa implements Runnable {

public void run() {

for( int i = 0; i < 100; i++ ) {

System.out.println( "pasul " + i );

}

}

?

}

public class TestFirNou {

public static void main( String argumente[] ) {

new Thread( new FirNou() ).start();

// Obiectele sunt create si folosite imediat

// La terminarea instructiunii, ele sunt automat

// eliberate nefiind referite de nimic

}

}

Dupa cum observati, clasa Thread are si un constructor care primeste ca argument o instanta a unei clase care implementeaza interfata Runnable . n acest caz, la lansarea n executie a noului fir, cu metoda start , se apeleaza metoda run din acest obiect si nu din instanta a clasei Thread .

Atunci cnd dorim sa cream un aplet care sa ruleze pe un fir de executie separat fata de pagina de navigator n care ruleaza pentru a putea executa operatii n fereastra apletului si n acelasi timp sa putem folosi n continuare navigatorul, suntem obligati sa alegem cea de-a doua cale de implementare. Aceasta pentru ca apletul nostru trebuie sa fie derivat din clasa standard Applet . Singura alternativa care ne ramne este aceea de a implementa n aplet interfata Runnable .

Securitatea in Web

Protejara resurselor Web. O resursa web poate fi protejata prin specificarea unei constrangeri de securitate. O astfel de constrangere determina cine este autorizat sa acceseze o anumita Colectie de Resurse Web, care este de fapt o lista de patternuri URL si metode HTTP ce descriu un set de resurse ce trebuie protejate.

Autentificarea Utilizatorilor unei Resurse Web. In momentul in care se incearca accesarea unei resurse Web protejata containerul va activa macanismul de autentificare ce a fost configurat pentru resursa respectiva. Exista 3 tipuri posibile de autentificare si anume:

autentificare HTTP standard

autentificare pe baza de formular

autentificare pe baza certificatului clientului

Autentificarea de Baza(HTTP). Daca este specificat acest tip de autentificare containerul va autentifica utilizatorul pe baza username-ului si a parolei primnite de la clientul Web

Autentificarea pe baza de formular. Prin acest tip de autentificare se pot customiza ecranul de login si paginile de eroare ce sunt prezentate userului de catre browserul HTTP.

Nici una din aceste tipuri de autentificare nu este sigura. In autentificarea pe baza de formular continutul cutiei de dialog este trimis ca text obisnuit iar serverul tinta nu este unul autentificat. Autentificarea obijnuita HTTP trimite username-ul si parola ca text ce este codat dar nu criptat. Acest tip de autentificare ce utilizeaza codarea Base64 poate expune username-ul si parola daca conexiunile nu sunt realizate peste SSL. Daca cineva poate intercepta transmisiunea username-ul si parola pot fi usor decodificate.

Autentificare pe baza certificatului clientului. Acest tip de autentificare este mult mai sigur decat celelalte 2 metode prezentate mai sus. Foloseste HTTP peste SSL (HTTPS) in care serverul si obtional clientul se identifica unul pe celalalt prin intermediul Certificatelor cu Cheie Publica (Public Key Certificates). SSL (Secure Sokets Layer) furnizeaza criptarea datelor , autentificare server, integritatea mesajelor si optional autentificarea clientuluui pentru conexiuniu TCP/IP. Un certificat cu cheie publica poate fi privit ca si un pasaport digital, acesta este emis de catre o organizatie de incredere Certificate Authority (CA) si il identifica pe purtator. Daca se specifica acest tip de autentificare serverul Web va autentifica clientul folosind un certificat X.509.

Ce este JDBC API?

JDBC API este un API Java pentru a accesa virtual orice tip de date sub forma de tabel.(ca un punct de interes JDBC este un nume comercial si nu un acronim ;totusi JDBC este adesea considerat ca venind de la Java Databrowse Connectivity) .JDBC API consista intr-un set de clase scrise in limbajul de programare Java ce furnizeaza un standard API pentru utilizatorii bazelor de date si face posibila scrierea de aplicatii pe baze de date , folosind un intreg API Java.

JDBC API usureaza trimiterea de mesaje SQL catre sisteme de baze de date relationale si sprijina toate dialectele SQL . Dar JDBC 3.0 API merge inca si mai departe , facand posibila interactiunea cu alte tipuri de surse de date , cum ar fi de exemplu fisierele , care nu tin d baze de date.

Valoarea JDBC API este aceea ca o aplicatie poate accesa virtual orice fel de surse de date si sa foloseasca orice platforma cu o masina virtuala Java.Cu alte cuvinte , cu JDBC API , nu mai este necesar sa scrii un program pentru a accesa o baza de date Sybase , un alt program pentru a accesa o baza de date Oracle , un altul pentru a accesa o baza de date IBMDB2 si asa mai departe.Poti scrie un singur progrm folosind JDBC API , si acesta va fi capabil sa trimita SQL sau alte informatii sursei de date potrivite. Si mai mult cu o aplicatie scrisa in limbajul de programare Java , nu mai trebuie sa-ti faci griji ca trebuie sa scrii mai multe aplicatii pentru a putea folosi diferite platforme. Combinatia dintre platforma Java si JDBC API permite unui programator sa scrie o data si sa poata accesa orice doreste.

Limbajul de programare Java , fiind sigur , usor de folosit , usor de inteles si in mod automat usor de introdus intr-o retea , este o excelenta baza lingvistica pentru aplicatii de baze de date.Ceea ce este necesar este o cale ca aplicatiile Java sa vorbeasca unei varietati de surse de date.

JDBC este mecanismul necesar pentru aceasta.

JDBC API extinde ceea ce poate fi facut cu platforma Java.De exemplu face posibila publicarea unei pagini in web continand o aplicatie care foloseste informatii obtinute de la o sursa de date indepartata. Sau o intreprindere poate folosi JDBC API pentru a-si conecta toti angajatii (chiar daca acestia folosesc o conglomeratie de masini windows , Macintash si UNIX) la una sau mai multe baze de date interne prin intermediul unei retele interne . Cu programatorii care folosesc din ce in ce mai mult limbajul de programare Java nevoia de acces facil si universal la baze de date oferita de JDBC API continua sa creasca.

Ce face JDBC API?

In termenii cei mai simpli din driver bazat pe tehnologia JDBC (JDBC driver) face posibile 3 lucruri , si anume:

1.Stabilirea unei legaturi cu o sursa de date.

2.Trimiterea de informatii actualizate catre sursa de date.

3.Procesarea rezultatelor.

Urmatorul fragment de cod este un exemplu simplu al acestor 3 pasi:

Context ctx = new InitialContext();

DataSource ds = (DataSource)ctx.lookup("jdbc/AcmeDB");

Connection con = ds.getConnection("myLogin", "myPassword");

Statement stmt = con.createStatement();

ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1");

while (rs.next()) {

int x = rs.getInt("a");

String s = rs.getString("b");

float f = rs.getFloat("c");

}

SQL este limbajul standard pentru a accesa baze de date relationale. Din nefericire , SQL nu este atat de standardizat pe cat s-ar dori. O zona de dificultate o constituie aceea ca tipurile de date folosite de diferite DBMS (Data Base Manageme System) variaza uneori si variatiile pot fi semnificative. JDBC se ocupa de acest lucru prin definirea unui set de identificatori generici de tip SQL in clasa java.sql.Types .Notati ca folositi in acest context termenii JDBC SQL type JDBC type si SQL type pot fi schimbati intre ei si se ppot referi la identificatorii generici de tip SQL definiti in java.sql.Types .

O alta zona de dificultate a conformantei SQL este aceea ca desi majoritatea DBMS-urilor folosesc o forma standard de SQL pentru functionalitatea de baza ele nu se conformeaza celor mai recent definite standarde de sintaxa sau semantica SQL pentru o functionalitate mai avansata. De exemplu , nu toate bzele de date sprijina procedurile de stocare sau legaturile exterioare , precum si pe cele care nu sunt intotdeauna consecvente unele fata de celelalte .

De asemenea suportu pentru tipurile SQL 99 si tipurile de date variaza simtitor. .Se spera ca portiunea SQL care este un adevarat standard sa se extinda in favoarea unei functionalitati din ce in ce mai mari .Dar in acelasi timp , JDBC API trebuie sa sprijine SQL asa cum este.

Un mod in care JDBC API se ocupa de aceasta problema este ca permite trecerea printr-un driver DBMS inferior. Aceasta inseamna ca o aplicatie este libera sa foloseasca oricata functionalitate SQL doreste , dar o pandeste riscul de a capata o eroare pe anumite sisteme DBMS .De fapt o cerere de aplicatie poate fi altceva decat SQL sau poate fi o derivata specializata a SQL desemnata pentru sisteme DBMS specifice(pentru documente sau imagini ).

O a doua modalitate in care JDBC se ocupa de problemele de conformanta SQL este aceea de a furniza propozitii de tip ODBC. Acest tip de sintaxa furnizeaza o sintaxa JDBC standard pentru cateva din cele mai comune arii de divergenta SQL.

Pentru aplicatii complexe , JDBC se ocupa de conformanta SQL intr-un al treilea mod. El furnizeaza informatii descriptive despre DBMS prin intermediul formulei DatabaseMetaData astfel incat aplicatiile se pot adapta cerintelor si capacitatilor fiecarui sistem DBMS .

Si totusi utilizatorii beneficiari nu trebuie sa-si faca griji in legatura cu metadatele.

Pentru ca JDBC API este folosita ca o baza API pentru a dezvolta unelte de acces la bazele de date , ea trebuie in acelasi timp sa se ocupe de problema de conformanta. Un driver JDBC trebuie sa sustina cel putin un Nivel Initial ANSISQL-92(ANSI-SQL-92 se refera la standardele adoptate de Institutul American al Standardelor in 1992. Nivelul initial se refera la o lista specifica de abilitat SQL ) Desi JDBC 3.0 API include suport pentru SQL99 , driver-I JDBC nu trebuie sa faca acelasi lucru. Data fiind acceptarea sistemului JDBC API de catre vanzatorii de baze de date , de conectivitate , de servicii de internet , acesta a devenit standardul pentru accesul la date din limbajul de programare Java.Driver manager

Clasa Driver Manager este nivelul de conducere traditional al JDBC , facand legatura intre utilizatori si drivere. El inregistreaza programele disponibile si stabileste o legatura intre o baza de date si driver-ul potrivit.

javax.sql furnizeaza interfata DataSource ca un mijloc preferential de conectare la o sursa de date.Totusi facilitatea Driver Manager poate fi inca folosita de driver-ele care sprijina implementarile DataSource .

Pentru aplicatii simple singura metoda din clasa Driver Manager pe care un programator trebuie sa o foloseasca in mod direct este Driver Manager. .Dupa cum ii spune si numele aceasta metoda stabileste o legatura cu o baza de date.O aplicatie poate necesita metoda Driver Manager ,get Driver si register Driver ca si metoda Driver connect, dar in cele mai multe cazuri este mai bine sa lasati clasa Driver Manager sa stabileasca o legatura.

Cum sa urmariti programele disponibile

Clasa Driver Manager mentine o lista de clase Driver care s-au inregistrat sub numele de Driver Manager.register Driver .In continuare este prezentata o modaliatte de a incarca un Driver :numind metoda Class.forName.Acesta incarca in mod explicit clasa driver.Din moment ce nu depinde de nici o stare externa aceasta cale este recomandata pentru a folosi fereastra Driver Manager.Urmatorul cod incarca clasa acme.db.Driver:

Class.forName("acme.db.Driver");

Este responsabilitatea Driver-ului nou incarcat sa se auto-inregistreze ca Driver Manager.regster Driver. Cum am mentionat deja aceasta se intampla automat cand clasa este incarcata. Din motive de securitate , JDBC va urmari ce driver a fost si de catre care incarcator. Apoi , cand Driver Manager incepe o legatura va folosi doar drivere care provin din fisiere locale sau din aceeasi clasa ca si codul necesar pentru conexiune.

Stabilirea unei legaturi

Odata ce clasele Driver au fost incarcate si inregistrate cu clasa Driver Manager , sunt dispuse sa stabileasca o legatura cu baza de date.

Cand se cere o legatura prin intermediul metodei Driver Manager.get Connection , Driver Manager testeaza fiecare driver pe rand pentru a vedea daca poate stabili o legatura. Uneori se poate intampla ca mai mult de un driver sa fie capabil de o legatura URL. De exemplu cand se conecteaza la o baza de date indepartata , s-ar putea , sa foloseasca un driver JDBC-ODBC sau un driver JDBC to generic network-protocol sau altul furnizat de baze de date.In asemenea cazuri ordinea in care se face testarea este semnificativa pentru ca Driver Manager va folosi primul driver pe care-l gaseste si care se poate conecta cu succes la URL-ul respectiv.

Mai intai Driver Manager incearca sa foloseasca fiecare driver in ordinea in care a fost inregistrat (driver-ele din jdbc.drivers sunt intotdeauna inregistrate primele).Driverele sunt testae prin metoda Driver.connect. Primul driver care recunoaste URL-ul face legatura.

La prima vedere , metoda poate parea ineficienta dar necesita doar cateva proceduri si comparatii per legatura , din moment ce e neplacut ca zeci de drivere sa fie incarcate concomitent. Urmatorul cod este un exemplu pentru ceea ce necesita o legatura cu un driver precum JDBC-ODBC:Class.forName("jdbc.odbc.JdbcOdbcDriver"); //loads the driver

String url = "jdbc:odbc:fred";

Connection con = DriverManager.getConnection(

url, "userID", "passwd");

Variabilele con reprezinta o legatura cu sursa de date fred , care poate fi folosita pentru a crea si executa declaratii SQL.

Prin adaugarea pachetului javax.sql , un obiect DataSource poate fi folosit pentru a stabili o legatura cu o sursa de date. Si Driver Manager poate fi folosit , dar un obiect DataSource ofera mai multe avantale si este alternativa preferata. Cei care scriu componente Enterprise JavaBeans , ar trebui sa foloseasca un obiect DataSource in locul unui Driver Manager . Folosind un obiect DataSource implementat in mod adecvat , se produc legaturi care pot fi folosite la tranzactii raspandite.

DataSouce

Un obiect DataSource este reprezentarea unei surse date in limbajul de programare Java.In termeni comuni , o sursa de date este o facilitate pentru a stoca date.Poate fi la fele de sofisticata ca o baza de date completa pentru o mare corporatie sau la fel de simpla ca un fisier cu randuri si coloane.

O sursa de date se poate gasi intr-un server izolat sau intr-un desktop local. Aplicatiile acceseaza o sursa de date folosind o legatura si un obiect DataSource poate fi considerat ca un factor pentru legaturi cu anumite surse de date.Interfata DataSource furnizeaza 2 metode pentru stabilirea unei legaturi cu o sursa de date. Folosirea unui obiect DataSource este alternativa preferata in detrimentul utilizarii unui Driver Manager pentru a stabili o legatura cu o sursa de date. Ele sunt similare ca si extensie pentru ca ambele detin metode de creare a unei conexiuni , metode de stabilire a unei limite pentru a face o legatura.

Totusi diferentele sunt mai semnificative decat asemanarile. Spre deosebire de un Driver Manager o DataSource are proprietatile care identifica si descriu sursa de datepe care o reprezinta . De asemenea , un obiect DataSource lucreaza cu un serviciu JDNI si este creat si dezvoltat separat fata de aplicatiile care-l utilizeaza. Faptul ca este inregistrat cu un serviciu JNDI , ii confera 2 avantaje majore , si anume:

-o aplicatie nu necesita codarea informatiei ca in cazul unui Driver Manager. Un programator poate alege un nume logic pentru sursa de date pe care sa-l inregistreze cu ajutorul serviciului JNDI .Aplicatia foloseste acest nume si serviciul JNDI va furniza obiectul DataSOurce asociat cu numele logic. Obiectul DataSource poate fi folosit apoi pentru a crea o conexiune cu sursa de date pe care o reprezinta.

-al doilea avantaj major este acela ca facilitatea DataSource permite implementarea unei clase DataSource . Legatura poate creste performanta in mod dramatic .Capacitatea de a folosi tranzactii variate da unei aplicatii posibilitatea de a in meritele intreprinderii.

Desi o aplicatie poate folosi fie un Driver Manager fie un obiect DataSource , pentru a obtine o legatura , folosirea unui obiect DataSource ofera avantaje semnificative si este recomandabila in stabilirea unei conexiuni.

StatementUn obiect statement este folosit pentru a trimite declaratii SQL catre o baza de date . Exista trei tipuri de obiecte Statement si toate actioneaza ca si recipienti pentru a executa declaratii SQL pentru o anumita legatura: Statement , Prepared Statement care vine de la Statement si Callable Statement care se mosteneste de la Prepared Statement . Ele sunt specializate in trimiterea unor tipuri speciale de declaratii SQL ; un obiect Statement este folosit pentru a executa o afirmatie simpla SQL fara parametri ; un obiect Prepared Statement pentru a executa o afirmatie SQL cu sau fara parametri IN si un obiect Callable Statement pentru a efectua un apel catre o baza de date.

Interfata Statement furnizeaza metode de baza pentru a face declaratii si a prezenta rezulatte . Interfata Prepared Statement adauga metode pentru a se ocupa de parametrii IN ;interfata Callable Statement adauga metode pentru a se ocupa de parametrii OUT

Crearea obiectelor StatementOdata ce se stabileste legatura cu o anumita baza de date , aceasta poate fi folosita pentru a trimite declaratii SQL . Un obiect Statement este creat cu metoda createStatement , ca in urmatorul cod:Connection con = DriverManager.getConnection(url, "sunny", "");

Statement stmt = con.createStatement();Declaratia SQL ce vafi trimisa bazei de date este furnizata ca un argument pentru una din metodele execute . Acest lucru este demonstrat in urmatorul exemplu care utilizeaza metoda executeQuery :

ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table2");

Variabila rs se refera la un set de rezultate care nu pot fi actualizate si unde cursorul se poate deplasa doar inainte. Exista de asemenea versiuni ale metodei Connection.createStatement care creaza obiecte de tip Statement ce produc obiecte ResultSet , ce pot fi actualizate si care raman deschise dupa ce s-a efectuat o tranzactie .

Executarea declaratiilor folosind obiecte Statement

Interfata Statemant furnizeaza trei metode diferite pentru a executa declaratii SQL: executeQuery , executeUpdate si execute . Metoda corecta este determinata de ceea ce produce declaratia SQL .

Metoda executeQuery este folosita pentru declaratiile care produc un singur set de rezultate , ca declaratiile Select.

Metoda executeUpdate este folosita oentru a executa declaratii insert , update , delete sau create table, drop table , alter table. Efectul unei taste insert update sau delete il constituie modificarea uneia sau a mai multor coloane in zero dintr-un tabel.

Trebuie notat ca interfata Prepared Statement care mosteneste toate metodele din interfata Statement are propriile versiuni ale metodelor executeQuery , executeUpdate si execute. Obiectele Prepared Statement nu furnizeaza declaratii SQL ca parametri pentru aceste metode pentru ca ele contin deja o declaratie SQL. Obiectele Callable Statement mostenesc formele Prepared Statement ale acestor metode. Furnizand o declaratie SQL pentru versiunile Prepared Statement sau Callable Statement ale metodelor executeQuery , executeUpdate sau execute se va produce o SQL Exception.JavaMail

Obiective si principii de design

APIul JavaMail este gandit pentru a face adaugarea de capabilitati de posta electronica un pas usor de facut. Suporta in acelasi timp crearea de interfete utilizator sofisticate. Include clase care incapsuleaza functiile si protocoalele obisnuite de mail. Se incadreaza ca mod de folosire in restul packetelor Java pentru a usura folosirea in comun cu alte APIuri Java si foloseste modele de programare comune. APIul JavaMail este gandit astfel incat sa satisfaca urmatoarele cerinte de dezvoltare si rulare:

clase simple si la obiect pentru a facilita dezvoltatorile invatarea si folosirea lor

folosirea de modele si concepte de programare familiare suporta foarte bine dezvoltarea de cod care se interfateaza cu alte APIuri Java

foloseste tratarea exceptiilor in mod familiar si tratarea evenimentelor conform cu JDK 1.1

foloseste unelte din JavaBeans Activation Framework pentru a folosi tipuri de date si pentru a adauga alte tipuri de date si comenzi acelor structuri

clasele si interfetele usoare fac banala adaugarea de functii de folosire a mailurilor aplicatiilor

suporta dezvoltarea de aplicatii robuste care pot folosi o varietate de formate de mesaje complexe, cat si tipuri de date si protocoale de acces si transport

APIul JavaMail se aseamana foarte mult cu IMAP, MAPI, CMC, client-c si alte sisteme de mesagerie. Multe concepte prezente in aceste sisteme sunt de aseamea folosite in APIul JavaMail. Este mult mai simplu de folosit pentru ca foloseste elemente din limbajul obiectual de programare Java pentru a ascunde complexitatea de implementare aplicatiilor.APIul JavaMail suporta o diversitate de implementari de sisteme de mesagerie diferite containere de mesaje, diferite formate de mesaje di diverse metode de transport al mesajelor.

JavaMail API are un set de clase de baza si interfete care definesc APIul pentru aplicatiile client. Multe aplicatii simple vor trebui sa interactioneze cu sistemul de mesagerie doar prin aceste clase si interfete de baza.

Subclasele JavaMail pot sa dezvaluie elemente aditionale ale sistemului de mesagerie. De exemplu, subclasa MimeMessage dezvaluie si implementeaza caracteristici comune ale mesajelor electronice rulate prin internet asa cum sunt ele definite de standardele RFC822 si MIME. Dezvoltatorii pot sa subclaseze clasele JavaMail pentru a obtine implementari particulare de sisteme de mesagerie cum ar fi IMAP4, POP3 sau SMTP.

Clasele de baza din JavaMail includ multe APIuri care simplifica folosirea API, dar nu adauga multa funcionalitate. Implementarile de subclase nu trebuie neaparat sa implementeze acele metode. Implementarile subclaselor trebuie sa implementeze doar clasele centrale si metodele care adauga functionaliteaza necesara pentru implementare.

Un sistem de mesajerie poate alege sa implementeze tot APIul JavaMail direct, permitind astgel sa faca un avantaj al optimizarilor de performanta, poate prin folosirea de cereri cu protocol in loturi. Implementarea IMAP4 foloseste aceasta alegere care ii ofera un avantaj.

Descriere Arhitecturala

Arhitectura stratificata JavaMail

Componentele arhitecurale ale JavaMail sunt stratificate dupa cum urmeaza:

stratul abstract declara clase, interfete si metode abstracte pentru a oferi functii de prelucrare a mailurilor suportate de toate sistemele de mesagerie electronica. Elementele API care construiesc stratul abstract sunt gandite pentru a fi subclasate si extinse ca o necesitate pentru a putea suporta tipuri de date standard si pentru a interfata cu accesul la mesaje si protocolul de transport al acestora dupa necesitate.

Stratul de implementare internet implementeaza partile layerului abstract folosind standardele internet: RFC822 si MIME

JavaMail foloseste JavaBeans Activation Framework pentru a incapsula date in mesaj si pentru a stoca comenzi care interactioneaza cu acele date

Clientii JavaMail folosesc APIul JavaMail iar furnizorii de servicii implementeaza APIul JavaMail. Arhitectura stratificata permite clientilor sa foloseasca acelasi apeluri JavaMail API pentru a trimite, primi si stoca o varietate de mesaje folosind diferite tipuri de date din diverse stocuri de mesaje si folosind o multitudine de protocoale de transport.

Arhitectura de clase JavaMail

Figura de mai jos prezinta clasele principale care construiesc APIul JavaMail.

Cadrul de lucru JavaMail

APIul JavaMail este intentionat sa implementeze urmatoarele functii, care compun procesul standard de prelucrare al mesajelor pentru o aplicatie client tipica:

crearea unui email ce consta dintr-un set de elemente header si un block de date de un anumit tip specificat in headerul Content-Type

JavaMail foloseste interfata Part si clasa mesaj pentru a defini un mesaj. Foloseste obiectul DataHandler definit de JAF care contine datele din mesaj

Crearea unui obiect sesiune, care autentifica utilizatorul si controleaza accesul la stocul de mesaje si la trasnport

Trimiterea mesajului catre lista de receptori

Receptionare mesajului dintr-un stoc de mesaje

Executarea unei comenzi de nivel inalt asupra unui mesaj receptionat. Comenzi de nivel inalt precum view si print sunt menite pentru a fi implementate via JavaBeanuri JAF.

Figura urmatoare ilustreaza procesul de prelucrare al mesajelor oferit de JavaMail

Componente JavaMail API importante

Clasa Message

Clasa Message este o clasa abstracta care defineste un set atribute si continut pentru un mesaj email. Atributele clasei Message specifica informatii de adresare si definesc structura continutului, inclusiv tipul continutului. Continutul este reprezentat ca un obiect DataHandler care ambaleaza datele reale. Clasa Message implementeaza interfata Part care defineste atributele necesare pentru a defini si formate datele continute in obiectul Message si pentru interfatarea cu succes cu un sistem de mailing. Clasa Message adauga atributele From, To, Subject, Reply-To si altele necesare pentru trimiterea unui mesaj prin intermediul unui sistem de transport. Atunci cand este continut intr-un folder, un obiect Message are un set de steaguri asociate. JavaMail pune la dispozitie subclase care suporta diverse implementari de mesaje.

Continutul unui mesaj este o colectie de bytes sau o referinta la o colectie de bytes, incapsulate intr-un obiect Message. JavaMail lucreaza fara a tine cont sau a avea cunostinte despre tipurile de date sau continutul unui mesaj. Un obiect Message interactioneaza cu continutul lui printr-un start intermediarL JavaBeans Activation Framework ( JAF ). Aceasta separare permite obiectului Message sa prelucreze continut arbitrar si sa il transmita folosind oricare dintre protocoalele de transmisie folosind apeluri catre aceleasi metode API. Receptorul mesajului stie de obicei tipul de date al continutului si cum sa prelucreze acel continut.

JavaMail suporta obiecte Message multipart, unde fiecare obiect Bodypart defineste propril set de atribute si continut.

Stocare si receptionare mesaj

Mesajele sunt stocate in obiecte Folder. Un obiect Folder poate contine subfoldere ca si mesaje, fiind astfel o ierarhie arbore de foldere. Clasa Folder declara metode care aduc, alipesc, copiaza si sterg mesaje. Un obiect Folder poate de asemenea sa trimita evenimente componentelor inregistrate ca ascultatori de evenimente.

Clasa Store defineste o baza de date care detine o ierarhie folder impreuna cu mesajele. Clasa Store specifica si protocolul de acces care acceaseaza folderele si receptioneaza mesajele continute in foldere. Clasa Store pune la dispozitie de asemenea si o conexiune la baza de date pentru a receptiona foldere si a inchide conexiunea. Furnizorii de servicii care implementeaza protocoale de acces la mesaje ( IMAP4, POP3, etc) incep prin a subclasa clasa Store. Un utilizator porneste de obicei o sesiune cu sistemul e posta electronica prin conectarea la o implementare particulara a clasei Store.

Compunerea mesajului si transportul

Un client creeaza un nou mesaj prin instantierea unei subclase potrivite a clase Message. Va seta de asemenea atribute cum ar fi adresa destinatarului, subiectul si introduce continut in obiectul Message. Finalul este reprezentat de trimiterea mesajului prin invocarea metodei Transport.Send.

Clasa transport modeleaza agentul de transport care ruteaza mesajul spre adresa de destinatie. Aceasta clasa pune la dispozitie metode pentu a trimite mesajul la o lista de adresanti. Invocarea metodei Transport.send cu un obiect Message identifica transportul de rigoare pe baza adreselor destinatarilor.

Clasa Session

Clasa Session defineste proprietati globale si per email utilizator care alcatuiesc interfata dintre un client care poate accesa emailul si retea. Componentele sistemului JavaMail folosesc obiectul Session pentru a seta si receptiona anumine proprietati. Clasa Session pune de asemenea la dispozitie o un obiect sesiune de baza autentificat pe care aplicatiile desktop pot sa-l partajeze. Clasa Session este o clasa finala. Nu poate fi subclasata. Clasa Session are rolul unei fabrici pentru obiectele Store si Transport care implementeaza protocoale de acces si transport specifice. Prin apelarea metodelor fabrica de rigoare ale unui obiect Session, clientul poate obtine obiecte Store si Transport care suporta anumite protocoale.Modelul de evenimente JavaMail

Modelul de evenimente JavaMail se conformeaza specifiactiilor de model de evenimente ale JDK 1.1, asa cum este descris in specificatiile JavaBeans. APIul JavaMail urmareste tiparele de design definite in specificatiile JavaBeans pentru denumirea evenimentelor, metodelor evenimentelor si inregistrarea ascultatorilor de evenimente.

Toate evenimentele sunt subclasate din clasa MailEvent. Clientii asculta dupa evenimente specifice inregistrandu-se ca ascultatori pentru acele evenimente. Evenimentele notifica ascultatorii de schimbarile de stare cat timp o sesiune progreseaza. In timpul unei sesiuni, componenta JavaMail genereaza evenimente de tipuri specifice pentru o notifica obiectele inregistrate ca ascultatori pentru acel tip de evenimente. Clasele JavaMail Store, Folder si Transport sunt surse de evenimente. Folosirea APIului JavaMail

Aceasta sectiune defineste sintaxa si listeaza ordinea in care o aplicatie client apeleaza anumite metode JavaMail pentru a accesa si a deschide mesaje localizate intr-un folder:

1 un client JavaMail incepe de obicei o sarcina de prelucrare emailuri prin obtinerea unui obiect Session de baza

Session session = Session.getDefaultInstance(

props, authenticator);

2 clientul foloseste metoda getStore a obiectului Session pentru a se conecta la continutul principal. Metoda getStore returneaza o subclasa care suporta protocolul de acces definit de obiectul de propietati utilizator, care de obicei contine preferinte utilizator

Store store = session.getStore();

store.connect();

3 daca conexiunea este realizata cu succes, clientul poate lista folderele disponibile in obiectul Store si apoi receptiona si vedea mesaje specifice.

// receptioneaza folderul INBOXFolder inbox = store.getFolder("INBOX");

// deschide folderul INBOXinbox.open(Folder.READ_WRITE);

Message m = inbox.getMessage(1); // get Message # 1

String subject = m.getSubject(); // get Subject

Object content = m.getContent(); // get content

...

...

La final, utilizatorul inchide toate folderele deschise si apoi inchide obiectul Store:

inbox.close(); // Close the INBOX

store.close(); // Close the StoreComponenetele JavaBeans in paginile JSP

Componentele JavaBeans sunt clase Java care pot fi usor refolosite si transformate in aplicatii.Orice clasa Java care se ia dupa anumite conventii de design poate fi o componenta JavaBeans.

Tehnologia JSP sprijina in mod nemijlocit folosirea componentelor JavaBeans cu elemente de limbaj JSP .Poti crea si initia cu usurinta programe si poti obtine si stabiliza valorile proprietatilor acestora.

Conventiile de design ale componentelor Java Beans guverneaza proprietatile clasei si metodele care confera accesul la proprietati.

Oproprietate a unei componente JavaBeans poate fi:

-Citit/scris , numai date sau numai scris;

-Simpla, ceea ce inseamna ca ea contine o singura valoare ,sau indexata, ceea ce inseamna ca reprezinta o multitudine de valori.

Nu exista nici o cerinta ca o proprietate sa fie implementata de o variabila instanta ;proprietatea trebuie sa fie accesibila pur si simplu doar prin folosirea metodelor publice care se conformeaza anumitor conventii.

-Pentru fiecare proprietate readable bean-ul trebuie sa contina o metoda a formei PropertyClass getProperty() { ... } -Pentru fiecare proprietate scrisa bean-ul trebuie sa contina o metoda a formei setProperty(PropertyClass pc) { ... }

Ca o adaugare la aceste metode o componenta JavaBean trebuie sa defineasca o constructie care nu contine parametriExample:

public class Currency {

private Locale locale;

private double amount;

public Currency() {

locale = null;

amount = 0.0;

}

public void setLocale(Locale l) {

locale = l;

}

public void setAmount(double a) {

amount = a;

}

public String getFormat() {

NumberFormat nf =

NumberFormat.getCurrencyInstance(locale);

return nf.format(amount);

}

}

De ce sa folosesti o componenta JavaBeans

O pagina JSP poate crea si folosi orice tip de limbaj Java in cadrul in cadrul unei declaratii sau al unui scriptlet.Urmatorul scriptlet creeaza caruciorul de cumparaturi dintr-un magazin si il stocheaza ca pe un atribut important:

Daca acest element creat este conform cu regulile JavaBeans paginile JSP pot folosi elemente pentru a crea si a accesa obiectul

Cum sa creezi si sa folosesti o componenta JavaBeans

Declari ca pagina ta JSP va folosi o componenta JavaBeans utilizand una dintre urmatoarele formate:

or

Al doilea format este folosit cand vrei sa incluzi declaratii jsp:setProperty descrise in sectiunea urmatoare , pentru a initia proprietatile bean-ului.

Elementul jsp:useBean inseamna ca pagina va folosi o informatie care este stocata in interior si accesibila din domeniul specfic ce poate fi aplication , session , request sau page.

Daca nu exista o asemenea informatie , ea este creata si sticata ca un atribut al domeniului respectiv.

Valoarea atributului id determina numele (name) campului din domeniul respectiv si identificatorul folosit pentru a face referire la acest camp in alte declaratii si scriptleti JSP.

Stabilirea proprietatilor componentelor JavaBeans

Exista doua moduri pentru a stabili proprietatile componentelor JavaBeans intr-o pagina JSP: cu elementul jsp:setProperty sau cu un scriptlet

Sintaxa elementului jsp:setProperty depinde de sursa valorii .Tabelul urmator cuprinde modurile variate pentru a stabili o proprietate a unei componente JavaBeans folosind elementul jsp:setProperty.

Table Setting JavaBeans Component Properties

Value SourceElement Syntax

String constant

Request parameter

Request parameter name matches bean property

Expression

1. beanName trebuie sa fie la fel ca cel specificat pentru atributul id intr-un element useBean. 2. Trebuie sa existe o metoda setPropName in componenta JavaBeans .3. paramName trebuie sa fie numele unui parametru necesar.

Recuperarea proprietatilor componentelor JavaBeans

Exista cateva moduri de a recupera proprietatile componentelor JavaBeans.Doua dintre acestea (elementul jsp:getProperty si o expresie )transforma valoarea proprietatii intr-un string si introduc valoarea in obiectul curent implicit:

Pentru ambele metode beanName trebuie sa fie acelasi cu cel specificat pentru atributul id intr-un element useBean si de asemenea este necesar sa existe o metoda getPropName in componenta JavaBeans. Daca este necesar sa recuperezi valoarea unei proprietati fara sa o transformi si sa o introduci in obiectul out trebuie sa folosesti un scriptlet.

Accesarea obiectelor dintr-o pagina JSPJavaScript

Conceptul de limbaj de scripting inseamna un limbaj de programare interpretat. Interpretarea permite transmiterea programelor in cod sursa cu conditia existentei la destinatie a unui interpretor pentru exectuita acestora. Exemple de limbaje de scripting: dBase, Visual Basic, Perl, Unix shell etc. Un program de scris in limbaj de scripting se numeste script.

In WWW, scripting-ul se foloseste atat la client cat si la server. Executia unui script la server poate produce continut ce este transmis clientului prin HTTP. Executia unui script la client produce continut dinamic. Scripting-ul la client este parte a tehnologiei HTML-DHTML.

Deosebirea esentiala dintre un limbaj de programare compilat si un limbaj de scripting interpretat este momentul legarii(engl. binding) momentul in care devin cunoscute atributele unei variabile. La limbajele compilate momentul legarii este cel al traducerii, iar la cele interpretate este cel al executiei. Amanarea legarii atributelor conduce la flexibilitate a executiei in dauna eficientei.

Cel mai raspandit limabj de scripting este JavaScript ,inventat de Netscape si standardizat apoi de Asociatia Europeana a producatorilor de calculatoare.Microsoft a incercat sa popularizeze Visual Basic Scripting Editon-VBScript.Datorita standardizarii JavaScript,Microsoft a decis ulterior sa suporte acest standard prin versiunea proprie Jscript si astfel ca interesul pentru VBScript a scazut.

Ce este JavaSript?

JavaScript este un limbaj de scripting orientat pe obiecte inventat de Netscape. Spre deosebire de limabjele orientate pe obiect bazate pe clase cum sunt C si Java,JavaScript este un limbaj orientat pe obiect bazat pe prototipuri.

JavaScript este un limbaj extensibil. Exista o compnenta de baza, numita CoreScript, care contine elementele de baza ale limabjului (cuvinte cheie, operatori, enunturi, structuri de control, modelul obiectual) si o multime de obiecte de baza, cum ar fi: Array, Date, Math etc. La ea se pot adauga in plus obiecte pentru controlul programului navigator si DOM si Server Side JavaScript care contine obiecte suport pentru partea de server, deci pentru comunicarea cu o baza de date relationala. In continuare prin JavaScript vom intelege partea de client a JavaScript.

Navigatoarele www interpreteaza scripturile JavaScript din paginile HTML. Ele citesc pagina, interpreteaza marcajele si o afiseaza, executand in acelasi timp scripturile JavaScript pe masura intalnirii lor in cadrul paginii. Rezultatul acestui proces de interpretare/executie este vizualizat de utilizator in fereastra navigatorului.

Intre JavaScript si Java exista unele asemanari, dar si cateva deosebiri fundamentale.

Asemanarile se refera la unele aspecte de sintaxa a enunturilor si structurior de control.

Deosebirile sunt:

Java are legare la compilare, este puternic tipizat si foloseste un model obiectual bazat pe clase.

JavaScript are legare la executie,este mult mai permisiv in ceea ce priveste declaratiile si foloseste un model obiectual bazat pe prototipuri.

Concluzii

Descarcarea unor programe in cod obiect si rularea acestora in programul navigator poate duce la incetinirea incarcarii paginii respective.

Deci nu trebuie abuzat de folosirea scripting-ului, aceasta facnadu-se numai in situatiile necesare. Includerea de script-uri face sa creasca dependenta paginilor pe care le scriem de programul navigator. Situl de licitatii MuzzyMoo

Descriere FunctionalaObiectivul acestui site este acela de a implementa un mecanism de licitatii online pentru produse electronice. Situl isi propune sa fie usor de folosit si sa ofere o interfata prietenoasa utilizatorului. Acesta poate folosi situl pentru a-si vinde propriile produse electronice la licitatie deschisa sau poate vedea produsele altor utilizatori care si-au propus produsele pentru a fi licitate. Modelul de licitatie electronica este foarte atractiv. El ofera cateva avantaje majore fata de celelalte moduri vanzare o produselor:

utilizatorul este scutit de timpul pierdut pe care l-ar pierde daca s-ar duce in magazin pentru a-si vinde produsul intr-o consignatie sau alt tip de magazin

utilizatorul este scutit de eventuale taxe percepute de catre vanzatorul produsului

vanzarea se executa intr-un mod profesional

utilizatorul poate obtine un pret maxim pentru produsul sau, obtinand astfel beneficii materiale substantiale

vanzarea se executa intr-un mod foarte confortabil utilizatorului poate fi chiar propria resedint, singura cerinta fiind posibilitatea accesarii situluiPrincipalele module functionale oferite de site utilizatorului sunt prezentate in cele ce urmeaza.

Listarea produselor oferite spre licitatie

Toate produsele oferite spre licitatii de utilizatori sunt catalogate dupa categoria carora apartin. Situl ofera un nivel ierarhic de categorii pe 3 niveluri. Nivelul principal este vizibil tot timpul pe site, el oferind un punct de plecare in cautarea unui anumit produs cautat. Nivelul secundar este afisat in stanga paginii si ofera o orientare foarte buna a utilizatorului. Se poate alege mai departe nivelul 3 de categorie din lista afisata:

Utilizatorului ii sunt afisate tot timpul toate nivelurile de categorii selectate pana in momentul respectiv. Aceste lucru confera utilizatorului o orientare foarte buna in site. Orientarea in site este unul din lucrurile importante in orice aplicatie web. Vizitatorul trebuie sa stie totdeauna ce face, unde a ajuns si cum sa se intoarca inapoi.

Prin apasarea pe unul din linkurile de mai sus utilizatorul este dus la pagina categoriei respective. Astfel intoarcerea catre pagini anterioare este facuta intr-un mod natural si usor de folosit.

Pentru ca vizitatorii sitului sa nu foloseasca derularea paginii, ceea ce este un lucru incomod, si pentru o mai rapida incarcare a paginilor sitului, afisarea produselor este facuta intr-un mod paginat. Se afiseaza 6 produse pe fiecare pagina si utilizatorul poate naviga prin paginile dintr-o anumita categorie prin simpla apasare a paginii dorite.

Dupa cum se vede in figura de mai sus, sunt afisate numarul total de produse, precum si numarul de ordine ar produselor afisate.Afisare produs

Fiecare produs este afisat in doua moduri:

modul listare

modul vizualizare detalii

In modul listare sunt afisate urmatoarele:

culoarea

pretul de vanzare recomandat in magazine

pretul curent

utilizatorul care a postat cea mai mare licitatie

primele 3 caracteristici ale produsului

Daca se apasa pe linkul More , utilizatorul va fi dus in pagina in care i se vor afisa detaliile produsului.

In aceasta pagina se afiseaza toate informatiile despre un produs. Se pot vizualiza toate informatiile disponibile despre un anumit produs. Este vizibila aici data de inchidere a licitatii si se poate pune o noua oferta ( cu conditia ca utilizatorul sa fie autentificat ).

Linkul Back to products listings il va duce pe utilizator inapoi la pagina de unde a venit. Aceasta este pagina care afiseaza varianta de listare a produsului vizualizat.

Cautare produse

Situl MuzzyMoo dispune si de un motor de cautare in propria baza de date de produse. Aceasta cautare se face pe baza urmatoarelor campuri

marca

model

descriere

culoare

Cautarea va incepe dupa completarea campului de text dupa care se face cautarea si apasarea butonului Find it.

Vor fi apoi listate toate produsele care contin unul sau mai multe dintre cuvintele dupa care s-a efectuat cautarea. Toate produsele gasite vor fi afisate utilizatorului folosind metoda de paginare descrisa anterior.

Banda rulanta

In cadrul acestei benzi rulante sunt prezentate pe scurt produsele uneia dintre categoriile de produse selectate de administratorul sitului. Sunt prezentate marca, modelul si pretul de start al licitatiei pentru respectivele produse. Fiecare produs este un link care prin apasare va conduce vizitatorul in pagina in care i se va