Sistemele distribuite de e-learning

SISTEMELE DISTRIBUITE DE E-LEARNING

Sistemele distribuite implementate pana in prezent evidentiaza o varietate arhitecturala mare. Cu toate aceseta, ele au in comun o serie de caracteristici si impartasesc unele probleme comune in dezvoltarea lor. Caracteristicile comune si aspectele de proiectare a sistemelor distribuite pot fi prezentate sub forma unor modele descriptive. Fiecare astfel de model va reprezenta o descriere abstracta, simplificata dar consistenta a aspectelor relevante ale proiectarii sistemelor distribuite.

O definitie standard, universal acceptata, pentru arhitectura sistemului informatic nu exista, majoritatea opiniilor exprimate punand in centrul atentiei conceptele de componenta si conexiune. Una din definitiile mai recente considera arhitectura programelor ca fiind "structura sau structurile care privesc componentele programului, proprietatile externe ale acestor componente, precum si relatiile dintre ele".

In functie de semnificatia notiunii de componenta, arhitectura sistemelor informatice poate fi definita intr-un sens restrans si intr-un sens mai larg. Proiectarea arhitecturii unui program poate viza, in sens restrins, componentele programului, respectiv modulele acestuia, insa ea poate fi extinsa prin includerea bazei de date si a componentei middleware care permite configurarea comunicarii intr-un sistem client/server. Proprietatile acestor componente sunt acele caracteristici care permit intelegerea modului in care ele interactioneaza, respectiv modul de apelare a unui modul din alt modul sau mecanismul de accesare a bazei de date de catre modulele programului. Proiectarea arhitecturala a programului nu ia in considerare proprietatile interne ale componentelor, cum ar fi detaliile unui algoritm specifice unui modul. Relatiile dintre componente se pot referi fie la apelarea unei proceduri, cu transmiterea eventuala a datelor necesare executiei procedurii respective, fie la protocolul de accesare a bazei de date de catre procedurile de program.

Obiectivul general urmarit in cadrul proiectarii arhitecturale vizeaza conceperea unei structuri a sistemului care sa corespunda cerintelor prezente si celor viitoare, astfel incat sistemul sa fie sigur in functionare, adaptabil, usor de gestionat, eficient. O buna proiectare arhitecturala se va traduce intr-un sistem usor de implementat, testat si modificat. Multitudinea sistemelor informatice distribuite implementate pana in prezent releva o varietate mare a arhitecturilor, dar care pot totusi fi incadrate in cateva modele arhitecturale.

Un model arhitectural defineste modul in care interactioneaza intre ele componentele unui sistem, precum si localizarea (maparea) lor intr-o retea de calculatoare. Modelul arhitectural al unui sistem distribuit are rolul de a simplifica si abstractiza functiile componentelor sistemului. Apoi, el ia in considerare:

plasarea componentelor in cadrul retelei - cautand sa defineasca modelele corespunzatoare de distribuire a datelor si a prelucrarilor;

interactiunile dintre componente - adica, rolurile lor finctionale si modelele de comunicare dintre ele.

Modelele de alocare a sarcinilor de lucru intr-un sistem distribuit se reflecta direct asupra performantelor si eficacitatea sistemului rezultat. Localizarea componentelor unui sistem distribuit este determinata de aspectele de performanta, siguranta in functionare, securitate si costurile implicate.

1 Arhitectura software

Intr-un sistem distribuit hardware-ul este important insa software-ul reprezinta elemental determinant de componenta software depinde cum va arata un sistem distribuit.

Initial, prin arhitectura software se facea referire la structurarea software-ului pe niveluri sau module, cea mai cunoscuta fiind structura ierarhica pe module. Recent, acelasi termen este descris in termenii serviciilor oferite si solicitate intre procesele localizate pe acelasi calculator sau pe calculatoare diferite. Prin urmare, noua orientare, catre procese si servicii, poate fi exprimata prin intermediul nivelurilor de servicii. Ea este prezentata schematic in figura 1.

Figura 1 Structura generala a unui sistem distribuit

