Tehnici de Programare

Distribuit

CUPRINS
1.

Sisteme distribuite. Infrastructur..........................................................................3

1.1. Introducere..........................................................................................................3
1.2. Hardware-ul retelelor...........................................................................................3
1.3. Protocoale i servicii de reea..............................................................................4
1.3.1.
1.3.2.

1.4.
1.5.

Middleware bazat pe document (Document-Based)............................................5

Middleware bazat pe sistem de fiiere (File System-Based)................................5

1.5.1.
1.5.2.
1.5.3.
1.5.4.
1.5.5.

1.6.

CORBA (Common Object Request Broker Architecture).......................................7

Globe.......................................................................................................................7

Middleware bazat pe coordonare (Coordination-Based).....................................8

1.7.1.
1.7.2.
1.7.3.

2.

Tipul transferului.....................................................................................................6
Arborele directoarelor..............................................................................................6
Transparena numelor..............................................................................................6
Semantica partajrii fiierelor..................................................................................6
AFS (Andrew File System)......................................................................................6

Middleware bazat pe obiecte partajate (Shared Object-Based)............................7

1.6.1.
1.6.2.

1.7.

Sevicii de reea.........................................................................................................4
Protocoale de reea...................................................................................................5

Linda........................................................................................................................8
Publicare/nregistrare (Publish/Subscribe)..............................................................8
Jini...........................................................................................................................8

Tehnici de programare distribuit...........................................................................9

2.1. Apelul procedurilor la distan (RPC - Remote Procedure Call).........................9
2.1.1.

Probleme de implementare......................................................................................9

2.2. Programarea bazat pe componente...................................................................10

3. Tehnologiile Java RMI, CORBA i DCOM............................................................13
3.1. Java RMI...........................................................................................................13
3.2. CORBA.............................................................................................................13
3.3. DCOM............................................................................................................... 14
Bibliografie..................................................................................................................... 15

1.

Sisteme distribuite. Infrastructur

1.1.

Introducere

Sistemele distribuite sunt similare multicalculatoarelor n sensul c fiecare nod are

memoria lui proprie, iar memoria fizic nu este partajat n cadrul sistemului. Nodul unui
multicalculator conine, n general, un procesor, memorie RAM, o interfata de reea i, eventual,
un harddisk pentru paginare. Spre deosebire de acestea, fiecare nod ntr-un sistem distribuit este
reprezentat printr-un calculator complet cu toate perifericele sale aferente. O alt diferen ar fi
aceea c multicalculatoarele sunt localizate, n general, n aceeai camer, putand comunica ntre
ele prin reele dedicate, de mare vitez, n timp ce nodurile unui sistem distribuit pot fi
mprtiate n ntreaga lume.
O alt diferen: nodurile unui multicalculator ruleaz cu acelai sistem de operare,
partajeaz un singur sistem de fiiere i se afl sub o administrare comun, n timp ce nodurile
unui sistem distribuit pot rula sisteme de operare diferite, fiecare avnd propriul sistem de fiiere
i, eventual, propriul administrator.
Tipul
Caracteristica
Configuraia nodului
Perifericele nodului
Lucalizarea
Comunicaia internod
Sistem de operare
Sistem de fiiere
Administrare

Multiprocesor
CPU
Toate partajate
Pe aceeai plac
RAM partajat
Unul, partajat
Unul, partajat
O singur organizaie

Multicalculator
CPU, RAM, interfa de reea
Eventual hard disk partajat
Aceeai camer
Interconectare dedicat
Mai multe, acelai tip
Unul partajat
O singur organizaie

Sistem distribuit
Calculator complet
Toate disponibile nodului
Posibil n toat lumea
Reea tradiional
Posibil toate diferite
Fiecare nod are cte unul
Mai multe organizaii

Aplicaiile tipice pentru Internet includ accesul la calculatoarele remote (folosind telnet i
rlogin), accesul la informaii (folosind WWW i FTP), comunicaiile interpersonale (folosind email i chat) i multe alte aplicaii derivate (de exemplu, e-commerce, e-learning etc.). Problema
cu aceste aplicaii este c fiecare trebuie s o ia de la zero. De exemplu, e-mail, ftp i WWW
transfer fiiere, dar fiecare dintre ele are un mod
absolut diferit de a realiza acest lucru din punct de vedere al conveniilor de nume, al
protocoalelor de transfer, al tehnicilor de replicare etc. Cu toate acestea multe browsere de Web
ascund aceste diferene utilizatorilor.
Sistemele distribuite adaug nivelului inferior de reea o paradigm comun (model) care
asigur o modalitate uniform de tratare a ntregului sistem. Intenia sistemelor distribuite este de
a transforma o mulime de maini slab cuplate ntr-un sistem coerent, bazat pe un singur concept
cu scopul de a asigura unificarea sistemului.
Un exemplu simplu de utilizare a paradigmei de unificare a sistemului se ntlnete n
sistemele UNIX unde toate dispozitivele I/O sunt tratate n aceeai manier ca i fiierele datorita
faptului c tastatura, porturile paralele i seriale opereaza la fel i sunt mai uor controlat dect
dac ar fi privite, din punct de vedere conceptual, diferit.
O modalitate de a obine, ntr-o oarecare masur, uniformizarea n sistemele distribuite
(compuse din platforme hardware i sisteme de operare diferite) este introducerea unui nivel
intermediar ntre sistemul de operare i nivelul aplicaiei. Acest nivel este numit, de obicei,
middleware. El asigur structuri de date i operaii, care permit utilizatorilor i proceselor
remote s interopereze ntr-o manier consistent. Middleware poate fi privit ca un sistem de
operare pentru sisteme distribuite.

1.2.

Hardware-ul retelelor

Sistemele distribuite au la baz reelele de calculatoare. Exist o mare varietate de reele:

reele locale (LAN - Local Area Network), care acoper o cldire sau un campus, reele
rspndite din punct de vedere geografic (WAN - Wide Area Network) care conecteaz
calculatoare situate la distane mari i reele metropolitane (MAN - Metropolitan Area Networks)
care acoper de obiecei un ntreg ora i funcioneaz la viteze specifice pentru LAN. Reelele
MAN sunt conectate n general prin fibre optice. Cel mai important tip de LAN este Ethernet, iar
cel mai utilizat tip de WAN este Internet-ul.

1.3.

Protocoale i servicii de reea

Toate reelele de calculatoare asigur anumite servicii pentru utilizatori, care sunt
implementate respectndu-se anumite reguli legate de schimbul legal de mesaje.

1.3.1.

Sevicii de reea

Reelele de calculatoare asigur host-urilor care le folosesc anumite servicii.

Serviciile orientate pe conexiune sunt modelate dup sistemele telefonice. Pentru a
folosi un serviciu de reea orientat pe conexiune, utilizatorul unui astfel de serviciu trebuie mai
nti s stabileasc conexiunea, o folosete i apoi se deconecteaz. Aspectul cel mai important al
unei conexiuni este acela c funcioneaz ca un tub: un utilizator emite obiecte (bii) la un capt
i un receptor le primete, n aceeai, ordine la cellalt capt.
Spre deosebire de serviciile orientate pe conexiune, celelalte servicii sunt modelate
dup sistemul potal. Fiecare mesaj (scrisoare) conine adresa de destinaie complet i este rutat
n sistem independent de toate celelalte. n mod normal cnd dou mesaje sunt trimise la aceeai
destinaie, primul trimis va fi primul sosit. Cu toate acestea este posibil ca primul mesaj trimis s
fie ntrziat, astfel nct al doilea mesaj ajunge primul. La un serviciu orientat pe conexiune acest
lucru este imposibil.
Fiecare serviciu poate fi caracterizat de un QoS (Quality of Service). Unele servicii sunt
sigure n sensul c nu pierd niciodat date. De obicei, un serviciu sigur ateapt de la receptor
confirmarea primirii fiecrui mesaj prin trimiterea unui pachet special de acknowledgement
pentru ca emitorul s fie sigur c mesajul a ajuns la destinaie. Procesul de confirmare
introduce ntrzieri i trafic de date suplimentar, necesare pentru detectarea pachetelor pierdute,
iar acest lucru duce la ncetinirea
comunicaiei.
Un caz n care este necesar un serviciu sigur, orientat pe conexiune, este transferul de
fiiere. Proprietarul fiierului vrea s fie sigur ca toi biii ajung corect i n aceeai ordine n care
au fost trimii. Pentru unele aplicaii ntrzierile introduse de procesul de confirmare sunt
inacceptabile. O astfel de aplicaie este traficul vocal digital. Este preferabil ca utilizatorii
telefonului s auda un pic de zgomot pe linie sau un cuvnt distorsionat, din cnd n cnd, dect
s se introduc o ntrziere pentru a atepta
confirmarea.
Nu toate aplicaiile necesit conexiuni. De exemplu, pentru a testa reeaua, singura
operaie necesar este trimiterea unui singur pachet cu prioritate maxim, dar fr garanie.
Serviciile care nu sunt orientate pe conexiune, fr proces de confirmare, sunt adesea numite i
servicii cu datagrame, prin analogie cu serviciul de telegrafie care nu folosete proces de
confirmare.
Sunt situaii n care este preferabil s nu se stabileasc o conexiune, pentru a trimite un
mesaj scurt, dar sigurana este esenial. Serviciul cu datagrame i proces de confirmare poate
fi o soluie acceptabil pentru aceste tipuri de aplicaii.
Alt serviciu este serviciul cerere-rspuns. La acest serviciu emitorul trimite o singur
datagram care conine cererea. Replica conine raspunsul. Serviciul cerere-rspuns este folosit

frecvent pentru implementarea comunicaiei n modelul client-server: clientul iniiaz o cerere iar
serverul rspunde la aceasta.

1.3.2.

Protocoale de reea

O reea are reguli specializate referitoare la tipurile de mesaje care pot fi trimise i la
rspunsurile care pot fi returnate. De exemplu, n anumite situaii (transferul fiierelor), cnd un
mesaj este trimis de la o sursa la o destinaie, destinaia trebuie s trimit un mesaj de confirmare
c transmisia s-a efectuat corect. n alte situaii (telefonia digital) nu se ateapt aceast
ntiinare. Setul de reguli care particularizeaz comunicaia ntre calculatoare se numeste
protocol. Toate reelele moderne de calculatoare folosesc aa numita stiv de protocoale pentru a
structura pe nivele diferitele protocoale. Fiecare nivel trateaz alt gen de problem. De exemplu,
pe cel mai jos nivel, protocoalele definesc modul n care, ntr-o secven de bii, ncepe i se
termin un pachet. Pe urmtorul nivel protocoalele trateaz modul de rutare a pachetelor n reele
complexe, de la surse la destinaie. Pe un nivel mai nalt, protocoalele asigur transferul corect,
din punct de vedere al integritii i succesiunii pachetelor, al mesajelor multipachet.
ntruct majoritatea sistemelor distribuite se bazeaz pe Internet, protocoalele cele mai
folosite sunt: IP i TCP. IP (Internet Protocol) este un protocol cu datagrame n care emitorul
trimite o datagrama (pn la 64 KB) n reea i sper s ajung la destinaie. Nu sunt oferite nici
un fel de garanii. Datagrama poate fi fragmentat n pachete mai mici atunci cnd cltorete
prin Internet. Pachetele cltoresc independent i nu neaprat pe aceeai rut. Cnd toate
pachetele au ajuns la destinaie, sunt reasamblate n ordinea corect.
Datagramele IP nu folosesc ACK (acknowledgment code), deci protocolul IP nu este
suficient pentru a avea o comunicaie sigur n Internet. Pentru a asigura comunicaii sigure se
folosete, n general, protocolul TCP (Transmission Control Protocol) care este situat, de obicei,
deasupra protocolului IP. Protocolul TCP folosete protocolul IP pentru a asigura structuri de
date orientate pe conexiune. Pentru a folosi TCP, un proces trebuie nti s stabileasc o
conexiune la un proces la distan. Procesul cerut este specificat prin adresa de IP a unei masini
i printr-un numr de port de pe respectiva main care este disponibil pentru ascultarea
cererilor. Dup ce conexiunea a fost stabilit, procesul trimite bii pe conexiune, garantndu-se
faptul c ei ajung nealterai i n ordinea corect la destinaie. Implementarea protocolului TCP
asigur aceste garanii folosind secvene numerotate, sume de control i retransmisia pachetelor
recepionate incorect. Toate aceste operaii sunt transparente emitorului i receptorului. Acetia
vd doar o comunicaie interproces sigur.

