Ingineria programarii I

Curs 7
Arhitecturi distribuite

<Ingineria programarii I>

Proiectare arhitecturala – cursul 8 <Gabriela Varvara>

Obiective curs:
Obiectivul 1: explicarea avantajelor si dezavantajelor diferitelor tipuri de
arhitecturi distribuite
Obiectivul 2: prezentarea arhitecturilor de tip client-server si cu obiecte
distribuite
Obiectivul 3: descrierea mecanismelor de tip broker de cerere de obiecte si a
principiilor ce definesc standardele CORBA
Obiectivul 4: prezentarea celor mai recente modele de calcul distribuit
materializate prin arhitecturi peer-to-peer si orientate pe servicii

Subiecte tratate:
A hit t i multiprocesor
Arhitecturi lti
Arhitecturi client-server
Arhitecturi cu obiecte distribuite
Calcul inter-organizational

Page 1
 <Ingineria programarii I>
Sisteme distribuite <Gabriela Varvara>

In cea mai mare parte sistemele informatice de dimensiune mare sunt, la ora
actuala, distribuite
Drept consecinta, procesarea informatiei a trecut de la stadiul implicarii unei
singure masini la conlucrarea calculatoarelor dintr-o retea
Ingineria dezvoltarii de aplicatii distribuite capata o pondere insemnata pentru
sistemele de calcul industriale

Clasificarea sistemelor software din punct de vedere al distributiei:

Sisteme personale – nu sunt distribuite si ruleaza pe o singura statie de
lucru
Sisteme incorporate (embedded) – ruleaza fie pe un procesor, fie pe un
grup integrat de procesoare
Sisteme distribuite –aplicatia ruleaza pe un grup de procesoare ce prezinta
un grad de integrare redus, dar coopereaza prin intermediul unei retele

<Ingineria programarii I>

Caracteristicile unui sistem distribuit <Gabriela Varvara>

Partajare de resurse ( hardware si software)

Deschidere – posibilitatea de a folosi echipament si software de la diferiti
furnizori
Concurenta – accepta executia concurenta a proceselor in vederea cresterii
performantei
Scalabilitate – poate suferi cresteri ale volumului de date procesat si numar de
utilizatori variabili in conditii de functionare similara
Toleranta la defecte – abilitatea de a-si continua operarea dupa aparitia unui
defect

Page 2
 <Ingineria programarii I>
Dezavantajele sistemelor distribuite <Gabriela Varvara>

Complexitate – au un grad crescut al complexitatii in raport cu aplicatiile

centralizate
Securitate – au g
grad crescut de vulnerabilitate la atacurile externe
Gestionabilitate – implica un efort crescut pentru managementul sistemului
global
Nepredictabilitate – exista un grad de predictabilitate scazut datorat organizarii
sistemului si incarcarii retelei

<Ingineria programarii I>

Arhitecturi pentru sisteme distribuite <Gabriela Varvara>

Arhitecturi client-server – au la baza crearea unor sevicii distribuite apelate de

catre clienti.
clienti Serverele ce furnizeaza serviciile sunt tratate diferit fata de clientii
ce doar folosesc serviciile.
Arhitecturi cu obiecte distribuite – pentru acestea nu exista nici o distinctie
intre clienti si servere. Fiecare obiect rezident pe o masina poate oferi/folosi
servicii catre/ale alte/altor obiecte.

Page 3
 <Ingineria programarii I>
Aplicatiile distribuite si componenta middleware <Gabriela Varvara>

Middleware – componenta software ce gestioneaza si ofera suport diferitelor

componente ale sistemului distribuit. Poarta aceasta denumire deoarece rezida
in miezul sistemului
sistemului.
Middleware este mai curand o componenta prefabricata (off-the-shelf) decat
dezvoltata pentru un anumit produs.
Exemple:
Monitoare pentru procesarea tranzactiilor;
Convertoare de date;
Controlere pentru comunicatii

<Ingineria programarii I>

Arhitecturi multi-procesor <Gabriela Varvara>

Reprezinta un model simplificat al unui sistem distribuit

Permite descrierea sistemului prin intermediul prin intermediul unui numar
oarecare de procese ce pot, dar nu este obligatoriu, sa fie executate pe
procesoare diferite.
Sistemele mari de timp real sunt descrise intotdeauna prin acest tip arhitectural
Distribuirea proceselor pe procesoare poate sa fie dispusa aprioric sau poate
sa fie controlata de catre un mecanism de tip dispecer.

Page 4
 <Ingineria programarii I>
Exemplu – sistem multi-procesor de control a traficului <Gabriela Varvara>

<Ingineria programarii I>

Arhitecturi distribuite client-server <Gabriela Varvara>

Sunt modelate sub forma unui set de servicii :

furnizate de catre server
utilizate de catre clienti

