.

1 Prezentarea arhitecturilor de dezvoltare a aplicatiilor distribuite

.1.1 Introducere
Aplicatiile distribuite s-au dezvolat cu o mare amploare si intr-o maniera naturala
ca urmare a utilizarii modelelor software cu aspect non functional ceea ce a dus la
orientarea deciziilor, in ceea ce priveste dezvoltarea aplicatiilor, catre dezvoltarea si
utilizarea arhitecturilor de sisteme distribuite.
Termenul de non-functional urmareste definirea aspectului de a dezvolta aplicatii
intr-o maniera neorientata pe functii ca model de a rezolva probleme computationale.
Astfel tehnologiile de dezvoltare software au urmarit dezvoltarea orientata pe obiecte iar
ulterior dezvoltarea orientata pe componente.
Cateva dintre principalele aspecte care absorb aceste cerinte spre modele nonfunctionale sunt scalabilitatea, eterogenitatea, toleranta la erori(software) si
defecte(hardware) precum si sisteme software care converg catre un sistem deschis sau
spre ideea de reutilizare a produselor software.[1]
Cea mai dezvoltata si utilizata metodologie este aceea de a construi sisteme
distribuite cu middleware[6]. Avantajul acestei abordari este asigurarea furnizarii, catre
dezvoltatorii de aplicatii software, a unor pachete de primitive care permit administrarea
cu o mai mare usurinta a complexitatii distribuirii resurselor sistemelor implicate cat si
rezolvarea multora dintre aspectele non-functionale.[1]
Pe masura evolutiei cerintelor de aplicatii non-functionale, gradul de cuplare
dintre middleware si arhitectura a devenit punctul principal catre care s-au focalizat
aspectele legate de stabilitatea arhitecturii sistemelor software distribuite. In acest sens
ipoteza urmareste ideea de domino si anume dezvoltarea unei arhitecturi de sistem
ditribuit stabile este condusa de alegerea facuta fata de sistemul middleware si a
flexibiltatii acestuia de a raspunde la viitorele schimbari de cerinte de sistem si aplicatii.
Cerintele software functionale si non-functionale prezinta un aspect volatil in
sensul existentei poisibilitatii ca acestea sa sufere modificari si sa evolueze de-a lungul
existentei lor. Schimbarile ce pot apare sunt inveiltabile deoarece in ele se reflecta
evolutia mediului in care sunt dezvoltate aplicatiile software.
Orice schimare care apare poate aduce prejudicii arhitecturii sistemului software
necesitind astfel modificari aduse structurii arhitecturale (de exemplu componente si
interfete), a topologiei arhitecturii sau chiar modificari aduse la nivel de middleware.
Toate aceste aspecte conduc catre o utilizate ineficienta si neeconomica si in final la
degradarea utilitatii ininitiale a sistemului.
Acest context conduce in final catre o nevoie imperioasa de a dezvolta sisteme
arhitecturi software flexibile care tind sa fie stabile pe masura ce are loc evoultia
cerintelor.

Notiunea de arhitectura stabila urmareste capacitatea unui sistem software de a

indura schimbarile aparute la nivel de cerinte in timp ce arhitectura acestuia ramane
intacta. [1]
Fenomenul indus de notiunea de mai sus poarta in mod uzual termenul de
stabiliate arhitecturala.
In ceea ce priveste nivelul de middleware acesta este prevazut in asa fel incat sa
permita simplificarea construirii sistemelor distribuite oferind primitive de nivel inalt care
protejeaza dezvoltarea aplicatiei de complexitatea aspectelor legate de sisteme
distribuite, de administrarea de resurse implicate si de implementarea detatliilor
corespunzatoare nivelelor inferioare cum ar fi controlul concurentei, administrarea
tranzactiilor si a comunicatiilor de date in retea.
Cu toate acestea, in ciuda faptului ca arhitectura sistemului si middleware se
adreseaza unor faze diferite in dezvoltarea produsului software, in final nivelul
middleware poate influenta arhitectura sistemul in curs de creare. In contrast alegeri
specifice arhitecturii sistemului determina anumite constrangeri in selectia fundamentului
reprezentat de middleware.
.1.2 Arhitecturi uzuale de dezvoltare a aplicatiilor distribuite
In cursul dezvoltarii unui produs software trebuie sa existe un echlibru intre
dezvoltarea tactica si dezvoltarea strategica.
Din punct de vedere tactic arhitectura urmareste aspectele legate de rezolvarea
problemei pentru care se dezvolta produsul in timp ce din punct de vedere strategic
arhitectura trebuie sa urmareasca cat mai multe dintre posibilitatile ulterioare catre care se
poate orienta utilitatea produsului care se dezvolta.
Majoritatea arhitecturilor existente se modeleaza pe baza unuia dintre urmatoarele
modele: modelul two-tier client/server si three-tier numit uzual si n-tier.
La nivel inalt aceste modele se concentreaza asupra partitionarii procesarii
realizate de sistem, mai abstract ele sunt responsabile pentru decizia prin care se
stabilieste pe care masina si in care psatiu de proces un anumit bit de cod se executa.
Arhitectura client-server se refera la modelul generic utilizat in orice arhitectura
care divide procesarea intre doua sau mai multe procese, uzual pe doua sau mai multe
masini. Intr-o astfel de arhitectura se urmareste sa se asigure un acces concurent la date.
.1.2.1 Arhitectura pe doua niveluri (two-tier)
Forma cea mai simpla a unei arhitecturi client-server poarta denumirea de twotier. Termenul two-tier este utilizat pentru a descrie modul in care procesarea realizata de
aplicatie poate fi distribuita intr-o aplicatie de tip client-server.[15]

