UNIVERSITATEA DUNREA DE JOS GALAI

FACULTATEA DE TIINA CALCULATOARELOR

SPECIALIZAREA CALCULATOARE

LUCRARE DE LICEN

GALAI - 2009
UNIVERSITATEA DUNREA DE JOS GALAI
 FACULTATEA DE TIINA CALCULATOARELOR
SPECIALIZAREA CALCULATOARE

LUCRARE DE LICEN
SISTEME DISTRIBUITE STUDIU DE CAZ

Tem Cerine:
S se studieze ca Sistem distribuit Sistemul naional informatic

GALAI - 2009

CUPRINS
1. Introducere 4
1.1 Definiie 4
1.2 Obiective 5

1
2. Arhitectura sistemelor distribuite 8
2.1 Noiuni introductive 8
2.2 Definirea arhitecturii sistemelor distribuite 8
2.3 Arhitectura software 9
2.4 Platformele hardware i software n sistemele distribuite 10
2.5 Nivelul middleware 13
2.6 Modele arhitecturale pentru sistemele distribuite 16
2.6.1 Modelul client/server 16
2.6.2 Servicii furnizate de mai multe servere 17
2.6.3 Servere proxy i tehnica de caching 17
2.6.4 Procese perechi 19
2.7 Modelul client/server 20
2.7.1 Noiuni introductive 20
2.7.2 Definirea modelului client/server 21
2.7.3 Arhitecturi client/server multistrat 22
2.7.4 Clasificarea modelelor arhitecturale client/server 26
2.7.5 Variaiuni pe aceeai tem: client/server 30
3. WORLD WIDE WEB ca Sistem distribuit 34
3.1 Noiuni introductive 34
3.2 Aspecte arhitecturale 35
3.3 Aspecte privind serverul 41
3.4 URL- Uniform Resource Locators Naming 45
3.5 Lipsa strii i utilizarea cookies 49
3.6 Documente Web statice 50
3.6.1 HTML - HyperText Markup Language 51
3.6.2 XML i XSL 55
3.7 Documente Web dinamice 56
3.7.1 Generare dinamic de pagini de Web la server 56
3.7.2 Generare dinamic de pagini de Web la client 58
3.8 mbuntiri ale performanei 59
3.9 Aplicaia SNIEP 62
4. Consistena Sistemelor distribuite i Toleranta la defecte 65
4.1 Modele de consisten 65
2
4.2 Protocoale de distribuie 67
4.3 Toleranta la defecte 67
4.3.1 Introducere n toleranta la defecte 67
4.3.2 Modele de defectare i mascarea defectrii prin redundan 68
4.3.3 Reziliena proceselor i mascarea defectelor i replicarea 69
4.3.4 Punerea de acord n sisteme cu funcionare defectuoas 71
4.4 Comunicaie de ncredere client-server 72
5. Replicarea serverelor, Backup 74
5.1 Noiuni introductive 74
5.2 De ce replicare? 74
5.2.1 Sporirea performantei 75
5.2.2 Sporire a disponibilitii i robusteii 75
5.2.3 Transparenta replicrii 75
5.3 Backup 76
6. Securitate 78
6.1. Noiuni introductive 78
6.2. Ameninri de securitate, politici i mecanisme 78
6.3. Elemente de proiectare 79
7. VPN - Virtual Private Network Comunicaii n Sistemele distribuite 81
7.1 Noiuni introductive 81
7.2 Intranet VPN 83
7.3 Cerine de baz i soluii pentru implementarea VPN-uri 84
7.4 Metode de transmisie prin VPN 86
7.5 Securitate VPN 90
7.6 Standardizarea reelelor VPN Standardul IPSec 92
8. Consideraii privind mbuntirea sistemului distribuit 95
Sisteme distribuite out of the paper i only adding 95
9. Concluzii 96
Bibliografie 97
1. Introducere

3
 n cadrul SNIEP (Sistemul naional informatic de eviden a populaiei) sunt activitai de
producere, eliberare si evidenta a documentelor, precum si administrarea bazelor de date
integrate, care cuprind informaii referitoare la persoana fizic.
Registrul naional de eviden a persoanelor (R.N.E.P.), este componenta principal a
S.N.I.E.P. i reprezint ansamblul datelor cu caracter personal ale cetenilor romni, rezultate n
urma procesrii automate, ntr-o concepie unitar, n scopul cunoaterii numrului, structurii i
micrii populaiei pe teritoriul rii.
Era calculatoarelor a nceput n 1945 i pana prin anii 1985 calculatoarele erau nc de
dimensiuni mari i la costuri prohibitive pentru unii. ncepnd cu mijlocul anilor '80 datorita
avansrii tehnologiilor de fabricaie situaia s-a schimbat. Prima data au aprut microprocesoare
mai puternice ce funcionau la nceput pe 8 bii iar mai apoi maini cu CPU-ri ce lucrau pe 16, 32
si ceva mai trziu chiar pe 64 de bii. Apoi au aprut reelele de calculatoare i implementarea
unor tehnologii ce permiteau interconectarea acestora la viteze mari. Aa au aprut si s-au
dezvoltat reelele locale (LAN) unde datele erau transferate la rate de transfer de 10 milioane
chiar si 100 de milioane de bii/secunda.
n cadrul reelelor larg rspndite geografic (WAN) erau i se pot conecta milioane de
maini(calculatoare) la viteze de transfer de 64Kb/sec ajungndu-se n cadrul unor reele
avansate la rate de transfer de 1Gbit/sec. Ca urmare interconectarea mai multor microprocesoare
n cadrul unor reele larg rspndite cu viteze de transfer relativ mari a devenit nu numai fiabila
dar i uor de realizat. Acestea sunt de obicei denumite Sisteme Distribuite n contrast cu cele
precedente unde aveam numai un singur microprocesor denumite si Sisteme centralizate.

1.1. Definiie

Exist multiple definiii furnizate de literatura de specialitate asupra noiunii de sistem

distribuit. n scopul acestei prezentri vom folosi o definiie oarecum larg a acestui concept:

Un sistem distribuit este o colecie de calculatoare independente ce apar utilizatorilor ca

un (unic) sistem coerent.

Trebuie subliniate dou aspecte incluse n aceast definiie: din punct de vedere
hardware, calculatoarele sunt autonome, iar din punct de vedere software, utilizatorii au impresia
c interacioneaz cu un singur sistem.
4
 Cea mai important caracteristic a unui sistem distribuit este acea c diferenele dintre
calculatoare precum i modul n care ele comunic sunt ascunse utilizatorului. Aceast
proprietate se numete transparen.
De asemenea, un sistem distribuit trebuie s fie relativ uor de extins n numr de resurse,
utilizatorul nefiind contient de faptul c anumite componente sunt defecte, nlocuite adugate
sau eliminate din sistem, deoarece acesta este mereu disponibil. Aceast proprietate se numete
scalabilitate.
Un exemplu comun de sistem distribuit este World Wide Web - n particular un sistem
distribuit de documente - acesta ofer o imagin simpl, consistent i uniform utilizatorilor. Pe
baza modelului acestui sistem, nu este necesar, cel puin n teorie, ca utilizatorul s tie locaia
serverului, caracteristicile acestuia, nici chiar identificatorul exact al serverului de unde primete
documentul.

1.2. Obiective

Principalul obiectiv al unui sistem distribuit este de a conecta utilizatori la resurse ntr-o
manier transparent, deschis i scalabil.
Prin resurse denumim n principiu orice, dar de regul pot fi: calculatoare, imprimante,
dispozitive de stocare, , date, fiiere, reele i altele. Motivul principal pentru care aceste resurse
sunt puse n comun pentru mai muli utilizatori este unul economic, mai ales cnd se pune
problema folosirii de resurse scumpe cum ar fi super calculatoarele sau sisteme de stocare de
mare performan. Desigur, pe msur ce conectivitatea crete apar i problemele, mai ales legate
de aspecte de securitate sau de exces de comunicare (de exemplu, junk mail).
Mecanismele ce implementeaz transparena ntr-un sistem distribuit permit obinerea de
grade de transparen. Pe de o parte, acest lucru este determinat de compromisul dintre
transparena i performana unui sistem - pe msur ce gradul de transparen crete, performana
sistemului scade. Pe de alt parte, limitrile fizice, de exemplu n privina transportului
informaiei, nu pot fi ascunse sau ignorate.
Un alt obiectiv important al unui sistem distribuit este deschiderea. Un sistem distribuit
deschis ofer servicii bazate pe reguli standard privind sintaxa si semantica acestor servicii.
De exemplu, comunicaia dintre calculatoare este guvernata de reguli standard privind
formatul, coninutul si semnificaia mesajelor primite si transmise. Aceste reguli sunt formalizate
n protocoale.
5
 n sistemele distribuite regulile sunt specificate prin interfee standard, ce sunt de cele
mai multe ori descrise folosind IDL (Interface Definition Language).
Doua consecine directe ale deschiderii sunt interoperabilitatea si portabilitatea.
- Interoperabilitatea caracterizeaz gradul pn la care doua implementri de sisteme sau
componente ce provin de la productori diferii pot coexista sau lucra mpreun prin folosirea
serviciilor ce acestea le furnizeaz, specificate ntr-un standard comun.
- Portabilitatea caracterizeaz gradul pn la care o aplicaie dezvoltat pentru sistemul A
poate fi executata, fr modificri, pe sistemul B, ce implementeaz aceleai interfee ca A.
Totui, de cele mai multe ori, definiia interfeelor standard nu este complet, motiv pentru care
dezvoltatorii adaug detalii dependente de implementare.
n fine, cel de-al treilea obiectiv este scalabilitatea. Aceasta este msurata pe trei
dimensiuni:
- scalabilitate in mrime - se pot aduga cu uurina resurse si utilizatori;
- scalabiltatea n distribuie geografica - se pot conecta resurse si utilizatori aflai la mare
distanta;
- scalabilitatea n administrare - sistemul este uor de administrat, chiar si cnd se ntinde
pe mai multe organizaii independente.
De regul, indiferent de gradul de scalabilitate al unui sistem, de ndat ce acesta creste
apare o pierdere de performan.
Limitrile scalabilitii n distribuie geografica pot proveni din mecanisme de
comunicaie sincrona sau din presupunerea ca mecanismele de comunicare sunt de ncredere, n
cazul sistemelor provenind din LAN, ce sunt extinse in WAN
Limitrile scalabilitii administrative sunt generate de existenta de diverse politici in
cadrul organizaiilor ce sunt deservite de sistem, de exemplu politicile de securitate.
Tehnicile de asigurare a scalabilitii sunt bazate pe:
- utilizarea comunicaiei asincrone - n acest fel latena de comunicare este ascunsa,
utilizatorul ce a fcut cererea primind rspunsul ulterior, fr a-i fi blocata activitatea n acest
timp.
- distribuirea componentelor ce furnizeaz serviciile - un exemplu bun este distribuirea
informaiei pe DNS.
- replicarea componentelor - ce creste disponibilitatea sistemului i creeaz premise
pentru echilibrarea ncrcrii pe computerele din sistem
Caching-ul este o forma de replicare si att n cazul acestuia, ca i n cazul replicrii, in
6
general, este afectata consistena sistemului, deoarece, orice modificare a informaiei/strii
originale a sistemului fie nu se propaga la utilizator, fie necesit mecanisme complexe de punere
de acord intre replici.

Figura 1-1 Exemplu de divizare a spaiului DNS n zone

2. Arhitectura sistemelor distribuite

7
2.1. Noiuni introductive

Pn acum, sistemele distribuite nu s-au impus pe piaa, ci au rmas mai mult n faza de
proiecte universitare. Pe de o parte, performana este limitata de transmisia datelor prin reea,
care se desfoar la o rat mica n comparaie cu puterea de calcul a procesoarelor. Pe de alt
parte, utilizarea n comun a staiilor dintr-o reea nu se justific dect n rezolvarea unor
probleme care necesit un volum de calcul mult peste posibilitile unui singur calculator. Astfel,
calculul distribuit poate fi vzut ca o alternativ mai mult pentru supercalculatoare i mai puin
pentru calculatoarele personale sau servere.
Sistemele distribuite implementate pn n prezent evideniaz o varietate arhitectural
mare. Cu toate acestea, ele au n comun o serie de caracteristici i mprtesc unele probleme
comune n dezvoltarea lor. Caracteristicile comune i aspectele de proiectare a sistemelor
distribuite pot fi prezentate sub forma unor modele descriptive. Fiecare astfel de model va
reprezenta o descriere abstract, simplificat dar consistent a aspectelor relevante ale proiectrii
sistemelor distribuite.

2.2. Definirea arhitecturii sistemelor distribuite

O definiie standard, universal acceptat, pentru arhitectura sistemului informatic nu

exist, majoritatea opiniilor exprimate punnd n centrul ateniei conceptele de component i
conexiune. Una din definiiile mai recente consider arhitectura programelor ca fiind structura
sau structurile care privesc componentele programului, proprietile externe ale acestor
componente, precum i relaiile dintre ele".
n funcie de semnificaia noiunii de component, arhitectura sistemelor informatice
poate fi definit ntr-un sens restrns i ntr-un sens mai larg. Proiectarea arhitecturii unui
program poate viza, n sens restrns, componentele programului, respectiv modulele acestuia,
ns ea poate fi extins prin includerea bazei de date i a componentei middleware care permite
configurarea comunicrii ntr-un sistem client/server.
Proprietile acestor componente sunt acele caracteristici care permit nelegerea modului
n care ele interacioneaz, respectiv modul de apelare a unui modul din alt modul sau
mecanismul de accesare a bazei de date de ctre modulele programului. Proiectarea arhitectural
a programului nu ia n considerare proprietile interne ale componentelor, cum ar fi detaliile
8
unui algoritm specifice unui modul.
Relaiile dintre componente se pot referi fie la apelarea unei proceduri, cu transmiterea eventual
a datelor necesare execuiei procedurii respective, fie la protocolul de accesare a bazei de date de
ctre procedurile de program.
Obiectivul general urmrit n cadrul proiectrii arhitecturale vizeaz conceperea unei
structuri a sistemului care s corespund cerinelor prezente i celor viitoare, astfel nct sistemul
s fie sigur n funcionare, adaptabil, uor de gestionat, eficient. O bun proiectare arhitectural
se va traduce ntr-un sistem uor de implementat, testat i modificat.
Multitudinea sistemelor informatice distribuite implementate pn n prezent relev o
varietate mare a arhitecturilor, dar care pot totui fi ncadrate n cteva modele arhitecturale. Un
model arhitectural definete modul n care interacioneaz ntre ele componentele unui sistem,
precum i localizarea (maparea) lor ntr-o reea de calculatoare. Modelul arhitectural al unui
sistem distribuit are rolul de a simplifica i abstractiza (n sensul de a evidenia caracteristicile
eseniale ale sistemului) funciile componentelor sistemului. Apoi, el ia n considerare:
plasarea componentelor n cadrul reelei - cutnd s defineasc modelele corespunztoare de
distribuire a datelor i a prelucrrilor;
interaciunile dintre componente - adic, rolurile lor funcionale i modelele de comunicare
dintre ele.
Modelele de alocare a sarcinilor de lucru ntr-un sistem distribuit se reflect direct asupra
performanelor i eficacitatea sistemului rezultat. Localizarea componentelor unui sistem
distribuit este determinat de aspectele de performan, siguran n funcionare, securitate i
costurile implicate.

2.3. Arhitectura software

ntr-un sistem distribuit hardware-ul este important ns software-ul reprezint elementul

determinant; de componenta software depinde cum va arta un sistem distribuit. De aceea,
discuia noastr privind arhitectura sistemelor distribuite se va axa pe arhitectura software.
Iniial, prin arhitectura software se fcea referire la structurarea software-ului pe
niveluri sau module, cea mai cunoscut fiind structura ierarhic pe module. Recent, acelai
termen este descris n termenii serviciilor oferite i solicitate ntre procesele localizate pe acelai
calculator sau pe calculatoare diferite. Prin urmare, noua orientare, ctre procese i servicii, poate
fi exprimat prin intermediul nivelurilor de servicii. Ea este prezentat schematic n figura 2.1.
9
 Figura 2.1 Structura general a unui sistem distribuit
Dup cum se poate observa din figura 2.1, structura general a unui sistem distribuit
presupune trei niveluri (straturi): platforma, middleware i programele de aplicaii distribuite.
Fiecare nivel ofer servicii nivelului superior. Astfel, aplicaiile distribuite apeleaz la serviciile
oferite de componenta middleware care, la rndul su, beneficiaz de serviciile oferite de
sistemele de operare.

2.4. Platformele hardware i software n sistemele distribuite

Componenta hardware i nivelul cel mai de jos al software-ului sunt adesea referite
mpreun prin termenul platform. n practic ele pot fi referite separat prin platforma hardware
i platforma software. Acest nivel ofer servicii nivelurilor situate deasupra sa, servicii care sunt
implementate n mod independent pe fiecare calculator. El ofer interfaa de programare
nivelului care faciliteaz comunicarea i coordonarea dintre procese. Printre cele mai cunoscute
exemple de platforme se regsesc: Intel x86/Windows, Sun SPARC/SunOS, PowerPC/MacOS,
Intel x86/Linux.
Referindu-ne la arhitectura hardware, ea specific modul n care sunt conectate
calculatoarele, mai concret procesoarele. Orice sistem distribuit presupune existena a multiple
procesoare, dar care pot fi organizate n cteva moduri diferite n ce privete interconectarea i
comunicarea dintre ele. Dei n literatura de specialitate au fost prezentate numeroase scheme de
clasificare a sistemelor bazate pe multiple procesoare, nici una nu a primit o recunoatere larg.
n continuare vom face o succint prezentare a ctorva clasificri.
Din punctul de vedere al partajrii sau nu a memoriei, exist dou tipuri de sisteme:
multiprocesoare, respectiv cele n care mai multe procesoare partajeaz memoria, i multi

10
calculatoare, respectiv cele care nu o partajeaz. n cazul sistemelor multa-procesoare, toate
procesoarele partajeaz o singur zon fizic de memorie. Astfel, dac oricare procesor scrie
valoarea 44 la adresa 1000, atunci ulterior oricare alt procesor care va citi valoarea coninut la
adresa respectiv va prelua valoarea 44. n contrast, ntr-un sistem multi-calculatoare, fiecare
procesor dispune de propria memorie. Dac un procesor va scrie valoarea 44 la adresa 1000 a
propriei memorii, ulterior un alt procesor care va citi valoarea coninut la adresa 1000 va obine
probabil o alt valoare. Cel mai comun exemplu de sistem multi-calculatoare l reprezint o
colecie de calculatoare conectate la reea.
O alt clasificare grupeaz sistemele distribuite n sisteme eterogene i sisteme omogene.
Aceast clasificare este aplicat doar n cazul sistemelor multi-calculatoare. Intr-un sistem
omogen, toate procesoarele sunt la fel i, n general, acceseaz zone fizice de memorie diferite
dar de aceeai capacitate, iar n cadrul reelei se utilizeaz aceeai tehnologie. De regul, acest tip
de sisteme sunt utilizate mai mult ca sisteme paralele (adic lucreaz pentru aceeai problem).
n schimb, sistemele eterogene pot conine calculatoare de tipuri diferite, interconectate prin
reele de diferite tipuri. De exemplu, un sistem distribuit poate fi construit pe baza unei colecii
de reele locale care utilizeaz tehnologii diferite, ele putnd fi interconectate printr-un backbone
bazat pe tehnologia FDDI.
Atunci cnd vorbim despre platforma software, cel mai adesea se face referire la sistemul
de operare. De fapt, sistemele distribuite se aseamn n bun msur cu sistemele de operare
tradiionale. Ele gestioneaz resursele hardware permind mai multor utilizatori i aplicaii s le
partajeze. Prin resurse hardware se face referire la procesoare, memorie, echipamente periferice
i reea. De asemenea, sistemele distribuite ascund complexitatea i eterogenitatea resurselor
hardware.
Sistemele de operare pentru sistemele distribuite pot fi mprite n dou categorii:
sisteme strns-cuplate(tightly-coupled) i sisteme slab-cuplate (loosely-coupled). n cazul
sistemelor strns-cuplate, sistemul de operare ncearc s menin o singur imagine, global,
asupra resurselor hardware, n timp ce sistemele slab-cuplate pot fi vzute ca o colecie de
calculatoare, fiecare cu propriul sistem de operare, dar care colaboreaz.
Distincia ntre sistemele strns-cuplate i cele slab-cuplate este legat de clasificrile
prezentate anterior pentru componenta hardware. Astfel, sistemele strns-cuplate, referite i ca
sisteme de operare distribuite, sunt utilizate n sistemele multa-procesoare i sistemele
omogene. Principala sarcin a unui sistem distribuit rezid n ascunderea complexitii gestiunii
resurselor hardware astfel nct ele s poat fi partajate de multiple procese. n schimb, sistemele
11
slab-cuplate, referite adesea ca sisteme de operare de reea (NOS - Network Operating
System), sunt utilizate n cazul sistemelor eterogene. Distincia dintre un NOS i un sistem de
operare tradiional const n faptul c, pe lng gestiunea resurselor, el asigur disponibilitatea
serviciilor locale clienilor aflai la distan.
Majoritatea sistemelor distribuite sunt eterogene, deci utilizeaz un NOS. n aceast
situaie, sunt necesare unele servicii suplimentare celor oferite de NOS, care s asigure o mai
bun transparen a naturii distribuite a sistemului. Toate aceste servicii sunt grupate pe un nivel
intermediar numit middleware. El reprezint inima sistemelor distribuite moderne. Imaginai-v
lipsa acestui nivel n figura 2.1. ntr-o astfel de situaie, aplicaiile distribuite ar trebui s apeleze
direct la serviciile oferite de sistemele de operare pentru realizarea diferitelor sarcini (cum ar fi
transmiterea mesajelor), ceea ce ar presupune un efort suplimentar considerabil din partea
programatorilor, ntruct fiecare sistem de operare are implementri diferite ale aceluiai
serviciu. Asupra acestui nivel ne vom opri n paragraful urmtor. n tabelul 2.1 este prezentat o
comparaie ntre sistemele distribuite (DOS), sistemele de operare pentru reea (NOS) i
middleware.
Tabelul 2.1 Prezentare general i comparativ a DOS, NOS i middleware (sursa:
Tanenbaum, A., Distributed Systems. Principles and Paradigms, Prentice-Hall, Inc., Upper
Saddle River, New Jersey, 2002, p.23)
Sistemul Descriere Obiectivul principal
DOS Sisteme de operare strns-cuplate, utilizate n Ascunde complexitatea
sistemele multa-procesoare i sistemele multi- gestiunii resurselor hardware
calculatoare omogene
NOS Sisteme de operare slab-cuplate, utilizate n Ofer servicii locale
sistemele multi-calculatoare eterogene (LAN i clienilor aflai la distan
WAN)
Middleware Strat software adiional situat deasupra NOS- Furnizeaz transparena
ului i furnizeaz servicii generale distribuirii

Ultimul nivel al arhitecturii software conine aplicaiile specifice diferitelor domenii, care
apeleaz la serviciile oferite de middleware. Utilizatorii interacioneaz cu sistemul distribuit
prin intermediul acestor programe.
2.5. Nivelul middleware

Probabil c importana i rolul nivelului middleware este relativ clar n urma celor

