Aplicații de tip web arhitecturi [606318]

Aplicații de tip web – arhitecturi

Cu puțin mai mult de un deceniu în urmă, la laboratorul de cercetare științifică din
apropierea orașului Geneva, Tim Berners -Lee a prezentat o propunere de informare care ar permite
schimbul de cunoștințe și resurse, și anume o rețea de calculatoare. Sistemul propus de el s -a
propagat în ceea ce se poate numi cu adevărat World Wide Web, deoarece oamenii din întreaga
lume o folosesc pentru o mare varietate de scopuri:
 Instituțiile educaționale și laboratoarele de cerc etare au fost printre primii utilizatori ai
paginii web, folosind -o pentru partajarea documentelor și pentru resursele internetului.
 Persoanele fizice utilizează astăzi Web -ul ca un serviciu poștal internațional
instantaneu.
 Întreprinderile se angajează în comerțul electronic, oferind persoanelor un mijloc de
cumpărare și vânzarea de bunuri și servicii pe net. De asemenea, comunică cu alte
companii prin intermediul schimburilor de date B2B (business -to-business), unde
companiile pot furniza cataloage de pro duse, inventare și înregistrări de vânzări către
alte companii.
Tim Berners -Lee a promovat inițial World Wide Web ca o bibliotecă virtuală, un
document de control pentru schimbul de informații între cercetători. Pe net, documentele ar putea
fi accesate p rintr-o adresă unică a documentului, o resursă universal locala (URL). Aceste
documente ar putea fi transcrise prin link -uri de tip hypertext. De la începuturile tehnologiei
internetului, a existat o dorință de utilizare a internetului ca mediu universal p entru schimbul de
informații între rețelele de calculatoare.
Inițial, ceea ce oamenii au împărtășit pe internet a constat în mare parte în informații statice
găsite în fișiere ce puteau fi deschise și editate. În orice caz, mare parte a resurselor împărt ășite pe
internet sunt fișiere statice.

4.1 Arhitecturi și protocoale IP
La baza oricărei rețele există o stivă de protocoale care au rolul de a face legătura între
echipamente. Stiva de protocoale respectă unul dintre cele două modele, OSI sau TCP/IP. F iecare
dintre cele două modele folosește aceleași protocoale, fiind diferită împărțirea lor pe straturi.
Stiva OSI este formată din 7 straturi, în timp ce stiva TCP/IP este forma tă doar din 4 straturi
(Figura 4 .1).

Figura 4.1 Modelul OSI – Modelul TCP/IP [8 ]

Modelul OSI oferă o lista extinsă de funcții care pot apărea pe fiecare strat. De asemenea,
descrie interacțiunea fiecărui strat cu straturile vecine acestuia.
Modelul TCP/IP oferă o ierarhizare mai simplă a straturilor. Astfel straturile 1 și 2 din
stiva OSI ( Physical și Data Link ) se regăsesc ca fiind primul strat din stiva TCP/IP, iar ultimele
3 straturi (Session, Presentation și Application) formează ultimul strat al stivei TCP/IP (Figura
4.1). Aceste model este cel întâlnit în alcătu irea rețelelor [7].
Stiva TCP/IP este formată din două mari nivele. Nivelul superior, TCP, este acela care gestionează
asamblarea unui mesaj sau fișier în pachete mai mici, le transmite, dar le și reasamblează pentru a
obține mesajul original. Nivelul inferior, IP, asigură fiecărui pachet o adresă, astfel încât s ă ajungă
la destinația corectă.
În alcătuirea stivei TCP/IP se află o serie de protocoale ce servesc la comunicarea
echipamentelor între ele, dar și cu omul. Aceste protocoale definesc un form at comun și un set de
reguli ce trebuie respectate, iar o lista completă a acestor protocoale în funcție de nivelul la care se
află, se poate vizualiza în figura de mai jos.

Figura 4.2 Lista protocoalelor [8 ]