Clientii au cunostinta despre serverele cu care conlucreaza, in timp ce

serverele nu au informatii despre clientii ce le vor solicita serviciile

Atat clientii cat si serverele sunt procese logice

Maparea procesoarelor pe procese nu este in mod necesar 1:1

10

Page 5
 <Ingineria programarii I>
Exemplu de arhitectura client-server <Gabriela Varvara>

11

Exemplu – dispunerea masinilor in retea pentru

<Ingineria programarii I>
arhitectura client-server <Gabriela Varvara>

12

Page 6
 <Ingineria programarii I>
Arhitectura pe aplicatie stratificata <Gabriela Varvara>

Nivelul de prezentare
prezinta rezultatele procesarii si colecteaza
datele de intrare
Nivelul de procesare al aplicatiei
livreaza elementele de functionalitate
ale aplicatiei
Nivelul de management date
gestiunea bazelor de date

13

<Ingineria programarii I>

Clienti thin(“subtiri”) si clienti fat (“grasi”) - I <Gabriela Varvara>

Modelul “thin-client” – in cadrul acestui model toate aplicatiile de procesare si

gestionare de date sunt pe server. Clientul este responsabil doar pentru rularea
softului de prezentare.

Modelul “fat-client”
fat-client – servul are doar responsabilitatea gestiunii datelor.
datelor Softul
de pe partea client implementeaza logica aplicatiei si interactiunea cu
utilizatorul

14

Page 7
 <Ingineria programarii I>
Clienti thin(“subtiri”) si clienti fat (“grasi”) - II <Gabriela Varvara>

Thin client:
Folosit in situatiile in care sistemele mostenite suporta un proces de
migrare catre arhitecturi client-server
Sistemul mostenit actioneaza ca un server cu drepturi depline si cu o
interfata cu utilizatorul implementata pe partea client
Are ca dezavantaj supraincarcarea serverului si a retelei
Fat client:
Cea mai mare parte a procesarii este delegata catre masina client
Se preteaza pentru sistemele in retea cu masini client puternice
Are un grad de complexitate crescut in raportul cu modelul thin mai
ales in ceea ce vizeaza partea de management. Noile versiuni ale
p
aplicatiei vor trebui instalate pe
p toti clientii.

15

<Ingineria programarii I>

Exemplu – ATM pe arhitectura client-server <Gabriela Varvara>

16

Page 8
 <Ingineria programarii I>
Arhitecturi client-server in 3 straturi (3-tier C/S architecture) <Gabriela Varvara>

Fiecare nivel arhitectural din aplicatie poate fi executat pe un procesor distinct

Permite o performanta crescuta in raport cu modelul thin client si este mai usor
de gestionat decat modelul fat client
Este o arhitectura cu grad de scalabilitate crescut – odata cu cresterea cererilor
noi servere pot fi adaugate

17

<Ingineria programarii I>

Sistem Internet banking <Gabriela Varvara>

18

Page 9
 <Ingineria programarii I>
Utilizarea arhitecturilor client-server <Gabriela Varvara>

Arhitecturi cu 2 nivele de tip thin client – aplicatii cu sisteme mostenite unde

nu este practic sa se separe partea de procesare a datelor de partea de
management a acestora. Se foloseste pentru aplicatii :
cu multe calcule (ex. compilatoare) unde exista putin sau nu exista
management de date.
Cu multe date (navigare, interogare) unde exista putina sau nu exista
deloc procesare de date.
Arhitecturi cu 2 nivele de tip fat client – aplicatii pentru care softul de procesare
pe partea de client este prefabricat (ex. Microsoft Excel). Se foloseste pentru
aplicatii:
Cu procesare intensa a datelor (ex. Vizualizare date)
Cu functionalitate end-user relativ stabila si care lucreaza intr-un mediu
cu management stabil pentru sistem
Arhitecturi cu 3 sau mai multe nivele – aplicatii pe scara larga cu sute pana la
mii de utilizatori unde atat datele cat si aplicatia sunt volatile sau in care se cere
integrarea datelor din mai multe surse.

19

<Ingineria programarii I>

Arhitecturi cu obiecte distribuite <Gabriela Varvara>

Pentru acestea nu exista nici o distinctie intre partea client si partea server.
Fiecare entitate ce suporta procesul de distributie este un obiect ce ofera servicii altor obiecte si
primeste servicii de la alte obiecte
Comunicarea intre obiecte este realizata in partea de middleware a sistemului numita broker de
cerere obiect.
Aceste arhitecturi au un grad de complexitate crescut in comparatie cu arhitecturile client-server.

20

Page 10
 <Ingineria programarii I>
Avantajele arhitecturii cu obiecte distribuite <Gabriela Varvara>

Permite proiectantului amanarea luarii deciziilor referitoare la unde si cum vor fi