Dupa cum se poate observa din figura 1, structura generala a unui sistem distribuit presupune trei niveluri (straturi): platforma, middleware si programele de aplicatii distribuite. Fiecare nivel ofera servicii nivelului superior. Astfel, aplicatiile distribuite apeleaza la serviciile oferite de componenta middleware care, la randul sau, beneficiaza de serviciile oferite de sistemele de operare.

2 Modele arhitecturale pentru sisteme distribuite

Dupa cum aratam in primul paragraf, una activitatile specifice dezvoltarii sistemelor distribuite consta in proiectarea arhitecturii sistemului, respectiv diviziunea responsabilitatilor intre componentelesistemului si plasarea lor pe calculatoarele din retea. In acest sens, exista mai multe modele arhitecturale. Asupra lor ne vom opri in continuare.

Modelul client/server. Aceasta arhitectura este de departe cea mai cunoscuta si mai utilizata la dezvoltarea sistemelor distribuite, fiind prezentata schematic in figura 2. In fapt, ea presupune impartirea sarcinilor aplicatiei in procese client si procese server care interactioneaza intre ele prin schimbul de mesaje in vederea realizarii unei activitati.

Figura 2 Modul in care clientul invoca un server

Servicii furnizate de mai multe servere. Conform acestei arhitecturi (figura 3), serviciile pot fi implementate sub forma mai multor procese server rezidente pe diferite calculatoare, care vor interactiona in functie de necesitati in vederea furnizarii serviciului cerut de un proces client. Setul de obiecte care sta la baza serviciului respectiv poate fi partitionat si distribuit pe mai multe servere. De asemenea, este posibil ca mai multe servere sa intretina copii ale obiectelor respective (este vorba despre replicare), cu scopul imbunatatirii tolerantei la erori, a perfomantelor de accesare si adisponibilitatii.

Servere proxy si tehnica de caching. Cache reprezinta tehnica de stocare a obiectelor de date recent utilizate mai aproape de locul de utilizare. Atunci cand un obiect este receptionat de un calculator, el va fi adaugat in zona de stocare cache, inlocuind eventual alte obiecte care exista deja in cache. La solicitatarea unui obiect de catre un proces client, serviciul de caching va cauta mai intai in cache pentru a pune la dispozitie obiectul solicitat, numai daca exista o copie actualizata a acestuia; altfel, o copie actualizata va fi incarcata de pe server. Zonele cache pot fi dispuse pe fiecare client sau le pot fi localizate pe un server proxy partajat de mai multi clienti.

Figura 3 Un serviciu furnizat de mai multe servere

Tehnica cache este utilizata pe scara larga in practica. Browserele Web intretin pe fiecare client un ache cu cele mai recente pagini Web vizitate si alte resurse Web. Ele utilizeaza o cerere HTTP speciala entru a verifica daca paginile din cache sunt corespunzatoare cu cele originale de pe server inainte de a e afisa. Serverele proxy Web (figura 4) ofera clientilor o zona de stocare cache partajabila ce contine resursele Web ale unui singur site sau a mai multor site-uri. In acest mod, se obtine o crestere a disponibilitatii si performantelor serviciilor Web prin reducerea incarcarii retelei si a serverului Web.

Figura 4 Server proxy Web

Procese perechi. In aceasta arhitectura toate procesele joaca roluri similare, interactionand in mod colaborativ ca perechi in vederea realizarii unei activitati sau prelucrari distribuite, fara a se face distinctia intre client si server. Codul corespunzator proceselor perechi va avea rolul de a mentine consistenta resurselor de la nivelul aplicatiei si de a sincroniza actiunile de la nivelul aplicatiei daca este necesar.

Eliminarea proceselor server determina reducerea intarzierilor aferente comunicarii inter-procese pentru accesarea obiectelor locale. De exemplu, o aplicatie poate fi conceputa astfel incat sa permita utilizatorilor sa afiseze si sa modifice interactiv o schita care este partajata. Aplicatia poate fi implementata sub forma unor procese aplicatie plasate pe fiecare nod care se va baza pe straturile middleware pentru a realiza notificarea evenimentelor si comunicarea in cadrul grupului pentru a instiinta toate procesele aplicatiei despre eventuala modificare a schitei. Acest model ofera o comunicare interactiva mai buna pentru utilizatorii unui obiect distribuit partajat decat in cazul unei arhitecturi bazate pe server.