Din aceasta listă amintim cele mai importante protocoalele care stau la baza aplicațiilor de tip
client – server sunt Ethernet , Internet Protocol ( IP), IP Routing Protocols ( RIP, OSPF, EIGRP,
BGP ), Transmission Control Protocol ( TCP ), User Datagram Protoc ol (UDP ), Hypertext Transfer
Protocol ( HTTP ), File Transfer Protocol ( FTP, TFTP ), Dinamic Host Configuration Protocol
(DHCP ).

 Ethernet – este protocolul de acces în rețea. Acesta descrie două funcții primare:
comunicarea prin legătura de date și transmite rea fizică a datelor de pe suportul de rețea.
Protocoalele de tip acces în rețea sunt folosite pentru a lua pachetele făcute de IP și a le
formata pentru a putea fi transmise în mediul extern.
 IP – este protocolul responsabil pentru a lua segmentele format e de TCP, a le încapsula în
pachete, atribuindu -le adresele corespunzătoare și a le livra către destinație.
 Ip Routing Protocols :
o RIP : Routing Information Protocol a fost cel mai popular protocol de rutare de
interior din suita TCP/IP pentru mulți ani. Istoria protocolului este una destul
de interesantă. Spre deosebire de multe dintre celelalte protocoale importante
în suita TCP/IP, RIP nu a fost dezvoltat pentru prima dată în mod oficial,
folosind procesul de standardizare RFC.
o OSPF : Open Shortest Pat h First este un protocol IP dinamic destinat rutării în
interiorul unei rețele mari sau sistem autonom. Principial, OSPF este bazat pe
caracteristicile conexiunilor dintre interfețe. OSPF înlocuiește RIP ca protocol
standard de interior în special în rețel e mari. Calitatea legăturii între interfețele
routerelor este numită generic cost în cazul OSPF și se stabilește matematic
având definitoriu criteriul lățimii de bandă.

o EIGRP : Enhanced Interior Gateway Routing Protocol este introdus în 1994 de
către Ci sco sub forma unui protocol de routare propriu. EIGRP este o versiune
îmbunătățită a IGRP cu care își păstrează compatibilitatea. EIGRP este, ca și
predecesorul său un protocol de rutare bazat pe principiul distanței vectoriale și
constă într -un schimb de informații cu celelalte routere din rețea, coroborat cu
un proces intern de stocare a datelor primite de la acestea, incluzând detaliile
bazate pe caracteristicile calitative ale rutelor raportate, informații pe baza
cărora se va lua decizia de alegere a rutei spre o anumită destinație. Viteza mare
de decizie privind nominalizarea unei rute în cazul unor schimbări de topologie
în rețea face din EIGRP un concurent al OSPF [7].
o BGP : Border Gateway Protocol este protocolul de rutare folosit în
nucleul Internetului. El menține o tabelă cu rețele IP care arată calea folosită
pentru a ajunge la rețeaua respectivă prin diferitele sisteme autonome. BGP este
considerat din acest motiv un protocol de rutare vector -cale. BGP nu folosește
aceleași metrici ca protocoalele de rutare folosite în interiorul sistemelor
autonome, ci ia decizii bazându -se pe cale și pe politicile de rutare ale
sistemului autonom din care face parte.

 TCP – este protocolul de transport care g estionează conversațiile individuale. Acesta
împarte mesajele de tip HTTP în bucăți mici, numite segmente. Aceste segmente sunt
trimise între serverul web și client pentru a valida comunicația de la un host la altul. TCP
este de asemenea responsabil pentru controlul dimensiunii și rata la care mesajele sunt
transmise între client și server, dar și pentru eliminarea mesajelor duplicate.
 UDP – Împreună cu Internet Protocol (IP), acesta face posibilă livrarea mesajelor într -o
rețea. Spre deosebire de protocolul TCP, UDP constituie un modul de comunicație fără
conexiune . Este similar cu sistemul poștal, în sensul că pachetele de informații sunt trimise
în general fără confirmare de primire, în speranța că ele vor ajunge, fără a exista o legătură
efectiv ă între expeditor și destinatar. Practic, UDP este un protocol ce nu oferă siguranța
sosirii datelor la destinație, nu dispune nici de mecanisme de verificare a ordinii de sosire
a datagramelor sau a datagramelor duplicate. UDP dispune, totuși, în formatul
datagramelor, de sume de control pentru verificarea integrității datelor sau de informații
privind numărul portului pentru adresarea diferitelor funcții la sursă/ destinație.
 HTTP – este un protocol de aplicație care determină modul în care un server web și un