12
prezentate n finalul paragrafului anterior. O definiie mai formal, consider middleware-ul ca
un nivel al software-ului al crui scop const n mascarea eterogenitii (platformei, s.n.) i
furnizarea unui model de programare comod dezvoltatorilor de aplicaii 2. El este format din
procese sau obiecte ce se regsesc pe un grup de calculatoare, i care interacioneaz ntre ele
pentru a asigura implementarea comunicrii i partajrii resurselor n aplicaiile distribuite.
Nivelul middleware sprijin comunicarea dintre programele de aplicaii prin intermediul unor
abstractizri" precum invocarea metodelor de la distan, comunicarea n cadrul unui grup de
procese, notificarea evenimentelor, replicarea datelor partajate i transmisia n timp real a datelor
mutimedia.
Unele aplicaii distribuite apeleaz direct la interfaa de programare furnizat de sistemul
de operare al reelei, ignornd nivelul middleware. Avantajul oferit de nivelul middleware const
n ascunderea eterogenitii platformelor pe care este implementat sistemul distribuit. De aceea,
majoritatea sistemelor middleware ofer o colecie de servicii mai mult sau mai puin complet,
descurajnd utilizarea altor interfee dect a celor ctre propriile servicii.
Pentru a simplifica dezvoltarea i integrarea aplicaiilor distribuite, majoritatea soluiilor
middleware se bazeaz pe un anumit model, care descrie aspectele privind distribuirea i
comunicarea. Cele mai utilizate astfel de modele sunt: apelarea procedurilor de la distan,
distribuirea obiectelor i distribuirea documentelor.
Apelarea procedurilor de la distan - RPC (Remote Procedure Calls). Unul dintre
primele modele middleware are la baz mecanismul RPC. n acest model, accentul este pus pe
ascunderea particularitilor comunicaiei n reea astfel nct s permit unui proces s apeleze o
procedur localizat pe un alt calculator. La apelarea unei astfel de proceduri, parametrii sunt
transmii n mod transparent calculatorului pe care este localizat procedura respectiv i pe care
ea va fi executat; rezultatele execuiei sunt transmise napoi procesului (procedurii) apelant(e).
n acest mod, se va crea impresia c procedura apelat este executat local; procesul apelant nu
are habar c este vorba de o comunicare n reea, cu excepia eventualei ntrzieri cu care
primete rezultatele. O soluie middleware care se bazeaz pe acest model este Sun RPC.
Distribuirea obiectelor. Lansarea modei orientate obiect" a avut efecte i asupra
soluiilor middleware. Att timp ct o procedur poate fi apelat de la distan, s-a pus problema
posibilitii invocrii obiectelor rezidente pe alte calculatoare ntr-o manier transparent. Astfel,
a aprut un nou model, care st la baza multor soluii middleware. n categoria soluiilor
middleware bazate pe distribuirea obiectelor se ncadreaz CORBA (Common Object Request
Broker Architecture) al OMG (Object Management Group), Java RMI (Java Remote Object
13
Invocation), DCOM (Distributed Component Object Model) al Microsoft i RM-ODP
(Reference Model for Open Distributed Processing) al ISO/ITU-T. Esena modelului bazat pe
distribuirea obiectelor const n faptul c fiecare obiect implementeaz o interfa care ascunde
detaliile interne ale obiectului fa de utilizatorii si (a se nelege de fapt programatori). Singurul
lucru pe care un proces l poate vedea la un obiect este interfaa sa. O interfa const n
metodele pe care obiectul le implementeaz.
De regul obiectele distribuite sunt implementate astfel nct fiecare obiect s fie localizat
pe un singur calculator i, n plus, interfaa sa s fie disponibil (vizibil) i pe alte calculatoare.
Invocarea unei metode de ctre un proces este transformat ntr-un mesaj care va fi transmis
obiectului n cauz (localizat pe alt calculator dect cel de pe care este iniiat procesul); obiectul
va executa metoda cerut i va transmite napoi rezultatele, tot sub form de mesaje; mesajul de
rspuns este transformat n valoare, ce va fi preluat i prelucrat corespunztor de procesul
invocat. Ca i n cazul mecanismului RPC, procesul apelant nu va fi contient de comunicaia
care a avut loc n reea.
Distribuirea documentelor. Succesul Web-ului se datoreaz n bun msur simplitii i
eficacitii modelului middleware bazat pe distribuirea documentelor. n acest model,
informaiile sunt organizate sub form de documente (care conin nu doar date de tip text, dar i
video, audio etc.), fiecare document fiind rezident pe un anumit calculator, localizarea sa fiind
transparent. Documentele pot conine link-uri ctre alte documente, iar prin intermediul unui
astfel de link documentul la care face referire poate fi descrcat de pe calculatorul pe care este
rezident i afiat pe ecranul utilizatorului.
Dup cum spuneam anterior, middleware-ul pune la dispoziie o serie de servicii care pot
fi utilizate de programele de aplicaii. De exemplu, standardul CORBA (Common Object
Request Broker Architecture) ofer o varietate de servicii prin intermediul crora furnizeaz
aplicaiilor o serie de faciliti, precum: atribuirea numelor, securitate, tranzacii, persistena,
notificarea evenimentelor. Serviciile cele mai comune oferite de majoritatea soluiilor
middleware sunt3:
- transparena accesului. Toate soluiile middleware acoper aceast cerin. Astfel de
servicii ofer faciliti de comunicare de nivel nalt care ascund modul n care are loc
transmiterea low-level" a mesajelor prin reelele de calculatoare. n acest fel, interfaa de
programare a nivelului de transport specific diferitelor sisteme de operare de reea este nlocuit
complet (de exemplu, nivelul transport n sistemul de operare Windows NT este implementat
prin protocolul TCP). Modul n care este asigurat suportul comunicrii difer foarte mult n
14
funcie de modelul de distribuire pe care o soluie middleware o ofer utilizatorilor i aplicaiilor.
Dup cum am vzut anterior, apelarea procedurilor de la distan sau invocarea obiectelor
distribuite reprezint astfel de modele. n plus, multe din soluiile middleware ofer faciliti nu
doar pentru transmiterea mesajelor, ci i pentru transparena accesrii datelor aflate la distan,
cum ar fi bazele de date distribuite. Un alt exemplu de comunicare de nivel nalt l reprezint
ncrcarea documentelor de pe web.
- utilizarea numelor (naming). n sistemele distribuite, numele sunt utilizate pentru
referirea unei mari varieti de resurse, precum calculatoare, servicii, obiecte i fiiere aflate la
distan, utilizatori. Utilizarea numelor faciliteaz partajarea i regsirea acestor entiti. De
exemplu, un URL reprezint numele atribuit unei pagini web i care va fi folosit pentru accesarea
ei. Procesele nu pot partaja o anumit resurs gestionat de un calculator dect dac i este
asociat un nume. De asemenea, utilizatorii nu vor putea comunica ntre ei n cadrul unui sistem
distribuit dect dac ei pot fi referii printr-un nume (de exemplu, adresele email). Acest serviciu
este comparabil cu o carte de telefoane sau arhicunoscutele pagini aurii. O limit specific
utilizrii numelor este legat de faptul c localizarea entitii care este referit prin nume trebuie
s fie fix. Aceast ipotez st la baza conceperii web-ului, de exemplu. Fiecare document are
atribuit un URL, acesta coninnd i numele serverului pe care este stocat documentul respectiv.
Dac se dorete mutarea documentului pe un alt server, atunci numele (URL-ul) nu mai este
valabil.
- Persistena. Multe din sistemele middleware ofer faciliti de stocare. n forma cea
mai simpl, persistena este asigurat prin intermediul unui sistem de fiiere distribuite. Soluiile
middleware mai avansate utilizeaz bazele de date sau ofer aplicaiilor faciliti de conectare la
baze de date.
- Tranzacii distribuite. Aceste servicii sunt utile n sistemele n care stocarea datelor
joac un rol important. O tranzacie reprezint o operaiune atomic efectuat asupra unei baze
de date (de exemplu, adugarea unei noi facturi). Tranzaciile distribuite opereaz asupra bazelor
de date rspndite pe mai multe servere. De aceea, n cazul lor sunt necesare unele servicii
suplimentare, cum ar fi ascunderea erorilor ivite n validarea sau anularea unei tranzacii. Asupra
mecanismului tranzacional, a tranzaciilor distribuite i a altor aspecte privind bazele de date
distribuite vom reveni pe larg n capitolul 3.
- Securitatea. Desigur c sistemele de operare ofer serviciile necesare asigurrii
securitii sistemului, la care aplicaiile pot apela. Spre deosebire de acestea, serviciile oferite de
middleware sunt universale, adic pot fi utilizate la nivelul ntregii reele de calculatoare, ceea ce
15
nu este valabil n cazul celor oferite de sistemul de operare care pot fi utilizate doar pe
calculatoarele respective i nu la nivelul ntregii reele. Prin urmare, serviciile de securitate sunt
implementate din nou n nivelul middleware (deasupra celor oferite de sistemele de operare).
Multe din sistemele distribuite moderne sunt construite ca middleware pentru o serie de
sisteme de operare. n acest fel, aplicaiile construite pentru un astfel de sistem distribuit vor fi
independente de sistemul de operare. Totui extinderea pe scar larg a sistemelor distribuite este
ncetinit tocmai de soluiile middleware, deoarece independena fa de sistemul de operare a
fost nlocuit cu o dependen puternic fa de o anumit soluie middleware. Prin urmare este
afectat una dintre caracteristicile eseniale ale sistemelor distribuite, prezentate n capitolul nti,
i anume caracterul lor deschis.
Explicaiile rezid n existena mai multor standarde dezvoltate de diferite organizaii ca
soluii middleware. De cele mai multe ori, aceste standarde sunt incompatibile ntre ele. Mai
mult, produsele diferiilor productori rareori interacioneaz corespunztor ntre ele, chiar dac
au implementat acelai standard. O astfel de situaie poate apare datorit incompletitudinei
definiiilor interfeei, care oblig programatorii s-i creeze propriile interfee (sau definiii). n
consecin, aplicaiile scrise de ei ar putea s nu fie portabile, dac dou echipe dezvolt propriile
sisteme middleware, chiar dac ambele echipe ader la acelai standard (incomplet).

2.6. Modele arhitecturale pentru sistemele distribuite

Dup cum artam n primul paragraf, una dintre activitile specifice dezvoltrii
sistemelor distribuite const n proiectarea arhitecturii sistemului, respectiv diviziunea
responsabilitilor ntre componentele sistemului i plasarea lor pe calculatoarele din reea. n
acest sens, exist mai multe modele arhitecturale.

2.6.1. Modelul client/server

Aceast arhitectur este de departe cea mai cunoscut i mai utilizat la dezvoltarea
sistemelor distribuite, fiind prezentat schematic n figura 2.2. n fapt, ea presupune mprirea
sarcinilor aplicaiei n procese client i procese server care interacioneaz ntre ele prin schimbul
de mesaje n vederea realizrii unei activiti. Acest model va fi discutat pe larg n paragraful
urmtor.

16
 Figura 2.2 Modul n care clientul invoc un server
2.6.2. Servicii furnizate de mai multe servere.

Conform acestei arhitecturi (vezi figura 2.3), serviciile pot fi implementate sub forma mai
multor procese server rezidente pe diferite calculatoare, care vor interaciona n funcie de
necesiti n vederea furnizrii serviciului cerut de un proces client. Setul de obiecte care st la
baza serviciului respectiv poate fi partiionat i distribuit pe mai multe servere. De asemenea,
este posibil ca mai multe servere s ntrein copii ale obiectelor respective (este vorba despre
replicare), cu scopul mbuntirii toleranei la erori, a performanelor de accesare i a
disponibilitii. De exemplu, serviciul web furnizat de altavista.digital.com este partiionat pe
mai multe servere care conin replici ale bazei de date.

2.6.3. Servere proxy i tehnica de caching.

Cache reprezint tehnica de stocare a obiectelor de date recent utilizate mai aproape de
locul de utilizare. Atunci cnd un obiect este recepionat de un calculator, el va fi adugat n zona
de stocare cache, nlocuind eventual alte obiecte care exist deja n cache. La solicitarea unui
obiect de ctre un proces client, serviciul de caching va cuta mai nti n cache pentru a pune la
dispoziie obiectul solicitat, numai dac exist o copie actualizat a acestuia; altfel, o copie
actualizat va fi ncrcat de pe server. Zonele cache pot fi dispuse pe fiecare client sau ele pot fi
localizate pe un server proxy partajat de mai muli clieni.

17
 Figura 2.3 Un serviciu furnizat de mai multe servere
Tehnica cache este utilizat pe scar larg n practic. Browserele Web ntrein pe fiecare
client un cache cu cele mai recente pagini Web vizitate i alte resurse Web. Ele utilizeaz o cerere
HTTP special pentru a verifica dac paginile din cache sunt corespunztoare cu cele originale
de pe server nainte de a le afia (este vorba de actualizarea lor). Serverele proxy Web (vezi
figura 2.4) ofer clienilor o zon de stocare cache partajabil ce conine resursele Web ale unui
singur site sau a mai multor site-uri. n acest mod, se obine o cretere a disponibilitii i
performanelor serviciilor Web prin reducerea ncrcrii reelei i a serverului Web.

Figura 2.4 Server proxy Web

18
 2.6.4. Procese perechi.

n aceast arhitectur toate procesele joac roluri similare, interacionnd n mod

colaborativ ca perechi n vederea realizrii unei activiti sau prelucrri distribuite, fr a se face
distincia ntre client i server. Codul corespunztor proceselor perechi va avea rolul de a menine
consistena resurselor de la nivelul aplicaiei i de a sincroniza aciunile de la nivelul aplicaiei
dac este necesar. n figura 2.5 este prezentat o astfel de arhitectur, format din trei procese
pereche, ns pot exista n procese care s interacioneze ntre ele.
Eliminarea proceselor server determin reducerea ntrzierilor aferente comunicrii inter-
procese pentru accesarea obiectelor locale. De exemplu, o aplicaie poate fi conceput astfel
nct s permit utilizatorilor s afieze i s modifice interactiv o schi (de exemplu schia unui
proiect pentru un autoturism realizat cu un program special, de exemplu AUTOCAD) care este
partajat. Aplicaia poate fi implementat sub forma unor procese aplicaie plasate pe fiecare nod
care se va baza pe straturile middleware pentru a realiza notificarea evenimentelor i
comunicarea n cadrul grupului pentru a ntiina toate procesele aplicaiei despre eventuala
modificare a schiei. Acest model ofer o comunicare interactiv mai bun (cu timpi de rspuns
mai buni) pentru utilizatorii unui obiect distribuit partajat dect n cazul unei arhitecturi bazate pe
server.

Figura 2.5 Aplicaie distribuit bazat pe procese perechi

19
2.7. Modelul client/server

2.7.1. Noiuni introductive

n general, puine sunt problemele legate de dezvoltarea sistemelor distribuite n care se

nregistreaz un consens n rndul specialitilor. Un aspect asupra cruia se nregistreaz un larg
consens n rndul cercettorilor i practicienilor privete organizarea componentelor unui sistem
distribuit prin folosirea termenilor client, care solicit servicii unui server, astfel nct s
faciliteze nelegerea i stpnirea complexitii sistemelor distribuite. Aadar, paradigma
client/server reprezint modelul arhitectural cel mai utilizat la dezvoltarea sistemelor distribuite.
Mult mai limitat, dar si mult mai utilizat este modelul client-server. Acesta presupune
existenta n reea a unor calculatoare mai puternice, numite servere, capabile sa realizeze anumite
activiti pe care staiile obinuite nu le pot efectua. n momentul n care o staie are nevoie de
rezultatele unei asemenea activiti, formuleaz o cerere ctre server, iar acesta i furnizeaz
datele cerute. Astfel, staia n cauza devine client pentru serverul respectiv. Noiunea de server nu
este foarte clar definita, putndu-se referi, n funcie de contextul n care este folosit, att la
calculatoare, ct i la programe; n general, un server este o entitate (hardware sau software) care
poate efectua anumite aciuni la cererea altor entiti (clieni) i le furnizeaz acestora rezultatele
obinute.
Sistemele client-server au de rezolvat o mare parte din problemele generale ntlnite la
sistemele distribuite. Ceea ce dispare este controlul centralizat asupra staiilor, precum i
asigurarea ncrcrii echilibrate. Comunicarea ntre server si client decurge n urmtoarele etape:
clientul formuleaz cererea, datele sunt convertite (tot de ctre client) la reprezentarea utilizata in
reea si trimise ctre server, serverul preia datele din reea si le convertete la formatul propriu se
analizeaz cererea i se realizeaz aciunile corespunztoare, rezultatele sunt convertite la
formatul reelei i trimise ctre client clientul preia rspunsul i l convertete la reprezentarea
proprie. Evident, modelul client-server nu exploateaz n ntregime posibilitile calculului
distribuit, dar este mult mai simplu de implementat i rspunde cerinelor n multe situaii. Cea
mai cunoscut materializare a acestui concept o reprezint severele Web.

20
 2.7.2. Definirea modelului client/server

Ideea subiacent conceptului client/server este serviciul. O aplicaie informatic

distribuit dezvoltat dup modelul client/server este descompus n dou grupuri de procese:
consumatorii de servicii, numii client i furnizorii de servicii, numii server, care comunic ntre
ele prin schimbul de mesaje de tip solicitare-rspuns (vezi figura 2.6). De exemplu, un server
poate fi conceput pentru a oferi un serviciu de baze de date clienilor si. Serverul este funcional
independent de client, iar relaia ntre client i server este de colaborare (cooperare). Ea se
difereniaz radical de aplicaiile centralizate, n care relaia este de tip "stpn-sclav"(master-
slave).
n modelul client/server, clientul solicit serverului execuia unui serviciu prin
transmiterea unui mesaj. La rndul su, serverul va transmite clientului rezultatul solicitrii sale.
Diferitele funcii ale aplicaiei informatice sunt regrupate sub forma programelor client i server,
fiecare cu roluri bine definite. Pentru utilizator totul este transparent, el comunicnd cu
programul client; schimbul de mesaje realizat ntre programele client i server i sunt
transparente, el percepnd aplicaia ca un ansamblu executat doar pe postul su de lucru.

Figura 2.6 Modelul general al interaciunii dintre client i server

Arhitectura client/server poate fi definit ca un model de dezvoltare a aplicaiilor conform

cruia sistemul informaional este descompus ntr-un mare numr de funcii server, executate pe
una sau mai multe platforme hardware, care furnizeaz servicii comune unui mare numr de
funcii client, executate pe una sau mai multe platforme hardware diferite dar interconectate, i
care realizeaz sarcini bine definite n legtur cu serviciile furnizate de funciile server.
Spre deosebire de cele prezentate pn acum, mai pot fi identificate dou situaii
distincte:

21
 - un server poate apela la serviciile furnizate de ctre un alt server, obinndu-se o relaie
client server pe mai multe straturi. n figura 2.7 este prezentat o astfel de relaie pe dou straturi.
Asupra relaiilor client-server pe mai multe straturi vom reveni n paragraful urmtor.
- programele client i server se pot gsi pe acelai calculator, un exemplu n acest sens
constituindu-l schimburile inter-aplicaii de tip DDE (Dynamic Data Exchange).

Figura 2.7 Relaii client/server pe dou niveluri

Din cele prezentate pn aici se poate clarifica relaia dintre sistemele distribuite i
sistemele client/server. Astfel, ntr-un sistem client/server nu este obligatoriu ca cele dou grupe
de funcii (client i server) s fie localizate pe calculatoare diferite, ele putnd fi rezidente pe
acelai calculator; de cele mai multe ori arhitectura client/server este implementat ntr-un sistem
distribuit. Pe de alt parte, un sistem distribuit nu implic neaprat arhitectura client/server.
Arhitectura cvasi-utilizat la dezvoltarea sistemelor distribuite este reprezentat de modelul
client/server ns, dup cum am vzut n paragraful 2.3, nu este singura alternativ. Aadar, dei
diferite conceptual, de cele mai multe ori n practica dezvoltrii sistemelor informaionale se
poate pune semnul de egalitate ntre sistemele distribuite i sistemele client/server. De aceea, pe
parcursul cursului cele dou noiuni vor fi utilizate interschimbabil cu acelai sens.

2.7.3. Arhitecturi client/server multistrat

Modelul client/server a constituit subiectul multor dezbateri i controverse. Problema

principal este legat de distincia clar dintre client i server. Proiectarea sistemelor client/server
presupune conceperea arhitecturii aplicaiilor pe straturi bine definite. O astfel de abordare
permite proiectarea independent a straturilor, singura grij constnd n definirea clar i
proiectarea atent a interfeelor, urmrindu-se ca:
fiecare strat s aib un domeniu bine definit, n sensul definirii foarte clare a sarcinilor i

22
responsabilitilor fiecrui strat;
fiecare strat trebuie s ndeplineasc o sarcin specific; dac, de ex., unul din straturi este
responsabil cu interaciunea cu utilizatorul, atunci numai acel strat va comunica cu utilizatorul,
celelalte straturi realiznd acest lucru prin intermediul acestui strat dac au nevoie de informaii
de la utilizator.
stabilirea unor protocoale bine definite pentru interaciunea dintre straturi, interaciune care s se
realizeze numai prin intermediul acestor protocoale.
O prim ncercare n acest sens a constituit-o mprirea aplicaiilor pe dou straturi,
rezultnd arhitectura cu dou straturi. Aceast arhitectur presupune descompunerea aplicaiei
n urmtoarele dou straturi:
- stratul corespunztor aplicaiei, n care se include interfaa grafic cu utilizatorul,
respectiv logica prezentrii, i implementarea regulilor de afaceri (business rules), respectiv
logica aplicaiei. Tot acest strat poate coordona i logica tranzaciei care garanteaz c
actualizrile n baza de date specifice unei tranzacii sunt terminate complet (validate sau
anulate).
- stratul corespunztor bazei de date, care este responsabil de meninerea integritii
bazei de date. n acest strat poate fi implementat ntreaga logic a tranzaciei sau o parte a ei.
Distincia dintre cele dou straturi nu este ntotdeauna bine definit deoarece logica
tranzaciei este adesea implementat pe server BD, sub forma procedurilor stocate, iar regulile
afacerilor, parte a logicii aplicaiei sunt de asemenea implementate pe server, sub forma trigger-
elor. n plus, sunt ntmpinate greuti considerabile n dezvoltarea sistemului informaional pe
baza creterii accentuate a numrului de aplicaii, a numrului i tipului serverelor de baze de
date. Aceast deficien poate fi rezolvat prin introducerea unui nivel suplimentar, care s
trateze regulile afacerii, rezultnd o arhitectur cu trei straturi.
Arhitectura cu trei straturi presupune mprirea aplicaiei n urmtoarele straturi:
- gestiunea interfeei utilizator (gestiunea prezentrii) - privete dialogul ntre
utilizatori i aplicaie, incluznd aici logica de prezentare a informaiei (ansamblul prelucrrilor
efectuate asupra datelor necesare afirii lor);
- logica aplicaiei - cuprinde ansamblul operaiilor de prelucrare specifice aplicaiei i
nlnuirea lor logic;
- gestiunea datelor - rezolv cererile de date, asigur integritatea datelor, emiterea
anumitor mesaje de alertare, precum i gestiunea fizic a datelor (adugri, modificri, tergeri).
n esen, arhitectura pe trei straturi difer de cea pe dou straturi prin separarea logicii
23
afacerii ntr-un strat distinct, localizat de regul pe un server de aplicaii care comunic strns cu
serverul de baze de date. Introducerea unui strat intermediar permite definirea i implementarea
regulilor afacerii independent de logica prezentrii interfeei GUI i a regulilor de proiectare a
bazei de date. Acest avantaj devine evident n condiiile n care regulile afacerii sunt supuse mai
des modificrilor, facilitnd astfel reimplementarea lor.
Dac cele trei straturi vor fi implementate pe calculatoare diferite, atunci vom avea
situaia n care un server va juca i rolul de client (vezi figura 2.7). O arhitectur pe trei straturi
este prezentat n figura 2.8. Se observ c programele care formeaz stratul logicii afacerii sunt
rezidente pe un server separat.

Figura 2.8 Arhitectura client pe trei straturi (serverul de aplicaie joac i rolul de client)
Un exemplu tipic de arhitectur pe trei straturi l reprezint modul de funcionare al unui motor
de cutare pe Internet, prezentat n figura 2.9

Figura 2.9 Modelul general de organizare pe trei straturi a unui motor de cutare pe Internet

24
 Interfaa (partea de front-end) permite utilizatorului s introduc expresia dup care