Intr-o arhitectura two-tier procesul client se executa pe o statie de lucru care

intercationeaza cu un proces server care ruleaza pe un sistem ce este accesibil printr-o
retea.
O aplicatie dezvoltata intr-o arhitectura two-tier asigura mai multe statii de lucru
cu un nivel de prezentare uniform care comunica cu nivelul centralizat de date.
Nivelul de prezentare reprezinta de regula clientul in timp ce nivelul de stocare al
datelor reprezinta serverul.

Server
Client
Figura 1.2.1-1 Arhitectura cu doua niveluri (Two Tier)
Arhitectura sistemului depinde de aplicatia dezvoltata insa prezinta doua mari
limitari generale care pot fi intalnite.
Aceste limitari intervin in situatia in care avem de-a face cu clienti cu o
complexitate ridicata si in situatia in care apre necesitatea de reutilizare a obiectelor.
In mod ideal arhitectura de tip client-server trebuie sa lase fiecare masina sa
realizeze numai procesarea relevanta specializarii acelei masini. Statiile de lucru sunt
concepute astfel incat sa ofere utilizatorilor o interfata, in timp ce serverele sunt
concepute sa manipuleze date si algoritmi complexi precum si adiminstrarea proceselor
de retea pentru a servi imediat ce datele sunt stocate. Pe masura ce sistemul devine mai
complex prin intermediul clientilor apar mai multe necesitati care nu pot fi plasate in mod
clar de o parte sau de alta a modelului two-tier.[15]
Cresterea in complexitate a fost combatuta, in paralel, prin cresterea complexitatii
la nivel hardware. Astfel masinile client au devenit mai puternice din punct de vedere
computational in timp ce masinile server au devenit mai ieftine. Pe masura ce masinile
client au devenit mai puternice si au fost in stare sa tina pasul cu necesitatile din ce in ce
mai complexe ale interfetei cu utilizatorul masinile server au suferit o reducere a
capacitatii de a face fata stocarii datelor complexe.

Reutilizarea obiectelor software reprezinta unul din conceptele centrale in

abordarea obiect-orientata. Acest lucru aduce o limitare in abordare de tip two-tier
deoarece exista o legatura prea puternica a aplicatiei cu baza de date necesara pentru
stocarea datelor. Solutia adoptata a fost utilizarea si dezvoltarea bibliotecilor de clase insa
acestea nu asigura felxibilitatea necesara pentru a asigura reutilizarea la un nivel inalt. [15]
.1.2.2 Arhitectura pe trei sau mai multe niveluri (three-tier / n-tier)
Problemele ce apar in dezvoltarea aplicatiilor distribuite prin arhitectura two-tier
pot fi evitate prin utilizarea unui model mai complex denumit three-tier care extinde
modelul de mai sus de la doua niveluri la trei. [15]
Astfel modelul arhitectural three-tier adauga modelului two-tier un nivel
suplimentar care izoleaza procesarea de date intr-o zona centrala maximizand astfel
reutilizarea obiectelor.
Arhitecura three-tier este arhitectura in care un proces client se executa pe o statie
de lucru client in timp ce procesul server se executa pe o masina de tip server. Masina
server este conectata la o masina gazda care ofera servicii masinii server.
Uzual diferenta intre three-tier si n-tier se refera la faptul ca arhitectura n-tier
asigura executia procesului client pe orice statie de lucru in timp ce procesul server se
executa pe una sau mai multe masini de tip server in mod distribuit. Nivelul middleware
mediaza toate interactiunile dintre diverse procese.

Serverul Aplicatiei
(Server middle-tier,
e.g Java Application
Server)

Alt tip de server

(Server de date, Server Web, etc.)
Client

Figura 1.2.2-1 Arhitectura cu trei niveluri (Three Ttier)

Nivelul central numit si middle-tier[15] din structura celor trei nivele ale
arhitecturii reprezinta serverul aplicatiei si se ocupa de procesarea datelor care nu se
incadreaza in oricare din restul nivelelor. Serverul aplicatie este astfel orientat catre
rezolvarea problemelor specifice organizate in obiecte denumite general obiecte practice