client web interacționează. Între client și server apare o serie ce cereri și de răspunsuri,
acestea fiind gestionate de acest protocol. Atât clientul cât și serverul pun în aplicare
protocolul HTTP. HTTP se folosește de alte protocoale pentru transp ortul mesajelor între
client și server. Deși HTTP este un protocol flexibil, acesta nu este securizat. Atât mesajele
de tip cerere, cât și mesajele de tip răspuns sunt necriptate, putând fi interceptate și citite
de oricine. Pentru o comunicare sigură pe H TTP este folosit protocolul Secure (HTTPS).
Acesta din urmă folosește autentificare și criptarea cu Secure Socket Layer (SSL) pentru
a securiza datele pe măsura ce se deplasează între client și server.

 File Transfer Protocol :
o FTP : este un protocol de rețea standard utilizat pentru transferul de fișiere de la un
server la un client folosind modelul client -server de pe o rețea de calculatoare.

FTP este construit pe o arhitectură client -server și utilizează conexiuni separate de
control și de date între c lient și server. Utilizatorii FTP -ului se pot autentifica cu un
protocol clear -text sign -in, în mod normal, sub forma unui nume de utilizator și o
parolă, dar se pot conecta și anonim dacă serverul este configurat pentru a permite acest
lucru. Pentru trans misia sigură, care protejează numele de utilizator și parola, precum
și criptează conținutul, FTP este adesea securizat cu SSL/TLS.
o TFTP : este un protocol asemănător FTP -ului, care permite unui client să obțină un
fișier de la o gazdă, la distanță. Una d intre utilizările sale primare se află în primele
etape ale nodurilor de booting ale unei rețele locale. TFTP a fost utilizat pentru această
aplicație, deoarece este foarte simplu de implementat.

 DHCP: Dinamic Host Configuration Protocol este un protocol de rețea standardizat utilizat
în rețelele IP (Internet Protocol). DHCP este controlat de un server DHCP care distribuie
în mod dinamic parametrii de configurare de rețea, cum ar fi adrese IP, pentru interfețe și
servicii. Un router sau un gateway rezidenț ial poate fi activat pentru a acționa ca un server
DHCP. Un server DHCP permite computerelor să solicite adrese IP și parametrii de rețea
în mod automat, reducând nevoia de un administrator de rețea sau un utilizator pentru a
configura manual aceste setări . În lipsa unui server DHCP, fiecărui computer sau altui
dispozitiv (de exemplu, o imprimantă) din rețea, trebuie să îi fie atribuită o adresă IP statică.
O condiție necesară pentru a permite ca arhitectura stratificată să funcționeze corespunzător
este că fiecare strat trebuie să știe informația ce vine de la stratul de deasupra sau de dedesubt. Este
posibil ca stratul să nu fie interesat de conținutul mesajului, dar trebuie să știe ce să facă cu el.
Pentru a simplifica această sarcină, fiecare strat adaug ă un bloc de date în fața și în spatele
mesajului, ceea ce indică stratul care este implicat, precum si un set de biți reprezentând
informațiile adăugate de alte straturi. Informația din mesaj este ignorată. Fiecare strat face propria
încapsulare, adică fi ecare strat adaugă o capsulă de informații în jurul informației inițiale,
constituind blocuri de început și sfârșit. Aceasta se materializează în câteva seturi de header -e și
trailer -e până când mesajul ajunge în rețea [6].

4.2 Protocolul HTTP

HTTP este protocolul de bază al World Wide Web -ului. Acesta este simplu, ceea ce
reprezintă atât o limitare cât și o sursă de putere. Mulți oameni din industrie au criticat HTTP -ul
pentru funcționalitatea limitată, însă protocolul HTTP a reușit ceea ce protoco ale mai avansate și
mai sofisticate nu au putut.
HTTP este un protocol situat la nivel de aplicație în suita de protocoale TCP / IP, folosind
TCP ca protocol de bază pentru transmiterea mesajelor. Principalele lucruri care trebuie știute
despre HTTP si st ructura acestuia sunt:
 Protocolul HTTP folosește structura cerere – răspuns, ceea ce înseamnă că un client