1.4.

Middleware bazat pe document (Document-Based)

Dup cum am mai menionat, pentru a obine consisten n sistemele distribuite s-a
introdus un nivel intermediar numit middleware. Acest nivel poate fi implementat pornind de la
concepte de baz diferite. Cel mai cunoscut exemplu de middleware este World Wide Web. Ideea
general care a stat la baza Web-ului este foarte simpl: fiecare calculator poate s stocheze unul
sau mai multe documente numite pagini Web. Fiecare pagin Web conine text, imagini, icon-uri,
sunete, filme i multe altele, mpreun cu hyperlink-uri (pointeri) ctre alte pagini Web.
Atunci cnd un utilizator cere o pagin Web folosind un program numit browser de Web,
pagina este afiat pe ecran. Fiecare pagin Web are o adres unic numit URL (Uniform
Resource Locator). Protocolul cel mai des folosit este http (HyperText Transfer Protocol), dar
exist i alte protocoale de transfer, cum ar fi ftp (File Transfer Protocol).
Modul de funcionare al sistemului este urmtorul. Web-ul este un sistem tipic clientserver n care utilizatorii sunt clieni i site-ul de Web este server-ul. Atunci cnd utilizatorul d
browser-ului o adres URL, acesta efectueaz cateva operaii pentru a afia pagina Web cerut.

1.5.

Middleware bazat pe sistem de fiiere (File System-Based)

Ideea de baz a Web este ca un sistem distribuit s arate ca o colecie imens de

documente cu legturi. O alt abordare este considerarea sistemelor distribuite ca un mare sistem
de fiiere.
Folosirea modelului de sistem de fiiere pentru un sistem distribuit presupune existena
unui sistem de fiiere global cu utilizatori rspandii n ntreaga lume, care s poat citi sau scrie
fiiere pentru care au autorizaie. Comunicaia este obtinut printr-un proces care scrie date ntrun fiier i alte procese care citesc datele din acest fiier. n acest caz apar problemele obinuite
pentru sistemele de fiiere, dar mai apar i alte probleme legate de sistemele distribuite.

1.5.1.

Tipul transferului

Primul aspect este alegerea ntre modelul upload/download i modelul remote access.
n modelul remote access fiierul rmane pe server i clientul trimite comenzi pentru ca
lucrul s se desfoare pe server.
n modelul upload/download un proces acceseaz un fiier copiindu-l mai nti de pe
server. Dac fiierul trebuie doar citit, el este citit local, pentru mbuntirea performanelor.
Dac fiierul trebuie modificat, modificarea se face local. La terminarea lucrului cu fiierul
respectiv, fiierul actualizat este repus pe server. Avantajul modelului upload/download este
simplitatea acestuia. Dezavantajul este c trebuie s existe capacitatea de a stoca local ntregul
fiier iar mutarea ntregului fiier este
ineficient dac nu sunt necesare dect pri din acesta. Pe lng aceste probleme mai apare i
problema consistenei, atunci cnd exist mai muli utilizatori.

1.5.2.

Arborele directoarelor

O alt parte a acestui sistem este constituit de sistemul de directoare. Toate sistemele de
fiiere distribuite asigur suport pentru directoarele care conin mai multe fiiere. Exist mai
multe aspecte de care trebuie inut cont n proiectarea unui astfel de sistem. Un prim aspect ar fi
dac toi utilizatorii dispun de acelai model de vizualizare al ierarhiei directoarelor. Un alt
aspect este dac trebuie s existe sau nu un director rdcin recunoscut de toate mainile ca
rdcin.
O modalitate de a avea un director rdcin global este de a avea o rdcin care conine
o intrare pentru fiecare server. n aceast situaie calea are forma /server/path cu propriile sale
dezavantaje dar cel puin este aceeai n tot sistemul.

1.5.3.

Transparena numelor

Principala problem a formei de reprezentare a numelor este aceea c nu exist transparen

complet. Exist dou forme importante de transparen. Prima este constituit de transparena
localizrii, ceea ce nseamn c n cale sunt incluse indicii despre localizarea fiierului, dar nu se
specific nimic despre localizarea serverului. O alt form de transparen o reprezint
independena localizrii, ceea ce nseamn c fiierele pot fi mutate fr ca numele acestora s se
schimbe.

1.5.4.

Semantica partajrii fiierelor

Atunci cnd doi sau mai muli utilizatori partajeaz acelai fiier, este necesar definirea
unei modalitati de citire i scriere precise pentru a evita problemele. n sistemele uniprocesor
tratarea obinuit este urmatoarea: atunci cnd o procedur de citire urmeaza dup o procedur
de scriere, procedura de citire returneaz ultima versiune scris. Similar, atunci cnd apare o
succesiune de dou proceduri de scriere urmate de o procedur de citire, valoarea citit este cea
stocat n urma ultimei proceduri de scriere. Se spune c acest model are consisten
secvenial.

1.5.5.

AFS (Andrew File System)

Au fost proiectate i implementate mai multe tipuri de infrastructuri de comunicaie