sau obiecte de lucru. La nivelul procesarii acestor obiecte intervin anumite reguli centrale
denumite reguli de preocupare sau de lucru astfel ca indiferent de domeniul problemei
regulile in care datele sunt procesate se schimba rareori iar, in mod ideal, de loc.
Cu toate ca aduce importante avantaje dezvoltarii de aplicatii distribuite
arhitectura three-tier prezinta limitarile sale si acestea sunt legate de gradul de
complexitate pe care il aduce sistemului.
.1.3 Evolutia paradigmelor utilizate in dezvoltarea aplicatiilor distribuite
Odata cu evolutia spectatculoasa a calcului distribuit s-au dezvoltat de-a lungul
timpului si o serie de paradigme si tehnologii urmarind prelevarea statiior de lucru
individuale, a calculatoarelor personale si a ubicuitativului sistem Internet.
Cresterea cererii de aplicatii care sa utilizeze facilitatile de mai sus a dus astfel la
necesitatea dezvoltarii de instrumente software de dezvoltare orientate catre obtinerea
unui nivel de abstractizare suficient de inalt pentru a acoperi vastitatea domeniului de
aplicatii ditribuite.
O aplicatie distribuita reprezinta o aplicatie dezvoltata si implementata astfel incat
sa utilizeze capacitatile puse la dispozitie prin intermediul unui sistem distribuit. Un
sistem distribuit, conform definitiei atribuite de IEEE, reprezinta un sistem de calcul in
care mai multe entitati de calcul interconectate partajeaza sarcina de calcul totala atribuita
sistemului.
La nivelul cel mai de jos de abstractizare intalnim modelul bazat pe transmitere
de mesaje care incapsuleaza cea mai mica cantitate de datlii in timp ce la cealalta extrema
intalnim spatiul obiectelor fiind cea mai abstracta paradigma.

nivel de abstractizare
ridicat

spatiul obiectelor, aplicatii colaborative

servicii de retea, obiect de intermediere a cererii, agenti mobili
apel de proceduri la distanta, invocare de metode la distanta
client-server, peer-to-peer
transmitere de mesaje

scazut

Figura 1.3-1 Paradigme de dezvoltare a aplicatiilor distribuite si nivelurile de

abstractizare [14]

.1.3.1 Modelul bazat pe transmiterea de mesaje

Modelul bazat pe trasnmiterea de mesaje reprezinta metoda uzuala de abordare a
comunicarii interproces. In aceasta paradigma datele care reprezinta mesajele sunt
interschimbate intre doua procese, un proces emitator si un proces receptor.
Modelul bazat pe transmiterea de mesaje reprezinta una dintre paradigmele
fundamentale utilizate in dezvoltarea aplicatiior distribuite. Functionalitatea de baza a
acestui model urmareste emiterea unui mesaj reprezentand o cerere care este livrata
receptorului. Procesul receptor proceseaza cererea si transmite un mesaj drept raspuns,
acesta putand la radnul sau declanseze o noua cerere care determina aparitia unui nou
raspuns.
Procesul A

Procesul B
mesaj
mesaj
mesaj

Transmitere de Mesaje
Figura 1.3-2 Paradigma Transmiterii de Mesaje [14]
.1.3.2 Paradigma client-server
Modelul client-server urmareste asignarea in mod asimetric a rolurilor
corepsunzatoare proceselor colaborante. Astfel un proces reprezentand server-ul are
asignat rolul de furnizor de servicii care asteapta pasiv sosirea cererilor, in timp ce al
doilea proces reprezentand clientul emite cereri specifice catre server si asteapta
raspunsul.[14]
Simpla paradigma client-server aduce un nivel de abstractizare suficient de bun
pentru a distribui servicii precum si pentru a permite o simplificare sincronizarii intre
evenimente.
Sistem gazda pentru
procese server

Sistem gazda
pentru procese
client

cerere de servicii
process client
process server
serviciu

Figura 1.3-3 Paradigma client-server

.1.3.3 Paradigma peer-to-peer