HTTP trimite un mesaj de cerere HTTP către un server HTTP, care întoarce un mesaj
de răspuns HTTP.

 Structura mesajelor de tip cerere și răspuns este similară cu cea a mesajelor de tip poștă
electronică. Ele constau într -un grup de linii care conține anteturi de mesaje, urmate de
o linie goală, urmată de un corp de mesaj.
 HTTP este un protocol fără stare , ceea ce înseamnă că nu are nici un sprijin expl icit
pentru noțiunea de stare. O tranzacție HTTP constă într -o singură cerere de la un client
la un server, urmat de un singur răspuns de la server înapoi la client.

Structura mesajelor HTTP

Structura mesajelor HTTP este mult mai sofisticată decât cea a mesajelor de tip mail.
Mesajele de tip mail sunt destinate să transmită informații direct între persoane, astfel atât antetul
mesajului cât și conținutul acestuia trebuie să fie ușor de citit; mesajele HTTP nu sunt citite direct
de către oameni, astfel c onținutul acestora este mai sofisticat și greu de înțeles de către oameni. O
altă diferență fundamentală este că atât mesajele HTTP cât și răspunsurile încep cu linii speciale
care nu respectă formatul standard al antetului. Aceste linii se numesc linie de cerere și respectiv
linie de răspuns.
Un exemplu simplu îl reprezintă încărcarea unei pagini web statice pe un server web. Un
utilizator poate tasta manual o adresă URL în browser, poate face clic pe un hyperlink găsit în
pagina pe care o vizualizează cu browser -ul sau poate selecta o pagină marcată pentru vizitare. În
fiecare dintre aceste cazuri, dorința de a vizita o anumită adresa URL este tradusă de browser într –
o cerere de tip HTTP.

Figura 4.3 Încărcare pagină web [2]

Fiecare cerere începe cu o linie specială numită request line care conține un număr de câmpuri. În
exemplul anterior “METHOD” reprezintă una dintre cele mai folosite metode de cerere solicitate
printre care se află GET și POST. “/path -to-resource” reprezintă porțiunea solicitată din calea
URL. /version -number reprezintă versiunea de HTTP folosită de client.
După prima linie se observă adesea o listă de anteturi, urmată de o linie necompletată având
rolul de a separa antetele de restul cererii.
Există o varietate de metode de ce rere specifice protocolului HTTP . Cele mai des întâlnite
sunt GET, HEAD și POST, iar cele mai rar utilizate sunt PUT, DELETE, TRACE, OPTIONS și
CONNECT.
La răspuns, primul rând îl reprezintă linia de stare constând în protocolul folosit, versiunea,
urmat apoi de un cod de stare format din 3 cifre și o scurtă explicație. Codul ne arată dacă răspunsul
a fost generat așa cum trebuie sau dacă trebuie efectuate operațiuni specifice.
Codurile de stare sunt grupa pe categorii. Dintre aceste categorii amintim de cele mai des
întâlnite:
 1xx – codurile de stare care încep cu 1 sunt definite ca fiind informaționale.

 2xx – codurile de stare care încep cu 2 indică succesul la răspuns.
 3xx – codurile de stare care încep cu 3 sunt folosite pentru redirecționare.
 4xx – codurile de stare care încep cu 4 reprezintă o eroare la cererea clientului.
 5xx – codurile de stare care încep cu 5 reprezintă o eroare de server.

4.3 Web browser

Principalele responsabilități ale unui browser sunt:

 Generarea și trimiterea cererii c ătre serverul web, în numele utilizatorului, ca rezultat
al urmăririi hyperlink -urilor, introducerea explicită a adreselor URL, trimiterea
formularelor și analizarea paginii HTML în vederea necesității de resurse auxiliare.
 Acceptarea răspunsurilor livrate de serverul web și interpretarea acestora în scopul
producerii reprezentării vizuale necesitate de utilizator. Acest lucru implică examinarea
unor antete din răspuns cum ar fi tipul de conținut necesar pentru a determina ce măsuri
trebuie luate și ce fel de redare este necesară.
 Afișarea rezultatelor în fereastra browser -ului în funcție de conținutul acestora.