(middleware) bazate pe sistem de fiiere. Unul dintre aceste tipuri este AFS, construit pe modelul
upload/download.
Denumirea acestui sistem - Andrew File System - este legat de Andrew Carnegie i
Andrew Mellon. Scopul iniial al acestui proiect a fost construirea unui sistem puternic bazat pe
UNIX, cu un sistem de fiiere partajat. Sistemul de fiiere a fost folosit ca middleware pentru a
transforma o colecie de staii de lucru ntr-un sistem coerent.
Fiecare utilizator AFS are o staie de lucru proprie pe care ruleaza un sistem UNIX uor
modificat. Modificarea const n adaugarea unei pri de cod numit venus la nucleu (kernel) i
rularea n spaiul utilizatorului a unui server de fiiere numit vice. Iniial venus rula tot n spaiul
utilizatorului, dar din considerente legate de performan a fost mutat n nucleu. Din motive
administrative, staiile de lucru ale utilizatorilor sunt grupate n celule. O celul poate fi o reea
local sau o colecie de reele locale interconectate.

1.6.

Middleware bazat pe obiecte partajate (Shared Object-Based)

Un al treilea mod de implementare a middleware este de a considera c toate sunt obiecte

n loc de a considera c toate sunt documente sau toate sunt fiiere. Un obiect este o colecie de
variabile asociate cu un set de proceduri de acces numite metode.

1.6.1.

CORBA (Common Object Request Broker Architecture)

Unele limbaje de programare cum ar fi C++ sau Java sunt orientate pe obiecte, dar aceste
obiecte sunt obiecte mai mult la nivel de limbaj dect obiecte run-time. Un sistem de baz pentru
obiecte run-time este CORBA (Common Object Request Broker Architecture). CORBA este un
model de tip client-server n care procesele client, rezidente pe mainile client, pot invoca
operaii pe obiectele localizate (posibil la distan) pe mainile server. Modelul CORBA a fost
proiectat pentru sisteme eterogene care ruleaz pe o varietate de platforme hardware i sisteme
de operare i implementate ntr-o multitudine de limbaje.
Standardul CORBA asigur infrastructura de comunicaie (middleware) a aplicaiilor.

1.6.2.

Globe

Un alt exemplu de sistem distribuit bazat pe obiecte, proiectat special pentru a fi folosit
de foarte muli utilizatori i a transfera un numar foarte mare de obiecte este Globe. Exist dou
probleme majore n proiectarea sistemelor de capacitate foarte mare. Primul aspect se refera la
replicarea obiectelor. A doua mare problem este constituit de flexibilitate. n sistemele cu mare
rspndire geografic, cu foarte muli utilizatori, nu exist nici o modalitate de a convinge toi
utilizatorii s foloseasc acelai limbaj de programare, aceeai strategie de replicare, acelai
model de securitate, i multe altele. Sistemul trebuie s permit utilizatori diferii i obiecte
diferite, care au o comportare diferit i, n acelai timp, trebuie s asigure un model coerent.
Acest lucru este realizat de Globe. ntruct un obiect Globe poate fi partajat de mai multe
procese n acelasi timp, acesta se mai numete i obiect distribuit partajat.
Pentru a folosi un obiect Globe, un proces trebuie s se conecteze mai nti la el prin
identificarea lui i prin gsirea a cel puin unei adrese de contact (de exemplu, adresa de IP i
port). La conectare se efectueaz cel puin o verificare de securitate i, dac procesul este
autorizat s se conecteze la obiect, plasa obiectului (codul acestuia) este ncrcat n spaiul de
adrese al procesului care a iniiat cererea, o copie a strii obiectului este instaniat i este
returnat un pointer la interfaa (standard) obiectului.
Folosind pointer-ul la interfaa, procesul poate apela metode ale instanei obiectului
respectiv. n funcie de obiect starea poate fi cea predefinit (default) sau o copie a strii curente
obinut de la unele copii n via.

Un element cheie al sistemului Globe este serviciul de localizare care permite

identificarea obiectelor oriunde s-ar afla acestea. Serviciul de localizare este organizat sub forma
unui arbore n care nregistrarea obiectelor este pstrat doar n nodul n care are loc. Pointer-ii
la aceste noduri se propag pn la rdcina arborelui, fapt care permite gsirea nregistrrii
oriunde s-ar afla aceasta.

1.7.

Middleware bazat pe coordonare (Coordination-Based)

Un alt model de sistem distribuit este middleware bazat pe coordonare.

1.7.1.

Linda

Linda este un sistem proiectat de Yale University pentru comunicare i sincronizare. n

Linda procesele independente comunic prin intermediul unui spaiu abstract de tupluri. Spaiul
de tupluri este global pentru ntregul sistem i procesele care ruleaz pe orice main pot insera
sau sterge tupluri n spaiul de tupluri, fr a ine cont de modul n care sunt stocate sau unde sunt
stocate acestea. Un tuplu este asemntor cu o structur din limbajul C sau cu o nregistrare din
limbajul Pascal. Tuplul const din unul sau mai multe cmpuri, fiecare putnd avea o valoare de
un anumit tip suportat de limbajul de baz (Linda este implementat prin adugarea unei
biblioteci la un limbaj existent, cum ar fi C).

1.7.2.

Publicare/nregistrare (Publish/Subscribe)

Acest sistem const din mai multe procese concatenate de o reea de difuzare (broadcast
network). Fiecare proces poate fi un productor de informaii, un consumator de informaii sau
amndou. Atunci cnd un productor de informaii are o informaie nou, o difuzeaz n reea
sub forma unui tuplu. Aceast aciunii se numete publicare. Fiecare tuplu conine o ierarhie de
linii de subiecte format din cmpuri multiple, separate prin perioade. Procesele interesate de
anumite informaii se pot nregistra la anumite subiecte. nregistrarea este realizat prin
furnizarea subiectului cutat unui proces pentru tupluri, rezident pe maina care controleaz
tuplurile nregistrate.

1.7.3.