In paradigma client-server procesele participante purtau roluri diferite si anume
procesul client emitea cereri si astepta raspunsul in timp ce procesul server urmarea in
mod pasiv aparitia de cereri de servicii si furniza serviciul cerut in raspuns.
In paradigma peer-to-peer proceselor participante li se confera roluri cu
capabilitati si responsabilitati echivalente (de aici si termenul de peer (engleza: egal, pe
pas de egalitate). In acest model fiecare participant poate emite o cerere catre un alt
participnat si poate primi raspuns.

Procesul 1

cerere
cerere

raspuns
raspuns

Procesul 2

Figura 1.3-4 Paradigma peer-to-peer[3]

.1.3.4 Paradigma sistemului de mesaje sau modelul Middleware orientat pe
mesaje(MOM)
Acest model reprezinta o extensie a mai vechiului model bazat pe transmiterea de
mesaje. Acest model introduce un nivel intermediar corespunzator unui sistem de mesaje
intre procese relativ indepndente. Sistemul de mesaje actioneaza ca un comutator pentru
mesaje si este astfel folosit de procesele participante pentru a schimba mesaje intre ele
intr-un mod asincron si cu un cuplaj slab. Modul de functionare urmareste depozitarea
mesajelor de catre emitator in sistemul de mesaje care il transmite mai departe catre o
coada de mesaje asociata cu fiecare proces receptor. Odata mesajul transmis emitatorul
este liber sa avanseze la o noua sarcina de lucru.[14]
Figura 1.3-5
emitator
Paradigma
sistemului de
mesaje
emitator
Sistem de mesaje
receptori

Modelul MOM prezinta doua submodele.

.1.3.4.1 Modelul bazat pe mesaje punct-la-punct
Modelul bazat pe mesaje punct-la-punct urmareste ca sistemul de mesaje sa emita
mai departe mesajul receptionat de la emitaor catre coada de mesaje a receptorului, spre
deosebire de modelul clasic bazat pe transmiterea de mesaje, nivelul middleware asigura
un depozit de mesaje si permite ca emisia si receptia sa fie slab cuplate. Prin intermediul
nivelului middleware emitatorul depunde mesajele in coada de mesaje a procesului
recptor care le extrage pe rand si le trateaza. In acets fel se obtine un plus abstractizare
care permite operatii asincrone.
.1.3.4.2 Modelul bazat pe mesaje publicare/subscriere
Modelul bazat pe mesaje publicare/subscriere asociaza fiecare mesaj cu un anumit
tip de eveniment, in timp ce aplicatiile interesate de aparitia unui anumit eveniment
subscriu catre mesajele corespunzatoare acelui tip de eveniment. Systemul de mesaje
distribuie mesajul corespunzator evenimentului asteptat catre toti abonatii.
Modelul ofera o abstractizare puternica mai ales in ceea ce priveste grupurile de
comunicatie.
.1.3.5 Apelul de proceduri la distanta (Remote Procedure Call RPC)
Modele descrise anterior asigura o functionare suficeint de buna pentru protocoale
de retea si penrtu aplicatii de retea simple. Evolutia complexiatii in timp a aplicatiilor a
dus insa la necesitatea dezvoltarii unor noi modele mai puternice si mai abstracte. In
particular era de dorit sa existe o paradigma care sa permita dezvoltarea unui produs
software distribuit intr-o maniera similara aplicatiilor conventionale care se executau pe
un singur procesor.In acest context a aparut modelul apelului de proceduri la distanta care
a permis comunicare interproces prin apeluri de proceduri atat de comune
programatorilor de aplicatii.[14][19][23]
Modelul implica existenta a doua procese independente care pot exista pe masini
diferite. Procesul care doreste sa adreseze o cererea catre celalalt proces emite un apel de
procedura transferand odata cu apelul si o lista de argumente. Ca si in cazul apelurilor
locale de proceduri apelul de metode la distanta declanseaza o actiune predefinita intr-o
procedura furnizata de procesul catre care s-a emis apelul.
Proces A

procedura1(arg1, arg2)

apel de procedura

procedura2(arg1)
procedura3(arg1, arg2,arg3)

Figura 1.3-6 Paradigma apelului de proceduri la distanta

Dupa finalizarea executiei procedurii procesul care a primit apelul de procedura

returneaza rezultatul catre procesul care a realizat apelul.
.1.3.6 Paradigma obiectelor distribuite
Odata cu dezvoltarea tehnologiei obiect-orientate s-a urmarit in mod natural si
tendinta aplicarii acestei directii catre aplicatiile distribuite care aceeseaza obiecte
distribuite in cadrul unei retele.
.1.3.6.1 Invocarea de metode la distanta (Remote method invocatio RMI)
Modelul invocarii de mdetode la distanta este modelul obiect-orienata echivalent
descris modelului mai sus mentionat si anume modelul apelului de proceduri la
distnata.[14][21]
In acest caz apelul se face asupra unei metode a unui obiect.
Proces 2
Proces 1

Invocare de metode la
distanta

o
o

metoda 1
metoda 2

obiect la distanta
Figura 1.3-7 Invocarea de metode la distanta
.1.3.6.2 Paradigma serviciilor de retea
Modelul serviciior de retea urmareste o abordare inovativa prin inregistrarea
furnizorilor de servicii in cadrul diverselor servere existente in retea.
Un proces care doreste un anumit serviciu contatcteaza serverul in momentul
exectutiei si in cazul in care serviciul este disponibil atunci va fi furnizata o referinta la
acesta prin utilizarea careia procesul intercationeza cu serviciul.[14]

Director de
servicii

Solicitant de
servicii

serviciu
obiect

Figura 1.3-8 Paradigma serviciilor de retea

.1.3.6.3 Paradigma cererii de obiecte prin intermediar (Object request

broker)
Paradigma cererii de obiecte printr-un intermediar urmareste ca aplicatia sa emita
o cerere catre un obiect intermediar al cererii (object request broker ORB) care
redirectioneaza cererea catre un obiect apropiat care ofera serviciul dorit.[18]
Principalul avantaj urmarit de aceasta paradigma provine din utilizarea unui nivel
middleware reprezentat de ORB permitand astfel accesul la multiple obiecte la distanta.
Solicitant de
obiecte

Obiect

Obiectul de intermediare a cererii/raspunsului la

cerere

Figura 1.3-9 Cererea de obiecte prin intermediar

.1.3.6.4 Paradigma spatiului de obiecte
Modelul spatiului de obiecte atinge unul dintre cele mai inalte nivele de
abstractizare aceasta paradigma presupunand existenta unor entitati logice numite spatii
de obiecte la care adera toti participantii unei aplicatii. Un furnizor plaseaza obiecte ca
intrari intr-un spatiu de obiecte in timp ce beneficiarii care subscriu la acelsi spatiu
acceseaza aceste inrari.[14][21]
furnizor

solicitant
citire
scriere

solicitant
citire

Spatiu de obiecte

Fihura 1.3-10 Modelul spatiului de obiecte

Modelul descris asigura astfel un spatiu virtual intre furnizori si beneficiari ai
resurselor de retea sau obiecte. Aceasta abstractizare ascunde detaliile impicate in
cautarea de resurse sau obiecte necesare in paradigme precum invocarea metodelor la
distanta, a serviciilor de retea sau au cererii de obiecte printr-un obiect intermediar.
In afara de aceste paradigme s-au dezvoltat multe alte modele insa nu la fel de
graitoare si de puternice.

10

.1.3.7 Paradigma Agentilor Mobili

Un agent mobil reprezinta un program sau un obiect transportabil.
Acest model, folosit petru dezvoltarea aplicatilor distribuite, utilizeaza un
mecanism ce urmareste lasnarea agentilor de pe masini gazda. Agentii parcurg un
itinireariu bine stabilit deplasandu-se de la o masina gazda la urmatoarea. La fiecare
stationare pe o masina gazda obiectul sau programul agent acceseaza resurse sau servicii
si executa sarcinile necesare pentru indeplinirea misiunii pentru care au fost lansati.
Sistem 2

Sistem 1

Sistem 3
agent

Sistem 4

Figura 1.3-11 Modelul bazat pe agenti mobili

.1.3.8 Paradigma aplicatiilor la nivel colaborativ sau Groupware
Modelul Groupware asigura participarea proceselor intr-o mniera colaborativa in
cadrul unei sesiuni de lucru sau , mai generic, intr-un grup. Fiecare proces participnat
poate contribui cu date la nivel de intrare catre o parte sau catre intregul grup al carui
membru este. Procsele apartenente grupului asigura aceasta contribuitie printr-un
mecanism de multidistribuire pentru a transmite date sau pot folosi asa numitele tabele de
inregistrare (sketchpads, whiteboards) [14] ceea ce premite fiecarui participant sa citeasca
si sa scrie date de la si spre un afisaj comun.
mesaj

Paradigma bazata pe transmitere de mesaje

Paradigma bazata pe modelul colaborativ

Figura 1.3-12 Modelul colaborativ

11

Aceasta paradigma repzinta o baza de plecare pentru mule sisteme software ce

urmaresc o distribuire in cadrul unui mdeiu colaborativ, cum ar fi Lotus Notes, CLIPS,
Microsoft NetMeeting si Groove.
.1.4 Tehnologii utilizate in dezvoltarea aplicatiilor distribuite
De-a lungul timpului aplicatiile distribuite, care au dictat, prin cerintele lor, modul
in care s-au dezvoltat tehnologiile utilizate scopul dezvoltarii acestora, au evoluat catre
doua domenii. Primul domeniu, care a constituit si punctul de plecare al dezvoltarii de
aplicatii distribuite, a urmarit asigurarea unui nivel de distribuire doar la nivel de
intreprindere. O data cu dezvoltarea uimitoare a tehnologiilor orientate catre aplicatii
desfasurate in sistemul Web a aparut si tendinta de a dezvolta aplicatii distribuite si la
acest nivel. Astfel a aprut urmatoarea generatie de aplicatii distribuite, ce constituie
fundamentul celui de-al doilea domeniu si anume aplicatii distribuite dezvoltate peste
sistemul Web.
.1.4.1Tehnologii orientate spre aplicatii dezvoltate la nivel de intreprindere
.1.4.1.1 Modelul bazat pe obiecte componente distribuite (Distribuited
Component Object Model DCOM)
Modelul obiectelor componente (COM) reprezinta o tehologie cu un caracter
general dezvoltata de Microsoft si care pune la dispozitie un cadru de lucru pentru
integrarea componentelor software.
Pricipiile de baza ale tehnologiei COM sunt utilizarea unor identificatori globali
unici denumiti identificatori de clasa (class identifiers CLSIDs) si intercatiunea dintre
obiecte si dintre obiecte si sistem se face printr-un set de functii denumite interfete.[8][9]

Proces
Client

Client

Obiect
intra-proces
(in-process)
Server intra-porces
(in-process)

Proces
Server
local

Server local
Stub
LPC

Obiect Proxy
Local

COM

Masina la distanta (remote)

COM
Obiect Proxy
la distanta

Obiect
local

RPC

Proces
Server
la distanta

Obiect
local
Server local

Stub
COM

Figura 1.4-1 Arhitectura tehnologiei COM

12

Arhitectura tehnologiei COM urmareste definirea modului in care componentele

si clientii acestora ineractioneaza. Intercatiunea este astfel definita astfel incat clientul si
componenta vizata se pot conecta fara necesitatea unui sistem intermediar.
In modelul adoptat de Microsoft se prevede ca procesele sa fie izolate unele de
altele asfel ca un client care doreste sa comunice cu o componenta in cadrul unui alt
proces trebuie sa utilizeze o metoda de comunicare interproces oferita de sistemul de
operare. COM ofera insa acest mod de comunicatie intr-o maniera ce asigura transparenta
si anume se intercepteaza apelurile de la client si le transmite mai departe catre
componenta intr-un alt proces.
Tehnologia COM a derivat, o data cu necesitatea dezvoltarii de aplicatii
distribuite, in tehnologia DCOM (COM Distribuit) astfel asigurandu-se comunicatia intre
obiecte aflate pe diferite calculatoare, ruland peste LAN, WAN sau Internet. Tehnologia
DCOM a fost dezvoltata pe baza paradigmei RPC pentru apelul de functii insa
majoritatea diferentelor care apar sunt transparente la nivelul dezvoltatorului. [16][18]

Client

COM
run-time
Furnizor
RPC
Securitate
Stiva de Protocol
(Protocol Stack)

COM
run-time
Furnizor
RPC
Securitate
Stiva de Protocol
(Protocol Stack)

Componenta

Protocol de
retea DCOM

Figura 1.4-2 Arhitectura tehnologiei DCOM

.1.4.1.2 .NET la distanta(.NET Remoting)
Odata ce Microsoft a anunat noul set de dezvoltare .NET a aparut si un set de
dezvoltare pentru aplicatii distribuite, denumit .NET Remoting, asigurandu-se astfel noua
tehnologie in cadrul Microsoft pentru aplicatii distribuite care permite ca programe si
componente software sa intercationeze peste diverse domenii de aplicatii, procese si
masini.
.NET Remoting utilizeaza o arhitectura flexibila si care poate fi extinsa fiind
orienata nu numai pe obiecte ci si pe componente software. Tehnologia .NET Remoting
utilizeaza unul din principalele concepte ale tehnologiei .NET si anume Domeniu de
Aplicatie care reprezinta o structura abstracta ce urmareste asigurarea izolarii datelor de
codul aplicatiei dar fara sa fie necesar sa se bazeze pe concepte specfifice sistemului de
operare cum ar fi procesele si thread-urile.[18]

13

Domeniul Aplicatiei la Client

(Client AppDomain)
Client

Domeniul Aplicatiei la Server

(Server AppDomain)
Dispecer

Proxy

Obiect
Server

Element de
formare

Element de
formare

Canal de
transport

Figura 1.4-3 Arhitectura .NET Remoting

.1.4.1.3
Architecture)