furnizate serviciile.
Este o arhitectura foarte deschisa ce permite adaugarea de noi resurse in
functie de necesitati.
Sistemul obtinut este flexibil si scalabil
scalabil.
Exista posibilitatea reconfigurarii dinamice a sistemului prin migrarea
obiectelor in retea in functie de necesitati.

Utilizarea arhitecturilor cu obiecte distribuite:

Ca modele logice ce permit structurarea si organizarea sistemului. In
acest fel functionalitatea va fi gandita in termeni de servicii si
combinatii de servicii.
Ca metoda flexibila de implementare a sistemelor client-server. Pentru
acestea modelul logic al sistemului este client-server, dar atat clientul
cat si serverul sunt realizate ca obiecte distribuite ce colaboreaza
utilizand acelasi mediu de comunicare.

21

<Ingineria programarii I>

Sisteme data mining <Gabriela Varvara>

Modelul logic al unui sistem data mining nu este unul de furnizare de servicii in
care sa existe servicii distincte de management de date.
Modelul permite cresterea numarului de baze de date accesat de catre sistem
fara afectarea acestuia.
Modelul permite extragerea unor noi tipuri de relatii prin adaugarea de noi
obiecte integratoare.

22

Page 11
 <Ingineria programarii I>
CORBA <Gabriela Varvara>
Este un standard international pentru ORB (Object Request Broker) –
componenta middleware de management a comunicatiilor intre obiecte
distribuite.
Aceasta componenta este organizata pe 2 nivele:
Nivelul logic – permite obiectelor rezidente pe masini diferite sa schimbe
date si sa contoleze informatia;;
Nivelul componenta – ofera baza pentru dezvoltarea de componente
compatibile ce respecta standardele CORBA
Structura unei aplicatii CORBA
Obiecte ale aplicatiei
Obiecte pentru un domeniu
(definite de Object Management
Group)
Servicii CORBA fundamentale
(ex. servicii de directoare, de management
al securitatii, etc.)
Facilitati orizontale ce sunt aceleasi
pentru mai multe aplicatii (ex. Interfete utilizator)

23

<Ingineria programarii I>

Standarde CORBA <Gabriela Varvara>

Modelul obiect pentru obiectele aplicatiei – este un obiect CORBA ce

incapsuleaza starea obiectului din aplicatie si care are o interfata neutra din
punct de vedere al limbajului aplicatie, definita in IDL (limbaj de definire a
interfetei)

Un broker de cerere obiect – ce gestioneaza cererile pentru diferite servicii

oferite de catre obiectele aplicatiilor

Un set de servicii generale de lucru cu obiecte ce poate fi folosit de mai multe

aplicatii distribuite

Un set de componente comune plasat in varful acestor servicii.

24

Page 12
 <Ingineria programarii I>
Obiecte CORBA <Gabriela Varvara>

In principiu, obiectele CORBA sunt asemanatoare cu obiectele C++ si Java

Ele TREBUIE sa aiba o definitie de interfata separata formulata in IDL (similar

cu C++)

Exista o relatie de mapare de la limbajul IDL la limbajul aplicatiei (C++, Java,

etc.)

Odata respectate aceste conditii, obiecte scrise in limbaje diferite pot sa

comunice intre ele

25

<Ingineria programarii I>

Broker cerere obiecte (Object Request Broker – ORB) <Gabriela Varvara>

ORB gestioneaza comunicarea intre obiecte. El au cunostinta de toate obiectele

din sistem, precum si de interfetele acestora.
Cu ajutorul unui ORB, obiectul apelant se mapeaza pe un stub (in IDL) ce
defineste interfata obiectului apelat (atribute si semnaturi ale metodelor
acestuia). Stub este o componenta software (un obiect) ce reprezinta, in
arhitecturi client-server,
client server serverul pe masina client.
client Prin stub se transmit sub
forma de mesaje, de catre masina client, apeluri de metode ale obiectelor de pe
server. Masina server contine un obiect skelton,sub forma de IDL publicat, ce
reprezinta clientul. Prin skelton se despacheteaza mesajul de la client si se
invoca metode de pe obiectul local.

26

Page 13
 <Ingineria programarii I>
Comunicare inter ORB <Gabriela Varvara>

ORB sunt reprezentate ca seturi de obiecte ce apartin unor biblioteci ce vor fi

incorporate in aplicatie chiar din faza de dezvoltare a acesteia.
Fiecare masina intr-o retea va avea propriul sau ORB ce va gestiona
comunicarea intre obiectele ce se executa pe acea masina.
Pentru apeluri de obiecte in retea se va recurge la comunicarea inter-ORB
inter-ORB.

27

<Ingineria programarii I>

Servicii CORBA <Gabriela Varvara>