Jini

Acest sistem a fost conceput de firma Sun Microsystems. Lumea Jini const ntr-un
numar mare de dispozitive Jini autoincluse, fiecare putnd oferi servicii celorlalte. Un dispozitiv
Jini poate fi conectat ntr-o reea i ncepe s ofere servicii instantaneu, fr a necesita o
procedur complex de instalare. Trebuie reinut faptul c dispozitivele sunt conectate ntr-o
reea i nu ntr-un calculator. Un dispozitiv Jini poate fi un calculator, dar poate fi i o
imprimant, un telefon celular, un televizor, un casetofon sau orice alt dispozitiv care are un
procesor, memorie i o posibilitate de conectare n reea (chiar i fr fir). Un sistem Jini este o
colecie de dispozitive Jini care pot aprea i disprea fr a avea o administrare centralizat.
Atunci cnd un dispozitiv Jini vrea s se alture coleciei de dispozitive Jini, acesta difuzeaz un
pachet, n reeaua local sau n celula wireless local, testand dac exist un serviciu de
identificare (lookup service). Protocolul folosit pentru a gsi serviciul de identificare este
protocolul de descoperire (discovery protocol) i este unul dintre puinele protocoale puternic
cablate (hardwired) din Jini. Atunci cnd serviciul de identificare descoper un nou dispozitiv
care vrea s se nregistreze i rspunde acestuia cu un cod cu care poate realiza nregistrarea.
Deoarece Jini este un sistem realizat n totalitate n Java, codul trimis de acest serviciu este n
format inteligibil pentru JVM (Java Virtual Machine). Toate dispozitivele Jini trebuie s fie
capabile s ruleze o maina virtual Java. Un dispozitiv Jini se poate deconecta din sistem i
existena lui va fi curnd uitat fr a fi nevoie de administrare centralizat.

2.

Tehnici de programare distribuit

2.1.

Apelul procedurilor la distan (RPC - Remote Procedure Call)

Ideea de la care a pornit dezvoltarea acestei arhitecturi este apelarea procedurilor pe alt
procesor. Atunci cnd un proces de pe o maina apeleaz o procedur de pe o a doua main,
procesul apelant de pe maina unu este suspendat i procedura apelat se efectueaz pe cealalt
main. Informaiile pot fi transportante de la apelant la apelat sub forma unor parametri i pot fi
returnate sub forma rezultatelor procedurii. Mesajele transferate sau I/O sunt complet
transparente programatorului. Aceast tehnic a fost numit apelul procedurilor la distan (RPC)
i a stat la baza dezvoltarii multor aplicaii i sisteme software. Procedura apelant poate fi
considerat client, iar procedura apelat poate fi considerat server.
Ideea de baz a RPC este aceea de a face un apel de procedur la distan s par pe ct
posibil un apel local. Cea mai simpl form de apelare a procedurilor la distana este de a lega
clientului o bibliotec de proceduri numit stub-ul clientului.
Stub-ul clientului reprezint procedura serverului n spaiul de adres al clientului.
n mod similar, serverul este legat cu o bibliotec de proceduri numit stub-ul server-ului.
Aceste biblioteci de proceduri ascund faptul c apelul de la client la server nu este local.
Comunicaia se desfoar n felul urmtor:
Clientul apeleaz stub-ul clientului. Acesta este un apel local de procedur n care parametrii
sunt stocai n stiv n modul obisnuit.
Stub-ul clientului mpacheteaz parametrii ntr-un mesaj i face un apel de sistem pentru a
trimite mesajul. mpachetarea parametrilor se numeste marshaling.
Nucleul sistemului de operare (kernel) trimite mesajul de pe maina clientului pe maina
serverului.
Nucleul sistemului de operare de pe maina serverului trimite pachetul recepionat stub-ului
serverului (care n mod normal a cerut recepionarea).
Stub-ul serverului apeleaz procedura serverului. Rspunsul urmeaz aceeai cale n sens
invers.
Elementul cheie al acestei modaliti de programare este c procedura clientului, scris de
utilizator s apeleze stub-ul clientului, are acelai nume ca procedura serverului. Din moment ce
procedura clientului i stub-ul clientului sunt localizate n acelai spaiu de adres, parametrii
sunt pasai n mod obisnuit. Similar, procedura serverului este apelat de o procedur din spaiul
su de adrese cu parametri cerui. Peocedura serverului nu are nimic neobinuit. n acest fel, n
loc s avem operaii de intrare/ieire folosind emisie i recepie (send and recive), comunicaia la
distan este realizat prin simularea unui apel de procedur obinuit.

2.1.1.

Probleme de implementare

n ciuda eleganei conceptului de apel al procedurii la distan, implementarea genereaza

o serie de probleme. O mare problem este folosirea pointer-ilor (referinelor). n mod normal,
un pointer la o procedur nu este o problem. Procedura apelat poate folosi pointer-ii n acelai
mod n care i poate folosi i apelantul deoarece ambele proceduri sunt localizate n acelai spaiu
de adrese virtuale. Pasarea pointer-ilor n cazul apelului procedurilor la distana este imposibil
ntruct clientul i serverul sunt situai n spaii de adrese diferite.
Exist situaii n care se poate folosi totui pasarea pointer-ilor. S presupunem c primul
parametru este un pointer la un ntreg k. Stub-ul clientului poate mpacheta ntregul i l poate
trimite n acest fel spre server. Dup aceea, stub-ul serverului creeaz un pointer la ntregul k pe
care l paseaz procedurii serverului. Atunci cnd procedura serverului cedeaz controlul stubului serverului, acesta trimite napoi la client ntregul, unde vechea valoare a ntregului este
suprascris cu noua valoare a lui. De fapt, secvena standard de apelare prin referin a fost
nlocuit prin copiere i reactualizare (copyrestore).
9