Tehnologia

CORBA

(Common

Object

Request

Broker

Acronimul CORBA provine de la Common Object Request Broker Architecture

si a fost lasnat in septembrie anul 1991 de catre OMG (Object Management Group) al
carui scop este de a crea standarde ce permit interoperabilitatea si portabilitatea
aplicatiilor obiect-orienate distribuite.
Arhitectura Administrarii de Obiecte (Object Management Architecture OMA)
creata de OMG isi propunea la acea vreme sa defineasca la un nivel foarte inalt de
abstractizare facilitatile necesare calcullui orientat pe obiecte.
La baza OMA s-a aflat ORB, arhitectura despre care am vorbit in capitolul
1.3.6.3, si a fost adoptata de Digital Equipment Corporation, Hewlett Packard, Hyper
Desk Corpoation, NCR Corporation s.a.
CORBA 1.1 a fost intodus in 1991 si definit Interface Definition Language si
Application Programming Interfaces (API), care a permis intercatiunea de tip clientserver intre obiecte in cadrul unei implementari specifice a ORB.
CORBA 2.0 a fost adopta in decembrie 1994 s a urmari asigurarea unei puternice
interoperabilitati prin specificarea felului in care Obiectele de Intermediere a
Cererii(ORB) dezvoltate de diferiti producatori de sisteme software pot intercationa.
Modelul OMA propus de CORBA prevedea obiecte care ofera servicii si clienti
care emit cereri pentru aceste servicii. Tehnologia CORBA s-a dezvoltat in jurul a cinci
componente de baza si anume nucleul ORB, Limbajul de definire al intefetei
(IDL),depozitul interefetei, interfata de invocare dinamica (DII) si adaptorii de
obiect.(OA).

14

Dezvoltarea aplicatiilor in standardul CORBA are la baza doua modele: Modelul

Obiectului Nucleu (Core Object model) si Modelul bazat Referinte (Reference Model).
Core Object Model defineste conceptele care faciliteaza dezvoltarea de aplicatii
distribuite folosind modelul ORB, in timp ce Modelul Referinta defineste modul de
dezvoltare pentru CORBA si a interfetelor standard utilizate de dezvoltatorii de produse
software pentru crearea structurilor software (frameworks), a componentelor si a
obiectelor.
Modelul Referinta plaseaza ORB-ul in centrul unui grup de obiecte care prin
intermediul interfetlor standardizate asigura suport pentru dezvoltarea si evolutia
aplicatiilor. [8][18][27]

Proces Client

Proces Client
Client
CORBA

Interfata de
invocare
dinamica

Stub
IDL

Obiect
CORBA
Interfata
ORB

Interfata
ORB

Skeleton
IDL static

Skeleton
Dinamic

Obiect
Adaptor

Depozit de
Interfeta

Nucleul ORB

Depozit de
Implementare

Figura 1.4-4 Arhitectura CORBA

.1.4.1.4 Tehnologia JINI (Java Intelligence Network Infrastructure)
Tehnologia JINI a fost dezvoltata ca un set de componente software care
furnizeaza infrastructura necesara pentru unirea serviciilor pe baza unor principii
concludente.
In acest sens tehnologia propusa de Sun Microsystems reprezinta un mdel care
suporta si incurajeaza dezvoltarea de servicii distribuite cu un grad inalt de fiabilitate si
care pot fi incluse intr-un sistem JINI pentru a oferi diverse functionalitati catre oricare
memru al sistemului.
Arhitectura JINI urmareste doua concepte de baza si anume protocoale de
descoperire-uniune-vizitare (Dicovery-Join-Lookup) si specificatii privind modalitatea de
concepere a dispozitivelor ce urmeaza sa fie inglobate in sistemul JINI.

15

Serviciu Jini

Serviciu Jini

JINI
Descoperire

Vizitare
(Lookup)

Uniune

JAVA
Dispozitiv

Aplicatia
software

Client

Figura 1.4-5 Structura si arhitectura tehnologiei JINI

Protocoalele Discovery-Join-Lookup sunt protocoale interne utilizate de sistemul
JINI pentru a realiza inregistrarea si utilizarea dispozitivelor JINI (de exemplu telefoane
celulare) sau a aplicatiilor software dezvoltate ca servicii JINI.
Procesul de descoperire al serviciilor reprezinat un proces ce urmareste serviciile
vizitate iat protocolul de descoperire este utlizat ata la clinet cat si de partea serviciilor in
sine.
Procesul de unire este un proces ce realizeaza inregistrarea unui nou serviciu JINI
fata de toate serviciile existente si vizitate. In acest sens este utilizat ceea ce se numeste
un serviciu Proxy care se comporta ca o semnatura pentru serviciul ce urmeaza a fi
adugat in grupul serviciilor deja existente.
LUS
Serviciu
Proxy
Serviciu
Proxy
Serviciu
Proxy

Serviciu
Proxy

Serviciu Serviciu
Proxy
Jini

Figura 1.4-6 Pocesul de uniune (Join)

Un serviciu JINI reprezinta din punct de vedere programatic un obiect descris in
limbajul de programare Java si care dispune de o interfata ce defineste operatiile ce pot fi
cerute acestui serviciu.
Serviciu Jini

Sistem de
calcul

Sistem de
stocare date

Canal de
comunicare

Echipament
HW

Alt
utilizator

Figura 1.4-7 Servicii JINI si relatia cu alte obiecte.

16

Comunicare intre serviciile JINI se realizeaza folosind standardul Java

corespunzator pradigmei RPC si anume invocarea de metode la distanta sau Java Remote
Method Invocation. Trebuie specificat ca mecanismul RMI utilizeaza interfete descrise
put in limbajul Java si din acest motiv el poate fi utilizat numai pentru obiecte Java. RMI
permite nu numai transmiterea de date intre obiecte ci chiar transmiterea de obiecte,
inclusiv cod.
Pentru administrarea diferitelor servicii disponibile intr-un sistem JINI tehnologia
dezvoltata de Sun a realizat un serviciu special numit Lookup Service (LUS) care
stocheaza proxie-urile servciilor si care este folosit de catre clienti pentru a descarca
proxie-ul unui serviciu atunci cand este realizata o astfel de cerere.[18][25][26]
.1.4.1.5 Tehnologia J2EE ca tehnologia pentru dezvoltarea aplicatiilor
distribute (EJB)
Tehnologia J2EE ofera o multitudine de variante arhitecturale in dezvoltarea
aplicatiilor precum printr-o serie de tipuri de componente, cum ar fi componente EJB,
componentele servlet, pagini JSP si filtre servlet, si o serie de servere de aplicatii cu
servicii aditionale.
Cu toate ca acesta matrice de optiuni de dezvoltare ne ofera posibiltatea de a
obtine cea mai buna proiectare pentru fiecare problema totusi ea nu este insotita de
absenta totala a riscurilor. Utlizatorii tehnologiei J2EE se pot gasi astfel in fata situatiilor
de a fi coplesiti de multitudinea alegerilor pe care le pot face sau pot alege o
infrastructura inadecavata probelemei pentru simplul motiv ca aceasta este diponibila.
Tehnologia J2EE asigura un suport deosebit pentru dezvoltarea si implementarea
arhitecturilor distribuite astfel ca mai multe componente ale unei aplicatii distribuite
J2EE pot fi rasfirate pe mai multe JVM-uri (Java Virtual Machine) care se pot afla pe
mai multe masini fizice de tip server. Aplicatiile distribuite dezvoltate la nivel de
intreprindere in tehnologia J2EE se bazeaza pe componente EJB (Enterprise Java Beans)
cu interfete remote prin intermediul carora server-ul asigura transparenta la nivelul
accesarii si administrarii componentelor distribuite. [21][28]
Nivelul
Prezentare

Nivelul
intermediar
(middle-tier)

Client
(browser Web)

Aplicatia
clientului
Servicii
JNDI

Container Web
Servlet

JSP
Container EJB

EJB

Nivelul
de date

Baza de date

EJB

JAAS
JDBC

Figura 1.4-8 Arhitecura mult-inivel

J2EE

17

.1.4.2 Tehnologii de dezvoltare a aplicatiilor distribuite in Internet

Majoritatea tehnologiilor prezentate anterior isi gasesc aplicabilitatea si in
domeniul aplicatiilor distribuite in Internet insa dezvoltarea acestui tip de aplicatii creste
nivelul de dificultate intampinat in proiectare. Din acest motiv aceste tehnologii au fost
utilizate ca architecturi de baza pentru crearea unor tehnologii care sa permita o
dezvoltare mai usoara a aplicatiilor in domeniul Internet.
Aplicatiile distribuite dezvoltate peste Internet se despart conceptual in doua
categorii si anume bazate general pe Internet folosind diverse protocoale Internet (sau
prootocoale proprii dezvoltatorului) si aplicatii bazate pe sistemul Web folosind de regula
protocolul HTTP. In prima categorie se incadreaza spre exemplu aplicatii bazate pe
componente servlet (sau JSP), care extind clasa Servlet si nu HttpServlet, in timp ce in a
doua categorie regasim aplicatii bazate pe componentele servlet ce extind HttpServlet,
servicii Web si servicii Grid. Cele mai raspandite aplicatii insa sunt aplicatiile Web.
O alta caracterizare a aplicatiilor distribuite in Internet prezinta doua categorii de
aplicatii: aplicatii care se adreseaza direct utilizatorului prin arhitecturi client-server in
care clientul este de regula un browser Web si care asigura deci interartiunea directa a
utilizatorului cu server-ul Web, iar cea de-a doua categorie descrie aplicatii ce sunt
dezvoltate peste sistemul Web dar nu prezinta o interactiune cu utilizatori umani ci numai
intre masini sau alte aplicatii si resurse cum ar fi de exmplu serviciile Web pentru
gestionarea accesului unei aplicatii la o baza de date.
O aplicatie Web reprezinta o colectie de tehnologii cu dezvoltarea aplicatiilor de
partea server-ului pentru generarea dinamica a continutului informatic accesat de
obicei prin intermediul unui browser Web de partea clientului.
Una din tehnologiile care s-a adresat facilitarii dezvoltarii aplicatiilor Web este
tehnologia J2EE care a introdus intr-o forma compacta, in cadul aceleasi arhitecturi,
componete software de tipul servlet-ilor, paginilor JSP si serviciilor Web. Astfel
platforma J2EE furnizeaza nucleul pentru arhitectura bazata pe componente software,
independente de platforma, a aplicatiilor Web. Un server al aplicatiei dezvoltat in
tehnologia J2EE include un container Web responsabil pentru administrarea cilcului de
viata al componentelor servlet si JSP. Containerul Web poate fi integrat intr-un server
Web ceea ce asigura usurinta in dezvoltarea si testarea aplicatiilor.
Componentele Servlet sun clase Java care receptioneaza cereri si emit raspunsuri
la aceste cereri utilizand de regula protocolul HTTP. De cele mai multe ori raspunsul
reprezinta o pagina HTML generata dinamic cu toate ca se pot emite pe post de raspuns si
documente XML, applet-uri sau obiecte Java serializate. In timp ce containerul Web este
responsail cu trasnmiterea cererilor catre servlet si receptionarea raspunsului acestuia prin
intermediul unui API bine definit, containerul pentru servlet-i este responsabil pentru
creare si distrugerea fiecarei componete servlet in parte.
Browser

Cerere HTTP
Raspuns HTTP

Container
pentru
Servlet-i

Componenta
Servlet
Continut
Static

Figura 1.4-9 Arhitectura aplicatiei Web bazate pe componente Servlet

18

Paginile JSP (Java Server Pages) reprezinta o extensie a tehnologiei bazate pe

componente Servlet. Spre deosebire de un servlet care este dezvoltat de un programator
sub forma unui document sursa, documentul JSP se aseamana cu un document HTML in
care se regasesc fragmente de cod Java. Paginile JSP permit generare dinamica de pagini
HTML prin imbinarea marcajelor XML cu tehnologia componentelor servlet. In practica
decizia privind alegerea dezvoltarii aplicatiilor pe baza compoentelor servlet sau pe baza
paginilor JSP depinde de regual de continutul final al paginii HTL generate. Astfel un
servlet este mai potrivit ca o componenta de control sau de modelare in timp ce
paginile JSP sunt mai potrivite pentru utilizarea ca si componente ce asigura o vedere
asupra conitnutului.
Serviciile Web reprezinta o tehnologie larg raspandita si utilizata in
implementarea aplicatiilor distribute la niveul sistemului Web. Ele dezvolta un model de
comunicatie program-la-program folosind standardul XML (eXtensible Markup
Language) care asigura o forma neutra raportata la platforme, limbaje de programare,
specificatii software.
Serviciile Grid extind arhitectura serviciilor Web pentru a permite mecansime
suplimentare de control si administrare a resurselor distribuite. Serviciile grid reprezinta
componentele de baza ale modelului orientat pe componente obiect distribuite numit
OGSA si exista mai multe interfete (portType) pe care un serviciului Grid le poate
implementa (asemanator clasei de baza in modelul obiect-orientat). Astfel se permite o
extindere a functionalitatilor de baza si indelinirea diverselor cerinte specificate privind
dezvoltarea unei aplicatii distribuite.[22][24]

19