In figura 5 este prezentata o astfel de arhitectura, formata din trei procese pereche, insa pot exista n procese care sa interactioneze intre ele.

Figura 5 Aplicatie distribuita bazata pe procese perechi

3 Modelul client/server

In general, putine sunt problemele legate de dezvoltarea sistemelor distribuite in care se inregistreaza un consens in randul specialistilor. Un aspect asupra caruia se inregistreaza un larg consens in randul cercetatorilor si practicienilor priveste organizarea componentelor unui sistem distribuit prin folosirea termenilor client, care solicita servicii unui server, astfel incat sa faciliteze intelegerea si stapanirea complexitatii sistemelor distribuite. Asadar, paradigma client/server reprezinta modelul arhitectural cel mai utilizat la dezvoltarea sistemelor distribuite.

Definirea modelului client/server

Ideea subiacenta conceptului client/server este serviciul. O aplicatie informatica distribuita dezvoltata dupa modelul client/server este descompusa in doua doua grupuri de procese: consumatorii de servicii, numiti client si furnizorii de servicii, numiti server, care comunica intre ele prin schimbul de mesaje de tip solicitare-raspuns (figura 6). De exemplu, un server poate fi conceput pentru a oferi un serviciu de baze de date clientilor sai.

Serverul este functional independent de client, iar relatia intre client si server este de colaborare (cooperare). Ea se diferentiaza radical de aplicatiile centralizate, in care relatia este de tip "stapan-sclav"(master-slave).

Figura 6 Modelul general al interactiunii dintre client si server

In modelul client/server, clientul solicita serverului executia unui serviciu prin transmiterea unui mesaj. La randul sau, serverul va transmite clientului rezultatul solicitarii sale. Diferitele functii ale aplicatiei informatice sunt regrupate sub forma programelor client si server, fiecare cu roluri bine definite. Pentru utilizator totul este transparent, el comunicand cu programul client; schimbul de mesaje realizat intre programele client si server ii sunt transparente, el percepand aplicatia ca un ansmablu executat doar pe postul sau de lucru.

Arhitectura client/server poate fi definita ca un model de dezvoltare a aplicatiilor conform caruia sistemul informational este descompus intr-un mare numar de functii server, executate pe una sau mai multe platforme hardware, care furnizeaza servicii comune unui mare numar de functii client, executate pe una sau mai multe platforme hardware diferite dar interconectate, si care realizeaza sarcini bine definite in legatura cu serviciile furnizate de functiile server.

In plus, mai pot fi identificate doua situatii distincte:

♦ un server poate apela la serviciile furnizate de catre un alt server, obtinanduse o relatie client server pe mai multe straturi. In figura 7 este prezentata o astfel de relatie pe doua straturi. Asupra relatiilor client-server pe mai multe straturi vom reveni in paragraful urmator.

♦ programele client si server se pot gasi pe acelasi calculator, un exemplu in acest sens

constituindu-l schimburile inter-aplicatii de tip DDE (Dynamic Data Exchange).

Figura 7 Relatii client/server pe doua niveluri

Din cele prezentate pana aici se poate clarifica relatia dintre sistemele distribuite si sistemele client/server. Astfel, intr-un sistem client/server nu este obligatoriu ca cele doua grupe de functii (client si server) sa fie localizate pe calculatoare diferite, ele putand fi rezidente pe acelasi calculator; de cele mai multe ori arhitectura client/server este implementata intr-un sistem distribuit. Pe de alta parte, un sistem distribuit nu implica neaparat arhitectura client/server. Arhitectura cvasi-utilizata la dezvoltarea sistemelor distribuite este reprezentata de modelul client/server. Asadar, desi diferite conceptual, de cele mai multe ori in practica dezvoltarii sistemelor informationale se poate pune semnul de egalitate intre sistemele distribuite si sistemele client/server.

Arhitecturi client/server multistrat