Procesarea fluxului

În figura de mai jos este prezentată procesarea fluxului de procese pentru crearea și
transmiterea unei cereri într -un browser tipic.

Figura 4.4 Procesarea fluxului de cereri HTTP [3]

Utilizatorii pot face click pe hyperlink -urile prezentate în fereastra de afișare a browser –
ului. Aceștia pot alege link -uri din listele de legătură vizitate anterior sau pot accesa o adresă URL
manual. În fiecare dintre aceste cazuri, procesarea începe cu modulul User Interface care este
responsabil cu prezentarea ferestrei de afișare și acordarea accesului utilizatorilor la funcțiile
browser -ului. În general o aplicație care utilizează un GUI, funcționează folosind un model de
eveniment.
De exemplu, acți unile utilizatorilor cum ar fi clic pe un hyperlink subliniat, trebuie
interpretate in mod corespunzător de modulul User Interface.
Cele mai importante evenimente ale interfeței folosite de utilizator sunt:
 Introducerea manuală a adreselor URL: de obicei , aceasta se realizează prin furnizarea
unei intrări de tip text în caseta destinată acestui lucru, în care utilizatorul poate
introduce o adresă URL, precum și printr -o opțiune de meniu care deschide o casetă de
dialog pentru o intrare manuală similară.
 Selectarea legăturilor vizitate anterior: existența acestui mecanism implică faptul că
modulul de interfață utilizator trebuie să ofere o istorie a legăturilor vizitate. Valoarea
maximă a timpului în care există astfel de legături va fi menținută în această listă,
precum și mărimea maximă la care este limitată această listă. Zona de text "Locație"
sau "Adresă" din fereastra browser -ului poate fi un câmp vertical care permite
utilizatorului să selecteze din legăturile vizitate recent.
 Selectarea hyperlink -urilor afișate: există mai multe moduri de selectare link -uri afișate
pe pagina prezentată. Cel mai des întâlnit mod de a selecta un link este cel cu mouse –
ul.
Odată ce link -ul selectat sau introdus este transmis modulului de generare a cererii, aceasta
trebuie rezolvată. Linkurile găsite pe o pagină afișată pot fi fie absolute sau relative.
Adresele URL absolute sunt adrese URL complete, conținând adresa URL necesară de
exemplu: // host / cale . Acestea nu trebuie rezolvate și pot fi procesate fără intervenț ia ulterioară.
O adresă URL relativă face referire la:
 Locația curentă fiind afișată și întreaga adresă URL, inclusiv calea la directorul în care
se află adresa URL curentă.
 Rădăcina serverului web al locației curente – doar partea gazdă a adresei URL.

Odată ce adresa URL a fost rezolvată, modulul de generare a solicitărilor construiește
solicitarea, care în cele din urmă, este transmisă modulului de rețea. Pentru a îndeplini această
sarcină, modulul de generare a cererilor trebuie să comunice cu celela lte componente ale browser –
ului.
După transmiterea cererii, browser -ul așteaptă să primească un răspuns. Poate trimite
solicitări suplimentare în așteptare. Este posibil ca solicitările să fie retrimise dacă conexiunea este
închisă înainte de primirea răspunsurilor corespunzătoare. Este r esponsabilitatea serverului de a
transmite răspunsuri în aceeași ordine în care au fost primite cererile corespunzătoare. Cu toate
acestea, browser -ul este responsabil pentru a se ocupa de serverele care nu întrețin corect această
comandă, întârziind proce sarea răspunsurilor care ajung fără succes.
Un răspuns este primit de modulul Networking, care îl transmite către modul de procesare
a răspunsului. Acest modul trebuie, de asemenea, să coopereze și să comunice cu alte module
pentru a -și face treaba.
Pe tot parcursul, diferitele module subordonate pun întrebări care trebuie să determine
cursul de procesare (inclusiv dacă anumite sarcini sau nu trebuie îndeplinite deloc).

4.4 HTML