dorete s se efectueze cutarea i, ulterior, va afia o list cu titlurile de pagini Web care
corespund expresiei introduse. Partea de back-end va consta dintr-o imens baz de date cu
informaii despre paginile Web. ntre cele dou niveluri se afl "inima" motorului de cutare,
respectiv partea de logic a programului, care transform expresia introdus de utilizator prin
intermediul interfeei n una sau mai multe interogri ale bazei de date, dup care va ordona
rezultatele interogrilor ntr-o list, i pe care o va transforma ntr-o serie de pagini HTML.
Un alt exemplu de arhitectur pe trei straturi, este cel al unui sistem de asistare a deciziei
pentru gestiunea portofoliului de aciuni. Acest sistem poate fi de asemenea mprit pe trei
niveluri: partea front-end va implementa interfaa utilizator, partea back-end va asigura accesarea
bazei de date cu date financiare, iar partea de mijloc va conine programele de analiz financiar.
Analiza datelor financiare poate implica tehnici i metode sofisticate, de la cele statistice la cele
de inteligen artificial, motiv pentru care logica aplicaiei ar putea fi implementat pe un server
special, capabil s execute operaiuni de calcul complexe.
Printre avantajele unei arhitecturi client/server distribuit pe trei straturi enumerm :
-Reutilizare. Componentele dezvoltate pot fi construite astfel nct funcionalitatea lor s
fie partajate ntre mai multe aplicaii;
-Performan. Aplicaiile ruleaz ntr-un strat dedicat, bazat eventual pe resurse proprii i
tehnologii ale cror scop esenial este atingerea unei viteze de execuie superioare i a unei
scalabiliti superioare.
-Mentenan. ntreinerea i reinstalarea aplicaiilor sau a unor pri ale acesteia, n cazul
schimbrii regulilor afacerii, este mult simplificat prin administrarea separat, centralizat, a
componentelor lor.
-Suport multi-limbaj. Aplicaiile dezvoltate pe componente pot fi scrise n mai multe
limbaje de programare (VB, C++, C#, Java) i pot fi fcute interoperabile, chiar dac provin de
pe platforme diferite (.NET, J2EE).
-Scalabilitate i echilibrarea solicitrii resurselor. Componentele pot fi distribuite pe mai
multe servere, ceea ce permite ridicarea pragului de scalabilitate n condiiile pstrrii
parametrilor de performan i disponibilitate a aplicaiilor.
-Eficientizarea accesului la date. Serverele de baze de date nu vor mai fi solicitate de un
numr mare de cereri de acces, gestiunea cererilor clienilor revenind serverelor de aplicaii (deci
stratului intermediar). n acest mod, clienii nu mai sunt nevoii s se conecteze direct la baza de
date i, prin urmare, nu vor mai avea nevoie de drivere specifice (ca n cazul arhitecturii pe dou
25
straturi).
-mbuntirea securitii. Componentele din stratul intermediar pot fi gestionate din
punctul de vedere al securitii printr-o infrastructur centralizat comun, determinnd
simplificarea i reducerea costurilor de administrare.
n prezent se manifest tendina dezvoltrii aplicaiilor multistrat, n care pot exista mai
mult de trei straturi, att din punct de vedere logic, ct i fizic. Acest lucru este posibil datorit
apariiei unei noi paradigme n dezvoltarea sistemelor informaionale, referit prin sintagma
orientat pe componente. Aceast nou abordare, coroborat cu libertatea n distribuirea
componentelor datorit apariiei unor protocoale (API) de comunicare specifice, determin
orientarea ctre dezvoltarea de aplicaii client/server multistrat.

2.7.4. Clasificarea modelelor arhitecturale client/server

Proiectarea sistemelor informatice conform tehnologiei client/server trebuie s ia n

considerare diferitele tipuri de sisteme client/server. O clasificare a modelelor client/server a fost
propus de Gartner Group, pornind de la cele trei pri funcionale componente ale unei aplicaii.
Figura 2.10 arat cele cinci tipuri de arhitecturi regrupate sub numele client-server, fiecare fiind
pus n discuie n continuare.
Interfa (prezentare) distribuit urmrete dispunerea de faciliti grafice pe postul
client, motiv pentru care acest model mai este referit i prin "cosmetica aplicaiei". Concret, acest
model presupune adugarea unei interfee grafice evoluate la o aplicaie centralizat, rezident pe
un mainframe sau minicalculator, n vederea nlturrii dezavantajelor asociate interfeelor la
modul caracter specifice platformelor mari. Aplicaia central nu este modificat ci numai partea
de interfa a aplicaiei, adic acea parte care selecteaz datele provenite de la calculatorul
central i le afieaz ntr-un mediu grafic specific microcalculatoarelor.
Operaia de transformare a interfeei se poate face de-o manier mai simpl, fr alterarea
succesiunii ecranelor specifice aplicaiei originale (unui ecran n modul caracter i corespunde un
ecran n modul grafic) fie de-o manier mai "radical", n sensul modificrii succesiunii
dialogurilor i ecranelor utilizator specifice aplicaiei originale, ns tot fr a efectua vreo
modificare n programele aplicaiei (unui ecran n modul caracter i poate corespunde mai multe
ecrane n modul grafic, precum i invers).
Dei aduce unele mbuntiri aplicaiei, modelul interfa distribuit poate fi cu greu
ncadrat n arhitectura client/server, ntru-ct partea server a aplicaiei rmne semnificativ,
26
manifestndu-se o relaie de tip master-slave. i totui, acest model ofer unele avantaje legate
de:
ameliorarea calitii interfeei aplicaiei;
conservarea investiiilor anterioare efectuate pentru realizarea aplicaiei, deoarece programele
aplicaiei nu sunt modificate;
ofer o soluie intermediar n vederea trecerii la arhitectura client/server.
Dei o asemenea rezolvare rspunde cerinelor utilizatorilor n materie de interfa
grafic, ea nu poate reprezenta dect o soluie temporar, deoarece:
nu rezolv problemele de comunicare a datelor, generate de traficul intens de date din reea (la
datele aplicaiei care tranziteaz reeaua ntre client i server se adaug informaiile tehnice
legate de poziia cmpurilor n ecran, controale etc.)
nu ofer deloc (sau prea puin) performane noi, serverul asigurnd n continuare toate
prelucrrile aplicaiei.
Interfa (prezentare) izolat (deportat) n care gestiunea interfeei utilizator a aplicaiei
este rezident pe platforma client, platform ce asigur n ntregime gestionarea dialogului.
Terminalele X reprezint un exemplu de implementare a acestui model, ele oferind o mare
portabilitate a aplicaiilor i o independen total fa de productori de hard i soft, putnd lucra
uor cu platforme hard i software eterogene.

Figura 2.10 Clasificarea modelelor client/server conform Gartner Group

Acest model asigur urmtoarele avantaje:
27
 - mbuntete calitatea interfeei aplicaiei;
- conserv investiiile anterioare efectuate pentru realizarea aplicaiei prin separarea
strict a interfeei de prelucrrile aplicaiei (logica aplicaiei);
- determin reducerea substanial a costurilor, datorit preului redus al terminalelor X
i uurina ntreinerii acestora.
Totui, ca i n primul caz, nu ofer performane deosebite deoarece serverul asigur ansamblul
prelucrrilor ceea ce presupune o mare ncrcare a reelei. n plus, terminalele X sunt utilizate
doar n mediile UNIX.
Prelucrri distribuite, model care presupune repartizarea prelucrrilor aplicaiei ntre
client i server. Pe platforma client se regsete logica funcional de baz care apeleaz serverul
pentru executarea unor servicii externe prin lansarea unor cereri ce vor activa prelucrrile
localizate pe server, numite i proceduri. Apelarea procedurilor de pe server de ctre clieni se
poate face prin intermediul mecanismului RPC (Remote Program Call). Acest mecanism
permite, de exemplu, apelarea de ctre aplicaia client a procedurilor rezidente pe server care, la
rndul lor, pot conine una sau mai multe cereri SQL.
Adoptarea acestui model necesit stabilirea unor criterii clare de repartizare a
prelucrrilor, ceea ce complic procesul de proiectare a sistemelor informatice. Aceast problem
constituie una din dificultile dezvoltrii de aplicaii conforme acestui model, deoarece
rezolvarea ei necesit o bun cunoatere a echipamentelor i programelor pe care va fi
implementat aplicaia, precum i o mare experien n dezvoltarea unor astfel de aplicaii. n
general, se consider c, cu ct numrul de cereri de accesare a datelor specifice unei proceduri
este mai mare i cu ct procedura este mai complex, cu att mai mult se justific localizarea
acelei proceduri pe server. De ce? Prelucrrile sunt mai aproape de locul fizic de stocare a
datelor, iar prin reea vor tranzita numai cererile de apel de la distan a procedurilor, nu i datele.
Avantajele principale ale modelului bazat pe prelucrri distribuite constau n reducerea
traficului prin reea i o repartizare echilibrat a prelucrrilor ntre client i server. n schimb,
dup cum am mai spus, dezvoltarea unor asemenea aplicaii este dificil datorit cunotinelor
numeroase i a experienei solicitate.
Un exemplu de adoptare a acestui model l reprezint aplicaiile care dispun de formulare
pentru culegerea datelor i care implementeaz diferite operaiuni de prelucrare i verificare a
datelor n cadrul formularelor, pentru a fi transmise datele ctre server ntr-o form consistent.
n acest fel, dialogul interactiv dintre utilizator i aplicaie (n cazul apariiei unor erori de
culegere, de exemplu) este localizat pe platforma client, reducnd astfel costurile i ntrzierile
28
specifice comunicaiilor.
Gestiunea izolat (deportat) a datelor, n care platforma client asigur att gestionarea
dialogului ct i logica aplicaiei, iar serverul asigur doar gestionarea datelor. n acest caz se
realizeaz o repartizare clar a funciilor ntre client i server i se asigur o securitate sporit a
datelor. Aplicaia client transmite cererile sale de date serverului, iar acesta din urm transmite
napoi datele cerute. Toate prelucrrile asupra datelor, specifice aplicaiei, sunt efectuate pe
platforma client.
Dezvoltarea aplicaiilor conform acestui model este facilitat nu numai de repartizarea
clar a funciilor ntre client i server ci i de oferta bogat de produse mature, cum ar fi SGBDR-
urile. Astzi, SGBDR-urile asigur i controlul integritii datelor din BD, ceea ce reprezint o
facilitate foarte important ntr-un mediu client/server n care mai multe aplicaii client pot
modifica aceste date. Localizarea controlului integritii datelor n acelai loc n care se afl
datele (pe server) permite consultarea i actualizarea datelor de ctre oricare din aplicaiile client
n deplin siguran, precum i reducerea traficului de reea (cererile privind controlul integritii
numai tranziteaz reeaua, ca n cazul n care controlul integritii ar fi localizat pe platforma
client). Introducerea trigger-elor n SGBDR-uri faciliteaz controlul integritii BD i gestiunea
datelor independent de aplicaiile client.
Modelul gestiunea izolat a datelor se difereniaz de sistemele bazate pe simpla partajare
a fiierelor de date, n care pe server sunt stocate numai datele n timp ce serviciile de gestionare
a datelor sunt rezidente pe client. Desigur c, n acest caz, traficul n reea este mult mai mare.
Din cele prezentate anterior se pot desprinde urmtoarele avantaje ale acestui model:
este mai uor de neles deoarece funciile aplicaiei sunt clar repartizate ntre client i
server;
garanteaz o securitate i consistena mai bun a datelor;
exist o ofert variat de produse bine maturizate.
ntre dezavantajele asociate pot fi enumerate:
nu este adaptat mediilor tranzacionale intensive; dei SGBDR-urile asigur accesul
concurent la date, ele nu suport dect un numr limitat de utilizatori (cteva sute), caz n care se
face apel la mainile tranzacionale, care au rolul de server frontal al SGBDR.
traficul n reea este mai mare dect n cazul modelului bazat pe distribuirea
prelucrrilor.
Gestiunea distribuit a datelor presupune repartizarea datelor ntre client i unul sau mai
multe
29
servere. Datele repartizate vor fi gestionate ca un ansamblu logic, fiind numai fizic distribuite.
Postul client devine el nsui server de date i se creeaz legturi de tip server-server care, de cele
mai multe ori presupune o gestiune a datelor ntr-un mediu eterogen (calculatoare, sisteme de
operare, reele sau
SGBD-uri diferite).
Acest model reprezint n teorie modelul ideal de distribuire deoarece permite
combinarea datelor ntr-o manier avantajoas att pentru unitate (coerena sistemului prin
globalizarea resurselor eterogene) ct i pentru utilizatori (sunt mai aproape de date, iar
prelucrrile datelor sunt mai rapide). Cu toate c asigur coerena global a sistemului, n
condiiile existenei unor resurse eterogene, i ofer performane sporite, implementarea acestui
model este deosebit de complex, fie i numai pentru c o cerere SQL trebuie analizat i
rezolvat la nivel global, iar pentru consistena datelor trebuie implementate mecanisme n dou
sau mai multe faze. La aceast complexitate se adaug i oferta (nc) limitat privind arsenalul
de produse necesare pentru implementarea unui asemenea model.
n practic, arhitectura client/server a unei aplicaii poate combina mai multe din cele
cinci modele prezentate anterior. O asemenea arhitectur poate rezulta prin distribuirea att a
datelor ct i a prelucrrilor.

2.7.5. Variaiuni pe aceeai tem: client/server

Dincolo de variantele clasice ale modelului client/server, prezentate anterior, mai pot fi
imaginate altele, rezultate prin combinarea facilitilor tehnologice existente cu cerinele
utilizatorilor i obiectivele urmrite n dezvoltarea sistemelor distribuite. Cteva dintre aceste
variante le vom prezenta n continuare.
Programe mobile (mobile cod). Applet-urile reprezint cele mai cunoscute i utilizate
programe mobile. Prin intermediul unui browser (Internet Explorer), un utilizator poate selecta
un link ctre un applet al crui cod este stocat pe un server web; codul (programul) este ncrcat
(download) pe calculatorul utilizatorului unde va fi i executat (vezi figura 2.11). Avantajul
executrii locale a programului const n mbuntirea comunicrii interactive (reducerea
timpului de rspuns), att timp ct ea nu mai nregistreaz ntrzierile inerente comunicrii n
reea.

30
 Figura 2.11 Utilizarea applet-urilor Web
Accesarea unui serviciu presupune lansarea n execuie a unui program care va invoca
operaiile acestuia (ale serviciului). Chiar dac multe din servicii sunt standardizate pentru a
putea fi accesate prin intermediul unor aplicaii arhi-cunoscute (web-ul este un exemplu n acest
sens), totui unele site-uri web utilizeaz anumite funciuni care nu sunt regsite n browser-ele
standard. n aceast situaie este necesar ncrcarea unor programe adiionale. De exemplu, un
astfel de program poate asigura comunicarea cu serverul atunci cnd o aplicaie solicit punerea
la curent a utilizatorului cu modificrile informaiilor stocate pe server, imediat ce ele apar. Acest
lucru nu poate fi realizat prin intermediul interaciunilor obinuite cu server-ul web, care sunt
iniiate de client (clientul nu ar ti cnd s iniieze comunicarea). Ar trebui ca interaciunea dintre
client i server s poat fi iniiat de server (atunci cnd au loc modificri ale informaiilor),
problem ce poate fi rezolvat tocmai prin ncrcarea unui program adiional pe platforma client.
Un exemplu concret: un broker ar putea oferi un serviciu personalizat pentru a ntiina
clienii despre schimbarea preurilor aciunilor pe pia; pentru a beneficia de acest serviciu,
fiecare client va trebui s ncarce un applet special care s preia actualizrile preurilor de pe
serverul brokeru-lui, s le afieze i, eventual, s execute cumprri sau vnzri automate n
funcie de condiiile stabilite de client i care sunt stocate pe calculatorul su. Totui, nu trebuie
s ne entuziasmm prea mult n ce privete utilizarea applet-urilor i s nu ignorm problemele
de securitate care pot apare la calculatorul destinaie. De aceea, browser-ele ofer applet-urilor
un acces limitat la resursele locale (ale calculatorului destinaie).
Agenii mobili.Un agent mobil reprezint o aplicaie (include att programul ct i
datele) care cltorete" n reea de la un calculator la altul pentru a realiza o sarcin n numele
cuiva, cum ar fi colectarea informaiilor i, eventual, returnarea rezultatelor. n acest scop, un
agent mobil poate face numeroase invocri ale resurselor locale ale fiecrui nod pe care l
viziteaz (de exemplu accesarea unei baze de date locale). O astfel de problem ar putea fi
rezolvat de un client static, care ar putea invoca resursele necesare de la distan, dar care ar
presupune un volum mare de date de transferat (prin urmare costuri mari de comunicaie i

31
ntrzieri n realizarea sarcinii respective). n cazul arhitecturii bazate pe ageni mobili, invocarea
resurselor de pe alte calculatoare (noduri) ale reelei nu se face de la distan, ci chiar invocarea
este iniiat la distan.
Agenii mobili pot fi utilizai la instalarea i ntreinerea aplicaiilor de pe calculatoarele
unei organizaii sau pentru compararea preurilor diferiilor productori pentru un anumit produs,
prin vizitarea site-urilor fiecrui productor i efectuarea unor operaiuni de interogare a bazei de
date.
Problema securitii este i mai acut dect n cazul applet-urilor. Un agent mobil poate
reprezenta o ameninare pentru reursele calculatoarelor pe care le viziteaz (de exemplu baza de
date). n cazul utilizrii lor, calculatorul care i primete n vizit" trebuie s decid asupra
resurselor care le vor fi disponibile, n funcie de ientitatea utilizatorului n numele cruia
acioneaz agentul. Prin urmare, identitatea utilizatorului trebuie s fie inclus, de o manier
securizat, n agent, alturi de program i datele sale.
Network computers (NC). Aceste tipuri de calculatoare au fost introduse ca rspuns la
problema gestiunii fiierelor din aplicaii i a ntreinerii diferitelor programe locale. Ele solicit
un efort i cunotine tehnice pe care de cele mai multe ori utilizatorii nu le au. De asemenea, ele
sunt mai ieftine ntruct dispun de resurse mai reduse fa de un PC; capacitatea procesorului i a
memoriei pot fi mai reduse. NC-urile ncarc sistemul de operare i programele de aplicaii
necesare utilizatorilor de pe un server. n acest mod, aplicaiile vor rula local, ns vor fi
gestionate i ntreinute centralizat, pe server. Un alt avantaj al utilizrii NC-urilor const n
faptul c utilizatorul se va putea deplasa i lucra pe orice calculator din reea, att timp ct
programele de aplicaii i datele sunt rezidente pe server. n cazul n care NC-ul dispune de un
harddisc, pe el va fi stocat doar un minim de aplicaii, iar partea de disc rmas disponibil va fi
utilizat ca loc de stocare de tip cache (n care vor fi memorate programele de aplicaii i datele
care au fost accesate i ncrcate de pe server recent). n ciuda acestor avantaje, tehnologia NC
nu a reprezentat un succes comercial.
Client slbnog (thin client). n aceast arhitectur, pe calculatorul utilizatorului este
disponibil o interfa bazat pe ferestre prin care acesta poate executa anumite programe de
aplicaii pe un alt calculator. Acest model ofer acelai avantaje ca n cazul NC-urilor, numai c
el nu ncarc programele necesare de pe un server pentru a le executa local, ci le execut chiar pe
serverul pe care programele sunt rezidente. Bineneles, serverul trebuie s fie un calculator cu
capacitate mare de prelucrare i s permit execuia simultan a numeroase aplicaii. De regul,
el va avea mai multe procesoare i va rula o versiune a sistemului de operare UNIX sau
32
Windows NT. Acest tip de calculator poate fi utilizat n aplicaiile interactive precum CAD
(Computer Aidded Design) sau prelucrarea imaginilor, atunci cnd ntrzierile aferente
comunicrii prin reea sunt compesate de nevoia de a lucra n echip. Astfel de implementri
sunt: sistemul X-11 pentru UNIX, sistemul Teleporting and Virtual Network Computer (VNC)
dezvoltat la laboratoarele AT&T din Cambridge.
Echipamentele mobile i reeaua spontan. Lumea de astzi este invadat de
dispozitivele de calcul portabile, precum laptop-urile, PDA-urile, telefoanele mobile, camerele
de luat vederi digitale etc. Multe dintre aceste echipamente pot fi conectate ntr-o reea fr fir,
iar prin integrarea lor ntr-un sistem distribuit se poate pune la dispoziia utilizatorilor o putere de
calcul mobil. Modalitatea de distribuire care integreaz echipamentele mobile i cele ne-mobile
ntr-o reea dat poate fi referit prin termenul reea spontan. El este utilizat pentru descrierea
aplicaiilor care implic conectarea dispozitivelor mobile i a celor ne-mobile n reea ntr-o
manier mai informal dect a fost posibil pn n prezent. Este evident sprijinul pe care-l ofer
n dezvoltarea afacerilor mobile.

33
3. WORLD WIDE WEB ca Sistem distribuit

3.1. Noiuni introductive

O aplicaie Web reprezint o colecie de tehnologii cu dezvoltarea aplicaiilor de partea

server-ului pentru generarea dinamica a coninutului informatic accesat de obicei prin
intermediul unui browser Web de partea clientului.
Web-ul este un context arhitectural pentru accesul la documente, rspndite pe mii de
maini din Internet, ntre care exist legturi. n 10 ani a evoluat de la o aplicaie pentru
transmiterea de date utile pentru fizica energiilor nalte la o aplicaie despre care milioane de
oameni cred c este Internetul. Popularitatea sa enorm se datoreaz faptului c are o interfa
grafic plin de culoare, uor de utilizat de ctre nceptori i n acelai timp ofer o cantitate
imens de informaie - de la animale mitologice la tribul Zulu. pe aproape orice subiect posibil.
Propunerea iniial pentru crearea unei colecii de documente avnd legturi ntre ele
(Web) a fost fcut de fizicianul Tim Berners-Lee, fizician la CERN, n martie 1989. Primul
prototip (bazat pe text) era operaional 18 luni mai trziu. n decembrie 1991, s-a fcut o
demonstraie public la conferina Hypcrtcx'91 n San Antonio, Texas.
Aceast demonstraie i publicitatea aferent au atras atenia altor cercettori, fapt care 1-
a determinat pc Marc Andreessen de la University of Ilinois s nceap s dezvolte primul
program de navigare grafic, Mosaic. Acesta a fost lansat n februarie 1993. Mosaic a fost att dc
popular nct un an mai trziu Marc Andreessen a plecat pentru a forma o nou companie,
Netscape Communications Corp., care se ocupa cu dezvoltarea de software pentru Web.
n 1994, CERN i M.I.T. au semnat o nelegere pentru a forma Consoriul World Wide
Web (cteodat abreviat ca W3C), o organizaie care are ca obiectiv dezvoltarea Web-ului,
standardizarea protocoalelor, i ncurajarea interoperabilitii ntre situri. Bcrners-Lec a devenit
director. De atunci, sute de universiti i companii au intrat n consoriu. M.I.T. coordoneaz
partea american a consoriului n timp ce centrul de cercetri francez, INRIA, coordoneaz
partea european. Dei exist foarte multe cri despre Web, cel mai bun loc pentru gsirea unor
informaii la zi despre el este (n mod natural) chiar Web-ul. Pagina consoriului are adresa
www.w3.org . Cititorii interesai vor gsi acolo legturi la pagini care acoper toate documentele
i activitile consoriului.

34
3.2. Aspecte arhitecturale

Din punctul de vedere al utilizatorului, Web-ul const dintr-o colecie imeas de

documente sau pagini de Web (Web pages), adesea numite prescurtat pagini, rspndite n toat
lumea. Fiecare pagin poate s conin legturi (indicatori) la alte pagini, aflate oriunde n lume.
Utilizatorii pot s aleag o legtur prin execuia unui clic care i va aduce la pagina indicat de
legtur. Acest proces se poate repeta la nesfrit.
Paginile pot s fie vzute cu ajutorul unui program de navigare (browser). Internet
Explorer i Netscape Navigator sunt cele mai cunoscute programe de navigare. Programul de
navigare aduce pagina cerut, interpreteaz textul i comenzile de formatare coninute n text i
afieaz pagina, formatat corespunztor, pe ecran. Ca majoritatea paginilor de Web, ncepe cu
un titlu, conine informaii i se termin cu adresa de pot electronic a celui care menine
pagina. irurile de caractere care reprezint legturi la alte pagini, se numesc hiper-legturi, sunt
afiate n mod diferit, fiind subliniate i/sau colorate cu o culoare special. Pentru a selecta o
legtur, utilizatorul va plasa cursorul pe zona respectiv, ceea ce va determina schimbarea
formei cursorului i va executa un clic.
Modelul de baz al funcionrii Web-ului este artat n Figura 3-1. Aici un program de
navigare afieaz o pagin de Web pe maina clientului. Atunci cnd utilizatorul face clic pe linia
de text ce indic spre o pagin de pe serverul abcd.com, programul de navigare urmeaz hiper-
legtura trimind un mesaj serverului abcd.com n care se cere pagina respectiv. Atunci cnd
pagina sosete, ea este afiat. Dac aceast pagin conine o hiper-legtur ctre o pagin de pe
serverul xyz.com pe care utilizatorul face clic, programul de navigare trimite o cerere mainii
respective pentru acea pagin, i aa mai departe la nesfrit.
S examinm acum n detaliu aspectele ce privesc clientul din Figura 3-1. n esen, un
program de navigare este o aplicaie capabil s afieze o pagin de Web i s capteze clicurile
mouse-ului pe elemente ale paginii afiate. Cnd un element este selectat, programul de navigare
urmeaz hiper-legtura i obine pagina selectat. Ca atare, hiper-legtura coninut n pagin
necesit o modalitate de a adresa prin nume orice alt pagin de pe Web. Paginile sunt adresate
prin nume folosind URL-uri (Uniform Resource Locators, rom.: Localizatoare Uniforme de
Resurse). Un URL tipic este:
http://www.abcd.com/products.html.

35
 Figura 3.1. Prile componente ale modelului Web-ului
Aspecte privind clientul
Vom explica ce nseamn URL mai trziu, n cadrul capitolului curent. Deocamdat, este sufici-
ent s tim c un URL are trei pri: numele protocolului (http), numele calculatorului pe care se
gsete pagina (www.abcd.com) i numele fiierului care conine pagina (products.html).
Cnd un utilizator execut un clic pe o hiper-legtur, programul de navigare urmeaz o
serie de etape pentru a obine pagina indicat de hiper-legtur. S presupunem ca utilizatorul
navigheaz pe Web i gsete o legtura despre telefonia pe Internet care indic spre pagina
principal a ITU, http://www.itu.org/home/index.html. S urmm etapele parcurse cnd aceast
legtur este selectat.
1. Programul de navigare determin URL (pe baza seleciei).
2. Programul de navigare ntreab DNS care este adresa IP pentru www.itu.org.
3. DNS rspunde cu 156.106.192.32.
4. Programul de navigare realizeaz conexiunea TCP cu portul 80 al 156.106.192.32.
5. Trimite o cerere pentru fiierul /home/index.html
6. Serverul www.itu.org transmite fiierul /home/index.html.
7. Conexiunea TCP este eliberat.
8. Programul de navigare afieaz textul din /home/index.html.
9. Programul de navigare aduce i afieaz toate imaginile din acest fiier.
Multe programe de navigare informeaz despre etapa care se execut ntr-o fereastr de

36
stare, n partea de jos a paginii. n acest mod, dac performanele sunt slabe, utilizatorul poate s
tie dac este vorba de faptul c DNS nu rspunde, c serverul nu rspunde, sau pur i simplu de
congestia reelei n timpul transmisiei paginii.
Pentru a afia noua pagin (sau orice pagin), programul de navigare trebuie s neleag
forma n care este scris. Pentru a permite tuturor programelor de navigare s neleag orice
pagin de Web, paginile de Web sunt scrise ntr-un limbaj standardizat numit HTML, care
descrie paginile de Web. Vom discuta acest limbaj mai trziu n acest capitol.
Dei un program de navigare este n principiu un interpretor de HTML, majoritatea
programelor de navigare au numeroase butoane i opiuni care ajut navigarea prin Web. Multe
au un buton pentru revenirea la pagina anterioar, un buton pentru a merge la pagina urmtoare
(acest buton este operaional numai dup ce utilizatorul s-a ntors napoi dintr-o pagin) i un
buton pentru selecia paginii personale (home page). Majoritatea programelor de navigare au un
bulon sau un meniu pentru nregistrarea unei adrese de pagin (bookmark) i un altul care
permite afiarea unor adrese nregistrate, fcnd astfel posibil revenirea la o pagin cu ajutorul
ctorva selecii simple realizate cu mausul. Paginile pot s fie salvate pe disc sau tiprite. Sunt
disponibile numeroase opiuni pentru controlul ecranului i configurarea programului dc
navigare conform dorinelor utilizatorului.
n afar de text obinuit (nesubliniat) i hipertext (subliniat), paginile de Web pot s
conin iconie, desene, hri, fotografii. Fiecare dintre acestea poate s fie, n mod opional,
legat la alt pagin. Dac se selecteaz unul dintre aceste elemente, programul de navigare va
aduce pagina respectiv i o va afia, aa cum se ntmpl n cazul selectrii unui text. Pentru
imaginile care sunt fotografii sau hri, alegerea paginii care se aduce poate s depind de
regiunea din imagine pe care se face selecia.
Nu toate paginile conin HTML. O pagin poate fi format dintr-un document n format
PDF, o iconi n format GlF, o fotografie n format JPEG, o melodie n format MP3, o
nregistrare video n format MPEG sau oricare din cele alte cteva sute de tipuri de fiiere.
Deoarece paginile n forma standard HTML pot avea legturi ctre oricare din acestea,
programul de navigare are o problem atunci cnd ntlnete o pagin pe care nu o poate
interpreta.
n loc sa fac programele de navigare din ce n ce mai mari, nglobnd interpretoare
pentru o colecie de tipuri de fiiere n cretere rapid, majoritatea programelor de navigare au
ales o soluie mai general. Atunci cnd un server ntoarce o pagin, el ntoarce de asemenea
informaii adiionale despre acea pagin. Aceast informaie include tipul MIME al paginii.
37
Paginile de tipul text/html sunt afiate direct, ca i paginile de alte cteva tipuri interpretate
implicit. Dac tipul MIME nu este unul dintre acestea, programul de navigare i consult tabela
de tipuri MIME pentru a afla cum s afieze pagina. Aceast tabel asociaz un tip MIME cu o
aplicaie de vizualizare.

Figura 3.2. (a) Un plug-in al programului de navigare, (b) O aplicaie auxiliar

Exist dou posibiliti: plug-in-uri i programe auxiliare (helper applications). Un plug-
in este un modul pe care programul de navigare l obine dintr-un director special de pe disc i l
instaleaz ca o extensie al nsui programului de navigare, aa cum se arat n Figura 3.2(a).
Deoarece plug-in-urile se execut n interiorul programului de navigare, acestea au acces la
pagina curent i pot s modifice modul n care aceasta este afiat. Dup ce plug-in-ul a
terminat ceea ce avea de fcut (de obicei dup ce utilizatorul s-a deplasat la alt pagin de Web),
acesta este scos din memoria programului de navigare.
Fiecare program de navigare are o colecie de proceduri pe care toate plug-in-urile trebuie
s le implementeze pentru ca programul de navigare s poat executa plug-in-ul. De exemplu,
exist de obicei o procedur pe care modulul principal al programului de navigare o apeleaz
pentru a oferi plug-in-ului date ce trebuie afiate. Aceast colecie de proceduri constituie
interfaa unui plug-in i este particular fiecrui program de navigare.
n plus, programul de navigare pune la dispoziia plug-in-ului propria sa colecie de
proceduri. Procedurile tipice din interfaa programului de navigare se refer la alocarea i
eliberarea memoriei, afiarea de mesaje n fereastra de stare a programului de navigare sau
obinerea parametrilor acestuia.
nainte ca un plug-in s poat fi folosit, acesta trebuie instalat. Procedura uzual de
instalare este ca utilizatorul s navigheze la situl de Web al plug-in-ului i s copieze un fiier de
instalare. Pe sistemele Windows, acesta este de obicei o arhiv zip cu decompresie automat cu
extensia .exe. Cnd pe acest fiier se execut un dublu clic, se execut un program de mici
dimensiuni ataat prii de nceput a fiierului. Acest program decomprim plug-in-ul i l

38
copiaz n directorul de plug-in-uri al programului de navigare. Apoi execut apelurile necesare
pentru nregistrarea tipului MIME corespunztor i asocierea acestuia cu plug-in-ul. Pe sistemele
UNIX, fiierul de instalare este in mod frecvent un fiier de comenzi care se ocup de copiere i
nregistrare.
Cea de-a doua modalitate de extindere a unui program de navigare este utilizarea
aplicaiilor auxiliare (helper applications). Acestea sunt programe complete ce se execut ca
procese separate. Acest fapt este ilustrat n Figura 3.2 (b). Deoarece acestea sunt programe
separate, nu ofer nici o interfa programului de navigare i nu utilizeaz serviciile acestuia. De
obicei ns accept doar numele unui fiier temporar unde a fost stocat coninutul paginii,
deschide acest fiier i i afieaz coninutul. De obicei, aplicaiile auxiliare sunt programe de
dimensiuni mari care exist independent de programul de navigare, cum ar fi Adobe Acrobat
Reader pentru afiarea fiierelor PDF, sau Microsoft Word. Unele programe (cum ar fi Acrobat)
dispun de un plug-in care execut aplicaia auxiliar.
Multe aplicaii auxiliare folosesc tipul MIME appIication. A fost definit un numr
considerabil de subtipuri, de exemplu application/pdf pentru fiiere PDF i application/msword
pentru fiiere Word. n acest mod, un URL poate s indice direct ctre un fiier PDF sau Word i
atunci cnd utilizatorul execut un clic asupra sa aplicaiile Acrobat sau Word sunt pornite
automat i li se transmite numele fiierului temporar ce conine datele ce trebuie afiate. Ca atare,
programele de navigare pot fi configurate s trateze un numr teoretic nelimitat de tipuri de
documente, fr schimbri aduse programului de navigare. Serverele de Web moderne sunt
adesea configurate cu sute de combinaii de tipuri/subtipuri i combinaii noi sunt adugate de
fiecare dat cnd este instalat un program nou.
Aplicaiile auxiliare nu sunt restricionate la utilizarea tipului MIME application. Adobe
Photoshop folosete image/x-photoshop i RealOne Player poate trata de exemplu audio/mp3.
Pe sistemele Windows, atunci cnd un program este instalat pe un calculator, el
nregistreaz tipurile MIME pe care dorete s ie trateze. Acest mecanism conduce la conflicte
atunci cnd mai multe aplicaii sunt disponibile pentru vizualizarea unui subtip, cum ar fi
video/mpg. Ceea ce se ntmpl este c ultimul program ce se nregistreaz supranscrie
asociaiile existente (tip MIME, aplicaie auxiliar), captnd tipul pentru sine. Ca o consecin,
instalarea unui nou program poate schimba modul n care un program de navigare trateaz
tipurile existente.
Pe sistemele UNIX. acest proces de nregistrare nu se face n general automat.
Utilizatorul trebuie s schimbe anumite fiiere de configurare. Aceast abordare conduce la un
39
volum mai mare de munc dar la surprize mai puine.
Programele de navigare pot de asemenea deschide fiiere locale n loc de a le obine de pe
servere de Web de la distan. Deoarece fiierele locale nu au tipuri MIME, programul de
navigare necesit o metod pentru a determina ce plug-in sau aplicaie auxiliar trebuie folosit
pentru alte tipuri dect cele tratate implicit ca text/html sau image/jpeg. Pentru tratarea fiierelor
locale, aplicaiile auxiliare pot fi asociate i cu o extensie de fiier, ca i cu un tip MIME.
Considernd configuraia standard, deschiderea fiierului foo.pdf l va ncrca n Acrobat i
deschiderea fiierului bar.doc l va ncrca n Word. Anumite programe de navigare folosesc tipul
MIME, extensia fiierului i chiar informaii din interiorul fiierului pentru a ghici tipul MIME.
In special Internet Explorer se bazeaz n primul rnd pe extensia fiierului dect pe tipul MIME
atunci cnd acest lucru este posibil.
i aici pot apare conflicte deoarece multe programe sunt dispuse, de fapt dornice s
trateze mpg, de exemplu. n timpul instalrii, programele create pentru profesioniti afieaz
frecvent csue de selecie pentru tipurile MIME i extensiile pe care sunt pregtite s le trateze
pentru a permite utilizatorului selecia celor dorite pentru a preveni astfel supranscricrea
accidental a asociaiilor existente. Programele ce au ca int marea mas a consumatorilor
presupun c utilizatorul nu tie ce este un tip MIME i pur i simplu acapareaz tot ce pot fr s
in seama de ceea ce au fcut programele instalate anterior.
Capacitatea de a extinde programul de navigare cu un numr mare de tipuri noi este util,
dar poate duce i la probleme. Atunci cnd Internet Explorer obine un fiier cu extensia exe i
d seama c acest fiier este un program executabil i ca atare nu are o aplicaie adiional
asociat. Aciunea evident este execuia fiierului. nsa aceast aciune poate fi o problem dc
securitate enorm. Tot ceea ce trebuie s fac un site de Web ru intenionat este s ofere o
pagin de Web de exemplu cu fotografii de staruri de cinema sau sportive, toate imaginile
indicnd ctre un virus. Un singur clic pe o imagine determin ca un program executabil
necunoscut i posibil ostil s fie copiat i executat pe maina utilizatorului. Pentru a preveni
astfel de vizitatori nedorii, Internet Explorer poate fi configurat s fie selectiv n a executa
programe necunoscute n mod automat, dar nu toi utilizatorii neleg cum s foloseasc aceast
configurare.
Pe sistemele UNIX pot exista probleme similare cu fiierele de comenzi pentru consola
sistemului, dar aceasta necesit ca utilizatorul s instaleze n mod contient consola sistemului ca
aplicaie auxiliar. Din fericire, acest proces este suficient de complicat pentru ca nimeni s nu
poat s l efectueze accidental (i puine persoane pot s l efectueze chiar intenionat).
40
3.3. Aspecte privind serverul

Cam att despre aspectele privind clientul. S ne referim acum la aspectele privind
serverul. Aa cum am vzut mai sus, atunci cnd utilizatorul tasteaz un URL sau execut un clic
asupra unei linii de hipertext, programul de navigare analizeaz URL-ul i interpreteaz partea
ntre Eroare! Referin hyperlink incorect. i urmtorul caracter / ca un nume DNS ce trebuie
cutat. narmat cu adresa IP a serverului, programul de navigare stabilete o conexiune TCP la
portul 80 de pe acel server. Apoi se transmite o comand ce conine restul URL-uIui, care este de
fapt numele fiierului de pe acel server. Serverul ntoarce apoi fiierul pentru a fi afiat de ctre
programul de navigare.
ntr-o prim aproximare, un server de Web este similar cu serverul din Figura 3.3. Acel
server, ca i un server de Web real, primete numele fiierului ce trebuie cutat i transmis
programului de navigare, n ambele cazuri, etapele pe care le parcurge serverul n bucla sa
principal sunt:
1. Accept o conexiune TCP de la un client (program dc navigare).
2. Obine numele fiierului cerut.
3. Obine fiierul (de pe disc).
4. ntoarce fiierul clientului.
5. Elibereaz conexiunea TCP.
Serverele de Web moderne au mai multe caracteristici, dar n esen acestea sunt funciile
unui server de Web. O problem cu aceast arhitectur este c fiecare cerere necesit acces la
disc pentru obinerea fiierului. Rezultatul este c serverul de Web nu poate servi mai multe
cereri pe secund dect numrul de accese la disc ce se pot executa pe secund. Un disc SCSI are
un timp de acces mediu de circa 5 ms, ceea ce limiteaz serverul la cel mult 200 de cereri/sec,
chiar mai puin dac trebuie citite des fiiere mari. Pentru un sit de Web de importan mare,
acest numr este prea mic.
O mbuntire evident (utilizat de toate serverele de Web) este folosirea unui sistem de
memorie ascuns, temporar pentru cele mai recente n fiiere utilizate. nainte de obinerea unui
fiier de pc disc, serverul verific memoria ascuns (cache). Dac fiierul exist acolo, el poate fi
servit direct din memorie, eliminnd astfel accesul la disc. Dei pentru o memorie ascuns
eficient sunt necesare o cantitate mare de memorie principal i timp de procesare suplimentar
pentru a analiza memoria ascuns i pentru a-i administra coninutul, economia de timp este
41
aproape ntotdeauna superioar timpului suplimentar de procesare i costului memoriei.

Figura 3.3. Un server de Web cu mai multe fire de execuie cu un modul frontal i
module de procesare
Urmtorul pas pentru construcia unui server mai rapid este de a face serverul s admit
mai multe fire dc execuie (miltithreaded). ntr-una din arhitecturi, serverul este format dintr-un
modul frontal (front-end module), care accept conexiunile nou venite, i k module de procesare,
aa cum arata Figura 3.3. Cele k + 1 fire de execuie aparin toate aceluiai proces, astfel c
modulele de procesare au toate acces la memoria ascuns din interiorul spaiului de adrese al
procesului. La sosirea unei cereri, modulul frontal o accept i construiete o scurt nregistrare
ce descrie cererea. Aceasta este transmis apoi unuia dintre modulele de procesare. n alt
arhitectur posibil, modulul frontal este eliminat i fiecare modul de procesare ncearc s i
obin propriile cereri, dar n acest caz este necesar un protocol de sincronizare pentru prevenirea
conflictelor.
Modulul de procesare verific mai nti memoria ascuns pentru a determina dac fiierul
necesar se afl acolo. Dac da, modific nregistrarea pentru a include i un indicator ctre
fiierul din nregistrare. Dac fiierul nu se afl acolo, modulul de procesare ncepe operaiile cu
discul pentru a citi fiierul n memoria ascuns (renunnd eventual la alte fiiere pentru a face
loc acestuia). Cnd fiierul este citit de pe disc, el este pus n cache i de asemenea transmis
clientului.
Avantajul acestei scheme este c n timp ce unul sau mai multe module de procesare sunt
blocate ateptnd terminarea operaiilor cu discul (i deci nu consum din timpul procesorului),
alte module pot fi active lucrnd la satisfacerea altor cereri. Desigur, pentru a obine o
mbuntire real asupra modelului cu un singur fir de execuie este necesar existena mai

42
multor uniti de disc, astfel nct mai multe discuri s poal fi ocupate n acelai timp. Cu
ajutorul a k module de procesare i k uniti de disc, eficiena poate crete pn la de k ori fa de
modelul serverului cu un singur fir de execuie i o singur unitate de disc.
Teoretic, un server cu un singur fir de execuie i k uniti de disc poate de asemenea
ctiga un factor k n ceea ce privete eficiena, dar implementarea i administrarea sunt mult mai
complicate deoarece apelurile de sistem READ normale, blocante nu pot fi folosite pentru
accesul la disc. n cazul unui server cu mai multe fire de execuie, acestea pot fi folosite deoarece
o operaie READ blocheaz doar firul dc execuie care a executat operaia i nu ntregul proces.
Serverele de Web moderne efectueaz mai multe operaii dect acceptarea numelor de
fiiere i transmiterea coninutului acestora. De fapt, procesarea fiecrei cereri poate deveni
destul de complicat. Din acest motiv, ntr-un numr mare de servere fiecare modul de procesare
efectueaz o serie de etape. Modulul frontal transmite fiecare cerere sosit ctre primul modul de
procesare disponibil, care apoi execut cererea, utiliznd o submulime a urmtorilor pai, n
funcie de ce pai sunt necesari pentru respectiva cerere.
1. Rezolvarea numelui paginii de Web cerute.
2. Autentificarea clientului.
3. Verificarea drepturilor de acces ale clientului.
4. Verificarea drepturilor de acces asupra paginii de Web.
5. Verificarea memoriei ascunse.
6. Obinerea paginii cerule, de pe disc.
7. Determinarea tipului MIME ce va fi inclus n rspuns.
8. Rezolvarea altor probleme minore.
9. Transmiterea rspunsului ctre client.
10. Adugarea unei nregistrri n jurnalul serverului.
Pasul 1 este necesar deoarece cererea sosit poate s nu conin numele propriu-zis al
fiierului, ca ir de caractere. De exemplu, putem considera URL-ul http://www.cs.vu.nl, care are
un nume de fiier vid. Acesta trebuie extins la un nume de fiier implicit. De asemenea,
programele de navigare moderne pot specifica limba implicit a utilizatorului (de ex.: italian sau
englez), ceea ce deschide posibilitatea ca serverul s selecteze o pagin de Web n acea limb,
dac aceasta este disponibil. n general, extinderea numelor nu este un proces att de banal cum
ar putea prea la prima vedere, datorita unei varieti de convenii existente privind numirea
fiierelor.
Pasul 2 const n verificarea identitii clientului. Acest pas este necesar pentru paginile
43
care nu sunt disponibile publicului larg. Vom discuta o modalitate de a realiza acest lucru mai
trziu, n acest capitol.
Pasul 3 verific dac exist restricii referitoare la satisfacerea cererii, avnd n vedere
identitatea i localizarea clientului. Pasul 4 verific dac exist restricii de acces asociate cu
pagina nsi. Dac un anumit fiier (de ex.: htaccess) este prezent n directorul unde se afl i
pagina dorit, accesul la acel fiier poate fi restrns la anumite domenii, de exemplu numai la
utilizatorii din interiorul companiei.
Paii 5 i 6 presupun obinerea paginii. Pasul 6 necesit capacitatea de tratare simultan a
mai multor citiri de pe disc.
Pasul 7 se refer la determinarea tipului MIME din extensia fiierului, primele cteva
cuvinte din fiier, un fiier de configurare sau alte surse posibile. Pasul 8 este destinat unei
diversiti de operaii, cum ar fi construcia unui profil al utilizatorului sau adunarea unor
statistici.
Pasul 9 este cel n care rezultatul este transmis clientului i pasul 10 adaug o nregistrare
n jurnalul sistemului, n scopuri administrative. Asemenea fiiere de jurnalizare pot fi analizate
ulterior pentru obinerea de informaii importante despre comportamentul utilizatorului, spre
exemplu ordinea n care vizitatorii acceseaz paginile.
Dac sosesc prea multe cereri n fiecare secund, procesorul nu va fi capabil sa suporte
ncrcarea, oricte uniti de disc ar fi utilizate n paralel. Soluia este adugarea mai multor
noduri (calculatoare), posibil cu uniti de disc replicate pentru a evita ca discurile s devin
urmtorul punct dc gtuire. Acest fapt conduce la modelul fermei de servere (server farm) din
Figura 3.4. Un modul frontal accept n continuare cererile dar le mparte mai multor procesoare,
nu mai multor fire dc execuie, pentru a reduce ncrcarea pe fiecare calculator. Mainile
individuale pot fi cu mai multe fire de execuie i n band de asamblare ca mai jos.

Figura 3.4. 0 ferm de servere

O problem cu fermele de servere este c nu mai exist o memorie ascuns partajat
deoarece fiecare nod are propria sa memorie - dect dac se folosete un sistem multiprocesor cu

44
memorie partajat de cost mic. O modalitate de a contracara aceast pierdere de performan este
un modul frontal care reine unde direcioneaz fiecare cerere i trimite cererile ulterioare pentru
aceeai pagin aceluiai nod. Aceast abordare specializeaz fiecare nod n tratarea anumitor
pagini astfel nct spaiul destinat pentru cache nu se pierde reinnd fiecare fiier n fiecare
cache.
O alt problem cu fermele de servere este aceea c fiecare conexiune TCP a clientului se
termin la modulul de intrare, astfel c rspunsul trebuie transmis prin acest modul. Aceast
situaie este evideniat n Figura 3.5.(a), unde cererea sosit (1) i rspunsul transmis (4) trec
ambele prin modulul frontal. Cteodat se poate folosi o soluie ingenioas numit parsare TCP
(eng.: TCP handoff) pentru a evita aceast problem. Cu acest truc, captul comunicaiei TCP
este pasat" nodului de procesare astfel c acesta poate replica direct clientului, lucru evideniat
ca (3) n Figura 3.5.(b). Aceast pasare este fcut ntr-un mod transparent pentru client.

Figura 3.5. (a) Secven normal dc mesaje cerere - rspuns, (b) Secven n care sc folosete
pasarea TCP.
3.4. URL- Uniform Resource Locators - Naming

Am spus de mai multe ori c o pagin de Web poate s conin referine la alte pagini. S
explicm cum sunt implementate aceste referine. nc de la crearea Web-ului, a fost clar c
pentru a avea o pagin care s indice spre alt pagin este necesar un mecanism care s permit
numirea i regsirea paginilor. n particular, sunt trei ntrebri la care trebuie s se rspund
nainte de a se putea afia o pagin:
1. Cum se numete pagina?
2. Cum este localizat pagina?
3. Cum se face accesul la pagin?
Dac fiecare pagin ar avea un nume unic, atunci nu ar exista nici o ambiguitate n
45
identificarea paginilor. Totui, problema nu este nc rezolvat. S considerm de exemplu o
paralel ntre oameni i pagini. n SUA aproape fiecare persoan are un numr de asigurare
social, care este un identificator unic , astfel nct nu exist dou persoane cu acelai numr.
Totui, cunoscnd numai numrul respectiv, nu exist nici o posibilitate de a gsi adresa
persoanei respective i sigur nu sc poate afla dac persoanei respective trebuie s i se scrie n
Englez, Spaniol sau Chinez. Web-ul are practic acelai fel de probleme.
Soluia aleas identific paginile ntr-un mod care rezolv toate trei problemele n acelai
timp. Fiecare pagin are un URL (Uniform Resource Locator - adresa uniform pentru
localizarea resurselor) care funcioneaz ca nume al paginii general valabil. Un URL are trei
componente: protocolul (cunoscut i sub numele dc schem), numele DNS al mainii pe care este
memorat fiierul i un nume local, care indic n mod unic pagina (de obicei numele fiierului
care conine pagina). De exemplu, situl de Web al departamentului din care face parte autorul
conine un numr dc nregistrri video despre universitate si despre oraul Amsterdam. URL-ul
paginii cu nregistrrile video este: http://www.cs.vu.nl/video/index-en.html
Acest URL este format din trei componente: protocolul (http), numele DNS al serverului
(www.cs.vu.nl) i numele fiierului (video/index-en.html), cu semnele de punctuaie
corespunztoare. Numele fiierului este o cale relativ la directorul de Web implicit de la
cs.vu.nl.
Se utilizeaz notaii care reprezint prescurtri standard. n cazul multor situri, un nume
de fiier nul nseamn implicit pagina principal a organizaiei. n mod obinuit, atunci cnd
numele fiierului denot un director, aceasta implic un fiier numit index.html. n sfrit, ~ user/
poate s fie pus n coresponden cu directorul WWW al utilizatorului user, i apoi cu fiierul
index.html n acest director. De exemplu, pagina autorului poate s fie referit ca:
http://www.cs.vu.nl/~ast/ chiar dac de fapt numele propriu-zis al fiierului este
index.html, implicit n acest director.
Acum ar trebui s fie clar cum funcioneaz hipcrtcxtul. Pentru a face o poriune de text
selectabil, cel care scrie pagina trebuie s furnizeze dou elemente: textul prin care se face
selecia i URL-ul paginii care trebuie adus, dac textul este selectat. Vom explica sintaxa
comenzii mai trziu n acest capitol.
Cnd se face selecia, programul de navigare caut numele serverului utiliznd DNS-ul.
Pe baza adresei IP a serverului, programul de navigare stabilete o conexiune TCP spre server.
Utiliznd aceast conexiune, se transmite numele fiierului utiliznd protocolul specificat. Bingo.
Acum sosete pagina.
46
 Aceast schem URL este deschis n sensul c este simplu s se utilizeze alte protocoale
pentru a se obine diferite tipuri de resurse. De fapt au fost definite URL-uri pentru protocoalele
obinuite, i multe programe de navigare neleg aceste protocoale. Forme simplificate ale celor
mai obinuite sunt prezentate n Figura 3.6.

Figura 3.6. Cteva URL-uri obinuite.

S parcurgem lista rapid. Protocolul http este protocolul nativ pentru Web, el este utilizat
de ctre serverele de Web. HTTP este o prescurtare pentru HyperText Transfer Protocol. Vom
examina mai detaliat acest protocol mai trziu n acest capitol.
Protocolul ftp este utilizat pentru accesul la fiiere prin FTP (File Transfer Protocol -
protocol pentru transferul de fiiere), protocolul Internet de transfer de fiiere. FTP este utilizat
de peste douzeci de ani i este foarte rspndit. Numeroase servere de FTP din toat lumea
permit ca de oriunde din Internet s se fac o conectare i s se aduc orice fiier plasat pe un
server FTP. Web-ul nu aduce schimbri aici, face doar ca obinerea fiierelor s se fac mai uor,
pentru c FTP are o interfa mai puin prietenoas (dar este mai puternic dect HTTP, deoarece
permite de exemplu ca un utilizator de pe maina A s transfere un fiier de pe maina B pe
maina C).
Este posibil s se fac acces la un fiier local ca la o pagin dc Web, fie utiliznd
protocolul file (fiier), fie pur i simplu utiliznd numele fiierului. Aceast abordare este
similar utilizrii protocolului FTP, dar nu implic existena unui server. Desigur funcioneaz
numai pentru fiiere locale, nu i pentru cele aflate la distan.
Cu mult nainte de apariia Internet-ului exista sistemul de tiri USENET. Acesta este
format din aproximativ 30000 de grupuri de tiri n care milioane de persoane discut despre o
mare varietate de subiecte, adugnd i citind articole legate de subiectul grupului de tiri.
Protocolul news permite citirea unui articol din tiri ca i cum ar fi o pagin de Web. Aceasta
nseamn c un program de navigare este n acelai timp i un cititor de tiri. De fapt, multe
programe de navigare au butoane sau clemente de meniu care permit citirea tirilor USENET mai

47
uor dect dac se utilizeaz cititoare standard de tiri.
Protocolul news admite dou formate. Primul format specific un grup de tiri i poate s
fie utilizat pentru a obine o list de articole de la un server de tiri preconfigurat. Al doilea
format cere identificatorul unui articol, de exemplu AA0134223112@cs.utah.edu. Programul de
navigare aduce articolul de la serverul corespunztor utiliznd protocolul NNTP (Network News
Transfer Protocol - Protocol dc transfer al tirilor prin reea). Nu vom studia NNTP n aceast
carte, dar este n mare bazat pe SMTP i are un stil similar.
Protocolul gopher era utilizat de sistemul Gopher, care a fost proiectat la universitatea
Minnesota. Numele este cel al echipei atletice a universitii, the Golden Gopher (de asemenea
acest nume este utilizat n argou pentru go for" adic o comand de aducere). Gopher-ul a
precedat Web-ul cu civa ani. Era o metod de regsire a informaiei, similar conceptual cu cea
utilizat de Web, dar acceptnd numai text i imagini. Este considerat depit i nu se mai
folosete n prezent.
Ultimele dou protocoale nu sunt de fapt protocoale pentru aducerea unor pagini de Web,
dar sunt utile. Protocolul mailto permite transmiterea de pot dintr-un program de navigare.
Pentru a face aceast operaie, se selecteaz butonul OPEN i sc specific un URL constnd din
mailto: urmat de adresa destinatarului. Majoritatea programelor de navigare vor rspunde prin
pornirea unei aplicaii de pot electronic cu adresa i cteva alte cmpuri din antet deja
completate.
Protocolul telnet este utilizat pentru stabilirea unei conexiuni cu o main aflat la
distan. Se utilizeaz n acelai fel ca i programul telnet, ceea ce nu constituie o surpriz,
deoarece majoritatea programelor de navigare utilizeaz programul telnet ca aplicaie auxiliar.
Pe scurt URL-urile au fost proiectate nu numai pentru a permite utilizatorilor s
navigheze prin Web, dar i pentru a utiliza FTP, news, Gopher, e-mail i telnet, ceea ce face
inutile interfeele specializate pentru aceste protocoale integrnd astfel ntr-un singur program,
navigatorul n Web, aproape toate tipurile dc acces n Internet. Dac metoda nu ar fi fost
proiectat de un fizician, ar fi putut s par produsul departamentului de publicitate al unei
companii de software.
n ciuda tuturor acestor proprieti, creterea Web-ului scoate n eviden i o slbiciune a
metodei utilizrii URL-urilor. Pentru o pagin care este foarte des referit, ar fi de preferat s
existe mai multe copii pe servere diferite, pentru a reduce traficul n reea. Problema este c
URL-rile nu ofer nici o posibilitate de indicare a unei pagini fr s se specifice unde este
localizat pagina respectiv. Nu exist nici o metod pentru a spune ceva de genul: Vreau
48
pagina xyz, dar nu m intereseaz de unde o aduci". Pentru a rezolva aceast problem i a
permite multiplicarea paginilor, IETF lucreaz la un sistem de URN (Universal Resource Names
- nume universale de resurse). Un URN poate s fie privit ca un URL generalizat. Acest subiect
este n curs de cercetare, dei o propunere de sintax este dat n RFC 2141.

3.5. Lipsa strii i utilizarea cookies

Aa cum am vzut n mod repetat, Web-ul este, n principiu, lipsit de stare. Nu exist
conceptul unei sesiuni de conectare. Programul dc navigare transmite o cerere ctre server i
primete un fiier. Apoi serverul uit c a discutat vreodat cu acel client.
La nceput, cnd Web-ul a fost folosit doar pentru obinerea de documente accesibile
publicului larg acest model era perfect adaptat cerinelor. Dar, pe msur ce Web-ul a nceput s
capete i alte funcii, acest model a dat natere unor probleme. De exemplu, anumite situri de
Web impun clienilor s se nregistreze (i chiar s plteasc bani) spre a le utiliza. Ca atare, se
pune ntrebarea cum pot serverele s disting ntre cereri din partea utilizatorilor nregistrai i a
celorlali. Un al doilea exemplu este comerul electronic. Dac un utilizator se plimb printr-un
magazin electronic, aruncnd din cnd n cnd produse n coul de cumprturi, cum poate
serverul s rein coninutul coului? Un al treilea exemplu sunt portalurile de Web configurabile
cum este Yahoo. Utilizatorii pot configura o pagin iniial detaliat, doar cu informaia pe care o
doresc (de ex.: valorile aciunilor la burs i echipele lor sportive favorite), dar cum poate
serverul sa afieze pagina corect dac nu tie cine este utilizatorul?
La o prim vedere, se poate crede c serverele pot s urmreasc utilizatorii uitndu-se la
adresele lor IP. Aceast idee nu funcioneaz ns. n primul rnd, muli utilizatori lucreaz pe
calculatoare partajate cu ali utilizatori, n special n cadrul companiilor, iar adresa IP identific
doar calculatorul nu i utilizatorul. n al doilea rnd, mult mai grav, muli dintre cei ce ofer
servicii de Internet (ISP) utilizeaz NAT, astfel nct toate pachetele ce pleac de la orice
utilizator folosesc aceeai adres IP. Din punctul de vedere al serverului, cele cteva de mii de
clieni ai unui ISP folosesc aceeai adres IP.
Pentru a rezolva aceast problem, Netscape a proiectat o tehnic mult criticat numit
cookies (rom. fursecuri). Numele deriv dintr-un argou foarte vechi al programatorilor n care un
program apeleaz o procedur i obine rezultate ce ar putea fi folosite mai trziu pentru a
executa ceva. n acest sens, o nregistrare de descriere a unui fiier UNIX sau un identificator al
unui obiect Windows reprezint un cookie. Mecanismul a fost formalizai mai trziu n RFC
49
2109.
Cnd un client cere o pagin de Web, serverul poate oferi informaii adiionale odat cu
pagina cerut. Aceste informaii pot include un cookie, care este un fiier (sau ir de caractere) de
dimensiune mic (cel mult 4 KB). Programele de navigare stocheaz cookie-urile oferite ntr-un
director special pentru acestea pe discul clientului, cu excepia cazurilor cnd utilizatorul a oprit
utilizarea cookie-urilor. Cookie-urile sunt doar fiiere sau iruri de caractere, nu programe
executabile. n principiu, un cookie ar putea conine un virus, dar deoarece cookie-urile sunt
tratate ca date, nu exist nici o posibilitate oficial ca virusul s fie executat i s cauzeze
probleme. Este ns posibil ca un hacker s exploateze o eroare a programului de navigare i s
cauzeze activarea virusului.
Cookie-urilc pot fi utilizate i n beneficiul serverului. De exemplu, s presupunem c un
server dorete s tie n fiecare moment ci vizitatori a avut i cte pagini au fost vizitate de
fiecare dintre acetia nainte de a prsi situl. Prima cerere nu va fi nsoit de nici un cookie,
astfel c serverul va transmite napoi un cookie ce conine Counter = 1. Selecii ulterioare ale
paginilor acestui site vor transmite acest cookie napoi la server. De fiecare dat, contorul este
incrementat i transmis napoi clientului. Urmrind aceste contoare, serverul poate s vad cte
persoane renun dup vizitarea primei pagini, cte au vizitat dou pagini, .a.m.d.
Cookic-urile au avut i utilizri greite. Teoretic, cookie-urile ar trebui s ajung doar la
situl lor de origine, dar sprgtorii au exploatat numeroase erori n programele de navigare pentru
a captura cookie-uri care nu le erau destinate. Deoarece numeroase situri de comer electronic
pun numerele de cri de credit n cookie-uri, potenialul pentru abuzuri este evident.
Pentru a menine impresia de intimitate, o serie de utilizatori i configureaz programele
de navigare pentru a refuza loate cookie-urile. Aceast aciune poate duce ns la probleme cu
siturile de Web legitime ce folosesc cookie-uri. Pentru a rezolva aceast problem, utilizatorii
instaleaz cteodat software care mnnc cookie-uri" (cookie-eating software). Acestea sunt
programe speciale care inspecteaz fiecare cookie la sosire i l accept sau refuz n funcie de
opiunile utilizatorului (de ex.: n ce situri Web se poate avea ncredere). Aceast metod ofer
utilizatorului un control fin asupra cror cookie-uri sunt acceptate i care sunt refuzate.
Programele de navigare moderne cum ar fi Mozilla (www.mozilla.org) au un nivel de control
complex asupra cookie-urilor.

3.6. Documente Web statice

50
 Fundamentul Web-ului este transferul de pagini de Web de la server la client. n forma
cea mai simpl, paginile de Web sunt statice, adic doar fiiere existente pe un server, ce ateapt
s fie cerute, n acest sens, chiar i o nregistrare video este o pagin de Web static, deoarece
este doar un fiier. In aceast seciune vom privi paginile de Web statice n detaliu. n seciunea
urmtoare vom examina coninutul static.

3.6.1. HTML - HyperText Markup Language

Paginile de Web sunt n prezent scrise ntr-un limbaj numit HTML (HyperTexl Markup
Language). HTML permite utilizatorilor s produc pagini de Web care conin text, imagini i
referine la alte pagini de Web. HTML este un limbaj de marcare, un limbaj care descrie cum
trebuie s fie formatate textele. Termenul dc marcare" provine din timpurile vechi, cnd editorii
fceau marcaje pe documente pentru a indica tipografului - n acele timpuri un om - ce font-uri
s foloseasc .a.m.d. Limbajele de marcare conin comenzi explicite pentru formatare. De
exemplu, n HTML, <b> nseamn nceput de mod aldin, i </b> nseamn terminarea utilizrii
modului aldin. Avantajul utilizrii unui limbaj de marcare fa de unul n care nu se utilizeaz
marcarea explicit const din faptul c este simplu de scris un program de navigare care s
interpreteze comenzile de marcare. TeX i troff sunt dou exemple foarte cunoscute de limbaje
de marcare.
Prin standardizarea i includerea comenzilor de marcaj n fiecare fiier HTML, devine
posibil ca orice program de navigare s poat s citeasc i s formateze orice pagin Web.
Posibilitatea formatrii paginii recepionate este foarte important, deoarece o pagin poate s fie
construit pe un ecran cu 1600 x 1200 pixeli utiliznd culori codificate cu 24 de bii, dar s-ar
putea s fie necesar afiarea ntr-o mic fereastr de pe un ecran cu 640 x 320 pixeli i utiliznd
culori codificate pe 8 bii.
n cele ce urmeaz se face o scurt introducere n limbajul HTML, doar pentru a oferi o
idee despre subiect. Cu toate c este posibil s se construiasc documente HTML utiliznd orice
editor, i muli fac asta, este posibil i s se utilizeze editoare HTML speciale care pot s fac
toat munca (desigur, n mod corespunztor utilizatorul are mai puin control asupra detaliilor
produsului final).
O pagin Web corect format conine o zon de cap i o zon de corp, cupriase ntre
marcajele (tag-uri) <html> i </html>, dar majoritatea programelor de navigare ignor absena
acestor marcaje. Capul este cuprins ntre marcajele <head> i </head>, iar corpul ntre marcajele
51
<body> i </body>. Comenzile cuprinse ntre aceste marcaje se numesc directive. Majoritatea
marcajelor HTML au acest format, adic, <ceva> pentru a indica nceputul a ceva i </ceva>
pentru a marca sfritul. Numeroase exemple de fiiere HTML sunt disponibile. Majoritatea
programelor de navigare au o opiune VIEW SOURCE (afiarea sursei) sau ceva similar.
Selectarea acestei opiuni afieaz pagina curent n format HTML n loc de forma interpretat.
Marcajele pot s fie scrise cu litere mici sau mari. Adic <head> i <HEAD> ascamn
acelai lucru, dar versiuni mai noi ale standardului cer existena doar a primei forme. Cum este
dispus textul n documentul HTML este nesemnificativ. Programele de navigare ignor spaiile i
trecerile la rnd nou, deoarece textul trebuie s fie formatat pentru a corespunde zonei de afiare
curente. Corespunztor, se pot utiliza spaii pentru a face documentele HTML mai uor de citit,
ceva ce ar fi necesar pentru majoritatea documentelor. Liniile albe nu pot s fie utilizate pentru
separarea paragrafelor, deoarece sunt pur i simplu ignorate. Este necesar utilizarea unor
marcaje explicite. Unele marcaje au parametri (care au nume), numii atribute. De exemplu:
<img src="abc" alt="foobar">
este un marcaj, <img>, avnd parametrul src cu valoarea abc i parametrul alt cu valoarea
foobar. Pentru fiecare marcaj, standardul HTML ofer o list a parametrilor care pot s fie
utilizai, dac este cazul i care este semnificaia lor. Deoarece parametrii au nume, ordinea n
care se dau valorile parametrilor nu este semnificativ.
Din punct de vedere tehnic, documentele HTML sunt scrise utiliznd setul de caractere
ISO 8859-1 Latin-1, dar pentru utilizatorii ale cror tastaturi suport numai codul ASCII, se pot
utiliza secvene de caractere pentru reprezentarea caracterelor speciale cum ar fi . Lista
caracterelor speciale este precizat n standard. Toate ncep cu caracterul &" i se termin cu ;
". De exemplu &egrave; produce iar &eacute; produce . Deoarece <, > i & au semnificaii
speciale, pot s fie reprezentate numai utiliznd secvenele speciale de caractere corespunztoare,
&lt; &gt; i &amp;.
Principalul element din zona de cap este titlul care este cuprins ntre <title> i </title>,
dar aici pot s apar i alte tipuri de informaii. Titlul nu este afiat pe pagin. Unele programe de
navigare l utilizeaz pentru a eticheta fereastra n care se afieaz pagina respectiv.
Depinde de programul de navigare s prezinte aceste titluri n mod diferit pe ecran. De
obicei, titlurile cu numr mai mic vor fi afiate utiliznd caractere mai mari. Programul de
navigare poate s utilizeze culori diferite pentru fiecare nivel de titlu. De obicei, pentru titlurile
marcate cu <hl> se utilizeaz litere mari scrise cu aldine cu cel puin o linie liber nainte i
dup. Corespunztor, pentru titlurile marcate cu <h2>, se utilizeaz caractere mai mici cu mai
52
puin spaiu lsat nainte i dup.
Marcajele <b> i <i> sunt utilizate pentru a indica modurile aldin i respectiv cursiv.
Dac programul de navigare nu poate s afieze aceste tipuri de caractere, va utiliza un alt mod
de a le reprezenta, de exemplu utiliznd diferite culori sau video-invers.
Limbajul HTML ofer diferite mecanisme pentru construirea de liste, inclusiv liste
coninute n alte liste. Listele ncep cu <ul> sau <ol>, <li> fiind folosit pentru a marca nceputul
elementelor n ambele cazuri. Marcajul <ul> indic nceputul unei liste neordonate. Elementele
individuale, care sunt marcate n surs cu <li>, sunt reprezentate precedate de buline (). O
variant a acestui mecanism este <ol>, care descrie o list ordonat. Cnd se utilizeaz acest
marcaj, textele precedate de <li> sunt numerotate de ctre programul de navigare. Marcajele
<ul> i <ol> au aceeai sintax i efecte asemntoare.
Marcajele <br>, <p> i <hr> indic o separare ntre diferitele pri ale textului. Formatul
precis este descris n pagina de stil (vezi mai jos) asociat cu pagina curent. Marcajul <br>
foreaz trecerea la linie nou. De obicei programele de navigare nu insereaz o linie liber dup
<br>. Marcajul <p> reprezint un nceput de paragraf, pentru care se va insera o linie nou i
eventual se va face o indentare. (n mod teoretic, exist i </p> pentru a indica sfritul de
paragraf, dar este foarte rar utilizat; majoritatea celor care scriu n HTML nici nu tiu c acest
marcaj exist). Ultimul marcaj, <hr>, foreaz trecerea la linie nou i deseneaz o linie
orizontal.
HTML permite includerea de imagini n paginile de Web. Marcajul <img> arat c pe
poziia curent din pagin se va include o imagine. Marcajul poate s aib o serie de parametri.
Parametrul src indic URL-ul imaginii. Standardul HTML nu specific ce formate grafice sunt
permise. n practic, toate programele de navigare accept fiiere n format GIF, multe pot lucra
i cu fiiere n format JPEG. Programele de navigare pot s lucreze i cu alte formate, dar o astfel
de extensie este o sabie cu dou tiuri. Dac, de exemplu un utilizator este obinuit cu un
program de navigare care suport fiiere n format BMP, este posibil ca el s includ astfel de
fiiere n pagina sa de Web i s fie uimit c alte programe de navigare ignor imaginile sale
minunate.
Ali parametri pentru <img> sunt align, care controleaz modul n care sc aliniaz
imaginea fa de limita de jos a textului (top, middle, bottom, alt), care furnizeaz textul afiat n
locul imaginii dac utilizatorul dezactiveaz opiunea de afiare a imaginilor i ismap, un
indicator care anun c imaginea este o hart selectabil.
n sfrit, s considerm hiper-legturile, care utilizeaz marcajele <a> (anchor) i </a>.
53
Ca i <img>, <a> arc diveri parametrii, printre care href (URL-ul) i nome (numele hiper-
legturii). Textul cuprins ntre <a> i </a> este afiat. Dac este selectat, atunci se utilizeaz
hiper-legtura pentru a se aduce o nou pagin. n locul textului se poate pune i un marcaj
<img>, caz n care, cu un clic pe imagine, se va activa legtura.
De exemplu, s considerm urmtorul fragment HTML:
<a href = http://www.politiaromana.ro ">Politia Romana home page </a>
Cnd se afieaz acest fragment, pe ecran apare:
Politia Romana home page
Dac utilizatorul execut un clic pe acest text, programul de navigare aduce i afieaz
pagina al crei URL aste http://www.politiaromana.ro. Ca al doilea exemplu, s considerm:
<a href = http:/ www.politiaromana.ro "> <img src=masina_politie.gif"alt =PolitiaRomana"> < /a>
Cnd se afieaz pagina va aprea o imagine (o main de poliie). Executnd un clic pe
imagine, se va aduce pagina Poliia Romn la fel ca i n cazul n care n exemplul anterior a
fost selectat textul. Dac utilizatorul a dezactivat opiunea de afiare a imaginilor, atunci n loc de
imagine va fi afiat textul Politia Romana.
Pentru marcajul <a> se poate utiliza parametrul name pentru a fixa o hiper-legtur, care
s fie referia din pagin. De exemplu, unele pagini de Web ncep cu o tabel de coninut
selectabil. Prin execuia unui clic pe o intrare n tabela de coninut, se va trece direct la
seciunea corespunztoare din pagin.
HTML evolueaz continuu, n versiunile HTML 1.0 i HTML 2.0 nu existau tabele, dar
au fost adugate n HTML 3.0. O tabel HTML este format din una sau mai multe linii, fiecare
fiind format din una sau mai multe celule. Celulele pot s conin diferite tipuri de informaii,
inclusiv text, figuri, iconie, fotografii i chiar tabele. Celulele pot s fie alipite, de exemplu un
titlu poate s se ntind peste mai multe coloane. Autorii paginilor au control asupra modului n
care se face afiarea, inclusiv alinierea, stilul bordurii, marginile celulelor, dar programul de
navigare este cel care hotrte de fapt cum se face afiarea.
Marcajul <caption> poate s fie utilizat pentru a furniza un titlu tabelei. Fiecare linie
ncepe cu marcajul <tr> (Table Row - linie n tabel). Celulele individuale sunt marcate cu <th>
(Table Headcr - titlu de coloan), <td> (Table Data - date n tabel). Diferenierea este necesar
pentru a permite programului de navigare s le afieze diferit, aa cum se vede i din exemplul
considerat.
n HTML 4.0 au fost adugate noi elemente. Acestea includ elemente ce fac paginile mai
accesibile utilizatorilor cu handicap, nglobarea obiectelor (o generalizare a marcajului <img>

54
astfel nct alte obiecte s poat fi nglobate n pagini), suport pentru limbaje de scripturi (pentru
a permite coninut dinamic) i multe altele.
Cnd un sit de Web este complex, fiind format din multe pagini produse de autori diferii
ce lucreaz pentru aceeai companie, este adesea de dorit s existe o modalitate pentru a
mpiedica moduri de prezentare diferite n pagini diferite. Aceast problem poate fi rezolvat
utiliznd paginile de stil (style sheets). Atunci cnd se utilizeaz pagini de stil, paginile
individuale nu mai folosesc stiluri fizice, cum sunt modurile aldin i cursiv. Autorii pot acum s
utilizeze stiluri logice, cum sunt <dn> (definiie), <em> (evideniere), <strong> (evideniere
accentuat) i <var> (variabile de program). Stilurile logice sunt definite n pagina de stil, pentru
care exist o referin la nceputul fiecrei pagini. n acest fel, toate paginile au acelai stil i
dac administratorul sitului (Webmaster) decide s schimbe stilul <strong> din stil cursiv de 14
puncte tipografice, culoare albastr n stil aldin, 18 puncte tipografice, culoare roz iptor, tot
ceea ce trebuie s fac este s schimbe o singur definiie pentru a converti ntregul sit Web. O
pagin de stil poate fi comparat cu o directiv #include ntr-un program C: schimbarea unei
macrodefiniii n fiierul inclus determin schimbarea n toate fiierele program ce includ
respectivul header.

3.6.2. XML i XSL

Limbajul HTML, cu sau fr formulare, nu confer nici o structur paginilor de Web. De

asemenea, el amestec coninutul cu informaii despre formatul paginii. Pe msur ce comerul
electronic i alte aplicaii devin din ce n ce mai rspndite, apare o cerere din ce n ce mai mare
pentru structurarea paginilor de Web i separarea coninutului de informaiile de format. De
exemplu, un program care caut pe Web preul cel mai bun al unei cri sau al unui CD trebuie s
analizeze multe pagini de Web cutnd numele produsului i preul su. Cu paginile de Web n
format HTML este foarte dificil ca un program s i dea seama unde se afl numele i unde se
afl preul.
Din acest motiv, consoriul W3C a dezvoltat mbuntiri ale limbajului HTML pentru a
permite paginilor de Web s fie structurare n vederea procesrii automate. Dou limbaje noi au
fost dezvoltate n acest scop. Mai nti, XML (eXtensible Markup Language) descrie coninutul
ntr-un mod structurat i apoi, XSL (eXtensible Style Language) descrie formatul independent de
coninut. Ambele limbaje reprezint subiecte mari i complexe, ca atare scurta introducere care
urmeaz atinge tangenial subiectul, dei ar trebui s ofere o idee despre modul cum
55
funcioneaz.
3.7. Documente Web dinamice

La nceputul Web-ului, tot coninutul era de fapt static n acest mod (doar fiiere). Totui,
n ultimii ani, din ce n ce mai mult coninut a devenit dinamic, adic generat la cerere i nu doar
stocat pe disc. Generarea de coninut poate avea loc fie la server, fie la client. S examinm acum
pe rnd fiecare din aceste cazuri.
3.7.1. Generare dinamic de pagini de Web la server

Pentru a vedea de ce este necesar generarea de coninut la server, s lum n considerare

utilizarea formularelor, aa cum a fost descris mai devreme. Atunci cnd un utilizator
completeaz un formular i apas butonul submit, se transmite un mesaj ctre server, mesaj ce
arat c are n interior coninutul unui formular, mpreun cu acele cmpuri completate de
utilizator. Acest mesaj nu este numele unui fiier ce trebuie ntors. n schimb, acest mesaj trebuie
s fie oferit unui program, sau script, pentru a fi procesat. De obicei, procesarea implic folosirea
informaiilor oferite de utilizator pentru cutarea unei nregistrri ntr-o baz dc date de pe discul
serverului i generarea unei pagini HTML personalizate pentru a fi trimis napoi clientului. De
exemplu, ntr-o aplicaie de Evidena Persoanei, atunci cnd utilizatorul face un clic pe
CUTARE PERSOAN, programul de navigare ntoarce cookie-ul ce conine persoana cutat,
dar la server trebuie apelat un program, sau script, care proceseaz acest cookie i genereaz o
pagin HTML ca rspuns. Pagina HTML ar putea afia o list cu mai multe persoane ce satisfac
criteriul de cutare i data de natere a acestor persoane ct i prenumele prinilor. Etapele
necesare pentru procesarea informaiei dintr-un formular HTML sunt ilustrate n Figura 3.7.

Figura 3.7. Etapele de procesare a informaiei dintr-un formular HTML

Modalitatea tradiional de a trata formularele i alte pagini de Web interactive este
sistemul numit CGI (Common Gateway Interface - Interfa comun de conversie). Aceasta este
o interfa standardizat ce permite serverelor de Web s discute cu programele din fundal i cu

56
scripturile care accept o intrare (de ex.: formulare) i s genereze pagini HTML ca rspuns. De
obicei, aceste programe de fundal sunt scripturi scrise n limbajul Perl deoarece scripturile Perl
sunt mai uor i mai rapid de scris dect programele (cel puin dac tii s programezi n Perl). n
mod obinuit, ele sunt localizate ntr-un director numit cgi-bin, care este vizibil n URL.
Cteodat un alt limbaj de scripturi, Python, este utilizat n loc dc Perl.
Scripturile CGI nu sunt singura modalitate de a genera coninut dinamic la server. O alt
modalitate des ntlnit este de a ngloba mici scripturi n paginile HTML si a lsa serverul s le
execute pentru a genera pagina. Un limbaj popular pentru scrierea acestor scripturi este PHP
(PHP: Hyper-text Procesor, rom.: Procesor Hipertext). Pentru a fi folosit, serverul trebuie s
neleag PHP (exact cum programul de navigare trebuie s neleag XML pentru a interpreta
paginile de Web scrise n XML). De obicei, serverele se ateapt ca paginile de Web ce conin
PHP s aib extensia php mai degrab dect html sau htm.
Un mic script PHP este ilustrat n Figura 3.8.; ar trebui s funcioneze pe orice server care
are PHP instalat. Conine HTML normal cu excepia scriptului PHP dintre marcajele <?php ... ?
>. Ceea ce genereaz este o pagin de Web ce afieaz ceea ce tie despre programul de navigare
care o apeleaz. Programele de navigare trimit de obicei o seric de informaii odat cu cererea lor
(i orice cookie aplicabil) i aceast informaie este pus n variabila HTTP_USER_AGENT.
Cnd acest program este pus n fiierul test.php n directorul de WWW al companiei ABCD,
tastnd URL-ul www.abcd.com/test.php se va afia o pagin de Web care spune utilizatorului ce
program dc navigare, ce limb i ce sistem de operare folosete.
<html>
<body>
<h2> This is what I know about you </h2>
<?php echo $HTTP_USER_AGENT ?>
</body>
</html>
Figura 3.8. 0 pagin HTML cu PHP nglobat
PHP este folositor n special la tratarea formularelor i este mai simplu de utilizat dect
scripturile CGI. Dei PHP uor de utilizat, este de fapt un limbaj de programare puternic, orientat
pe interfaarea dintre Web i o baz de date a serverului. Suport variabile, iruri de caractere,
vectori i majoritatea structurilor de control din C, dar un sistem de I/E mult mai puternic dect
printf. PHP este un program public (open source) i disponibil gratuit. A fost conceput special s
lucreze bine cu Apache, care este de asemenea gratuit i care este cel mai larg utilizat server de
57
Web din lume.
Am vzut pn acum dou moduri diferite de a genera pagini HTML dinamice: script-
urile CGI i PHP-ul nglobat. Exist i o a treia tehnic, numit JSP (JavaServer Pages), care este
similar cu PHP, cu excepia faptului c partea dinamic este scris n limbajul de programare
Java n loc de PHP. Paginile ce folosesc aceast tehnic au n numele fiierului extensia jsp. O a
patra tehnic, ASP (Active Server Pages), este versiunea de la Microsoft a PHP i JavaServer
Pagcs. Pentru generarea coninutului dinamic folosete limbajul de script proprietar al Microsoft-
ului, Visual Basic Script. Paginile ce folosesc aceast tehnic au extensia asp. Alegerea dintre
PHP, JSP, i ASP are n general mai mult de-a face cu politici (open-souce vs. Sun vs. Microsoft)
dect cu tehnologia, cele trei limbaje fiind comparabile. Colecia de tehnologii pentru generarea
din zbor a coninutului este uneori denumit HTML dinamic.

3.7.2. Generare dinamic de pagini de Web la client

Scripturile CGI, PHP, JSP i ASP rezolv problema formularelor i a interaciunilor cu

bazele de date din server. Toate pot s accepte informaii care vin din formulare, s caute
informaii ntr-una sau mai multe baze de date i s genereze pagini HTML cu rezultate. Ceea ce
nu poate face nici unul dintre scripturi este s rspund la micrile mouse-ului sau s
interacioneze direct cu utilizatorii, n acest scop, este necesar ca scripturile s fie nglobate n
paginile HTML care sunt executate mai degrab pe maina clientului, dect pe maina serverului.
ncepnd cu HTML 4.0, astfel de scripturi erau permise folosind marcajul <script>. Cel mai
popular limbaj de script la client este JavaScript, aa c o s aruncm o scurt privire asupra lui.
JavaScript este un limbaj de script, foarte inspirat din cteva idei ale limbajului de
programare Java. Nu este cu sigurana Java. Ca alte limbaje de script, el este un limbaj de nivel
foarte nalt. De exemplu, ntr-o singur linie din JavaScript este posibil s se creeze o fereastr de
dialog, s se atepte introducerea de text i s se memoreze irul rezultat ntr-o variabil. Astfel
de caracteristici de nivel nalt fac din JavaScript un limbaj ideal pentru crearea de pagini Web
interactive. Pe de alt parte, faptul c nu este standardizat i c se modific mai repede ca o
masc prins ntr-o main cu raze X, fac extrem de dificil scrierea de programe JavaScript care
s funcioneze pe toate platformele, dar poate ntr-o zi se va stabiliza.
Din moment ce aproape toate programele de navigare pot s interpreteze att programe
Java ct i JavaScript, un programator care vrea s fac o pagin Web foarte interactiv va putea
s aleag ntre dou tehnici, iar dac nu se dorete portabilitatea pe mai multe platforme, poate s
58
aleag i Active-X. Ca o regul general, programele JavaScript sunt mai uor de scris, applet-
urile Java se execut mai rapid iar controalele Active-X cel mai rapid dintre toate. De asemenea,
din moment ce toate programele de navigare implementeaz exact aceeai JVM, dar nu exist
dou programe de navigare care s tie aceeai versiune de JavaScript, applet-urile Java sunt mai
portabile dect programele JavaScript.
nainte de a prsi subiectul coninutului dinamic al Web-ului, s recapitulm pe scurt ce
am atins pn acum. Pagini Web complete se pot genera din mers, folosind diverse script-uri pe
maina server. Odat ce sunt primite de programul de navigare, ele sunt tratate ca pagini HTML
normale i sunt doar afiate. Script-urile pot fi scrise n Perl, PHP, JSP sau ASP, dup cum este
artat n Figura 3.9.

Figura 3.9. Diverse moduri de a genera i afia coninut.

Generarea coninutului dinamic este posibil i n partea clientului. Paginile Web pot fi
scrise n XML i convertite la HTML conform unui fiier XSL. Programele JavaScript pot s
efectueze diverse calcule, n sfrit, plug-in-urile (plug-ins) i aplicaiile ajuttoare (helper
applications) pot fi folosite pentru afiarea coninutului ntr-o varietate dc forme.

3.8. mbuntiri ale performanei

Popularitatea Web-ului aproape c a fost propria sa distrugere. Servere, rutere i linii
folosite de Web sunt adesea suprancrcate. Mult lume a nceput s denumeasc WWW-ul ca
World Wide Wait (rom: ateptare de ntindere planetar). Ca o consecin a acestor ntrzieri fr
sfrit, cercettorii au dezvoltat diverse tehnici pentru mbuntirea performanelor. Vom
examina acum trei dintre ele: memoria ascuns, replicarea servcrelor i reele de livrare a
coninutului.
Un mod simplu de a mbunti performana este de a salva paginile care au fost cerute
pentru cazul n care ele vor ti utilizate din nou. Aceast tehnic este efectiv n special pentru
paginile care sunt vizitate foarte mult, ca www.yahoo.com i www.cnn.com. Paginile pot fi

59
pstrate pentru utilizri ulterioare n memoria ascuns (eng cache). Procedura uzual este ca un
proces, denumit proxy (rom.: delegat), s ntrein aceast memorie. Pentru a utiliza memoria
ascuns, un program de navigare poate fi configurat s adreseze toate cererile de pagini proxy-
ului, i nu serverului real unde se afl pagina respectiv. Dac proxy-ul are pagina, o returneaz
imediat. Dac nu, aduce pagina de la server, o adaug n memoria ascuns pentru utilizarea
ulterioar i o ntoarce clientului care a cerut-o.
Dou ntrebri importante aferente memoriei ascunse sunt:
1. Cine ar trebui s dein memoria ascuns?
2. Ct de mult timp ar trebui s stea paginile n memoria ascuns?
Exista mai multe rspunsuri la prima ntrebare. PC-urilc individuale de obicei ruleaz
proxy-uri, deci pot s caute rapid pagini vizitate anterior. ntr-un LAN al unei companii, proxy-ul
este n general o main ce poate fi accesat de toate mainile din acel LAN, astfel c dac un
utilizator se uit la o anumit pagin i apoi alt utilizator din acelai LAN vrea aceeai pagin, ea
poate fi adus din memoria ascuns a proxy-ului. Multe ISP-uri ruleaz proxy-uri, pentru a
accelera accesul clienilor lor. De obicei toate memoriile ascunse opereaz n acelai timp, deci
cererile se duc iniial la proxy-ul local. Dac eueaz, proxy-ul local cere pagina proxy-ului din
LAN. Dac i aceasta eueaz, proxy-ul din LAN ncearc la proxy-ul ISP-ului. Ultimul trebuie
s reueasc s aduc paginile, fie din memoria sa ascuns, fie de la o memorie ascuns de nivel
superior, fie de la nsui serverul ce deine pagina. O schem ce include mai multe memorii
ascunse care pot fi ncercate n secven este denumit memorie ascuns ierarhic (hierarchical
caching). O pasibil implementare este ilustrat n Figura 3.10.

Figura 3.10. Memorie ascuns ierarhic cu 3 proxy-uri.

Ct timp ar trebui paginile s rmn n memoria ascuns este un pic mai dificil de aflat.
Anumite pagini nu ar trebui s fie pstrate deloc n memoria ascuns. De exemplu, o pagin ce
conine preurile pentru cele mai active 50 de aciuni la burs se schimb la fiecare secund.
Dac s-ar pstra n memoria ascuns, un utilizator ce ia o astfel de copie ar lua date vechi (adic
depite). Pe de alt parte, din momentul n care schimbul de aciuni s-a nchis pe ziua

60
respectiv, pagina va rmne valid ore sau zile, pn cnd ncepe urmtoarea licitaie. Astfel,
eficiena meninerii unei pagini n memoria ascuns poate varia foarte mult in timp.
Problema-cheie n determinarea eliminrii unei pagini din memoria ascuns este legat de
vechimea pe care utilizatorii sunt dispui s o accepte (din moment ce paginile din memoria
ascuns sunt inute pe disc, cantitatea de memorare consumat reprezint rareori o problem).
Dac un proxy elimin repede paginile, el va ntoarce rar o pagin veche, dar nu va fi prea
eficient (adic va avea o rat sczut de succes). Dac pstreaz paginile prea mult, poate avea o
rat mai marc dar cu preul de a ntoarce deseori pagini cu informaie expirat.
Exist dou abordri n tratarea acestei probleme. Prima utilizeaz o euristic pentru a ti
ct timp s menin fiecare pagin. O euristic des ntlnit este cea n care se ine cont de antetul
Last-Modified (vezi Figura 3.11.). Dac o pagin a fost modificat cu o or n urm, se ine n
memoria ascuns o or. Dac a fost modificat cu un an n urm, este evident o pagin foarte
veche (de exemplu, o list a zeilor din mitologia greac i cea roman), deci poate fi pstrat n
memoria ascuns pentru un an, cu o probabilitate rezonabil c nu se va modifica n decursul
anului. Dei aceast euristic funcioneaz bine n practic, ea ntoarce, totui, pagini vechi din
cnd n cnd.
Cealalt abordare este mai costisitoare dar elimin posibilitatea paginilor vechi prin
utilizarea unor caracteristici speciale ale RFC 2616 care trateaz administrarea memoriei
ascunse. Una din cele mai utilizate caracteristici este antetul dc cerere If-Modified-Since, pe care
un proxy poate s-1 trimit unui server. El specific pagina pe care o vrea proxy-ul i momentul
la care pagina din memoria ascuns a fost modificat ultima dat (din antetul Last-Modified).
Dac pagina nu a mai fost modificat de atunci, serverul trimite napoi un scurt mesaj Not
Modified (codul de stare 304 din Figura 3.12.), care indic proxy-ului s utilizeze pagina din
memoria ascuns. Dac pagina a mai fost modificat de atunci, este returnat noua pagin. n
timp ce pentru aceast abordare este ntotdeauna nevoie de un mesaj de cerere i unul de rspuns,
mesajul de rspuns va fi foarte scurt cnd intrarea n memoria ascunsa este nc valid.
Aceste dou abordri pot fi combinate uor. Pentru primul AT dup aducerea paginii,
proxy-ul doar returneaz pagina clienilor ce o cer. Dup ce pagina a stat un timp n memoria
ascuns, proxy-ul utilizeaz mesajul If-Modified-Since pentru a verifica valabilitatea acesteia.
Alegerea AT implic invariabil o euristic, depinznd de ct de mult timp a trecut de la
modificarea paginii.
Paginile Web cu coninut dinamic (de exemplu, cele generate de un script PHP) nu ar
trebui niciodat pstrate n memoria ascuns, deoarece parametrii pot fi diferii la urmtoarea
61
accesare. Pentru a trata aceasta i alte cauze, exist un mecanism general prin care un server
instruiete toate proxy-urile pn la client s nu foloseasc din nou pagina curent pn nu i
verific valabilitatea. Acest mecanism poate fi folosit de asemenea pentru orice pagin pasibil
s fie modificat curnd. Diverse mecanisme dc control al memoriei ascunse sunt definite n
RFC 2616.

Figura 3.11. Cteva antete de mesaje HTTP.

Figura 3.12. Grupuri de rspunsuri ale codurilor de stare.

Mai exis o abordare n mbuntirea performanei, memoria ascuns proactiv. Cnd un
proxy aduce o pagin de la un server, el poate inspecta pagina pentru a vedea dac ea conine
hiper-legturi. Dac este aa, poate s lanseze cereri serverelor corespunztoare pentru a
prencrca n memoria ascuns paginile la care puncteaz, pentru cazul n care va fi nevoie dc
ele. Aceast tehnic poate reduce timpul de acces pentru cererile ulterioare, dar poate, la fel de
bine, s inunde liniile de comunicaie cu pagini care nu vor fi niciodat necesare.

3.9 Aplicaia SNIEP

n vederea actualizrii on-line a bazei de date , este realizat o aplicaie de inere n
actualitate a bazei de date de evidena persoanelor, aplicaie realizat folosind tehnologia WEB.

62
 Lansarea n execuie a aplicaiei se face tastnd n bara de adrese al browserului a adresei
http:\\adresa_ip\cgi-bin\w_evp.exe, (adresa_ip reprezint adresa de IP a serverului bazei de date),
moment n care se va ncrca pagina de conectare la aplicaie.

Dup ce utilizatorul completeaz toate cmpurile, aplicaia verific n cataloage dac este
un utilizator valid, dac grupul din care face parte are acces la aceast aplicaie, dac drepturile
de acces nu i-au fost revocate. Dac toate condiiile sunt ndeplinite, utilizatorului i se va afia
pagina pentru selecia modulelor aplicaiei.

63
 n caz contrar, utilizatorul va fi redirectat ctre o pagin web unde va fi explicat motivul
pentru care nu se poate realiza conectarea la baza de date.

Principalele module ale aplicaiei sunt:

Administrare operatori - conine submodule de administrare drepturi de acces, administrare
parole, administrare utilizatori (introducere/tergere din UPM)
nregistrare migrri externe
nregistrare persoane
nregistrare deces
Conectare la BDJ - se realizeaz conectarea la baza de date judeean de eviden a persoanelor,
pentru inerea n actualitate a R.J.E.P, http://10.0.1.199/cgi-bin/srch_bd.exe
Conectare la MVS - se realizeaz conectarea la baza de date central de eviden a persoanelor,
prin aplicaia http://adresa_ip/cgi-bin/w_srch.exe.

64
4. Consistena Sistemelor distribuite i Toleranta la defecte

4.1. Modele de consisten

n mod tradiional, consistena este tratat n contextul operaiilor de citire/scriere a

datelor partajate, fie prin memorie partajat, fie prin baze de date distribuite partajate, fie prin
sisteme de fiiere distribuite. Vom folosi, pentru a denumi acest context vast, termenul de data
store - depozit de date.
Un model de consisten este un contract ntre procese si depozitul de date - daca
procesele respecta un numr de reguli, depozitul de date funcioneaz corect.
Printre modelele de consisten centrat pe date avem urmtoarele posibiliti (exprimate prin
contractul dintre procese si depozitul de date), ce sunt potrivite pentru diverse tipuri de sisteme.
Consisten stricta. - orice citire a datei x ntoarce o valoare egala cu rezultatul celei mai
recente scrieri a lui x.
Consistenta secveniala - rezultatul oricrei execuii este acelai ca si cnd toate
operaiile de citire/scriere ale tuturor proceselor pe depozitul de date ar fi executate intr-o
ordine si toate operaiile din fiecare proces individual apar n aceasta secven n ordinea
specificata n programul acestora. - Mai precis toate procesele vad toate operaiile de scriere n
aceeai ordine (acest model este mai puin restrictiv dect cel strict)
Consistenta cauzala - operaiile de scriere ce sunt legate cauzal sunt vzute de toate
procesele n aceeai ordine, iar scrierile concurente (nelegate cauzal) pot fi vzute n diverse
ordini pe diverse maini. (acest lucru poate fi realizat prin marcaje de timp de tip vector, i este
un model mai puin strict dect cel secvenial)
Consistenta FIFO - scrierile executate de un singur proces sunt vzute de celelalte
procese n ordinea execuiei, dar scrierile de la procese diferite pot fi vzute n ordini diferite de
ctre procese diferite.
Consistenta slaba - (introduce noiunea de variabila sincronizata - ce permite ca dup
efectuarea unei modificri asupra unei copii locale sa fie sincronizate toate copiile din sistem)
accesele la variabile sincronizate sunt consistente secvenial, variabilele sincronizate nu sunt
disponibile pn cnd scrierile anterioare s-au ncheiat si operaiile pe date nu sunt permise
pn ce operaiile pe variabile sincronizate nu s-au ncheiat. ( practic se impune parial
consistenta secveniala pe un grup de operaii, nu pe toate).
Exist si alte modele, dar aici s-au enumerat cele mai importante. Consistena stricta este
65
cea mai apropiata de ideal, dar implementarea ei in sisteme distribuite este practic imposibil,
deci nu este folosita dect ca termen de comparaie. Consistena secvenial este mai slaba si este
bazata pe ceasuri sincronizate si destul de uor de programat,. dar ofer performante slabe.
Consistenta cauzala si cea slaba sunt modele i mai puin restrictive n care nu exist un
acord asupra viziuni globale asupra operaiilor pe depozitul de date.
Exist si modele de consistenta centrate pe client.
Protocoalele de consisten sunt implementri ale modelelor de consisten. n cadrul
implementrilor consistenei secveniale avem, de exemplu protocolul bazat pe principal
(primary-based) n care toate operaiile de modificare sunt trimise spre copia principala ce
asigura ordinea potrivita a operaiilor i le retransmite copiilor. Avem de asemenea protocoale
replicated-write, n care o modificare este trimisa la toate replicile n acelai timp, caz n care
ordonarea corecta a operaiilor devine mai dificil.

4.2. Protocoale de distribuie

Un aspect major de proiectare a depozitelor distribuite de date este de a decide unde, cnd
si de ctre cine sunt plasate copii ale datelor. Astfel putem avea:
a) replici permanente - fie exist mai multe replici pe mai multe computere i la orice cerere
se desemneaz computerul ce va rspunde printr-o strategie de tip round-robin; fie se
folosete mirroring si clientul alege computerul ce va trebui sa rspund la cerere;
b) replici iniiate de server - un algoritm de replicare dinamica iniiata de server, presupune
decizia de a scdea ncrcarea serverului si apoi migrarea si replicarea informaiei n
proximitatea clienilor cei mai activi;
c) replici iniiate de client - acestea sunt mai degrab cunoscute ca cache client, fiind
folosite pentru creterea performantei
Propagarea modificrilor, iniiate n general de client si adresate uneia din copii, trebuie
efectuat pentru a asigura consistena.
Mecanismele de implementare a propagrii pot fi
- propagarea unei notificri de modificare - rezult protocoale de invalidare, deoarece n urma
notificrii datele referite devin invalide n copii nemodificate; acestea au avantajul de a
economisi lime de banda;
- transferul valorilor de la o copie la alta -