Modelul client/server a constituit subiectul multor dezbateri si controverse. Problema principala este legata de distinctia clara dintre client si server. Proiectarea sistemelor client/server presupune conceperea arhitecturii aplicatiilor pe straturi bine definite. O astfel de abordare permite proiectarea independenta a straturilor, singura grija constand in definirea clara si proiectarea atenta a interfetelor, urmarindu-se ca:

♦ fiecare strat sa aiba un domeniu bine definit, in sensul definirii foarte clare a sarcinilor si responsabilitatilor fiecarui strat;

♦ fiecare strat trebuie sa indeplineasca o sarcina specifica; daca, de ex., unul din straturi este responsabil cu interactiunea cu utilizatorul, atunci numai acel strat va comunica cu utilizatorul, celelalte straturi realizand acest lucru prin intermediul acestui strat daca au nevoie de informatii de la utilizator.

♦ stabilirea unor protocoale bine definite pentru interactiunea dintre straturi, interactiune care sa se realizeze numai prin intermediul acestor protocoale.

O prima incercare in acest sens a constituit-o impartirea aplicatiilor pe doua straturi, rezultand arhitectura cu doua straturi. Aceasta arhitectura presupune descompunerea aplicatiei in urmatoarele doua straturi:

♦ stratul corespunzator aplicatiei, in care se include interfata grafica cu utilizatorul, respective logica prezentarii, si implementarea regulilor de afaceri (business rules), respectiv logica aplicatiei. Tot acest strat poate coordona si logica tranzactiei care garanteaza ca actualizarile in baza de date specifice unei tranzactii sunt terminate complet (validate sau anulate).

♦ stratul corespunzator bazei de date, care este responsabil de mentinerea integritatii bazei de date. In acest strat poate fi implementata intreaga logica a tranzactiei sau o parte a ei.

Distinctia dintre cele doua straturi nu este intotdeauna bine definita deoarece logica tranzactiei este adesea implementata pe server BD, sub forma procedurilor stocate, iar regulile afacerilor, parte a logicii aplicatiei sunt de asemenea implementate pe server, sub forma trigger-elor. In plus, sunt intampinate greutati considerabile in dezvoltarea sistemului informational pe baza cresterii accentuate a numarului de aplicatii, a numarului si tipului serverelor de baze de date. Aceasta deficienta poate fi rezolvata prin introducerea unui nivel suplimentar, care sa trateze regulile afacerii, rezultand o arhitectura cu trei straturi.

Arhitectura cu trei straturi presupune impartirea aplicatiei in urmatoarele straturi:

♦ gestiunea interfatei utilizator (gestiunea prezentarii) - priveste dialogul intre utilizatori si aplicatie, incluzand aici logica de prezentare a informatiei (ansamblul prelucrarilor efectuate asupra datelor necesare afisarii lor);

♦ logica aplicatiei - cuprinde ansamblul operatiilor de prelucrare specifice aplicatiei si inlantuirea lor logica;

♦ gestiunea datelor - rezolva cererile de date, asigura integritatea datelor, emiterea anumitor mesaje de alertare, precum si gestiunea fizica a datelor (adaugari, modificari, stergeri).

In esenta, arhitectura pe trei straturi difera de cea pe doua straturi prin separarea logicii afacerii intr-un strat distinct, localizat de regula pe un server de aplicatii care comunica strans cu serverul de baze de date. Introducerea unui strat intermediar permite definirea si implementarea regulilor afacerii independent de logica prezentarii interfetei GUI si a regulilor de proiectare a bazei de date. Acest avantaj devine evident in conditiile in care regulile afacerii sunt supuse mai des modificarilor, facilitand astfel reimplementarea lor. Daca cele trei straturi vor fi implementate pe calculatoare diferite, atunci vom avea situatia in care un server va juca si rolul de client (figura 7). O arhitectura pe trei straturi este prezentata in figura 8. Se observa ca programele care formeaza stratul logicii afacerii sunt rezidente pe un server separat.

Figura 8 Arhitectura client pe trei straturi

Un exemplu tipic de arhitectura pe trei straturi il reprezinta modul de functionare al unui motor de cautare pe Internet, prezentat in figura 9.