Din pcate aceast metod nu funcioneaz n toate cazurile. De exemplu, dac pointer-ul
se refer la o structur complex nu mai este posibil aceast metod. Din aceste considerente
trebuie fcute anumite restricii pentru parametrii pasai n apelul procedurilor la distana.
O a doua problem este constituit de slbiciunile limbajelor de programare cum ar fi C.
n C, de exemplu, este permis declararea unui vector fr s fie nevoie s se specifice
dimensiunea maxim a acestuia. Fiecare vector are o dimensiune maxim cunoscut numai de
procedura apelant i de procedura apelat. ntr-o astfel de situaie, mpachetarea de ctre stub-ul
clientului a parametrilor este imposibil deoarece acesta nu poate determina dimensiunile
maxime ale vectorilor respectivi.
O a treia problem este c nu ntotdeauna se poate deduce tipul parametrilor. Un exemplu
este funcia printf, care poate avea orici parametri de tipuri diferite: ntregi, caractere, stringuri, etc. ncercarea de a apela la distana funcia printf este practic imposibil pentru c limbajul
C este prea ngduitor. Cu toate acestea, dac s-ar specifica o regul ca RPC s nu fie permis n
limbajul C, ci numai n C++, aceasta nu ar fi acceptat.
A patra problem se refer la utilizarea variabilelor globale. n mod obinuit, apelarea,
procedura apelant i procedura apelat pot comunica folosind variabile globale ca parametri.
Dac procedura apelat este mutata pe o main la distan, codul nu va putea fi executat pentru
c variabilele globale nu mai sunt partajate. Cu toate problemele de implementare pe care la
ridic apelul procedurilor la distan, aceast tehnic este totui foarte utilizat. Pentru ca
funcionarea s se desfaoare corect, trebuie impuse anumite restricii.

2.2.

Programarea bazat pe componente

Creterea complexitii sistemelor computaionale a determinat programatorii s

cerceteze modalitile de abstractizare i de simplificare a procesului de dezvoltare a
programelor. O abordare de succes o costituie aplicarea paradigmei mparte i cucerete la
proiectarea i implementarea aplicaiilor. Ideea de baz este de a recunoate i descrie ntreaga
structur a unui sistem de programe pentru a putea identifica componentele sale fundamentale i
a putea folosi componente deja existente. Tehnici ca design paterns, proiectarea arhitecturii
sistemelor i dezvoltarea aplicaiilor bazate pe componente au la baza aceast idee de a refolosii
soluii deja existente.
Dezvoltarea World Wide Web-ului i a Internet-ului i n paralel cu acestea creterea
numarului calculatoarelor personale i a reelelor locale de calculatoare (LAN) complic din ce
n ce mai mult scenariul n care programatorii trebuiau s conceap aplicaii complet noi. Se face
trecerea de la aplicaii monolitice, care rulau pe o main izolat, la sisteme distribuite, care
ruleaz pe platforme eterogene att din punct de vedere hardware ct i software. Tehnologiile de
programare bazate pe componente permit celor care proiecteaz aplicaii reducerea costurilor de
proiectare, att din punct de vedere al timpului ct i al resurselor umane necesare pentru
proiectarea de produse noi. Firmele de soft sunt implicate ntr-o continu concuren pentru
dezvoltarea familiilor de produse i, pentru a putea lansa mai repede versiuni noi, ele folosesc, ca
punct de pornire, versiunile mai vechi deja existente. Aceast abordare, de refolosire, schimb
orientarea de la producerea de aplicaii ntregi, la reutilizarea i asmblarea prilor deja existente.
Lansarea primei versiuni de implementare a limbajului Java a avut un puternic impact n
industria de software. Portabilitatea, flexibilitatea i securitatea conferite de limbajul Java fac
proiectarea aplicatiilor mai uniform. Java conine faciliti pentru realizarea sistemelor
distribuite. Extensiile Java, ca RMI (Remote Method Invocation), Java-IDL, JavaBeans i
JavaSpaces completeaza distribuia iniial cu posibiliti avansate de dezvoltare a sistemelor
distribuite. Programarea orientat pe obiect a fost una din cele mai utlizate tehnici de programare
n ultimul deceniu. Obiectele reprezint abstractizarea unor entitati concrete. ncapsularea att a
datelor ct i a comportamentului, permite separarea implementrii i a interfeei pentru orice
obiect, iar clasele reprezint o abstractizare pentru grupurile de obiecte cu acelai comportament.
Mecanismul de motenire permite reutilizarea specificaiilor unei clase pentru definirea unei noi
clase i ofera o ierarhizare a relaiilor dintre obiecte. Clasa derivat poate refolosi
10