66
- propagarea operaiei de modificare la celelalte copii - denumita si replicare activa, are
avantajul de a consuma putina lime de banda (comenzile sunt mai scurte dect ansamblul
datelor) dar pot consuma timp procesor din nou, pe toate replicile, in cazul operaiilor
complexe (timp ce ar fi economisit n cazul n care se transfera ansamblul datelor).
Propagarea poate fi automata, cu protocoale bazate pe server (push-based approach) sau la cerere
din partea replicii cu protocoale bazate pe client (pull-based approach).
Funcie de necesitile de consisten se poate folosi una din cele doua abordri.
Exista n plus aa-numitele protocoale epidemice, al cror scop este sa propage modificrile n
ct mai puine mesaje posibile. Un model este cel antientropie, n care o replic alege aleatoriu o
alta replic i i transfera modificrile: fie primul le trimite (push) celuilalt, fie primul le extrage
(pull) de la cellalt, fie schimb ntre ei modificrile (push-pull approach).

4.3. Toleranta la defecte

Un aspect prin care sistemele distribuite se disting de cele nedistribuite este defectarea
parial, adic defectarea unei singure componente din sistem. Aceasta atrage dup sine
comportamentul defectuos al altor componente lsndu-le pe celelalte neafectate. Unul din
elurile importante ale unui sistem distribuit este acela de a construi sisteme ce pot fi recuperate
n mod automat din defectare parial fr ca performana global s fie afectat.
n continuare vom prezenta tehnicile prin care un sistem distribuit devine tolerant la
defecte, fcnd mai nti o introducere n noiunile legate de tolerana la defecte, apoi referindu-
ne la reziliena proceselor i la multicasting de ncredere (reliable multicasting). Reziliena
proceselor corespunde unor tehnici prin care unul sau mai multe procese se pot defecta fr a
afecta comportamentul restului sistemului, iar multicastingul sigur, unor tehnici prin care
transmiterea unui mesaj ctre o colecie de procese are reuita garantat.