Interfata (partea de front-end) permite utilizatorului sa introduca expresia dupa care doreste sa se efectueze cautarea si, ulterior, va afisa o lista cu titlurile de pagini Web care corespund expresiei introduse. Partea de back-end va consta dintr-o imensa baza de date cu informatii despre paginile Web. Intre cele doua niveluri se afla "inima" motorului de cautare, respectiv partea de logica a programului, care transforma expresia introdusa de utilizator prin intermediul interfetei in una sau mai multe interogari ale bazei de date, dupa care va ordona rezultatele interogarilor intr-o lista, si pe care o va transforma intr-o serie de pagini HTML.

Figura 9 Modelul general de organizare pe trei straturi a unui motor de cautare pe Internet

Un alt exemplu de arhitectura pe trei straturi, este cel al unui sistem de asistare a deciziei pentru gestiunea portofoliului de actiuni. Acest sistem poate fi de asemenea impartit pe trei niveluri:

partea front-end va implementa interfata utilizator,

partea back-end va asigura accesarea bazei de date cu date financiare,

partea de mijloc va contine programele de analiza financiara.

Analiza datelor financiare poate implica tehnici si metode sofisticate, de la cele statisticie la cele de inteligenta artificiala, motiv pentru care logica aplicatiei ar putea fi implementata pe un server special, capabil sa execute operatiuni de calcul complexe.

Printre avantajele unei arhitecturi client/server distribuita pe trei straturi enumeram:

- Performanta. Aplicatiile ruleaza intr-un strat dedicat, bazat eventual pe resurse proprii si tehnologii ale caror scop esential este atingerea unei viteze de executie superioare si a unei scalabilitati superioare.

- Mentenanta. Intretinerea si reinstalarea aplicatiilor sau a unor parti ale acesteia, in cazul schimbarii regulilor afacerii, este mult simplificata prin administrarea separata, centralizata, a componentelor lor.

- Suport multi-limbaj. Aplicatiile dezvoltate pe componente pot fi scrise in mai multe limbaje de programare (VB, C++, Java) si pot fi facute interoperabile, chiar daca provin de pe platforme diferite (.NET, J2EE).

- Scalabilitate si echilibrarea solicitarii resurselor. Componentele pot fi distribuite pe mai multe servere, ceea ce permite ridicarea pragului de scalabilitate in conditiile pastrarii parametrilor de performanta si disponibilitate a aplicatiilor.

- Reutilizare. Componentele dezvoltate pot fi construite astfel incat functionalitatea lor sa fie partajate intre mai multe aplicatii;

- Eficientizarea accesului la date. Serverele de baze de date nu vor mai fi solicitate de un numar mare de cereri de acces, gestiunea cererilor clientilor revenind serverelor de aplicatii (deci stratului intermediar). In acest mod, clientii nu mai sunt nevoiti sa se conecteze direct la baza de date si, prin urmare, nu vor mai avea nevoie de drivere specifice (ca in cazul arhitecturii pe doua straturi).

- Imbunatatirea securitatii. Componentele din stratul intermediar pot fi gestionate din punctual de vedere al securitatii printr-o infrastructura centralizata comuna, determinand simplificarea si reducerea costurilor de administrare.

In prezent se manifesta tendinta dezvoltarii aplicatiilor multistrat, in care pot exista mai mult de trei straturi, atat din punct de vedere logic, cat si fizic. Acest lucru este posibil datorita aparitiei unei noi paradigme in dezvoltarea sistemelor informationale, referita prin sintagma orientata pe componente.

Clasificarea modelelor arhitecturale client/server

Proiectarea sistemelor informatice conform tehnologiei client/server trebuie sa ia in considerare diferitele tipuri de sisteme client/server. O clasificare a modelelor client/server a fost propusa de Gartner Group, pornind de la cele trei parti functionale componente ale unei aplicatii. Figura 10 arata cele cinci tipuri de arhitecturi regrupate sub numele client-server.

Figura 10 Clasificarea modelelor client/server conform Gartner Group