comportamentul superclasei oferind aceleai operaii asupra interfeei sale i permind crearea
de noi metode sau redefinirea unora din superclasa. Polimorfismul motenirii permite unor
obiecte diferite s raspund n mod diferit la acelai mesaj, face mai puternic mecanismul de
pasare a mesajelor ntre obiecte.
Tehnologiile bazate pe componente extind programarea orientat pe obiect oferind o
puternic abstractizare a modelului structural al sistemelor software. n general, termenul de
aplicaie bazat pe componente se refer la un model software care const dintr-un set de
concepte pe care un programator le poate folosi pentru a combina dinamic componentele
software n realizarea unei aplicaii. Conceptele de obiect, componenet, spaiu de lucru i
document au o semnificatie strns legat de contextul din care fac parte, dar, ntr-o prim
aproximare, se pot defini dup cum urmeaz:
Obiectul reprezint un container cu operaii de identificare i interfaare care partajeaz o stare
persistent.
Componenta este un obiect software care include o parte de algoritm logic. Componenta are
capacitile de granularitate variabil, refolosire i posibilitatea existenei unei entiti de sine
stttoare.
Spaiul de lucru nglobeaz componente colaborative cu o comportare extensibil pentru API
Documentul este o component prevzut cu o interfa interactiv pentru navigare i editare.
Documentul compus activ este un document format din pri distincte programabile prin scripturi. Complexitatea unei componente poate varia de la o simpl component grafic cum ar fi
butonul pn la procesoare de text sau tabele complexe de date.
Un model de aplicaie bazat pe componente trebuie s asigure o serie de servicii
esentiale pentru crearea eficient a unei aplicaii. Cnd o component este legat n run-time,
sunt necesare mecanisme pentru identificarea acesteia astfel nct celelalte componente s tie s
interacioneze cu ea. Acest proces se numete nregistrare i publicare a interfeei componentei
n cadrul spaiului de lucru. Este necesar persistena pentru a putea stoca informaiile oferite de
o component. Aceste faciliti sunt oferite de tipuri de componente ca OpenDoc, COM i
JavaBeans i n acelai timp de anumite medii de programare cum ar fi VisualBasic sau Delphi,
care ofer biblioteci extinse i utiliti care sunt referite tot sub numele de componente .
Spaiile de lucru (frameworks) sunt o colecie de componente colaborative prevzute cu
interete extensibile specializate pe domeniu pentru clieni. Documentele sunt componente
specializate ale cror interfee grafice sunt prevzute cu faciliti de editare i navigare. Spre
deosebire de acestea, documentele compuse activ sunt formate din pri cu funcionare autonom
asigurat prin thread-uri multiple sau prin script-uri. OpenDoc extinde paradigma din 1980 de
file/folder desktop pentru a asigura un model de document compus, puternic i simplu, care are
la baz interoperabilitatea dintre obiectele CORBA distribuite.
Componentele ActiveX prevd un model de document pentru documentele World Wide
Web (WWW) bazat pe componentele Microsoft, COM sau OLE.
Componentele JavaBeans mpachetate n arhive JAR confer un mediu de dezvoltare a
aplicaiilor bazate pe Java pentru managementul componentelor i construirea de platforme din
beans-uri (clase care respect anumite convenii legate de interfa).
Comparaia dintre modelele de document oferite de OpenDoc, ActiveX i JavaBeans
genereaz principii valabile pentru proiectarea i implementarea spaiilor de lucru bazate pe
componente colaborative prevzute cu interfee grafice interactive. OpenDoc, COM/OLE i Java
ofer modele foarte diferite de componente. Componentele OpenDoc au o identitate, o stare i
interfee vizuale, componentele COM/OLE sunt colecii de interfee care asigur servicii
independente de timp i trateaz identitatea i starea ca proprieti ale unor interfee speciale,
dependente de stare, ale containerelor, n timp ce componentele Java au o interfa nucleu i un
model de securitate care pot fi extinse cu clase modulare, biblioteci i unelte (tools).
OpenDoc specific o infrastructur independent de limbaj i un model de document
elaborat de OMG. Elegana conceptual i arhitectural a acestui model ofer un punct de pornire
pentru nelegerea arhitecturii documentului. ActiveX specializeaz componentele Microsoft
11

COM/OLE spre un model de document bazat pe Web. Java, cu extensiile acesteia incluse n
bibliotecile de clase java.lang, java.util i java.awt, asigur nu numai un limbaj ci i un mediu
de dezvoltare pentru tehnologia bazat pe componente, n timp ce JavaBeans extinde mediul de
programare Java pentru a oferi un toolkit de dezvoltare al componentelor i documentelor.
CORBA a jucat un rol important n formularea conceptelor i arhitecturilor interoperabile.
Interoperabilitatea COM-urilor la nivel binar (cod maina) i interoperabilitatea Java n cadrul
unui singur limbaj bine proiectat sunt mai puin ambiioase ca abordarea multilimbaj oferit de
CORBA. Interoperabilitatea este mult mai simpla n Java, care ofer un limbaj integrat, un mediu
de dezvoltare i un model bazat pe componente datorit faptului c diferenele datorate
limbajului sunt minime i ntrebrile semantice legate de interoperabilitate pot fi adresate direct.
JavaBeans pune accentul pe construirea de componente compuse din componentele Java i d
posibilitatea unei mai bune integrri a aplicaiilor de tip frame sau applet-urilor Java n sisteme
Web sau CORBA.

12

3.

Tehnologiile Java RMI, CORBA i DCOM

n acest capitol sunt prezentate, pe scurt, avantajele i dezavantajele fiecreia din cele trei
tehnologii. Pentru a executa cod rezident pe alte maini distribuite n reea, abordarea tradiional
a implementrii genereaz confuzii i erori. O modalitate mai bun de abordare a acestei metode
este de a considera c unele obiecte rezid pe diferite maini din reea i c se pot invoca metode
ale acelor obiecte prin trimiterea de mesaje ctre acestea, rezultatele de la ele obinndu-se ca i
cum apelul ar fi fost local.
Scopul principal al acestor trei tehnologii este s asigure o infrastructur care s permit
scrierea relativ simpl a aplicaiilor distribuite, dar acest scop este atins de fiecare tehnologie n
alt mod.
Pe scurt, tehnologia Java RMI a fost elaborata de JavaSoft, CORBA este o specificatie
de la OMG, iar DCOM provine de la Microsoft Corporation. De altfel, standardul CORBA a fost
elaborat ca rspuns la tehnologiile Microsoft COM i DCOM.
Cele trei tehnologii au aspecte comune, folosind un fel de regitri pentru nregistrarea
obiectelor i un limbaj de definire a interfeelor pentru generarea stub-ului pentru codul
clientului.

3.1.

Java RMI

Invocarea la distana nu este o tehnic nou. De exemplu, programatorii au folosit RPC

