Arhitecturile aplicatiilor web

Calitatea aplicatiilor web este influentata semnificativ de arhitectura acestora. Lipsa aspectelor arhitecturale influenteaza in mod negativ cerintele privind calitatea aplicatiilor web. Performanta scazuta, intretinerea si extinderea insuficienta si slaba disponibilitate a unei aplicatii web sunt deseori cauzate de o arhitectura neadecvata. Pe langa constrangerile tehnice precum disponibilitatea serverelor web, serverele de aplicatii utilizate sau integrarea sistemelor de mostenire, arhitecturile aplicatiilor web trebuie sa ia in considerare si cadrul de lucru organizational in care ele sunt incluse (de exemplu experienta arhitectilor). Utilizarea unor arhitecturi multi-strat flexibile, tratarea continutului multimedia si integrarea depozitelor de date existente sunt stringente pentru dezvoltarea arhitecturii aplicatiilor web. Vom discuta in continuare proprietatile generale ale arhitecturilor, influenta cunostintelor arhitecturale existente sub forma sabloanelor si cadrelor de lucru asupra calitatii aplicatiilor web si arhitecturi reprezentative pentru aplicatii web impreuna cu componentele necesare construirii acestora.

Cand dezvoltam aplicatii web trebuie sa luam in considerare un numar mare de cerinte si constrangeri, incepand cu cerinte functionale (comenzile de produse online) si cerinte de calitate (performanta si disponibilitatea) si pana la integrarea sistemelor software existente (asa numitele sisteme de mostenire sau depozitele de date existente pe care aplicatiile web ar trebui sa le citeasca). In mod normal, aplicatiile web nu sunt dezvoltate "din nimic" in ceea ce priveste infrastructura tehnica; deseori trebuie extinsa sau adaptata o infrastructura existenta. Pe langa constrangerile pur tehnice, putem identifica alte aspecte cum ar fi viabilitatea economica a infrastructurii tehnice.

1 Generalitati

Definirea arhitecturii