Interfata (prezentare) distribuita urmareste dispunerea de facilitati grafice pe postul client, motiv pentru care acest model mai este referit si prin "cosmetica aplicatiei". Concret, acest model presupune adaugarea unei interfete grafice evoluate la o aplicatie centralizata, rezidenta pe un mainframe sau minicalculator, in vederea inlaturarii dezavantajelor asociate interfetelor la modul caracter specifice platformelor mari.

Aplicatia centrala nu este modificata ci numai partea de interfata a aplicatiei, adica acea parte care selecteaza datele provenite de la calculatorul central si le afiseaza intr-un mediu graphic specific microcalculatoarelor.

Operatia de transformare a interfetei se poate face de-o maniera mai simpla, fara alterarea succesiunii ecranelor specifice aplicatiei originale (unui ecran in modul caracter ii corespunde un ecran in modul grafic) fie de-o maniera mai "radicala", in sensul modificarii succesiunii dialogurilor si ecranelor utilizator specifice aplicatiei originale, insa tot fara a efectua vreo modificare in programele aplicatiei (unui ecran in modul caracter ii poate corespunde mai multe ecrane in modul grafic, precum si invers). Desi aduce unele imbunatatiri aplicatiei, modelul interfata distribuita poate fi cu greu incadrat in arhitectura client/server, intru-cat partea server a aplicatiei ramane semnificativa, manifestandu-se o relatie de tip master-slave. Si totusi, acest model ofera unele avantaje legate de:

♦ ameliorarea calitatii interfetei aplicatiei;

♦ conservarea investitiilor anterioare efectuate pentru realizarea aplicatiei, deoarece programele aplicatiei nu sunt modificate;

♦ ofera o solutie intermediara in vederea trecerii la arhitectura client/server.

Desi o asemenea rezolvare raspunde cerintelor utilizatorilor in materie de interfata grafica, ea nu poate reprezenta decat o solutie temporara, deoarece:

♦ nu rezolva problemele de comunicare a datelor, generate de traficul intens de date din retea (la datele aplicatiei care tranziteaza reteaua intre client si server se adauga informatiile tehnice legate de pozitia campurilor in ecran, controale etc.)

♦ nu ofera deloc (sau prea putin) performante noi, serverul asigurand in continuare toate prelucrarile aplicatiei.

Interfata (prezentare) izolata (deportata) in care gestiunea interfatei utilizator a aplicatiei este rezidenta pe platforma client, platforma ce asigura in intregime gestionarea dialogului. Terminalele X reprezinta un exemplu de implementare a acestui model, ele oferind o mare portabilitate a aplicatiilor si o independenta totala fata de producatori de hard si soft, putand lucra usor cu platforme hard si software eterogene.

Acest model asigura urmatoarele avantaje:

♦ imbunatateste calitatea interfetei aplicatiei;

♦ conserva investitiile anterioare efectuate pentru realizarea aplicatiei prin separarea stricta a interfetei de prelucrarile aplicatiei (logica aplicatiei);

♦ determina reducerea substantiala a costurilor, datorita pretului redus al terminalelor X si usurinta intretinerii acestora.

Totusi, ca si in primul caz, nu ofera performante deosebite deoarece serverul asigura ansamblul prelucrarilor ceea ce presupune o mare incarcare a retelei. In plus, terminalele X sunt utilizate doar in mediile UNIX.

Prelucrari distribuite, model care presupune repartizarea prelucrarilor aplicatiei intre client si server. Pe platforma client se regaseste logica functionala de baza care apeleaza serverul pentru executarea unor servicii externe prin lansarea unor cereri ce vor activa prelucrarile localizate pe server, numite si proceduri. Apelarea procedurilor de pe server de catre clienti se poate face prin intermediul mecanismului RPC (Remote Program Call).

Avantajele principale ale modelului bazat pe prelucrari distribuite constau in reducerea traficului prin retea si o repartizare echilibrata a prelucrarilor intre client si server. In schimb, dupa cum am mai spus, dezvoltarea unor asemenea aplicatii este dificila datorita cunostintelor numeroase si a experientei solicitate.