4.3.1. Introducere n toleranta la defecte

Conceptul de baz pentru studierea toleranei la defecte este dependabilitatea,

caracteristic ce acoper un numr de cerine printre care cele mai importante sunt:
- Disponibilitatea - este proprietatea unui sistem de a fi gata de utilizat n orice moment;
- ncrederea - este proprietatea unui sistem de a funciona continuu fr a se defecta;

67
 - Sigurana - este proprietatea unui sistem ca, n caz de defectare, acest incident s nu
atrag dup sine consecine catastrofale;
- Mentenabilitatea - este o proprietate care exprim ct de uor este de reparat un sistem n
cazul n care se defecteaz.
Uneori, o alt cerin inclus n conceptul de dependabilitate este securitatea sistemului.
Un sistem se defecteaz cnd nu funcioneaz conform specificaiilor sale. O eroare este o parte a
strii sistemului ce poate conduce la defectare. Cauza unei erori se numete defect.
Construirea unui sistem cu nivel nalt de dependabilitate este strns legat de controlul
defectelor ce pot aprea, pe de o parte prin prevenirea, nlturarea sau prevederea defectelor i pe
e alta prin asigurarea toleranei la defecte, ceea ce nseamn c sistemul funcioneaz corect chiar
i n prezenta defectelor. Defectele pot fi:
- tranziente: apar i dispar de la sine;
- intermitente: apar, dispar i apoi reapar - sunt dificil de diagnosticat;
- permanente: defecte ce continu s existe pn cnd componenta defect este reparat.