Nu exista o definitie unica a termenului "arhitectura", renumitul institut de proiectare a software-ului (SEI -Software Engineering Institute) din cadrul Universitatii Carnegie-Mellon (https://www.sei.cmu.edu) oferind peste 20 de variante explicative. In loc de a adauga o alta varianta, vom incerca sa descriem principalele proprietati ale arhitecturilor software:

- arhitectura descrie structura: arhitectura sistemelor software consta in structura acestora, descompunerea in componente, interfata si relatiile dintre ele[1]. Arhitectura descrie atat aspectele statice cat si cele dinamice ale sistemului software, astfel incat este necesara construirea de diagrame de flux pentru un produs software.

- arhitectura face tranzitia de la analiza la implementare: Cand cream arhitectura incercam sa descompunem cerintele functionale si cele de calitate in componente software, relatii si interfete intr-un mod iterativ. Acest proces este sustinut de mai multe abordari, cum ar fi Procesul Unificat.

- arhitectura poate fi abordata din diferite puncte de vedere, in functie de care se pot specifica aspecte arhitecturale distincte. Se remarca urmatoarele puncte de vedere:

* abordarea conceptuala - identifica identitatile domeniului aplicatiei si relatiile dintre acestea

* abordarea in functie de momentul rularii - descrie componentele in momentul rularii sistemului (de exemplu servere sau cai de comunicatie)

* abordarea pe procese - mapeaza procesele in momentul rularii sistemului, avandu-se in vedere aspecte precum sincronizarea si concurenta

* abordarea in functie de implementare - descrie artefactele software-ului si include subsisteme, componente sau cod sursa.

Aceasta clasificare in functie de diferitele puncte de vedere este de asemenea sustinuta si de limbajele de modelare (de exemplu UML).

- arhitectura face sistemul mai inteligibil: structurarea sistemelor software si descompunerea acestora ne permit un management mai bun al complexitatii sistemelor software, sistemele devenind astfel mai usor de inteles.

- arhitectura reprezinta cadrul de lucru pentru un sistem flexibil: Tom DeMarco se refera la arhitectura ca la un "cadru al schimbarii" (de exemplu arhitectura software formeaza cadrul in care un sistem software poate evolua). Daca extinderea unui sistem nu a fost luata anterior in calcul, atunci aceasta va fi greu de realizat.

Avand in vedere proprietatile mentionate, putem afirma ca deciziile arhitecturale au o importanta majora in dezvoltarea aplicatiilor web.

Dezvoltarea arhitecturilor

Cerintele software-ului si arhitectura acestuia sunt intr-o continua schimbare. Constrangerile tehnice si de organizare se modifica pe parcursul si dupa dezvoltarea unei aplicatii. Aceasta se poate datora unor cerinte neclare de la inceputul procesului de dezvoltare sau unei schimbari a cerintelor dupa finalizarea sistemului. Din acest motiv sistemele software sunt deseori numite "tinte in miscare". Figura 1 ilustreaza factorii si constrangerile care influenteaza dezvoltarea unei arhitecturi conform opiniei lui Jacobson[2].

Figura 1 Factori care influenteaza dezvoltarea unei arhitecturi

Arhitectura unei aplicatii este influentata in principal de cerintele functionale -serviciile oferite de un sistem- si consideratiile privind calitatea (scalabilitatea sau performanta). Dincolo de aceste cerinte, arhitecturile sunt influentate de constrangeri tehnice cum ar fi sistemul software utilizat (de exemplu sistemul de operare), middleware (de exemplu implementarea CORBA), sistemele de mostenire care vor fi integrate, standardele utilizate, regulile de dezvoltare (de exemplu ghiduri de scriere a codului) sau aspectele de distribuire (de exemplu distribuirea in diverse locatii a unei companii).

Deoarece sistemele software sunt in permanenta schimbare arhitecturile sunt de obicei dezvoltate intr-o maniera iterativa, ceea ce nu garanteaza o arhitectura solida. O abordare iterativa nu este suficienta pentru rezolvarea problemelor specifice de proiectare precum integrarea sistemelor de mostenire in dezvoltarea unei arhitecturi (sabloanele de proiectare sunt foarte eficiente in sprijinirea deciziilor de proiectare).

Sabloane

Sabloanele[3] descriu probleme de proiectare recurente care apar intr-un anumit context si propun solutii la acestea. O solutie descrie componentele participante, responsabilitatile lor, relatia intre aceste componente si interactiunea acestor componente in contextul unei probleme specifice. De aici rezulta ca sabloanele ne permit reutilizarea cunostintelor de proiectare, sprijinind dezvoltarea sistemelor software de calitate superioara.

Buschmann[4] identifica sabloane la trei nivele de abstractizare:

- sabloanele arhitecturale - mapeaza mecanismele de structurare fundamentale pentru sistemele software. Ele descriu subsistemele arhitecturale, responsabilitatile acestora, relatiile si interactiunea dintre ele. Un exemplu de astfel de sablon este sablonul MVC (Model-View-Controller[5]).

- sabloanele de proiectare -descriu structura, relatiile si interactiunea intre componente pentru a rezolva problemele de proiectare aparute intr-un anumit context si deriva dintr-un limbaj de programare specific.

- dialecte - descriu sabloanele care se refera la o implementare specifica dintr-un limbaj de programare.

Sabloanele sunt disponibile pentru diverse infrastructuri - de exemplu J2EE, CORBA[6] si PHP.

Totusi, sabloanele reprezinta doar un ghid pentru o anumita problema. Arhitectii software trebuie sa adapteze sabloanele la problema si constrangerile respective, sa integreze si sa imbunatateasca sabloanele folosite. Pentru a sustine procesul de integrare, Buschmann recomanda folosirea asa-numitelor limbaje-sablon. Un limbaj-sablon descrie interconexiunile sabloanelor pe nivele de abstractizare diferite, sugereaza diferite utilizari pentru sabloane si indica adaptarea necesara pentru a oferi un sistem solid.

IBM descrie in sabloanele pentru afaceri electronice sabloanele de arhitectura pentru aplicatiile comerciale si modul in care pot fi mapate pe infrastructura IBM[7]. Aceste sabloane de arhitectura sunt perfectionate printr-un lant de decizii, pornind de la cazurile de utilizare si terminand cu arhitectura tinta.

Cadre de lucru

Cadrele de lucru de lucru reprezinta o alta optiune pentru reutilizarea cunostintelor arhitecturale existente. Un cadru de lucru este un sistem software reutilizabil cu o functionalitate generala deja implementata. Cadrul de lucru poate fi intalnit sub forma aplicatiilor gata de folosire[8] si serveste ca o schita pentru arhitectura si functionalitatile de baza ale unui domeniu specific al aplicatiei. (deci cunostintele arhitecturale continute in cadrul de lucru pot fi preluate in intregime in aplicatie).

Beneficiile unui cadru de lucru - simpla reutilizare a arhitecturii si functionalitatii- trebuie puse in balanta alaturi de dezavantajele sale (gradul inalt de instruire necesara, lipsa standardelor pentru integrarea diferitelor cadre de lucru si dependenta de producatori).

Clasificarea arhitecturilor

In ultimii ani au fost dezvoltate o serie de arhitecturi pentru rezolvarea cerintelor specifice din   diverse domenii de aplicatii. Anastopoulos si Romberg descriu arhitecturile pentru mediul aplicatiilor web in functie de aspectul stratificat al arhitecturilor sau de aspectul datelor (sustinerea diferitelor date si formate de date):

- aspectul stratificat: se refera la faptul ca sistemele software sunt structurate pe cateva nivele pentru implementarea principiului "separarea intereselor" in cadrul unui sistem software. Multe cadre de lucru din domeniul sistemelor distribuite si aplicatiilor web sunt structurate in principal pe aspectul stratificat (de exemplu arhitecturile J2EE[10] utilizate pentru a integra sistemele de mostenire; portalurile).

- aspectul datelor: datele pot fi structurate sau nestructurate. Datele structurate urmeaza o schema predefinita asemanator tabelelor din bazele de date relationale sau structurilor XML dintr-un document. Datele nestructurate sunt elemente multimedia (imagini, audio, video) care nu respecta o schema explicita, ceea ce face dificila procesarea lor automata.

Raspandirea din ce in ce mai mare a sistemelor software a condus la dezvoltarea arhitecturilor si infrastructurilor ce se adreseaza distribuirii datelor si mesajelor:

- DOM (Distributed Object Middleware) - permite accesarea obiectelor de la distanta in mod transparent si se bazeaza pe mecanismul RPC (Remote Procedure Call) (exemplu: Microsoft's DCOM (Distributed Component Object Model)

- VSM (Virtual Shared Memory) - permite proceselor distribuite sa acceseze datele comune (exemplu: Corso https://www.tecco.at)

- MOM (Message Oriented Middleware) - ofera functionalitati pentru transmiterea asincrona a mesajelor. Comunicarea asincrona difera de cea sincrona prin faptul ca mesajele sunt trimise destinatarului indiferent de starea acestuia ( de exemplu destinatarul poate sa nu fie disponibil cand mesajul este trimis - este offline). Exemplu: Microsoft's MSMQ (Microsoft Message Queue).

- P2P (Peer to Peer) - inseamna comunicarea directa intre doua dispozitive (parteneri) intr-un sistem fara utilizarea unui server (ei pot comunica printr-o conexiune de tip punct-la-punct). Exemplu: Xmiddle (https://xmiddle.sourceforge.net/)

- SOM (Service Oriented Middleware) - imbunatateste sistemele DOM prin conceptul de servicii. Un serviciu in acest context reprezinta un numar de obiecte si comportamentul acestora; aceste obiecte folosesc o interfata predefinita pentru a face un serviciu disponibil altor sisteme/servicii. Exemplu: sistemul Jini de la Sun (https://www.sun.com/software/jini/).

Arhitecturile prezentate se pot aplica sistemelor distribuite in general si nu sunt limitate doar la aplicatiile web.

2 Particularitatile arhitecturilor pentru aplicatiile web

Pentru inceput este necesara realizarea unei distinctii intre arhitectura infrastructurii web (Web Platform Architectures -WPA) si infrastructura aplicatiilor web (Web Application Architectures - WAA). Deoarece WAA depinde de domeniul problemei aplicatiei web, vom insista asupra WPA-urilor.

WPA-urile au fost dezvoltate pentru o arie larga de probleme. Serverele de aplicatii precum implementarea J2EE si platforma .NET incearca sa ofere servicii de baza pentru controlul sesiunilor si accesul la date. In afara serverelor de aplicatii au fost dezvoltate solutii arhitecturale specifice pentru rezolvarea problemelor de securitate, performanta si integrare a datelor (firewall-uri, proxy-uri ptr caching si EAI).

Paradoxal, utilizarea unui numar mare de sisteme diferite face dificila evaluarea si pastrarea  unor cerinte de calitate distincte. De exemplu, indeplinirea cerintelor de performanta devine din ce in ce mai dificila datorita numarului din ce in ce mai mare de componente si produse utilizate de la terti (comerciale sau gratuite).

Alte probleme in dezvoltarea aplicatiilor web sunt neomogenitatea si imaturitatea infrastructurilor tehnice. In acest sens mentionam problemele care apar in analiza performantei pentru serverele de aplicatii in situatia unor update-uri frecvente; un astfel de studiu releva ca versiunile noi de produse sunt mai lente fata de cele anterioare si noile funtionalitati determina incompatibilitati in codul aplicatiei existente. Indiferent de problemele de neomogenitate si imaturitate, aplicatiile web actuale utilizeaza un numar ridicat de infrastructuri tehnice pentru rezolvarea anumitor probleme: cadre de lucru open-source (Struts (https://jakarta.apache.org/struts/ si Cocoon (https://xml.apache.org/cocoon/), servere de aplicatii (de exemplu implementarea EJB) si JetSpeed (https://jakarta.apache.org/jetspeed/).

Un alt aspect important pentru arhitectura aplicatiilor web este internationalizarea aplicatiilor web, care solicita suport pentru limbi diferite, seturi de caractere si mecanisme de reprezentare (reprezentarea caracterelor arabice de la dreapta la stanga) la nivelul WPA. Aceste aspecte sunt oferite si de limbajele de programare sau sistemele de operare (exemplu platforma PHP ofera un mecanism de internationalizare pentru codificarea seturilor de caractere diferite (exemplu ISO-8859-2, UTF-8) realizata si cu ajutorul programului Gettext.

3 Componentele arhitecturii aplicatiilor web

In Figura 2 sunt reprezentate componentele de baza ale arhitecturilor web si relatiile dintre ele. Comunicarea dintre aceste componente se bazeaza in general pe principiul cerere-raspuns ( o componenta - un browser web trimite o cerere catre o alta componenta - serverul web si raspunsul la aceasta cerere este trimis inapoi pe acelasi canal de comunicare - comunicare sincrona).

Figura 2 Componentele de baza ale arhitecturilor unei aplicatii web

Componentele frecvent implicate in comunicare sunt:

- client: in general un browser (agent utilizator) este controlat de catre un utilizator care foloseste aplicatia web. Functionalitatea clientului poate fi extinsa prin instalarea plug-in-urilor si applet-urilor.

- firewall: un software care reglementeaza comunicarea intre retele nesecurizate (exemplu Internet) si securizate (exemplu retele locale ale unei companii). Aceasta comunicare este filtrata prin reguli de acces.

- proxy: un proxy este utilizat pentru a stoca paginile web intr-un cache, pentru a adapta continutul pentru utilizatori (personalizare) sau pentru a urmari utilizatorii.

- server web: un software care suporta diferite protocoale web (exemplu HTTP si HTTPS) pentru a procesa cererile clientului.

- server de baze de date: prezinta datele organizatiei intr-o forma structurata (exemplu: in tabele)

- server media: este utilizat pentru streamingul continutului pentru datele nestructurate (exemplu: audio sau video)

- server pentru managementul continutului: pastreaza continutul aferent unei aplicatii, care este disponibil sub forma datelor semistructurate (exemplu: documente XML)

- server de aplicatii: pastreaza functionalitatea necesara diverselor aplicatii (exemplu: fluxul de date sau personalizarea)

- aplicatii mostenite: un sistem mai vechi care trebuie integrat ca o componenta interna sau externa.

4 Arhitecturile stratificate

Arhitecturi pe doua straturi

Arhitectura pe doua straturi, numita si arhitectura client-server, utilizeaza un server web pentru a oferi servicii unui client (vezi figura 3).

Figura 3 Arhitectura pe doua straturi pentru aplicatiile web

Arhitectura pe doua straturi poate lua forme diferite in mediul aplicatiilor web. O cerere a unui client poate puncta direct catre o pagina HTML statica, fara o solicita un rationament de procesare pe stratul server sau poate accesa o baza de date prin intermediul logicii aplicatiei pe serverul web (de exemplu sub forma scripturilor CGI). Paginile HTML dinamice includ instructiuni de tip script direct in codul HTML (de exemplu cand este utilizat SSI - Server-Side Include sau PHP) si ele sunt interpretate fie de bazele de date cu functionalitati HTML fie de un server web. Logica aplicatiei sau paginile HTML dinamice pot utiliza servicii (exemplu identificarea utilizatorilor sau criptarea datelor) cand este generat un raspuns HTML. Aceasta arhitectura este adecvata aplicatiilor web simple.

O abordare arhitecturala multi-stratificata este necesara pentru aplicatiile mai complexe care sunt accesate de un numar mare de clienti concurenti sau care ofera procese de afaceri complexe ce necesita accesarea sistemele de mostenire.

Arhitecturi pe N straturi

Arhitecturile pe N straturi permit organizarea aplicatiilor web pe un numar arbitrar de nivele (vezi figura 4). Acestea constau de obicei in trei straturi: stratul datelor, care ofera acces la datele aplicatiei, stratul afacerii - care gazduieste logica de afaceri a aplicatiei intr-un server de aplicatii si stratul prezentare - care returneaza rezultatul cererii in formatul de iesire dorit. In plus, mecanisme de securitate cum ar fi firewall-urile sau mecanismele de caching (proxy) pot fi integrate in fluxul cerere-raspuns.

Figura 4 O arhitectura pe N straturi pentru aplicatiile web

Arhitecturile pe doua straturi si N straturi difera in principal prin modul in care incorporeaza serviciile in componenta server a aplicatiei. Servicii precum personalizarea sau fluxul de date sunt pastrate in serverul aplicatiei, astfel incat sa fie disponibile pentru toate aplicatiile web.

Serviciile sunt incorporate in serverele de aplicatii cu o interfata definita, care poate fi utilizata si pentru a administra aceste servicii. Un exemplu pentru aceste functionalitati este serverul de aplicatii WebSphere, impreuna cu componentele afacerii WebSphere. 

Conectorii pot fi utilizati pentru a integra sistemele externe (sisteme partener de afaceri) sau pentru a integra aplicatii de mostenire si sisteme informationale ale companiilor.

Majoritatea serverelor de aplicatii comerciale au fost optimizate pentru procesarea continutului bazelor de date, suportul pentru continutul multimedia si structurile hipertext fiind neglijat. Un exemplu de integrare a datelor video intr-un server de aplicatii este disponibil la https://www.ibm.com/software/data/informix/blades/video/.

JSP-Model-2

Arhitectura JSP-Model-2 (Java Server Pages) de la Sun Microsystems (https://java.sun.com/developer/technicalArticles/javaserverpages/servlets jsp/) implementeaza sablonul MVC pentru aplicatiile web, punand astfel bazele pentru integrarea aspectelor de navigare, internationalizare si distribuire multi-platforma in aplicatiile web (vezi figura 5)

Figura 5 Arhitectura JSP-Model-2

Arhitectura JSP-Model-2 este inclusa intr-un server web - view-uri, controller-e si parti ale functionalitatii modelului acestui sablon sunt disponibile intr-o extensie a serverului web (un container servlet). Controller-ul (logica fluxului si controlului aplicatiei web) este implementa sub forma servlet-urilor - componente software care ruleaza intr-un container servlet. Controller-ul este responsabil de oferirea accesului la logica aplicatiei (model) si selectarea prezentarii grafice (view). JavaBeans - componentele software ce reprezinta datele aplicatiei - sunt folosite pentru a implementa modelul. Modelul acceseaza sisteme backend precum o baza de date sau o aplicatie de mostenire. Prezentarea grafica este realizata prin JSP.

Struts

Arhitectura JSP-Model-e este imbunatatita prin proiectul open-source Struts de la Apache Software Foundation (https://struts.apache.org/). Struts imbunatateste aplicatiile web adaugand facilitati precum tratarea erorilor si internationalizarea. In plus, Struts utilizeaza un fisier de configurare XML care permite controlul fluxului de procesare din sablonul MVC pentru a facilita procesarea cererilor clientului.

Figura 6 arata modul in care cadrul de lucru Struts proceseaza cererea unui utilizator: in faza initiala fiecare cerere a utilizatorului (1) este receptionata de un ActionServlet central. Acest servlet citeste URI-ul cererii pentru a gasi controller-ul (Action); cererea este trimisa mai de parte catre (2) - logica aplicatiei care trebuie executata pentru aceasta cerere. Controller-ul este responsabil pentru selectarea sau crearea modelului sub forma unui JavaBean ce poate fi reprezentat intr-un view (3). Pe baza modelului selectat si a altor informatii (informatii despre utilizator, agentul utilizator) ActionServlet poate selecta un view pentru a reprezenta continutul (4). In cele din urma view-ul selectat genereaza rezultatul, care este trimis utilizatorului (5). Spre deosebire de JSP-Model-2 original, Struts permite configurarea view-ului si modelului in fisierul struts-config.xml; astfel continutul poate fi prezentat intr-un mod mai flexibil in vederea adaptarii sau distribuirii multi-platforma.

Figura 6 Implementarea arhitecturii JSP-Model-2 in Struts

OOHDM-Java2

Abordarea OOHDM-Java2 descrie modul in care modelul de navigare OOHDM este mapat pe platforma J2EE. Implementarea acestuia se bazeaza pe sablonul MVC. Figura 7 ilustreaza modul in care componentele OOHDM-Java2 sunt mapate in sabloane MVC. Spre deosebire de JSP-Model-2 si Struts, aceasta abordare prezinta o componenta de navigare intr-un mod explicit.

Figura 7 Componentele OOHDM-Java2

In aceasta figura secventa de executie este indicata de marginile numerotate: (1) o cerere HTTP este trimisa catre parserul de cerere HTTP, care trimite mai departe un mesaj Dispatcher-ului.(2) Similar cu Struts, acest parser ruleaza obiectele aplicatiei alocate (3). Ulterior, obiectul aplicatiei selectate sau o alta informatie (exemplu agentul utilizator) este utilizat pentru a identifica interfata utilizatorului (4). In continuare, la interfata utilizator se adauga elementele de navigare (5). In final rezultatul este plasat intr-un layout adecvat si transmis clientului.

Proxy-uri

Initial proxy-urile erau folosite pentru a salva latimea de banda, din acest motiv fiind numite si proxy-uri de caching[11]. Proxy-urile sunt capabile sa indeplineasca si alte functii:

- proxy-uri de legaturi: sunt de cel putin doua tipuri. In primul rand, sistemele de tipul URL-urilor persistente (PURLs- Persistent URLs[12]) utilizeaza componente de tip proxy. Mai exact, un proxy este utilizat ca un server intermediar pentru a trimite cererile de URL-uri ale clientului catre serverul real. Daca numele sau locatia resursei solicitate se schimba, este necesara doar schimbarea adresei URL interne (clientul nu trebuie sa stie acest lucru). O astfel de schimbare necesita un tabel de mapare intre URL-ul solicitat si cel "real", acesta fiind gestionat de catre proxy. In al doilea rand, proxy-urile sunt utilizate pentru a adapta si formata legaturile si continutul pentru utilizatori. O metoda implicata in acest concept este inserarea dinamica a legaturilor care se potrivesc intereselor unui utilizator, prin aceasta paginile HTML fiind analizate de proxy si modificate pentru a se potrivi profilului utilizatorului. Utilizatorul va fi informat in privinta schimbarii resursei transmise la sfarsitul documentului.

- proxy-uri de istoric: multe aplicatii web incearca sa-si adapteze functionalitatile cerintelor utilizatorilor. Problema care apare este ca HTTP-ul este un protocol simplu, care nu ofera informatii despre istoricul navigarii unui utilizator pe mai multe situri. De exemplu, daca un utilizator planifica o vacanta si rezerva un zbor, un hotel si inchiriaza o masina pe internet, atunci vanzatorul de bilet de avion nu stie ca utilizatorul a rezervat o camera la un hotel si a inchiriat o masina. Daca compania de zbor ar cunoaste aceste informatii, atunci camera de hotel rezervata si masina inchiriata ar putea fi anulate daca utilizatorul contramandeaza zborul. O problema similara apare si in domeniul marketingului direct, in care, cu cat se cunosc mai multe detalii despre interesele utilizatorului, cu atat va fi mai mare efortul pentru publicitatea orientata pe consumator. Proxy-urile pot fi utilizate pentru a administra istoricul paginilor vizitate de utilizator, prin atribuirea unui ID unic pentru un utilizator si stocarea acestui ID utilizand tehnologia cookie. In aceasta situatie, daca utilizatorul viziteaza situl web al unei alte companii conectate la acelasi proxy, atunci informatiile despre acest utilizator pot fi extrase, permitand identificarea unui utilizator unic. Serverul Boomerang de pe DoubleClick (https://www.doubleclick.com) utilizeaza acest concept pentru marketingul direct.

Arhitecturi integrate

Sistemele interne sau externe - aplicatiile existente, baze de date existente si interfete catre parteneri de afaceri externi- pot fi integrate in aplicatiile web pe trei nivele: nivelul prezentare, nivelul logic al aplicatiei si nivelul continutului. Arhitecturi integrate se refera la aspectul de integrare de pe nivelul continut si de pe cel logic al aplicatiei si sunt cunoscute sub numele de arhitecturi EAI (Enterprise Application Integration). In esenta, EAI se focalizeaza pe integrarea sistemelor de mostenire. O alternativa la EAI sunt serviciile web care ofera integrarea serviciilor (logica aplicatiei si continutul). La nivel de prezentare, un set de sisteme diferite sunt integrate tipic prin utilizarea arhitecturilor portal.

Portalurile reprezinta cele mai recente dezvoltari ale aplicatiilor web multi-stratificate. Cu ajutorul portalurilor continutul, care este distribuit pe mai multe noduri ale diversilor furnizori de servicii, va fi disponibil dintr-un singur nod, oferind un aspect consistent. In figura 9 este schematizata arhitectura de baza a unui server portal. Serverele portal se bazeaza pe portlet-uri, care aranjeaza continutul si logica aplicatiei intr-o structura de navigare si un layout adecvate portalului. Un exemplu de server portal este proiectul open-source JetSpeed (https://portals.apache.org/).

Figura 9 Exemplu de arhitectura a unei aplicatii web orientata pe portal

5 Arhitecturi in functie de aspectul datelor

Datele pot fi grupate in una din urmatoarele categorii arhitecturale: (1) date structurate de tipul celor aflate in bazele de date; (2) documente de tipul celor utilizate in sistemele de management al documentelor; (3) date multimedia de tipul celor incluse pe serverele media. Aplicatiile web nu sunt limitate la una din aceste categorii de date, ele integreaza documente, media si baze de date.

Arhitecturi axate pe baze de date

Sunt disponibile numeroase utilitare si abordari pentru integrarea bazelor de date in aplicatiile web. Aceste baze de date sunt accesate fie direct prin intermediul extensiilor serverului web (in cazul arhitecturilor pe doua straturi) fie prin serverele de aplicatii (in cazul arhitecturilor pe N straturi). Pentru accesul la bazele de date relationale sunt disponibile interfete (APIs) pentru diferite platforme (Java Database Connectivity (JDBC) pentru aplicatii bazate pe Java sau Open Database Connectivity (ODBC) pentru tehnologii Microsoft).

Arhitecturi pentru managementul documentelor web

Pe langa datele structurate din bazele de date si cele multimedia de pe serverele media, continutul aplicatiilor web este frecvent procesat sub forma documentelor. Arhitecturile de management al continutului ofera posibilitatea integrarii documentelor din surse diferite, reprezentand un mecanism pentru integrarea acestora in aplicatiile web.

Figura 10 reprezinta componentele unei arhitecturi de management a continutului. Un server web receptioneaza o cerere de la client si o trimite mai departe serverului de furnizare a continutului. Daca continutul solicitat nu este in cache atunci cererea este trimisa mai departe serverului de management al continutului. Continutul poate fi disponibil direct pe server (in forma statica ca un document sau intr-o baza de date) sau poate fi accesat extern. In functie de tipul de integrare continutul extern poate fi extras fie prin accesarea bazelor de date externe (direct sau prin utilizarea unui serviciu de agregare) sau dintr-un serviciu sindicat. Spre deosebire de accesarea unei baze de date, serviciile sindicat pot avea si functii suplimentare (exemplu facturarea automata a drepturilor de licenta).

Figura 10 Arhitectura de management a continutului pentru aplicatiile web

Arhitecturi pentru datele multimedia

Capacitatea de a manipula un volum mare de date are un rol important in proiectarea sistemelor care utilizeaza continut multimedia. Desi volumul de date nu este important in arhitecturile web axate pe baze de date, acesta influenteaza considerabil arhitectura si proiectarea aplicatiilor web multimedia.

Datele multimedia - audio si video- pot fi transmise prin intermediul protocoalelor internet standard (HTTP sau FTP), asemenea celorlalte date utilizate in aplicatiile web. Aceasta abordare este utilizata de un numar mare de aplicatii web deoarece prezinta avantajul ca nu necesita componente suplimentare pe server; dezavantajul este ca descarcarile de fisiere multimedia sunt foarte lente.

Se pot utiliza tehnologii streaming pentru a minimiza perioada de asteptare pentru redarea continutului multimedia; prin streaming un client reda un fisier audio si/sau video la cateva secunde dupa ce incepe receptionarea acestuia de pe server. Aceasta tehnica evita descarcarea intregului fisier inainte de a incepe redarea lui. Continutul trebuie transmis in timp real, ceea ce necesita o latime de banda corespunzatoare (garantarea latimii de banda a transmisiei este numita calitatea serviciului - quality of service).

In general sunt folosite doua protocoale pentru streaming-ul de continut multimedia: un protocol preia transmisia datelor multimedia la nivelul retea, iar celalalt controleaza fluxul prezentarii (exemplu pornirea si oprirea unui clip video) si transmisia meta-datelor. Un exemplu de protocol de retea este RTP (Real Time Protocol) care coopereaza cu un protocol de control numit RTSP (Real Time Streaming Protocol).

Exista doua domenii distincte de aplicatii pentru streaming-ul datelor multimedia: primul face disponibil la cerere continutul existent (video la cerere) iar al doilea distribuie live continutul unui numar mare de utilizatori (exemplu web casting). Fiecare din aceste doua cazuri de utilizare formuleaza cereri diferite la nivelul retelei si arhitecturilor hardware si software. Desi fiecare utilizator stabileste propria sa conexiune la server intr-un scenariu la cerere (vezi figura 12) cauzand probleme majore ale latimii de banda si incarcarii serverului, broadcasting-ul realizeaza cereri sporite la nivelul retelei. In mod ideal, un server utilizat pentru broadcasting sa administreze un singur stream media, care este difuzat simultan catre toti utilizatorii de catre infrastructura retelei (exemplu de router-e) ca in figura 13. Deoarece multicasting-ul nu este suportat in general in internet, serverul trebuie sa foloseasca conexiuni punct-la-punct pentru a simula functionalitatea broadcast.

Figura 12 Arhitectura media de streaming care utilizeaza conexiuni punct-la-punct

Figura 13 Arhitectura media de streaming care utilizeaza o infrastructura broadcasting

6 Concluzii

The development of Web applications is driven by the technical development of (new) client

devices and emerging server infrastructures. The trend towards ubiquitous and portal-oriented

applications will undoubtedly continue in view of the emergence of continually more powerful

client hardware. Portal-oriented Web applications will be supported by developments toward

service architectures and Web services.

This trend has also led to the emergence of a number of new infrastructure approaches, e.g.,

peer-to-peer infrastructures, which will have a major influence on the development of ubiquitous

Web applications. On the other hand, the bandwidth of server infrastructures used for Web

applications has also been growing continually.