Un exemplu de adoptare a acestui model il reprezinta aplicatiile care dispun de formulare pentru culegerea datelor si care implementeaza diferite operatiuni de prelucrare si verificare a datelor in cadrul formularelor, pentru a fi transmise datele catre server intr-o forma consistenta. In acest fel, dialogul interactiv dintre utilizator si aplicatie (in cazul aparitiei unor erori de culegere, de exemplu) este localizat pe platforma client, reducand astfel costurile si intarzierile specifice comunicatiilor.

Gestiunea izolata (deportata) a datelor, in care platforma client asigura atat gestionarea dialogului cat si logica aplicatiei, iar serverul asigura doar gestionarea datelor. In acest caz se realizeaza o repartizare clara a functiilor intre client si server si se asigura o securitate sporita a datelor.

Aplicatia client transmite cererile sale de date serverului, iar acesta din urma transmite inapoi datele cerute. Toate prelucrarile asupra datelor, specifice aplicatiei, sunt efectuate pe platforma client.

Dezvoltarea aplicatiilor conform acestui model este facilitata nu numai de repartizarea clara a functiilor intre client si server ci si de oferta bogata de produse mature, cum ar fi SGBDR-urile. Astazi, SGBDR-urile asigura si controlul integritatii datelor din BD, ceea ce reprezinta o facilitate foarte importanta intr-un mediu client/server in care mai multe aplicatii client pot modifica aceste date. Localizarea controlului integritatii datelor in acelasi loc in care se afla datele (pe server) permite consultarea si actualizarea datelor de catre oricare din aplicatiile client in deplina siguranta, precum si reducerea traficului de retea (cererile privind controlul integritatii numai tranziteaza reteaua, ca in cazul in care controlul integritatii ar fi localizat pe platforma client).

Introducerea trigger-elor in SGBDR-uri faciliteaza controlul integritatii BD si gestiunea datelor independent de aplicatiile client. Modelul gestiunea izolata a datelor se diferentiaza de sistemele bazate pe simpla partajare a fisierelor de date, in care pe server sunt stocate numai datele in timp ce serviciile de gestionare a datelor sunt rezidente pe client. Desigur ca, in acest caz, traficul in retea este mult mai mare.

Avantaje ale acestui model:

♦ este mai usor de inteles deoarece functiile aplicatiei sunt clar repartizate intre client si server;

♦ garanteaza o securitate si consistenta mai buna a datelor;

♦ exista o oferta variata de produse bine maturizate.

Dezavantajele asociate pot fi enumerate:

♦ nu este adaptat mediilor tranzactionale intensive; desi SGBDR-urile asigura accesul concurrent la date, ele nu suporta decat un numar limitat de utilizatori (cateva sute), caz in care se face apel la masinile tranzactionale, care au rolul de server frontal al SGBDR.

♦ traficul in retea este mai mare decat in cazul modelului bazat pe distribuirea prelucrarilor.

Gestiunea distribuita a datelor presupune repartizarea datelor intre client si unul sau mai multe servere. Datele repartizate vor fi gestionate ca un ansamblu logic, fiind numai fizic distribuite. Postul client devine el insusi server de date si se creaza legaturi de tip server-server care, de cele mai multe ori presupune o gestiune a datelor intr-un mediu eterogen (calculatoare, sisteme de operare, retele sau SGBD-uri diferite).

Acest model reprezinta in teorie modelul ideal de distribuire deoarece permite combinarea datelor intr-o maniera avantajoasa atat pentru unitate (coerenta sistemului prin globalizarea resurselor eterogene) cat si pentru utilizatori (sunt mai aproape de date, iar prelucrarile datelor sunt mai rapide).

Cu toate ca asigura coerenta globala a sistemului, in conditiile existentei unor resurse eterogene, si ofera performante sporite, implementarea acestui model este deosebit de complexa, fie si numai pentru ca o cerere SQL trebuie analizata si rezolvata la nivel global, iar pentru consistenta datelor trebuie implementate mecanisme in doua sau mai multe faze.

La aceasta complexitate se adauga si oferta (inca) limitata privind arsenalul de produse necesare pentru implementarea unui asemenea model. In practica, arhitectura client/server a unei aplicatii poate combina mai multe din cele cinci modele prezentate anterior. O asemenea arhitectura poate rezulta prin distribuirea atat a datelor cat si a prelucrarilor.