Una dintre pietrele de temelie ale Web -ului este HTML. Acesta este un limbaj care are
scopul de a permite încrucișarea documentelor prin intermediul unor hyperlink -uri.
HTML -ul a fost definit ca o cerere a SGML pentru a defini limbajele de marcare. Pe
parcursul ultimilor 10 ani specificațiile HTML -ului au trecut printr -o serie de modificări având ca
scop micșorarea sintaxei acestuia.

4.4.1 Structura HTML -ului

Conform specificațiilor, un document HTML trebuie să conțină o referință la versiunea
folosită , un antet care să conțină declarații la nivel de document și conținutul documentului. Un
exemplu în acest sens îl reprezintă figura de mai jos:

Figura 4.5 Structura unui mesaj HTML [2]

 Antetul – Secțiunea antet începe cu elementul <HEAD> opțional și include declarațiile
documentului. Cel mai frecvent utilizat element de antet este <TITLE> care datează de la
începutul versiunilor HTML. Cele mai multe browsere afișează valoarea acestui element
în afara corpului documentului. Alte elemente definite în s ecțiunea antet HTML sunt
<STYLE> și <SCRIPT>. Elementul <STYLE> este proiectat să modifice comportamentul
implicit al browser -ului atunci când facem marcajul corpului. Elementul <SCRIPT>, în
combinație cu dispozitivele de gestionare a evenimentelor care po t fi menționate din corpul
documentului, este proiectat pentru a oferi acces la obiectele browser -ului create atunci
când procesează răspunsuri HTTP.
 Conținutul documentului – Conținutul unui document HTML este inclus în elementul
<BODY>. Pe lângă acesta mai există și alte elemente folosite destul de des, cum ar fi
<TABLE>, <H1>, <H2> folosite pentru titluri dar și liste ordonate și neordonate folosite

pentru a controla aspectul informației afișate. La fel de importante sunt și elementele ce
conțin documen te sau locații de referință pentru documente, sau elemente de imagine.

4.4.2 JavaScript

Limbajele precum HTML au scopul de a furniza informații de formatare pentru
interpretarea statică a conținutului. Una dintre cele mai notabile tendințe în evoluția H TML a fost
introducerea de noi elemente și atribute care fac posibilă depășirea interpretării statice și controlul
comportamentului browser -ului în mod programabil.
Soluția a fost introducerea unui limbaj de programare orientat pe obiecte, JavaScript, care
include funcționalități integrate pentru accesarea obiectelor browser -ului (de exemplu elemente de
pagină, module de generare a cererilor, etc.) și să introducă atributele HTML care permit
cartografierea de metode JavaScript la evenimentele utilizatorilor .
JavaScript a fost inițial dezvoltat pentru Netscape Navigator, dar este acum acceptat de cele
mai multe browsere desktop, inclusiv Internet Explorer. Browserele procesează instrucțiunile
JavaScript încorporate în pagini HTML. Lucrul care trebuie reținut este acela că există diferențe
subtile în implementările JavaScrip pentru diferite browsere. Este posibil ca un program JavaScript
care funcționează în mod constant în diferite browsere, chiar dacă utilizează o funcționalitate
relativ simplă, să devina ad esea un proces iterativ de încercare și eroare.
Un alt aspect important este că nu toată procesarea JavaScript este efectuată in același timp.
Unele instrucțiuni sunt interpretate înainte de redarea codului HTML document, sau în timp ce
documentul este re dat. Aceste afirmații sunt de obicei conținute în blocuri de script. Alte declarații
sunt grupate în procesări de evenimente care sunt asociate cu evenimentele browser -ului prin
eticheta HTML atribute.

4.4.3 Dynamic HTML

DHTML sau Dynamic HTML este o nouă specificație a HTML -ului cu o funcționalitate
avansată. În realitate, DHTML este doar un nume folosit pentru a descrie caracteristicile existente
in HTML, JavaScript și CSS folosite pentru a furniza diferite forme ale paginii prezentate.
În timp c e codul HTML oferă un format static de prezentare, combinarea de etichete HTML
cu directivele JavaScript și specificațiile stilului CSS, oferă un grad de control dinamic asupra
prezentării paginii. Este dinamic în sensul că prezentarea unei anumite pagini se poate schimba în
timp odată cu interacțiunea utilizatorului, spre deosebire de aplicațiile Web dinamice care
generează întreaga pagină de prezentare.