Specificatiile de interoperabilitate intre obiecte sunt grupate sub termenul generic de

“arhitectura de gestiune a obiectelor” (OMA – Object Management Architecture).
OMA se dezvolta in 2 directii:
Modelarea fundamentala a obiectelor (COM – The Core Object Model) – ce
stabileste conceptele fundamentale de obiect
obiect, interfata
interfata, lucru cu instante
instante, etc
etc.
CORBA este un stadiu evolutiv superior COM.
Arhitectura de referinta OMA – defineste infrastructura de servicii si mecanisme ce
permit interoperarea intre obiecte. Are urmatoarele componente:
Mecanismul de cerere de obiecte (ORB)
Servicii:
De nume – permit obiectelor sa se descopere si sa se refere unele la altele
in retea
De notificare – permit obiectelor sa notifice alte obiecte asupra producerii
evenimentelor
De tranzactionare – permit realizarea de schimburi atomice cu gestiune a
caderilor
Facilitati comune de lucru

28

Page 14
 <Ingineria programarii I>
Calcul inter-organizational <Gabriela Varvara>

Din motive de inter-operabilitate si securitate, cea mai mare parte a calculului

distribuit este implementata la nivel de organizatie

Drept consecinta se vor aplica standarde si procese operationale si de

management locale

Modelele noi de calcul distribuit, cu noduri de procesare plasate in organizatii

diferite, vor trebui dezvoltate astfel incat sa suporte comunicarea
interorganizationala

29

<Ingineria programarii I>

Arhitecturi peer-to-peer <Gabriela Varvara>

Sistemele peer-to-peer (p2p) sunt in esenta sisteme descentralizate pentru care

efortul de procesare poate fi preluat de oricare nod al retelei distribuite
Sistemul global este proiectat astfel incat sa se beneficieze de puterea de
calcul si de capacitatea de memorare a numarului mare de masini
interconectate in retea
Majoritatea sistemelor p2p sunt bazate pe retele de PC-uri

Modele arhitecturale p2p:

Arhitectura de retea logica – cuprinde arhitecturile descentralizate si semi-
centralizate
Arhitecturi pe aplicatii – reprezentate prin arhitecturi generice pentru
aplicatii p2p

30

Page 15
 <Ingineria programarii I>
Arhitecturi p2p <Gabriela Varvara>

Artitectura descentralizata

Arhitectura semi-centralizata

31

<Ingineria programarii I>

Arhitecturi orientate pe servicii <Gabriela Varvara>

S-au dezvoltat in jurul notiunii de servicii furnizate din exterior ( servicii Web)
Un serviciu Web este reprezentat printr-o metoda standard de a face
reutilizabila o componenta disponibila si accesibila pe Web

Serviciu generic:
Un act sau o performanta oferita de catre o parte altei parti. Cu toate ca un
proces poate fi legat de un produs fizic, performanta este, in mod esential,
un element intangibil si nu este un rezultat al proprietatii asupra vreunui
factor de productie
Drept consecinta, furnizarea de servicii este independenta de aplicatiile ce
folosesc serviciul

32

Page 16
 <Ingineria programarii I>
Servicii Web <Gabriela Varvara>

33

<Ingineria programarii I>

Servicii si obiecte distribuite <Gabriela Varvara>

Accesul distribuit la obiecte prin intermnediul serviciilor ofera urmatoarele

avantaje:
Independenta de furnizor
Anuntarea publica a disponibilitatii serviciului
Legarea potentiala in faza de executie (dinamica) cu serviciul
Construirea pe principii oportunistice, prin compunere, de noi servicii
Plata folosirii serviciilor
Aplicatii mai mici si mai compacte
Aplicatii reactive si adaptive

Standarde ale serviciilor Web – au la baza standarde XML si pot fi furnizate pe

orice platforma si scrise in orice limbaj de programare.
programare Standarde cheie:
SOAP – Simple Object Access Protocol
WSDL – Web Services description language
UDDI – Universal Description, Descovery and Integration

34

Page 17
 Scenariu de organizare arhitecturala bazata pe servicii
<Ingineria programarii I>
Sistem automotiv <Gabriela Varvara>

Un sistem de informare intern unui vehicul furnizeaza

informatii despre: vreme,
vreme conditii trafic rutier,
rutier informatii
locale, etc. El este legat de aparatul radio al masinii si livrat
ca un semnal al unui canal radio.

Masina este echipata cu un receptor GPS pentru localizare

si, bazat pe aceasta pozitie, sistemul acceseaza o anumita
gama de servicii de informare, ce vor fi livrate in limba
solicitata de sofer.

35

<Ingineria programarii I>

Arhitectura sistem GPS de informare sofer despre vreme si trafic <Gabriela Varvara>

din Ian Sumerville, 2004

36

Page 18