(Remote Procedure Call) pentru a executa funcii C de pe o main gazd aflat la distan.
Java a adugat cu fiecare nou versiune pachete de clase. De cele mai multe ori
introducerea de package-uri noi a fost necesar pentru a acoperi aspecte care nu fuseser tratate
n versiunile anterioare. n acest sens, exemple de subiecte care nu faceau parte din versiunea
Java 1.0 i au fost tratate ulterior sunt: JDBC (Java DataBase Connectivity) (pentru accesul la
baze de date), securitate, beans-uri i RMI (Remote Method Invocation).
Ceea ce face ca RMI s fie diferit este faptul c trebuie mpachetate i trimise n reea att
date ct i metode, n timp ce la RPC se transferau numai structuri de date primare, iar la recepie
obiectele trebuie s poat fi interpretate corespunzator.
Avantaje:
Este foarte uor de folosit.
Exist o excepie special pentru interfeele care pot fi remote.
Permite apelul prin valoare.
Versiunile sunt serializabile.
Dezavantaje:
Este modificat semantica apelurilor Java i din aceast cauz nu se menine identitatea
thread-urilor.
Rspunsurile sunt blocate n metodele sincronizate.
Nu este ntotdeauna intuitiv.
Nu este disponibil n alte limbaje.
Dificulti:
Nu exist prea multe programe utilitare pentru dezvoltarea aplicaiilor.
Clienii trebuie s aib acces la ultima versiune de stub.
Performanele pot fi sczute.

3.2.

CORBA

Arhitectura CORBA este probabil cel mai ambiios i mai important proiect middleware
realizat vreodata n industrie. Corporaia OMG (Object Management Group) la care firma Sun a
fost una din companiile fondatoare, nglobeaza un spectru larg de firme din industria de soft.
13

 Avantaje:
Este o arhitectur conceput pentru dezvoltarea sistemelor.
Ofer o terminologie standard pentru concepte.
Interfeele pentru declaraii separ interfaa i implementarea.
Asigur maparea din IDL n C, C++, ADA, SmallTalk i Java.
Pentru c a fost proiectat pentru distribuire, exist suport pentru modificarea i concatenarea datelor.
Asigur portabilitatea proiectelor.
Este scalabil pentru sisteme mari.
Ofer protocoale standard de interoperabilitate.
Dezavantaje:
Nu exist nici o interfa pentru excepii.
Motenirea cauzeaz probleme n versionare i obiectele nu pot suporta dou versiuni ale
aceleiai interfee.
Limbajul IDL nu este internaionalizat.
Exist mecanisme divergente pentru securitate (kerberos, SSL).
Exist servicii de baz, dar foarte puine servicii avansate.
Dificulti:
Maparea n C++ are reguli complicate pentru managementul memoriei.
Exist puine programe utilitare pentru dezvoltarea aplicaiilor (n general doar un
compilator de IDL).
Modelul de concuren este limitat pentru c nu exist standardizare pentru prioritatea
thread-urilor, blocaje i timeout.

3.3.

DCOM

Soluia Microsoft pentru programarea distribuit cu obiecte este DCOM (Distributed

Component Object Model). Cu alte cuvinte, DCOM reprezint baza pentru programarea n
Internet i strategia orientat pe componente a Microsoft. De exemplu, un control ActiveX este
un obiect DCOM. Pachetul VJ++ include legturi pentru DCOM.
Avantaje:
Exist o mulime de programe utilitare, crti i proiectani.
Rezolv multe probleme ale versionrii IDL prin separarea interfetei de implementare.
n VisualBASIC i Java exist o bun integrare a obiectelor automatizate.
Exist un set bun de interfee pentru documentele compuse.
Microsoft depinde de folosirea lui..
Dezavantaje:
Suportul pentru alte platforme este minim. Dei unele platforme UNIX ncearc s
integreze DCOM, aceast tehnologie nu s-a dovedit ndeajuns de stabil.
O referin la un serviciu trebuie pstrat n memorie.
Este greu de meninut consistena registrilor.
Dificulti:
Maparea n limbajul de implementare nu prevede modificarea automat a UUID
(Universal Unique IDentifier) atunci cnd o interfa este revizuit.
Codul generat este amestecat cu codul scris de utilizator. Fiierele de header sunt fie n C,
fie n C++.
Contorizarea referinelor constituie o problem.
Clientul trebuie s aleag modelul de interacionare (creare de instan (CreateInstance),
obinerea obiectului (GetObject sau Monikers)) i nu ntotdeauna se poate determina care
este cel mai potrivit.
14

Un aspect important este rularea aceluiai cod pe ct mai multe platforme posibil. Soluia
Java/CORBA este mai potrivit dect DCOM atunci cnd se dorete mutarea aplicaiei pe
platforme diferite fr ca acest lucru s necesite recompilare. Chiar dac aplicaia trebuie s
interacioneze cu obiecte DCOM tot soluia Java i CORBA poate fi mai bun putndu-se folosi
o tehnologie de legatur cu interfaa DCOM.
RMI, CORBA, i DCOM sunt toate exemple de tehnologii middleware, iar dezvoltarea
middleware va continua s joace un rol important n dezvoltarea de sisteme extensibile.

Bibliografie
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

Berg, C., Advanced Java Development for Enterprise Applications, Sun Microsystems
Press, New York, 1999
Box, D., Essential COM, Addison-Wesley, 1998.
Chung, P.E., Huang, Z., Yajnik, S., Liang, D., Shih, J.C., Wang, C.Z., and Wang, Z.M.,
DCOM and CORBA Side by Side, Step by Step, and Layer by Layer, C++ Report, Vol.
10, No. 1, pp. 18-29, 40, Jan. 1998.
Jurca, I., Programarea reelelor de calculatoare, Editura de Vest, Timioara, 2000
Rubin, W., Brain, M., Understanding DCOM, Prentice Hall Inc., 1999
Tanenbaum, A., Computer Networks, Third Edition, Prentice Hall, Upper Saddle River,
New Jersey, 1996
Tanenbaum, A., Modern Operating Systems, Second Edition, Prentice Hall, Upper
Saddle River, New Jersey, 2001
www.appdevadvisor.com, The house CORBA built, Component Computing
www.cariboulake.com, Lake, C., RMI versus CORBA
www.java.sun.com, Java.RemoteMethodInvocation Specification, Sun Microsystems
www.whatis.com, What is CORBA;

15