4.5 Aplicații web dinamice

Aplicațiile client -server sunt grupuri de programe distribuite care rulea ză pe computere din
rețea și interacționează cu protocoalele de comunicare cunoscute. Mai degrabă decât să efectueze
toate procesările pe un singur sistem și să transmită rezultatele formatate către terminale "mute",
aplicațiile client -server distribuie ef ectuarea procesărilor între servere dedicate și mașinile
clienților. Această arhitectură a fost facilitată de dezvoltarea rapidă a computerelor personale, a
căror putere de procesare a permis descărcarea aplicațiilor de la server la client. Cu timpul, unel e

platforme de aplicații client -server au devenit foarte complexe, iar configurarea și întreținerea lor
a devenit un coșmar.
O aplicație web este o aplicație client -server care utilizează browser -ul web pe post de
client. Browserele trimit solicitări căt re servere, iar serverele generează răspunsuri și le returnează
la browser. Răspunsurile diferă de aplicațiile client -server mai vechi deoarece utilizează un
program comun, și anume browser -ul web.
Există avantaje importante pentru utilizarea browserelor web ca clienți:
 Browserele web sunt prezente pe aproape orice desktop și pot fi folosite pentru a
interacționa cu multe aplicații web diferite. Nu este nevoie de instalarea mai multor
programe client specializate pe desktop.
 Browserele oferă mecanisme pent ru a descărca în siguranță și pentru a rula aplicații mai
complexe atunci când nu este necesară o funcționalitate suplimentară pe care numai
navigatorii nu o pot oferi.

Figura 4.6 Legătura client -server [3]

4.6 Arhitectura aplicațiilor

O bună reprezentare a arhitecturii aplicațiilor de tip web se regăsește în figura de mai jos

Aplicațiile Web

TCP/IP Protocol

Browser Web

Figura 4.7 Arhitectura aplicațiilor web [3]

 Interpreting and routing user requests (interpretare și direcționarea solicitărilor
utilizatorului)
În timpul acestui pas, serverul web este responsabil pentru determinarea acțiunii ce trebuie
luate pentru procesarea cererii. Această acțiune poate fi recuperarea unui fișier HTML static,
executarea unui script, sau invocarea unui modul de procesare specializat.

 Controlling acces to the application (controlarea accesului la aplicație)
Cu excepția cazului în care avem de -a face cu o problemă nerestricționată, avem nevoie de
mecanisme de control al accesului. Acest lucru implică mai mult decât a oferi suport la
autentificare. Unele funcții pot fi disponibile tuturor, altele doar clienților înregistrați.

 Enabling data access (activarea accesului la date)
Dacă utilizatorii doresc să vizualizeze informațiile despre p rodus dintr -un catalog sau doresc
sa citească articole dintr -o bibliotecă online, atunci aplicația trebuie sa dețină accesul la datele
reale.

 Accessing and modifying content (accesarea și modificarea conținutului)
Pentru accesarea și afișarea conținutului , aplicația poate fi responsabilă de efectuarea
actualizărilor de conținut. Aceste actualizări pot fi rezultatul unei acțiuni explicite a
utilizatorului sau pot avea loc automat, bazate pe logica aplicațiilor.

 Customizing responses (personalizarea răspu nsurilor)
Poate fi necesară transformarea răspunsurilor generate pentru facilitarea prezentării
personalizate a utilizatorului original. Aceste transformări pot suporta modificări bazate pe
preferințele utilizatorilor sau bazate pe site.

 Transmitting fo rmatted responses (transmiterea răspunsurilor formatate)

În aplicațiile web mai vechi, odată ce au fost efectuate transformările de conținut, un răspuns
HTML care conține o prezentare formatată, a fost trimis înapoi la clientul inițial. Aplicațiile mai
sofisticate pot trece la un browser sau un dispozitiv special, aflate la final, utilizând o foaie XSL
înainte ca răspunsul să fie transmis. Rezultatul poate fi o pagină HTML sau un document WML.

 Recording and logging application activity (activitate de înreg istrare și înregistrarea
aplicațiilor)
Este importantă evidența utilizării unei aplicații