4.3.2. Modele de defectare i mascarea defectrii prin redundan

Dac considerm un sistem distribuit ca o colecie de servere ce comunic ntre ele i cu

clienii lor, defectarea poate aprea la nivelul serverelor, a canalelor de comunicaie sau la
amndou.
Modurile n care un sistem se poate defecta sunt de diverse categorii:
- de tip crash - serverul se oprete din funcionare, dar a funcionat corect pn la oprire;
- de tip omisiune - serverul nu rspunde ca cererile ce i sunt adresate:
- omisiune la primire - serverul nu priete cererile;
- omisiune la transmitere - serverul nu poate transmite rspunsuri;
- de sincronism - serverul rspunde, dar n afara intervalului de timp prevzut;
- legat de rspuns - rspunsul serverului este incorect:
- legat de valoare - valoarea rspunsului este greit;
- legat de tranziia de stare - serverul deviaz de la fluxul corect de aciune;
- de tip arbitrar - un server poate produce rspunsuri arbitrare n momente de timp
arbitrare.

68
 Acestea din urm sunt cele mai serioase tipuri de defecte. O categorie particular este
aceea cnd serverul produce rspunsuri incorecte ce nu pot fi depistate ca fiind incorecte.
Defectarea arbitrar este strns legat de defectarea de tip crash.
Pentru ca un sistem s fie tolerant la defecte este foarte important sa ncerce s ascund
apariia unui defect de celelalte procese din sistem. O tehnic cheie de mascare a defectrii este
folosirea redundanei. Tipurile de redundan sunt:
- redundan a informaiei - se realizeaz prin adugarea de bii (coduri detectoare i
corectoare de erori) ce permit recuperarea informaiei distorsionate;
- redundant de timp - repetarea unei aciuni atunci cnd aceasta se impune; folosirea
tranzaciilor este un bun exemplu de redundan de timp, aceasta fiind foarte folositoare
n cazul defectelor tranziente sau intermitente.
- redundan fizic - poate fi de tip hardware sau software i implic adugarea de
echipamente, respectiv procese, astfel nct la defectarea unei componente, componenta
de rezerv s o nlocuiasc n funcionare.
O variant de redundan fizic se obine prin multiplicarea unei componente critice i
aplicarea pe rspunsurile furnizate de colecia de componente identice a unui mecanism de
votare prin majoritate, care s ofere rspunsul corect celorlaltelor componente din sistem chiar
dac una din componentele din colecie s-a defectat (pentru a tolera K defectri ale
componentelor trebuie prevzute 2k+1 componente identice pentru a putea asigura majoritatea la
ieire).

4.3.3. Reziliena proceselor i m ascarea defectelor i replicarea

Aceast tehnic permite replicarea proceselor n grupuri de procese. Vom considera

modul n care se proiecteaz grupuri de procese, cum se ajunge la un grup tolerant la defecte i
modul n care se ajunge la acord n cadrului unui grup cnd unul sau mai muli membri sunt
suspeci de a da rspunsuri incorecte.
Principala proprietate a unui grup de procese identice este aceea c atunci cnd se
transmite un mesaj ctre unul din procese din grup toi membrii primesc acel mesaj. n acest fel,
dac un proces se defecteaz celelalte pot continua n locul lui. Grupurile de procese pot avea un
caracter dinamic, n sensul n care grupurile pot fi create sau distruse, un proces se poate altura

69
unui grup sau poate prsi grupul n timpul funcionrii sistemului. n consecin se impun
mecanisme de administrare a grupurilor i a apartenenei la grup.
Grupurile pot fi difereniate prin structura intern. Astfel, pot exista grupuri n care
procesele sunt egale i deciziile se iau colectiv (flat group). Alte grupuri pot avea o structur
ierarhic, cuprinznd un proces coordonator i mai multe procese executive. Fiecare din aceste
moduri de organizare intern prezint avantaje i dezavantaje: n grupurile plate, la defectarea
unui proces grupul continu s funcioneze dar modul de luare a deciziilor este mai complicat, pe
cnd la cele ierarhice exist o dependen foarte mare de buna funcionare a procesului
coordonator.
n condiiile comunicrii de grup sunt necesare metode de manipulare a grupurilor i a
proceselor. O abordare const din existena unui server de grupuri care s cuprind evidena
tuturor grupurilor i a proceselor componente. Din nefericire aceast metod are dezavantajul de
a avea un punct important de defectare i anume, dac serverul de grup de blocheaz gestiunea
grupurilor nu mai este accesibil. O metod complet diferit este de a implementa apartenena la
grup n mod distribuit, printr-un protocol de comunicaie care s permit aderarea sau prsirea
unui grup de ctre un proces. Aceast metod presupune existena comunicaiei de ncredere ntre
membrii grupului.
Dou moduri de replicare sunt luate n considerare pentru mascarea defectelor prin
replicare:
- replicarea bazat pe un proces primar - se aplic n cazul grupurilor ierarhice, procesul
primar fiind coordonatorul grupului, mai ales n privina operaiilor de scriere; n cazul n
care procesul primar se defecteaz celelalte procese trec printr-un algoritm electiv prin
care dintre ele se desemneaz un nou proces primar
- replicarea prin protocoale de scriere - acestea pot fi realizate fie prin replicare activ, fie
prin protocoale bazate pe cvorum i corespund grupurilor plate de procese.
Un punct de vedre important in economia toleranei la defecte este estimarea factorului
de replicare necesar. Un sistem se numete tolerant la k defecte dac poate supravieui dup ce
defecte n k componente. De regul, pentru componente care se defecteaz i se opresc din
funcionare, pentru asigurarea acestei caracteristici sunt necesare k+1 procese. Dac defectarea
componentelor presupune rspunsuri incorecte ale componentelor defectate, sunt necesare 2k+1
componente identice pentru a putea asigura majoritatea rspunsului corect asupra celor incorecte.

70
 4.3.4. Punerea de acord n sisteme cu funcionare defectuoas

Punerea de acord n cadrul unui grup de procese n privina unei decizii poate aprea n
mai multe cazuri cum ar fi: alegerea unui nou coordonator, efectuarea sau nu a unei tranzacii,
mprirea sarcinilor ntre procese, sincronizarea. n condiiile n care comunicaia este perfect i
procesele funcioneaz corect punerea de acord se realizeaz n mod trivial; pe noi ns nu cazul
perfect ne intereseaz. Ideea este ca toate componentele fr defecte s ajung la consens ntr-un
numr finit de pai.
S luam n considerare situaia n care dou componente ncearc s se pun de acord n
privina unei aciuni comune, sincronizate, n condiiile unei comunicaii care nu este de
ncredere:
Pasul1. O component propune o soluie i o transmite celei de a doua; Pasul2. A doua
component primete mesajul i transmite confirmare celeilalte; Pasul3. Prima componenta
primete mesajul i punerea de acord ar fi ncheiat dac nu ar fi cazul comunicaiei lipsite de
ncredere - pentru ca a doua component s fie ntiinat c mesajul de confirmare a ajuns cu
succes, prima component i trimite un mesaj de confirmare a confirmrii. Urmeaz, desigur,
confirmarea confirmrii confirmrilor, amd. In continuare, oricare ar fi mesajul final al unui
protocol de punerea de acord, se va ajunge n situaia n care transmitorul acestui mesaj final nu
poate ti dac el a ajuns la destinaie. n consecin, fr o comunicaie de ncredere, punerea de
acord ntre 2 procese nu se poate realiza.
S considerm cazul unei comunicaii de ncredere ntre procesele ce urmeaz s se pun
de acord. Problema pe care o vom supune ateniei n continuare se numete problema
generalilor bizantini: este necesar punerea de acord a n generali ce au la ndemn
telefoane ce le permit s comunice instantaneu i perfect doi cte doi, dintre cei n generali
m sunt trdtori, adic furnizeaz informaii greite i contradictorii. Scopul problemei
este ca generalii s-i transmit unii altora efectivul trupelor.
Un algoritm propus de Lamport funcioneaz astfel:
Pasul 1. fiecare general transmite celorlali efectivul trupelor sale.
Pasul 2. fiecare general formeaz un vector de valori cu efectivul trupelor sale i cele
primite de la ceilali.
Pasul 3. Fiecare general trimite acest vector tuturor celorlali generali.
Pasul 4. Fiecare general compar valorile din vectorii primii, aplicnd pentru fiecare

71
poziie din vector un operator de majoritate pentru a stabili valoarea corect.
Acest algoritm funcioneaz corect doar dac n este mai mare sau egal cu 3m+1.

4.4. Comunicaie de ncredere client-server

n continuare ne vom concentra atenia pe defectele legate de comunicaia dintre

componentele unui sistem.
n cazul comunicaiei punct-la-punct pentru a obine o comunicaie de ncredere se poate
folosi un protocol de transport cum ar fi TCP. TCP ascunde defectarea de tip omisiune prin
confirmri i retransmisii. Defectarea de tip crash nu este ascuns, caz n care clientul este
informat prin ridicarea unei excepii. Modul n care un sistem distribuit poate masca o astfel de
defectare este prin tentativa de a deschide un nou canal de comunicaie.
n cazul unui nivel mai nalt de comunicaie, cum ar fi Remote Procedure Call sau
Remote Methos Invocation pot aprea urmtoarele tipuri de defecte generate de comunicaie:
1. Clientul nu poate localiza serverul. Aceast situaie poate aprea, de ex. cnd serverul nu
este pornit. O posibil soluie este ridicarea unei excepii, ca n Java, sau trimiterea unui
semnal, ca n C.
2. Mesajul de cerere de la client s-a pierdut. Soluia n acest caz este de a porni un contor de
timp la momentul emiterii cererii i dac ntr-un timp determinat nu se primete un
rspuns sau o confirmare, cererea este retransmis. Dac mesajul nu a fost de fapt
pierdut, singura problem este ca serverul s poat distinge ntre mesajul original i cel
retransmis.
3. Serverul cade dup primirea mesajului. De regul, la nivelul serverului manipularea unei
cereri de la client const n primire, execuie i transmitere rspuns. Tratamentul difer
ntre cazul n care serverul cade nainte sau dup execuia cererii. De aceea, exist mai
multe abordri:
Tehnica "mcar o dat" n care se ateapt ca serverul s reporneasc, clientul
continund s retransmit cereri pn primete un rspuns;
Tehnica "cel mult o dat" n care clientul renun imediat i raporteaz eroare;
4. Rspunsul serverului s-a pierdut. O soluie evident este pornirea unui contor de timp i
retransmiterea cererii cnd contorul expir. Apar ns probleme la cereri care nu se pot

72
 repeta fr grij, cum ar fi transferul unui miliard dintr-un cont ntr-altul. O alt soluie
const n asignarea unui numr fiecrei cereri, astfel serverul avnd posibilitatea s
disting ntre o cerere original i una retransmis.
5. Clientul cade dup trimiterea cererii. n aceste condiii, s-a iniiat o operaie care rmne
fr procesul printe cruia s-i transmit rezultatul. Un astfel de proces se numete
orfan. Pentru eliminarea orfanilor exist mai multe politici posibile:
Exterminarea - un mesaj RPC este nregistrat ntr-un fiier jurnal, iar la repornire se
verific acest fiier i orfanul este ucis n mod explicit;
Rencarnarea - se bazeaz pe conceptul de epoc de timp numerotat cresctor i
presupune ca la repornirea clientului acesta s anune toate celelalte componente c a
nceput o nou epoc; n consecin toi orfanii din epoca anterioar pot fi identificai
i ucii
Expirarea - n care fiecrei operaii la distan i se asociaz un timp standard de
execuie, care este prelungit explicit dac timpul respectiv nu este suficient; n cazul
n care nu are cine s-i acorde timp suplimentar, orfanul este ucis. Totui, uciderea
orfanilor poate pune diverse probleme, cum ar fi cazul n care orfanul a blocat accesul
la fiiere sau alte resurse, ce vor rmne blocate dup uciderea procesului.

5. Replicarea serverelor, Backup

73
5.1. Noiuni introductive

Memoria ascuns este o tehnic orientat spre client pentru mbuntirea performanelor, dar
exist i tehnici orientate pe server. Cea mai ntlnit abordare pentru mbuntirea
performanelor serverelor este replicarea coninutului lor n mai multe locuri separate. Aceast
tehnic este cteodat denumit oglindire (mirroring).
Replicarea bazelor de date nu este altceva dect copierea, att a structurii, ct i a coni-
nutului unei baze de date, astfel nct s se menin consecvena datelor ntre cele dou baze de
date.
Exist dou modaliti fundamentale de replicare a bazelor de date: varianta sincron i
cea asincron. Cu replicarea sincron toate copiile, numite i replici ale datelor, sunt pstrate
perfect sincronizate i consecvente. Dac o copie oarecare este actualizat, modificrile vor fi
aplicate imediat tuturor celorlalte baze de date din aceeai tranzacie. Cnd pentru aplicaia
economic este important aceast consecven exact, este indicat utilizarea unei replicri
sincrone. n cazul replicilor asincrone, atunci cnd o copie este actualizat, modificrile se vor
propaga i vor fi aplicate celorlalte copii ntr-o etap urmtoare, n tranzacii separate, care ar
putea apare cu o ntrziere de secunde, minute sau chiar zile. De aceea copiile pot fi temporar
desincronizate, dar cu timpul datele ar trebui s convearg ctre aceleai valori ca n replicile
sincrone.

5.2. De ce replicare?

Un aspect important n sistemele distribuite este replicare datelor. Scopul acestei replicri
este de a creste disponibilitatea acestora, precum si de a spori performanta sistemului. Una din
marile probleme legate de replicare este ca dac o copie este modificat, toate copiile trebuie
modificate, altfel consistenta sistemului este compromisa.
Replicarea este n acelai timp o tehnic de scalabilitate a sistemelor, deoarece de ndat
ce numrul de resurse creste mult (n dimensiune, n numr de utilizatori) existenta unei singure
surse de date poate deveni un aspect critic n meninerea performantei sistemului.
Replicarea este procesul de copiere si meninere a datelor in mai multe baze de date ce
alctuiesc baza de date distribuita. n primul rnd, ideea principala din spatele replicrii este
aceea ca o operaie de re mprosptare este efectuata mai nti local, dup care este propagata
unei alte remote replica database (replica bazei de date la distanta) aparinnd unui singur sistem
74
complet (care devine distribuita). Teoretic, presupunnd ca nu sunt ntrzieri datorita
sincronizrii si conflicte ale tranzaciilor de reamprosptare, acest sistem va asigura utilizatorului
un mod rapid si constant de regsire a informaiei cu acces alternativ la date.

5.2.1. Sporirea performantei

Nevoia replicrii se dovedete in cazul in care un singur sistem de baza de date are de a
face cu un numr sporit de operaii de citire din parte clienilor pe care nu le poate satisface in
timp util. mprirea datelor stocate cu alte replici, nseamn distribuirea (mprirea) traficului,
care la-nceput a fost dirijat catre un singur server, numit fenomen de strmtorare (fenomen
bottleneck), ctre mai multe destinaii. Astfel pot fi numai beneficii atta timp cat ne ngrijoreaz
timpul de rspuns pentru cererile fiecrei aplicaii. Sporirea performantei este mai vizibila in
cazurile in care exista mai multe operaii de citire dect operaii de remprosptare. Acest lucru
poate fi verificat uor, prin verificarea raportului citire/ remprosptare e(read-update ). Cu cat
acest numr este mai mare, cu att mbuntirile duse prin folosirea unui sistem de replicare este
mai mare. mbuntirile aduse timpului de rspuns pot fi mai mari daca sistemul deine o
interfaa inteligenta fata-spate (front-end), care poate sa schimbe cererile ctre o anume baza de
date distribuita, depinznd de locul unde se gsete clientul.

5.2.2. Sporire a disponibilitii i robusteii

Replierile ofer un mare avantaj al disponibilitii si robusticitii al serviciului ctre

aplicaia client, si astfel ctre utilizator (end-user). Cu cat un sistem distribuit are mai multe
replicri, cu att riscul de a avea eroare la rspuns scade mai mult. Sigur acest lucru depinde de
interfaa front-end, ca acesta sa fac trecerea la alta sursa de date cnd una dintre ele nu este
disponibila.

5.2.3. Transparenta replicrii

Transparenta intr-un sistem distribuit este menit sa ascund arhitectura si mecanismul

sistemului prin care se realizeaz comunicarea cu clientul, facondu-l pe acesta sa perceap
sistemul ca un tot unitar si nu ca un ansamblu de diferite elemente. Cnd este aplicat replicrii,
transparenta are rolul de a ascunde orice replicri din sistem. Acest lucru este realizat prin
75
folosirea unei interfee intre client si sistem, numit fata-spate (front-end ).
Mecanismul front-end schimba mesajele care vin de la aplicaia client ctre un manager de
replicri (replica-manager), depinznd de multe criterii, care asigura ca mecanismele front-end
opereaz independent unul de altul: in particular, arhitectura care sta la baza sistemului, tipul
operaiei (citire / scriere), originea, etc.

5.3. Backup

Replicarea datelor a devenit mult mai acceptat ca o metod de backup. Se tie ct de

important este pentru un administrator de sistem s dein o metod de recuperare a datelor care
s funcioneze bine n caz de nevoie. Astfel, replicarea datelor este posibil s fie o foarte bun
soluie de securitate i confort n ceea ce privete asigurarea faptului c datele firmei sunt
protejate.
Replicarea bazelor de date ajut la rezolvarea multor probleme cu care ne-am putea con-
frunta n cazul sistemelor distribuite. Replicarea bazelor de date n sisteme ce aparin unor oficii
de subramur permit utilizatorilor oficiilor de subramur s acceseze o copie local a datelor n
loc s acceseze un server central prin link-uri WAN. De asemenea replicarea bazelor de date ar
putea suplimenta planurile de recuperare n urma dezastrelor prin duplicarea datelor de la un
server local de baze de date la un server de baze de date la distan. Dac primul server cade,
aplicaiile pot comuta pe copia replicat a datelor i operaiile de actualizare asupra datelor pot
continua. Multe produse de replicare a bazelor de date au i unelte ncorporate pentru a permite
actualizarea primei baze de date cu orice modificri pe care utilizatorii le-au fcut bazei de date
backup n timp ce prima baz de date a fost offline.
Dac avem un singur sistem de gestiune a bazelor de date (SGBD), atunci probabil nu va
fi nevoie de un produs de replicare a bazelor de date, deoarece bazele de date ca Microsoft
SQLServer, Oracle i DB2 ofer caracteristici interne de replicare, care s copieze datele n baze
de date asemntoare, cu ajutorul programelor de BACKUP specifice mediului de lucru la
anumite perioade.
Totui, dac avem SGBD-uri multiple, un produs de replicare a bazelor de date poate
ajuta, deoarece nici-unul din produsele majore de baze de date nu asigur tehnologii prea bune
pentru lucrul cu replici ale bazelor de date aparintoare altor firme.
Atunci cnd se cumpr produsele de replicare a bazelor de date trebuie verificat care
platforme de baze de date sunt suportate de ctre produs, care tipuri de replicri sunt oferite de
76
produs (de exemplu tipurile snapshot, near-realtime, two-way), dac produsul suport replici
planificate, ce mecanisme declaneaz replicarea, dac procesul de replicare este controlat sau nu
prin program i ce tipuri de obiecte de baze de date pot fi replicate. De asemenea trebuie
determinat dac se pot face modificri de schem, dac produsul suport transformri de date i
dac produsul suport calcularea unor noi cmpuri n tabele replicate.
n plus fa de aceste caracteristici de baz ale produsului e necesar s ne asigurm de
faptul c produsul de replicare a bazei de date pe care l-am ales este compatibil cu mediul
aplicaiei noastre. Unele produse de replicare a bazelor de date ar putea necesita modificri ale
sistemului care ar putea face incompatibil baza noastr de date cu aplicaiile noastre.
Produsele de replicare a bazelor de date pot furniza un mecanism eficient pentru distribu-
irea datelor i meninerea unor backup-uri, care s poat fi folosite dac ar avea loc o cdere de
sistem. n orice caz ns produsele de replicare a bazelor de date vor trebui testate i evaluate n
mediul de lucru propriu, deoarece fiecare mediu este diferit i ar putea reaciona ntr-un mod
neateptat.

6. Securitate

77
 Unul din principiile de mare importan pentru sistemele distribuite este securitate. Este,
de asemenea, unul dintre principiile cel mai dificil de implementat, deoarece o singur greeal
de proiectare poate face toate msurile de securitate inutile.
Securitatea sistemelor distribuite poate fi mprit n dou pri:
- Securitatea comunicaiei dintre utilizatori i procese - unul din mecanismele ce pot
asigura o comunicaie sigur este canalul sigur de comunicaie (secure channel);
- Autorizarea - reprezentnd respectarea drepturilor de acces ale proceselor la resurse -ce
se realizeaz prin mecanisme de control al accesului.
Ambele aspecte ale securitii necesit utilizarea de chei criptografice.

6.1. Noiuni introductive

Vom defini, n cele ce urmeaz, un sistem sigur. Vom face separarea ntre politica de
securitate i mecanismul de securitate.

6.2. Ameninri de securitate, politici i mecanisme

O noiune strns legat de securitate n sistemele distribuite este cea de dependabilitate.

Aceasta include: disponibilitatea, ncredere, siguran i mentenabilitate. Pentru a putea avea
ncredere ntr-un sistem, trebuie s lum n considerare i:
- confidenialitatea - proprietatea unui sistem de a dezvlui informaii doar prilor
(prin parte se nelege actor, agent, etc., n sensul contractelor comerciale) autorizate;
- integritatea - proprietatea unui sistem de a fi alterat (la nivel hardware, software
sau de date) doar n moduri autorizate sau, mai precis, orice alterare improprie s poat fi
detectat i recuperat.
Sunt patru categorii de ameninri de securitate ce trebuie luate n calcul:
- interceptarea - o parte neautorizat obine acces la servicii sau date (spionaj);
- ntreruperea - o parte neautorizat atac un sistem n scopul interzicerii accesului
autorizat la date i servicii (bruiaj);
- modificarea - cuprinde modificarea neautorizat a datelor sau a serviciilor astfel
nct acestea s nu mai corespund specificaiilor iniiale;
- fabricarea - date sau activiti suplimentare, ce nu ar fi putut s apar, sunt
generate (furnizarea de informaii false).
78
Ultimele trei tipuri de ameninri se clasific drept forme de falsificare. Modul n care se
construiete un sistem sigur ncepe cu stabilirea politicii de securitate, adic descrierea cerinelor
de securitate. Aceasta cuprinde descrierea precis aciunilor permise i interzise entutilor din
sistem. Entitile pot fi: utilizatori, dervicii, date, maini, etc. Dup ce a fost stabilit politica de
securitate, sunt alese mecanismele prin care aceast politica poate fi implementat.
Cele mai importante mecanisme de securitate sunt:
- criptarea - este un mecanism de implementare a confidenialitii, deoarece datele sunt
transformate ntr-o exprimare neinteligibil;
- autentificare - const n verificarea identitii entitilor participante la funcionarea sistemului;
utilizatorii sunt, de pild, autentificai pe baz de parole, dar exist multe alte mijloace;
- autorizarea - const n verificarea permisiunii de a accesa date sau efectua operaii de ctre
entitatea autentificat;
- controlul - dei nu este un mecanism de securitate n sensul prevenirii atacurilor, controlul
activitii entitilor din sistem (realizat pe baz de fiiere jurnal de exemplu) este util n
analizarea modului n care mecanismele de securitate existente conduc la implementarea politicii
de securitate dorite.

6.3. Elemente de proiectare

Dintre multiplele aspecte ce trebuie luate n calcul la implementarea de servicii de

securitate de scop general ne vom concentra atenia pe: subiectul controlului, stratificarea
mecanismelor de securitate i simplitate.
Din punct de vedere al controlului de securitate exercitat exist trei abordri:
- orientat pe protecia datelor - n acest caz principala grij este integritatea datelor, ca n
cazul sistemelor de baze de date n care la modificarea unui item se efectueaz diverse verificri
a constrngerilor de integritate;
- orientat pe accesul la operaii sau date - caz n care sunt specificate pentru fiecare din
entitile accesabile ale sistemului lista clienilor ce o pot accesa;
- orientat pe utilizator - caz n care controlul este axat pe rolurile diverilor utilizatori,
permind sau interzicnd accesul la aplicaii funcie de rolul utilizatorului curent.
Stratificarea mecanismelor de securitate se ocup cu stabilirea nivelului la care sunt
plasate acestea n organizarea sistemului (Figura 6.).

79
 Figura 6 Organizarea logic pe straturi a unui sistem distribuit.
De exemplu, se poate asigura securitate plasnd dispozitive de criptare/decriptare pentru
comunicaia ntre dou site-uri (reele locale). Aceste dispozitive ns nu au nici o contribuie
asigurarea unei comunicaii sigure n cadrul unui site. S spunem c pentru a lua msuri
suplimentare de securitate, se folosete un serviciu de securitate de nivel transport cum ar fi SSL
(Secure Socket Layer). La alegerea unui mecanism de securitate, n aceste condiii, clientul
trebuie s aib ncredere c respectivul mecanism va funciona conform cu specificaiile sale.
De asemenea, plasarea serviciilor de securitate n middleware depinde de nivelul de
securitate al serviciilor din nivelele inferioare pe care acestea se bazeaz (de ex. un serviciu sigur
de RPC se bazeaz parial pe SSL, dac acesta din urm nu funcioneaz corect nici RPC-ul nu
mai este sigur)..

7. VPN - Virtual Private Network Comunicaii n Sistemele distribuite

80
7.1. Noiuni introductive

O Reea Virtual Privat (VPN - Virtual Private Network) conecteaz componentele i

resursele unei reele private prin intermediul unei reele publice. Altfel spus, o reea virtual
privat este o reea a companiei implementat pe o infrastructur comun, folosind aceleai
politici de securitate, management i performan care se aplic de obicei ntr-o reea privat.
Practic, tehnologia reelelor virtuale private permite unei firme s-i extind prin Internet, n
condiii de maxim securitate, serviciile de reea la distan oferite utilizatorilor, reprezentanelor
sau companiilor partenere. Avantajul este evident: crearea unei legturi de comunicaie rapid,
ieftin i sigur.
Tehnologiile VPN ofer o cale de a folosi infrastructurile reelelor publice cum ar fi
Internetul pentru a asigura acces securizat i privat la aplicaii i resurse ale companiei pentru
angajaii din birourile aflate la distan sau cei care lucreaz de acas, pentru partenerii de afaceri
i chiar pentru clieni.

Figura 7.1. VPN (Reea Privat Virtual)

O reea VPN poate fi realizat pe diverse reele de transport deja existente: Internetul
public, reeaua furnizorului de servicii IP, reele Frame Relay i ATM. Astzi, tot mai multe
VPN-uri sunt bazate pe reele IP.
Tehnologia VPN folosete o combinaie de tunneling, criptare, autentificare i mecanisme
i servicii de control al accesului, folosite pentru a transporta traficul pe Internet, o reea IP
administrat, sau reeaua unui furnizor de servicii.
VPN permite utilizatorilor s comunice printr-un tunel prin Internet sau o alt reea

81
public n aa fel nct participanii la tunel s se bucure de aceeai securitate i posibiliti puse
la dispoziie numai n reelele private.
Pentru a utiliza Internetul ca o reea privat virtual, de tip WAN (Wide Area Network),
trebuie depite dou obstacole principale. Primul apare din cauza diversitii de protocoale prin
care comunic reelele, cum ar fi IPX sau NetBEUI, n timp ce Internetul poate nelege numai
traficul de tip IP. Astfel, VPN-urile trebuie s gseasc un mijloc prin care s transmit
protocoale non-IP de la o reea la alta. Cnd un dispozitiv VPN primete o instruciune de
transmitere a unui pachet prin Internet, negociaz o schem de criptare cu un dispozitiv VPN
similar din reeaua destinaie. Datele n format IPX/PPP sunt trecute n format IP pentru a putea
fi transportate prin reeaua mondial. Al doilea obstacol este datorat faptului c pachetele de date
prin Internet sunt transportate n format text. n consecin, oricine poate vedea traficul poate s
i citeasc datele coninute n pachete. Aceasta este cu adevrat o problem n cazul firmelor care
vor s comunice informaii confideniale i, n acelai timp, s foloseasc Internetul. Soluia la
aceste probleme a permis apariia VPN i a fost denumit tunneling.
n loc de pachete lansate ntr-un mediu care nu ofer protecie, datele sunt mai nti criptate, apoi
ncapsulate n pachete de tip IP i trimise printr-un tunel virtual prin Internet.
Din perspectiva utilizatorului, VPN este o conexiune punct-la-punct ntre calculatorul
propriu i serverul corporaiei (figura 7.2).

Figura 7.2. Reea Privat Virtual - Echivalent logic

Confidenialitatea informaiei de firm care circul prin VPN este asigurat prin criptarea
datelor. n trecut, reelele private erau create folosind linii de comunicaie nchiriate ntre sedii.
Pentru a extinde acest concept la Internet, unde traficul mai multor utilizatori trece prin aceeai

82
conexiune, au fost propuse o serie de protocoale pentru a crea tuneluri. Tunelarea permite
expeditorului s ncapsuleze datele n pachete IP care ascund infrastructura de rutare i comutare
a Internetului la ambele capete de comunicaie. n acelai timp, aceste pachete ncapsulate pot fi
protejate mpotriva citirii sau alterrii prin diverse tehnici de criptare.
Tunelurile pot avea dou feluri de puncte terminale, fie un calculator individual, fie o
reea LAN cu un gateway de securitate - poate fi un ruter sau un firewall. Orice combinaie a
acestor dou tipuri de puncte terminale poate fi folosit la proiectarea unei reele VPN.
n cazul tunelrii LAN-to-LAN, gateway-ul de securitate al fiecrui punct terminal
servete drept interfa ntre tunel i reeaua privat LAN. n astfel de cazuri, utilizatorii ficecrui
LAN pot folosi tunelul n mod transparent pentru a comunica unii cu alii.
Cazul tunelului client-to-LAN, este cel stabilit de regul pentru utilizatorul mobil care
dorete s se conecteze la reeaua local a firmei. Pentru a comunica cu reeaua de firm, clientul
(utilizatorul mobil), iniiaz crearea tunelului. Pentru aceasta, clientul ruleaz un software client
special, care comunic cu gateway-ul de protecie al reelei LAN.

7.2. Intranet VPN

Permite conectarea diferitelor sedii ale unei firme folosind legturi dedicate (permite
realizarea unor medii client-server foarte performante prin utilizarea conexiunilor dedicate care
pot s ating rate de transfer foarte bune). Diferena fa de Remote Access VPN const n faptul
c se folosesc legturi dedicate cu rata de transfer garantat, fapt care permite asigurarea unei
foarte bune caliti a transmisiei pe lng securitate i band mai larg.

Figura 7.3. Intranet VPN

83
 Arhitectura aceasta utilizeaz dou routere la cele dou capete ale conexiunii, ntre
acestea realizndu-se un tunel criptat. n acest caz nu mai este necesar folosirea unui client de
VPN ci folosirea IPSec. IPSec (IP Security Protocol) este un protocol standardizat de strat 3 care
asigur autentificarea, confidenialitatea i integritatea transferului de date ntre o pereche de
echipamente care comunic. Folosete ceea ce se numete Internet Key Exchange ( IKE ) care
necesit introducerea la ambele capete ale conexiunii a unor chei de autentificare care mai apoi
vor permite logarea reciproc. Schematic conexiunea este prezentat n figura 7.4. :

Figura 7.4. Arhitectura Intranet VPN

7.3. Cerine de baz i soluii pentru implementarea VPN-uri

La adoptarea unei reele virtuale private prin Internet exist dou probleme majore:
securitatea i performana. Protocolul de control al transmisiei (TCP/IP) i Internetul nu au fost
gndite iniial s asigure n principal securitate i performan, deoarece la acea vreme utilizatorii
i aplicaiile lor nu necesitau o securitate puternic i o performan garantat. Din fericire,
standardele pentru securitatea datelor din reelele IP au evoluat, fiind posibil crearea VPN-urilor
folosind reele IP.
n mod normal, cnd proiecteaz o soluie de acces de la distan la o reea, o companie
dorete s permit accesul controlat la resurse i informaii. Soluia trebuie s permit clienilor
autorizai s se conecteze uor la LAN-ul corporaiei, i s permit sucursalelor s se conecteze
ntre ele pentru a pune n comun informaii i resurse (conexiuni LAN-LAN). n plus, soluia
trebuie s asigure securitatea i integritatea datelor cnd traverseaz Internet-ul. Aceleai
preocupri apar i n cazul cnd datele ce trebuie protejate traverseaz inter-reeaua corporaiei.
n consecin, o soluie VPN trebuie s realizeze cel puin urmtoarele funcii vitale:
- Autentificarea utilizatorului. Soluia trebuie s verifice identitatea utilizatorului i s
permit accesul prin VPN numai utilizatorilor autorizai. n plus, soluia trebuie s permit

84
monitorizarea i jurnalizarea activitilor pentru a arta cine i cnd a accesat o anume
informaie.
- Gestionarea adreselor. Soluia trebuie s asocieze unui client o adres din reeaua
privat, i s asigure c adresele private rmn secrete.
- Criptarea datelor. Datele transferate prin reeaua public trebuie fcute ilizibile pentru
clienii neautorizai.
- Gestiunea cheilor. Soluia trebuie s genereze i s mprospteze cheile de criptare
pentru client i pentru server.
- Suport multiprotocol. Soluia trebuie s fie capabil s manevreze protocoalele
existente n reelele publice, cum ar fi Internet Protocol (IP), Internet Packet Exchange (IPX),
etc.
Dup cum am afirmat n partea introductiv, implementarea unui VPN presupune crearea
unui tunel printr-o reea public prin intermediul cruia s fie transferate datele. Ca o definiie,
tunelarea (tunneling) este o metod de folosire a infrastructurii unei inter-reele pentru
transferul datelor dintr-o reea peste o alt reea. Datele de transferat (ncrctura - payload) pot
fi cadrele (sau pachetele) altui protocol. n loc de a transmite cadrul n forma n care a fost
produs de nodul surs, protocolul de tunelare ncapsuleaz cadrul ntr-un antet adiional. Acesta
conine informaii de rutare astfel nct ncrctura ncapsulat poate traversa inter-reeaua
intermediar. Pachetele ncapsulate sunt apoi rutate ntre capetele tunelului prin inter-reea. Calea
logic pe care pachetele ncapsulate o urmeaz n inter-reea se numete tunel (figura 7.5.).
Odat ce cadrele ncapsulate ajung la destinaie prin inter-reea, cadrul este decapsulat i trimis la
destinaia sa final. De notat c tunelarea include ntregul proces: ncapsulare, transmitere i
decapsulare a pachetelor.
Tehnologiile de tunelare exist de ctva timp, printre cele mai cunoscute numrndu-se:
Tunelare SNA peste IP. Cnd traficul SNA este trimis peste o inter-reea IP de
corporaie, cadrul SNA este ncapsulat n UDP si antet IP.
Tunelare IPX pentru Novell NetWare peste IP. Cnd un pachet IPX este trimis
unui server NetWare sau unui ruter IPX, serverul sau ruterul anvelopeaz pachetul IPX
ntr-un UDP cu antet IP, i l trimite apoi peste inter-reeaua IP. Ruterul IP-IPX destinaie
d la o parte UDP-ul i antetul IP, i trimite pachetul ctre destinaia IPX. n ultimii ani au
aprut noi tehnologii de tunelare, tehnologii care stau la baza mplementrilor de VPN
existente:

85
 Figura 7.5. Tunelarea datelor
Protocolul de tunelare punct-la-punct (PPTP). Acesta permite traficului IP,
IPX i NetBEUI s fie criptat i ncapsulat ntr-un antet IP pentru a fi transmis peste o
inter-reea IP de corporaie sau public (Internet).
Protocolul de tunelare pe nivel 2 (L2TP). Acesta permite traficului IP, IPX sau
NetBEUI s fie criptat i transmis peste orice mediu care suport transmisia punct-la-
punct a datagramelor, cum ar fi: IP, X.25, Frame Relay sau ATM.
Tunel bazat pe securitatea IP (IPSec). Acesta permite ncrcturii IP s fie
criptat i apoi ncapsulat ntr-un antet IP pentru a fi transmis peste o inter-reea IP.

7.4. Metode de transmisie prin VPN

Aa cum am vzut, pentru a asigura confidenialitatea datelor ntr-o transmisie pe canale

de comunicaii nesigure, cum este Internetul, pot fi folosite diverse tehnici criptografice. Modul
de transmisie utilizat n cazul unei soluii VPN va determina care pri ale unui mesaj sunt
criptate. Unele soluii cripteaz ntregul mesaj (antetul IP i datele din mesaj), n timp ce altele
cripteaz doar datele. Cele patru moduri (metode) de transmisie ntlnite n soluiile VPN sunt:
In Place Transmission Mode (modul de transmisie in-place) - este de obicei o
soluie specific unui anumit productor, n care doar datele sunt criptate. Dimensiunea
pachetelor nu este afectat, prin urmare mecanismele de transport nu sunt afectate.

86
 Transport Mode (modul transport) - doar segmentul de date este criptat, deci
mrimea pachetului va crete. Acest mod ofer o confidenialitate adecvat a datelor
pentru reele VPN de tip nod-la-nod.
Encrypted Tunnel Mode (modul tunel criptat) - informaia din antetul IP i
datele sunt criptate, anexndu-se o nou adres IP, mapat pe punctele terminale ale VPN.
Se asigur o confidenialitate global a datelor.
Non - encrypted Tunnel Mode (modul tunel necriptat) - nici o component nu
este criptat, toate datele sunt transportate n text clar. Nu se ofer nici un mijloc de
asigurare a confidenialitii datelor.
Dei poate prea ciudat, exist i soluii VPN care nu realizeaz nici un mod de criptare.
n schimb, pentru a oferi un grad de confidenialitate a datelor, ele se bazeaz pe tehnici de
ncapsulare a datelor, cum ar fi protocoalele de tunelare sau forwarding. Nu toate protocoalele de
tunelare i forwarding folosesc un sistem criptografic pentru confidenialitatea datelor, ceea ce
nseamn c toate datele vor fi transmise n clar, punnd sub semnul ntrebrii cum poate o astfel
de soluie s asigure protecia mpotriva interceptrii datelor - cerin critic n cazul reelelor
VPN.
Din nefericire, terminologia utilizat n industria de profil poate s contribuie la apariia
de astfel de confuzii. Pentru clarificarea acestor confuzii, trebuie ca utilizatorul s identifice care
mod de transmisie este folosit. Ca i n cazul autentificrii datelor i a utilizatorilor, modurile de
transmisie trebuie s fie analizate dac sunt criptate sau necriptate. Dac o soluie VPN nu
furnizeaz nici o form de criptare n scopul confidenialitii datelor, atunci aceast soluie poate
fi denumit mult mai corect Virtual Network (VN - reea virtual), din moment ce nimic nu este
privat n aceast reea Internet, ntre surs i destinaie.
Dup cum am afirmat, o reea virtual privat (VPN) este iniiat n jurul unui protocol de
securizare, cel care cripteaz sau decripteaz datele la surs i la destinaie pentru transmisia prin
IP. Pentru realizarea unui tunel, clientul i serverul de tunel trebuie s foloseasc acelai protocol
de tunelare.
Tehnologia de tunelare poate fi bazat pe un protocol de tunelare pe nivel 2 sau 3. Aceste
nivele corespund modelului de referin OSI. Protocoalele de nivel 2 corespund nivelului
legtur de date, i folosesc cadre ca unitate de schimb. PPTP, L2TP i L2F (expediere pe nivel
2) sunt protocoale de tunelare pe nivel 2; ele ncapsuleaz ncrctura ntr-un cadru PPP pentru a
fi transmis peste inter-reea. Protocoalele de nivel 3 corespund nivelului reea, i folosesc

87
pachete. IP peste IP i Tunel IPSec sunt exemple de protocoale care ncapsuleaz pachete IP ntr-
un antet IP adiional nainte de a le transmite peste o inter-reea IP.
Pentru tehnologiile de nivel 2, cum ar fi PPTP sau L2TP, un tunel este asemntor cu o
sesiune; ambele capete ale tunelului trebuie s cad de acord asupra tunelului i s negocieze
variabilele de configurare, cum ar fi atribuirea adreselor, criptarea, comprimarea. n cele mai
multe cazuri, datele transferate prin tunel sunt trimise folosind un protocol bazat pe datagrame.
Pentru gestionarea tunelului se folosete un protocol de meninere a tunelului.
Tehnologiile de tunelarea pe nivel 3 pleac de la premiza c toate chestiunile de
configurare au fost efectuate, de multe ori manual. Pentru aceste protocoale, poate s nu existe
faza de meninere a tunelului. Pentru protocoalele de nivel 2, un tunel trebuie creat, meninut i
distrus.
n prezent exist o mare varietate de astfel de protocoale - de exemplu PPTP, L2F, L2TP,
IPSec, SOCKS5, FPSecure. Unele se suprapun n funcionalitate, altele ofer funcii similare dar
complementare.
n cele ce urmeaz vom identifica pe scurt cele mai importante caracteristici ale acestor
protocoale:
Point to point tunneling protocol (PPTP), reprezint o extensie a Point-to-Point
Protocol (PPP), care ncapsuleaz datele, IPX sau NetBEUT n pachetele IP. Acest
protocol este folosit n mod fundamental de echipamentele ISP, deoarece duce la un
numitor comun participanii la sesiuni de comunicaii. Este cea mai cunoscut dintre
opiunile pentru securitatea transferului de date n reeaua VPN. Dezvoltat de Microsoft i
inclus n Windows NT v 4.0 pentru a fi folosit cu serviciul de rutare i acces de la distan
(Routing & Remote Access Service). Este plasat la nivelul 2 OSI.
Layer 2 forwarding (L2F) este un protocol de tip forwarding, folosit pentru
tunelarea protocoalelor de nivel nalt ntr-un protocol de nivel 2 (legtur de date - Data
Link). De exemplu, se folosesc ca protocoale L2: HDLC, HDLC asincron sau cadre SLIP.
Dei aceast soluie faciliteaz conectivitatea pe linii de acces n reele cu comutaie de
circuite, informaia din fluxul L2F nu este criptat. Acest protocol a fost creat de Cisco.
Combinat cu PPTP, constituie component a L2TP.
Layer 2 Tunneling Protocol, sau L2TP, este o combinaie dintre un protocol al
firmei Cisco Systems (L2F) i cel al firmei Microsoft denumit Point-to-Point Tunneling
Protocol (PPTP). Fiind conceput pentru a suporta orice alt protocol de rutare, incluznd
IP, IPX i AppleTalk, acest L2TP poate fi rulat pe orice tip de reea WAN, inclusiv ATM,
88
 X.25 sau SONET. Cea mai important trstur a L2TP este folosirea protocolului Point-
to-Point, inclus de Microsoft ca o component a sistemelor de operare Windows 95,
Windows 98 i Windows NT. Astfel c orice client PC care ruleaz Windows este echipat
implicit cu o funcie de tunneling, iar Microsoft furnizeaz i o schem de criptare
denumit Point-to-Point Encryption. n afara capacitii de creare a unei VPN, protocolul
L2TP poate realiza mai multe tunele simultan, pornind de la acelai client, de exemplu
spre o baz de date a firmei i spre intranetul aceleiai firme.
Internet Protocol Security sau IPSec, este o suit de protocoale care asigur
securitatea unei reele virtuale private prin Internet. IPSec este o funcie de layer 3 i de
aceea nu poate interaciona cu alte protocoale de layer 3, cum ar fi IPX i SNA. ns
IPSec este poate cel mai autorizat protocol pentru pstrarea confidenialitii i
autenticitii pachetelor trimise prin IP. Protocolul funcioneaz cu o larg varietate de
scheme de criptare standard i negocieri ale proceselor, ca i pentru diverse sisteme de
securitate, incluznd semnturi digitale, certificate digitale, chei publice sau autorizaii.
ncapsulnd pachetul original de date ntr-un pachet de tip IP, protocolul IPSec scrie n
header toat informaia cerut de terminalul de destinaie. Deoarece nu exist modaliti
de autentificare sau criptare liceniate, IPSec se detaeaz de celelalte protocoale prin
interoperabilitate. El va lucra cu majoritatea sistemelor i standardelor, chiar i n paralel
cu alte protocoale VPN. De exemplu, IPSec poate realiza negocierea i autentificarea
criptrii n timp ce o reea virtual de tip L2TP primete un pachet, iniiaz tunelul i
trimite pachetul ncapsulat ctre cellalt terminal VPN.
SOCKS 5 constituie o alt abordare a reelelor virtuale private. Iniial produs de
Aventail, SOCKS 5 este puin mai diferit de L2TP sau IPSec: el seamn cu un server
proxy i lucreaz la nivelul de socket TCP. Pentru a utiliza SOCKS 5, sistemele trebuie
ncrcate cu un software client dedicat. n plus, firma trebuie s ruleze un server de tip
SOCKS 5.
Partea pozitiv a lui SOCKS 5 este aceea c permite administratorilor de reea s aplice diverse
limitri i controale traficului prin proxy. Deoarece lucreaz la nivel TCP, SOCKS 5 v permite
s specificai care aplicaii pot traversa prin firewall ctre Internet i care sunt restricionate.
Principalele dezavantaje rezid n faptul c Socks 5 adaug un nivel de securitate prin
rutarea traficului printr-un sistem proxy, ceea ce duce la performane n general inferioare fa de
protocoalele de nivel inferior. n plus el prezint o dependen fa de modul de implementare a
reelelor VPN. Dei gradul de securitate este mai ridicat n comparaie cu soluiile plasate la
89
nivelul OSI reea sau transport, acest supliment de securitate pretinde o administrare mult mai
sofisticat a politicilor. Mai mult, pentru construirea de conexiuni printr-un sistem firewall sunt
necesare aplicaii client, astfel nct toate datele TCP/IP s fie transmise prin serverul proxy.
7.5. Securitate VPN

O reea VPN bine proiectat folosete cteva metode care menin datele i conexiunea
securizate: firewall-uri, criptarea, IPSec sau server AAA.. Astzi securitatea reelei este n
principal asigurat de firewall-uri, produse care pun o barier software ntre resursele companiei
(reeaua privat) i Internet. Firewall-urile pot fi configurate s restricioneze numrul de porturi
deschise, pot fi instruite care feluri de pachete s le lase s treac i care nu, dar un firewall poate
fi utilizat pentru a ncheia sesiunile VPN.

Figura 7.6. Firewall

CheckPoint Software Technologies i Raptor Systems sunt dou dintre cele mai
cunoscute firme care vnd soft de firewall pentru servere Unix, situate n apropierea router-ului
de reea. Alte firme, ca Cisco Systems i Ascend Communications, vnd produse de securitate la
nivel de router.
Criptarea este procesul prin care toate datele trimise de un calculator sunt codificate ntr-o
form pe care doar calculatorul destinatar o poate decodifica. Majoritatea sistemelor de criptare
cu ajutorul calculatorului se mpart n dou categorii: criptarea cu cheie simetric sau criptarea cu
cheie public.
n criptarea cu cheie simetric, fiecare calculator posed o cheie secret pe care o poate
folosi la criptarea unui pachet de informaie nainte de a-l trimite prin reea celuilalt calculator.
Cheia simetric presupune cunoaterea perechilor de calculatoare care vor comunica aa nct
este nevoie de cte o cheie pentru fiecare calculator.

90
 Criptarea cu cheie public folosete o combinaie de cheie privat i cheie public. Cheia
privat o cunoate doar calculatorul dumneavoastr, iar cea public este oferit oricrui alt
calculator ce dorete s comunice n manier securizat. Pentru a decodifica un mesaj criptat, un
calculator trebuie s foloseasc cheia public oferit de iniiatorul comunicaiei, precum i cheia
sa privat. Un utilitar cunoscut este Pretty Good Privacy (PGP), care poate cripta aproape orice.
Cel mai ntlnit dintre protocoalele VPN discutate anterior este IPSec - un open-
standard de securitate folosit de cele mai mari firme, printre care se numr IBM, Sun sau
BayNetworks - pentru stabilirea comunicaiilor directe private prin Internet.
Internet Protocol Security (IPSec) ofer caracteristici de securitate extins, precum i
algoritmi de criptare mai buni, pe lng mecanisme de autentificare. IPSec are dou moduri de
criptare : tunel i transport. Tunelul cripteaz doar antetul, n timp ce transportul cripteaz i
datele. IPSec poate cripta date ntre diverse echipamente: ruter-ruter, firewall-ruter, PC-ruter, PC-
server.
IPSec v protejeaz datele n trei moduri, folosind tehnici criptografice:
Autentificare: Procesul prin care este verificat identitatea unui host (staie de
lucru).
Verificarea integritii: Procesul prin care se semnaleaz orice modificri ale
datelor survenite n procesul de transport prin Internet, ntre surs i destinaie.
Criptarea: Procesul de codificare a informaiei n tranzit prin reea, pentru a
asigura caracterul su privat.
Serverele AAA (de autentificare, autorizare i jurnalizare) sunt folosite pentru accesurile
mult mai securizate dintr-un mediu VPN de accesul la distan. Cnd vine o cerere de stabilire a
unei sesiuni de la un client dial-up, serverul AAA verific urmtoarele:
- cine suntei (autentificare);
- ce permisiuni avei (autorizare);
- ce anume de fapt facei (jurnalizare).
Funcia de jurnalizare este util atunci cnd urmrii ce anume face clientul, n scopul facturrii,
de exemplu.
O soluie complet pentru realizarea unei reele VPN necesit mbinarea a trei
componente tehnologice critice: securitatea, controlul traficului i administrarea la nivelul
organizaiei.

91
 Securitatea
Tehnologiile importante care acoper componenta de securitate a unei reele VPN sunt:
controlul accesului pentru garantarea securitii conexiunilor din reea, criptarea, pentru
protejarea confidenialitii datelor, autentificarea, pentru a verifica identitatea utilizatorului, ca i
integritatea datelor.
Controlul traficului
O a dou component critic n implementarea unei reele VPN este dat de controlul
traficului, realizat pentru un scop simplu i clar: garantarea fiabilitii, calitii serviciilor i a
unor performane optime n ceea ce privete ratele de transfer. Comunicaiile n Internet pot duce
la apariia unor zone de congestie, impropii unor aplicaii critice n domenniul afacerilor.
Alternativa este dat de stabilirea unor prioriti de rutare a traficului, astfel nct transferul
datelor s fie realizat cu fiabilitate maxim.

Administrarea la nivelul organizaiei

Ultima component critic este dedicat garantrii unei integrri complete a reelei VPN
n politica de securitate global, unei administrri centralizate (fie de la o consol local, fie de la
una la distan) i unei scalabilti a soluiei alese.
Deoarece n cazul reelelor VPN nu exist o reet unic, este necesar o combinaie
particular a acestor trei componente, astfel nct rezultatul practic s ntruneasc criteriile de
evaluare mai sus menionate.

7.6. Standardizarea reelelor VPN Standardul IPSec

Este cunoscut faptul c numai standardele susinute de industrie vor asigura
interoperabilitatea aplicaiilor. Administratorii care implementeaz o soluie VPN sunt pui n
faa unor anumite probleme, din cauza absenei standardelor. Internet Engineering Task Force
(IETF) a stabilit un grup de lucru dedicat definirii standardelor i protocoalelor legate de
securitatea Internetului. Unul dintre cele mai importante scopuri ale acestui grup de lucru este
finalizarea standardului IPSec, care definete structura pachetelor IP i considerentele legate de
securitatea n cazul soluiilor VPN.
De-a lungul ultimilor ani, grupul de lucru IPSec din cadrul IETF a nregistrat mari
progrese n adugarea de tehnici de securitate criptografice la standardele pentru infrastructura
Internet.
IPSec a aprut n cadrul efortului de standardizare pentru IPv6 i reprezint singura
92
soluie deschis pentru securizarea conexiunilor pe Internet. IPSec poate fi configurat pentru
dou moduri distincte: modul tunel i modul transport. n modul tunel, IPSec ncapsuleaz
pachetele IPv4 n cadre IP securizate, pentru transferul informaiei ntre dou sisteme
firewall, de exemplu. n modul transport, informaia este ncapsulat ntr-un altfel de mod,
nct ea poate fi securizat ntre punctele terminale ale conexiunii, deci ambalajul nu ascunde
informaia de rutare cap-la-cap. Modul tunel este cea mai sigur metod de securizare, ns crete
gradul de ncrcare a sesiunii de comunicaie, prin mrirea dimensiunilor pachetelor.
Standardul pentru Arhitectura de Securitate IP, descris n RFC 2401, prezint
mecanismele de securitate pentru IP versiunea 4 (IPv4) i pentru IP versiunea 6 (IPv6).
La ora actual exist dou tipuri de antete (headere) ce pot fi ataate la un pachet IP
pentru realizarea securitii. Acestea sunt:
Authentification Header (AH) - antetul de autentificare care furnizeaz
serviciile de integritate i autentificare.
Encapsulated Security Payload (ESP) - nveliul de securitate - care furnizeaz
confidenialitate i, n funcie de algoritmii i de modurile folosite, poate furniza, de
asemenea, integritate i autentificare.
Pe lng autentificarea sursei, AH asigur numai integritatea datelor, n timp ce ESP, care
asigura pn acum doar criptarea, acum asigur att criptarea, ct i integritatea datelor.
Diferena dintre integritatea datelor prin AH i cea dat de ESP st n scopul datelor care sunt
autentificate. AH autentific ntregul pachet, n timp ce ESP nu autentific antetul IP exterior. n
autentificarea ESP, sumarul de mesaj se afl n finalul pachetului, n timp ce n AH, sumarul se
gsete nuntrul antetului de autentificare.
Cele dou antete, respectiv mecanisme de securitate, pot fi folosite independent unul de
cellalt, combinate sau ntr-un mod imbricat. Ele sunt definite n mod independent de algoritm
astfel nct algoritmii criptografici pot fi nlocuii fr ca alte pri din implementare s fie
afectate. n mod implicit sunt specificai algoritmi standard, pentru asigurarea interoperabilitii.
Ambele mecanisme de securitate IP pot furniza servicii de securitate ntre:
- dou calculatoare gazd ce comunic ntre ele,
- dou gateway-uri de securitate comunicante sau,
- un calculator gazd i un gateway.
Standardul IPSec stabilete c nainte de orice transfer de date trebuie negociat o
asociere de securitate (Security Association - SA) ntre cele dou noduri VPN (de tip gateway

93
sau client), s conine toate informaiile necesare pentru execuia diferitelor servicii de securitate
pe reea, cum sunt serviciile corespunztoare nivelului IP (autentificarea antetului i ncapsularea
datelor), serviciile nivelurilor de transport sau aplicaie, precum i autoprotecia traficului de date
din negociere.
Aceste formate furnizeaz un cadru consistent pentru transferul cheilor i a datelor de
autentificare, care este independent de tehnica de generare a cheilor, de algoritmul de criptare sau
mecanismul de autentificare.
IPSec poate fi privit ca un nivel intermediar sub stiv TCP/IP. Acest nivel este controlat
de o politic de securitate pe fiecare main i de o asociere de securitate negociat ntre emitor
i receptor. Politica const ntr-un set de filtre i un set de profile de securitate asociate. Dac un
pachet are o adres, protocolul i numrul de port corespunztoare unui filtru, atunci pachetul
este tratat conform profilului de securitate asociat.
Unul dintre avantajele majore ale elaborrii unui standard IPSec este c structura
standardizat a pachetului i asocierea de securitate vor facilita interoperarea diferitelor soluii
VPN la nivelul transmisiei de date. Cu toate acestea, standardul nu ofer un mecanism automat
de schimb pentru cheile de criptare i autentificare a datelor, necesare pentru stabilirea unei
sesiuni criptate, aspect care introduce al doilea avantaj major al standardului: PKI sau
infrastructura de administrare a cheilor.

94
 4 Consideraii privind mbuntirea sistemelor distribuite

Sisteme distribuite out of the paper i only adding

Aa cum istoria civilizaiei marcheaz distinct apariia tiparului, tot astfel se va marca
dispariia documentelor imprimate n sistemele informatice moderne. Nu este o fantezie, este o
realitate care devine dominant pe zi ce trece. Sistemele informatice n care nu apar documentele
de imprimare sunt de neconceput pentru foarte mult lume. Ele sunt, ns, o realitate pe care
societatea modern trebuie s o accepte de bunvoie i nesilit de nimeni pentru c:
- se limiteaz sever capacitatea de depozitare a documentelor imprimate pe fundalul
exploziei de informaie disponibil;
- mediile noi de stocare a informaiei sunt mai stabile i mult mai fiabile ca documentele
imprimate;
- accesarea informaiei stocate pe ali supori dect hrtia este direct, dispozitivele de citire
fiind la ndemna oricui, cu costuri aproape nule;
- controlul redundanei, n sistemele care opereaz fr documente imprimate, este la un
nivel superior modalitilor clasice de abordare;
- arhivele de documente electronice se pstreaz mai bine, iar costurile de conservare sunt
suportabile;
- procedurile de autentificare i de asigurare a securitii le fac incomparabil mai sigure i
mai accesibile din orice punct de vedere, n orice moment, de ctre oricine are drepturi atribuite;
- operaionalitatea documentului electronic capt alte valene, din moment ce actualizarea
bazelor de date multimedia se rezum, exclusiv, la adugare de componente; despre celelalte
operaii precum modificare subiruri, tergere subiruri, sistemele de gestiune nu mai fac referire
sub nici o form n nici un context;
- sistemul legislativ ofer importan documentului electronic oferindu-i aceeai putere pe
95
care o are documentul scris, prin gestionarea riguroas a semnturii electronice i a documentelor
electronice autentificate.
Sistemele informatice, care nu mai opereaz cu documente imprimate, prezint numeroase
avantaje:
- creterea vitezei de soluionare a problemelor;
- gestionarea strict a intrrilor i ieirilor de documente electronice;
- transparena proceselor care se deruleaz;
- eliminarea birocraiei la vedere" n favoarea proceselor active i eficiente;
- readucerea duratei de regsire;
- eliminarea pierderilor de documente datorate neglijenei sau distrugerii, ntruct gestiunea
lor este un proces asistat de produse software, n care securitatea este esenial pentru baza de
date;
- profesionalizarea manipulrii cu documente, ntruct utilizarea sistemelor de management
documente electronice impune obinerea obligatorie a unei calificri recunoscute i acceptate;
- crearea responsabilitii privind primirea, studierea, utilizarea informaiei coninut n
documente electronice, cel puin la acelai nivel cu situaia n care se lucra pe documente
imprimate sau documente olografe.
n sistemele i aplicaiile distribuite "only adding" sunt acceptate numai operaii de
adugare i de arhivare a informaiilor stocate n baze de date. Sunt excluse modificrile i
tergerile de informaii i se accentueaz rolul pe care l au bazele de date, n care mentenana se
realizeaz prin adugare de informaii noi. Existena i crearea de baze de date la nivel naional
impune proiectarea de sisteme i aplicaii distribuite "only adding" i "out of the paper": baza de
date a populaiei permite prelucrarea de date privind adresa, starea civil a ceteanului; baza de
date a educaiei permite prelucrarea de date privind diplomele obinute de cetean; baza de date
a fiscului permite prelucrarea de date privind taxele i impozitele ceteanului; baza de date a
agenilor economici permite prelucrarea de date privind locul de munc, veniturile i reinerile
ceteanului.

5 Concluzii

Noul SNIEP va permite dezvoltarea unor funcii informatice de nivel superior, prin
mecanisme soft-ware si resurse hard adecvate menite s asigure punerea n aplicare a
reglementarilor privind confidenialitatea i protecia datelor referitoare la persoan. Sistemul
96
distribuit prezentat foloseste modelul client/server, acesta va fi implementa n curnd pentru
gestionarea i actualizarea Registrul naional de eviden a persoanelor.

Bibliografie

Andrew S. Tanenbaum & Maarten van Steen. Distributed Systems: Principles and Paradigms;
Prentice Hall 2002;

Andrew S. Tanenbaum Reele de calculatoare Editura Computers Press Agora, 1997;

V. V. Patriciu, M. Pietroanu, I. Bica, C. Vduva, N. Voicu Securitatea Comerului

Electronic, Editura ALL, Bucuresti, 2001.

http://www.microsoft.com/windowsserver2003/technologies/networking/vpn/default.mspx

http://www.cisco.com/en/US/products/hw/routers/ps341/products_configuration_guide_book091
86a008051522f.html

http://www.chip.ro/revista/iunie_2000/46/retele_virtuale_private/8232

www.folio.fr/tech_vpn.htm

www.tridentusa.com/.../ p_parts_equip.html

www.sonicwall-solutions.com/ what_is_vpn.htm

www.networksunlimited.com/ whitepaper4.html

97
98