Tehnici de Programare Distribuită

CUPRINS

1. Sisteme distribuite. Infrastructură................................................................................31.1. Introducere............................................................................................................31.2. Hardware-ul retelelor............................................................................................31.3. Protocoale şi servicii de reţea...............................................................................4

1.3.1. Sevicii de reţea.........................................................................................................41.3.2. Protocoale de reţea...................................................................................................5

1.4. Middleware bazat pe document (Document-Based).............................................51.5. Middleware bazat pe sistem de fişiere (File System-Based).................................5

1.5.1. Tipul transferului.....................................................................................................61.5.2. Arborele directoarelor..............................................................................................61.5.3. Transparenţa numelor..............................................................................................61.5.4. Semantica partajării fişierelor..................................................................................61.5.5. AFS (Andrew File System)......................................................................................6

1.6. Middleware bazat pe obiecte partajate (Shared Object-Based)............................71.6.1. CORBA (Common Object Request Broker Architecture)......................................71.6.2. Globe.......................................................................................................................7

1.7. Middleware bazat pe coordonare (Coordination-Based)......................................81.7.1. Linda........................................................................................................................81.7.2. Publicare/Înregistrare (Publish/Subscribe)..............................................................81.7.3. Jini...........................................................................................................................8

2. Tehnici de programare distribuită...........................................................................92.1. Apelul procedurilor la distanţă (RPC - Remote Procedure Call).........................9

2.1.1. Probleme de implementare......................................................................................92.2. Programarea bazată pe componente....................................................................10

3. Tehnologiile Java RMI, CORBA şi DCOM.............................................................133.1. Java RMI.............................................................................................................133.2. CORBA...............................................................................................................133.3. DCOM.................................................................................................................14

Bibliografie.......................................................................................................................15

2

1. Sisteme distribuite. Infrastructură

1.1. IntroducereSistemele 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 conţine, în general, un procesor, memorie RAM, o interfata de reţea ş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 aceeaşi cameră, putand comunica între ele prin reţele dedicate, de mare viteză, în timp ce nodurile unui sistem distribuit pot fi împrăştiate în întreaga lume.

O altă diferenţă: nodurile unui multicalculator rulează cu acelaşi sistem de operare, partajează un singur sistem de fişiere şi se află sub o administrare comună, în timp ce nodurile unui sistem distribuit pot rula sisteme de operare diferite, fiecare având propriul sistem de fişiere şi, eventual, propriul administrator.

TipulCaracteristica

Multiprocesor Multicalculator Sistem distribuit

Configuraţia nodului CPU CPU, RAM, interfaţă de reţea Calculator completPerifericele nodului Toate partajate Eventual hard disk partajat Toate disponibile noduluiLucalizarea Pe aceeaşi placă Aceeaşi cameră Posibil în toată lumeaComunicaţia internod RAM partajat Interconectare dedicată Reţea tradiţionalăSistem de operare Unul, partajat Mai multe, acelaşi tip Posibil toate diferiteSistem de fişiere Unul, partajat Unul partajat Fiecare nod are câte unulAdministrare O singură organizaţie O singură organizaţie Mai multe organizaţii

Aplicaţiile tipice pentru Internet includ accesul la calculatoarele remote (folosind telnet şi rlogin), accesul la informaţii (folosind WWW şi FTP), comunicaţiile interpersonale (folosind e-mail şi chat) şi multe alte aplicaţii derivate (de exemplu, e-commerce, e-learning etc.). Problema cu aceste aplicaţii este că fiecare trebuie să o ia de la zero. De exemplu, e-mail, ftp şi WWW transferă fişiere, dar fiecare dintre ele are un modabsolut diferit de a realiza acest lucru din punct de vedere al convenţiilor de nume, al protocoalelor de transfer, al tehnicilor de replicare etc. Cu toate acestea multe browsere de Web ascund aceste diferenţe utilizatorilor.

Sistemele distribuite adaugă nivelului inferior de reţea o paradigmă comună (model) care asigură o modalitate uniformă de tratare a întregului sistem. Intenţia sistemelor distribuite este de a transforma o mulţime de maşini 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 întâlneşte în sistemele UNIX unde toate dispozitivele I/O sunt tratate în aceeaşi manieră ca şi fişierele datorita faptului că tastatura, porturile paralele şi seriale opereaza la fel şi sunt mai uşor controlat decât dacă ar fi privite, din punct de vedere conceptual, diferit.

O modalitate de a obţine, î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 aplicaţiei. Acest nivel este numit, de obicei, middleware. El asigură structuri de date şi operaţii, care permit utilizatorilor şi proceselor remote să interopereze într-o manieră consistentă. Middleware poate fi privit ca un sistem de operare pentru sisteme distribuite.

3

1.2. Hardware-ul retelelorSistemele distribuite au la bază reţelele de calculatoare. Există o mare varietate de reţele:

reţele locale (LAN - Local Area Network), care acoperă o clădire sau un campus, reţele răspândite din punct de vedere geografic (WAN - Wide Area Network) care conectează calculatoare situate la distanţe mari şi reţele metropolitane (MAN - Metropolitan Area Networks) care acoperă de obiecei un întreg oraş şi funcţionează la viteze specifice pentru LAN. Reţelele 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 reţeaToate reţelele de calculatoare asigură anumite servicii pentru utilizatori, care sunt

implementate respectându-se anumite reguli legate de schimbul legal de mesaje.

1.3.1. Sevicii de reţeaReţelele 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 reţea orientat pe conexiune, utilizatorul unui astfel de serviciu trebuie mai întâi să stabilească conexiunea, o foloseşte şi apoi se deconectează. Aspectul cel mai important al unei conexiuni este acela că funcţionează ca un tub: un utilizator emite obiecte (biţi) la un capăt şi un receptor le primeşte, în aceeaşi, ordine la celălalt capăt.

Spre deosebire de serviciile orientate pe conexiune, celelalte servicii sunt modelatedupă sistemul poştal. Fiecare mesaj (scrisoare) conţine adresa de destinaţie completă şi este rutat în sistem independent de toate celelalte. În mod normal când două mesaje sunt trimise la aceeaşi destinaţie, primul trimis va fi primul sosit. Cu toate acestea este posibil ca primul mesaj trimis să fie întârziat, astfel încât 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 aşteaptă de la receptor confirmarea primirii fiecărui mesaj prin trimiterea unui pachet special de acknowledgement pentru ca emiţătorul să fie sigur că mesajul a ajuns la destinaţie. Procesul de confirmare introduce întârzieri şi trafic de date suplimentar, necesare pentru detectarea pachetelor pierdute, iar acest lucru duce la încetinireacomunicaţiei.

Un caz în care este necesar un serviciu sigur, orientat pe conexiune, este transferul de fişiere. Proprietarul fişierului vrea să fie sigur ca toţi biţii ajung corect şi în aceeaşi ordine în care au fost trimişi. Pentru unele aplicaţii întârzierile introduse de procesul de confirmare sunt inacceptabile. O astfel de aplicaţie este traficul vocal digital. Este preferabil ca utilizatorii telefonului să auda un pic de zgomot pe linie sau un cuvânt distorsionat, din când în când, decât să se introducă o întârziere pentru a aşteptaconfirmarea.

Nu toate aplicaţiile necesită conexiuni. De exemplu, pentru a testa reţeaua, singura operaţie necesară este trimiterea unui singur pachet cu prioritate maximă, dar fără garanţie. Serviciile care nu sunt orientate pe conexiune, fără proces de confirmare, sunt adesea numite şi servicii cu datagrame, prin analogie cu serviciul de telegrafie care nu foloseşte proces de confirmare.

Sunt situaţii în care este preferabil să nu se stabilească o conexiune, pentru a trimite un mesaj scurt, dar siguranţa este esenţială. Serviciul cu datagrame şi proces de confirmare poate fi o soluţie acceptabilă pentru aceste tipuri de aplicaţii.

Alt serviciu este serviciul cerere-răspuns. La acest serviciu emiţătorul trimite o singură datagramă care conţine cererea. Replica conţine raspunsul. Serviciul cerere-răspuns este folosit

4

frecvent pentru implementarea comunicaţiei în modelul client-server: clientul iniţiază o cerere iar serverul răspunde la aceasta.

1.3.2. Protocoale de reţeaO reţea are reguli specializate referitoare la tipurile de mesaje care pot fi trimise şi la

răspunsurile care pot fi returnate. De exemplu, în anumite situaţii (transferul fişierelor), când un mesaj este trimis de la o sursa la o destinaţie, destinaţia trebuie să trimită un mesaj de confirmare că transmisia s-a efectuat corect. În alte situaţii (telefonia digitală) nu se aşteaptă această înştiinţare. Setul de reguli care particularizează comunicaţia între calculatoare se numeste protocol. Toate reţelele moderne de calculatoare folosesc aşa 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 biţi, începe şi se termină un pachet. Pe următorul nivel protocoalele tratează modul de rutare a pachetelor în reţele complexe, de la surse la destinaţie. Pe un nivel mai înalt, protocoalele asigură transferul corect, din punct de vedere al integrităţii şi succesiunii pachetelor, al mesajelor multipachet.

Întrucât 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 emiţătorul trimite o datagrama (până la 64 KB) în reţea şi speră să ajungă la destinaţie. Nu sunt oferite nici un fel de garanţii. Datagrama poate fi fragmentată în pachete mai mici atunci când călătoreşte prin Internet. Pachetele călătoresc independent şi nu neapărat pe aceeaşi rută. Când toate pachetele au ajuns la destinaţie, sunt reasamblate în ordinea corectă.

Datagramele IP nu folosesc ACK (acknowledgment code), deci protocolul IP nu este suficient pentru a avea o comunicaţie sigură în Internet. Pentru a asigura comunicaţii sigure se foloseşte, în general, protocolul TCP (Transmission Control Protocol) care este situat, de obicei, deasupra protocolului IP. Protocolul TCP foloseşte protocolul IP pentru a asigura structuri de date orientate pe conexiune. Pentru a folosi TCP, un proces trebuie întâi să stabilească o conexiune la un proces la distanţă. Procesul cerut este specificat prin adresa de IP a unei masini şi printr-un număr de port de pe respectiva maşină care este disponibilă pentru ascultarea cererilor. După ce conexiunea a fost stabilită, procesul trimite biţi pe conexiune, garantându-se faptul că ei ajung nealteraţi şi în ordinea corectă la destinaţie. Implementarea protocolului TCP asigură aceste garanţii folosind secvenţe numerotate, sume de control şi retransmisia pachetelor recepţionate incorect. Toate aceste operaţii sunt transparente emiţătorului şi receptorului. Aceştia “văd” doar o comunicaţie interproces sigură.

1.4. Middleware bazat pe document (Document-Based)După cum am mai menţionat, pentru a obţine 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 conţine text, imagini, icon-uri, sunete, filme şi multe altele, împreună cu hyperlink-uri (pointeri) către alte pagini Web.

Atunci când un utilizator cere o pagină Web folosind un program numit browser de Web, pagina este afişată 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 funcţionare al sistemului este următorul. Web-ul este un sistem tipic client-server în care utilizatorii sunt clienţi şi site-ul de Web este server-ul. Atunci când utilizatorul dă browser-ului o adresă URL, acesta efectuează cateva operaţii pentru a afişa pagina Web cerută.

5

1.5. Middleware bazat pe sistem de fişiere (File System-Based)Ideea de bază a Web este ca un sistem distribuit să arate ca o colecţie imensă de

documente cu legături. O altă abordare este considerarea sistemelor distribuite ca un mare sistem de fişiere.

Folosirea modelului de sistem de fişiere pentru un sistem distribuit presupune existenţa unui sistem de fişiere global cu utilizatori răspandiţi în întreaga lume, care să poată citi sau scrie fişiere pentru care au autorizaţie. Comunicaţia este obtinută printr-un proces care scrie date într-un fişier şi alte procese care citesc datele din acest fişier. În acest caz apar problemele obişnuite pentru sistemele de fişiere, dar mai apar şi alte probleme legate de sistemele distribuite.

1.5.1. Tipul transferuluiPrimul aspect este alegerea între modelul upload/download şi modelul remote access.În modelul remote access fişierul rămane pe server şi clientul trimite comenzi pentru ca

lucrul să se desfăşoare pe server.În modelul upload/download un proces accesează un fişier copiindu-l mai întâi de pe

server. Dacă fişierul trebuie doar citit, el este citit local, pentru îmbunătăţirea performanţelor. Dacă fişierul trebuie modificat, modificarea se face local. La terminarea lucrului cu fişierul respectiv, fişierul actualizat este repus pe server. Avantajul modelului upload/download este simplitatea acestuia. Dezavantajul este că trebuie să existe capacitatea de a stoca local întregul fişier iar mutarea întregului fişier esteineficientă dacă nu sunt necesare decât părţi din acesta. Pe lângă aceste probleme mai apare şi problema consistenţei, atunci când există mai mulţi utilizatori.

1.5.2. Arborele directoarelorO altă parte a acestui sistem este constituită de sistemul de directoare. Toate sistemele de

fişiere distribuite asigură suport pentru directoarele care conţin mai multe fişiere. Există mai multe aspecte de care trebuie ţinut cont în proiectarea unui astfel de sistem. Un prim aspect ar fi dacă toţi utilizatorii dispun de acelaşi model de vizualizare al ierarhiei directoarelor. Un alt aspect este dacă trebuie să existe sau nu un director rădăcină recunoscut de toate maşinile ca rădăcină.

O modalitate de a avea un director rădăcină global este de a avea o rădăcină care conţine o intrare pentru fiecare server. În această situaţie calea are forma /server/path cu propriile sale dezavantaje dar cel puţin este aceeaşi în tot sistemul.

1.5.3. Transparenţa numelorPrincipala problemă a formei de reprezentare a numelor este aceea că nu există transparenţă completă. Există două forme importante de transparenţă. Prima este constituită de transparenţa localizării, ceea ce înseamnă că în cale sunt incluse indicii despre localizarea fişierului, dar nu se specifică nimic despre localizarea serverului. O altă formă de transparenţă o reprezintă independenţa localizării, ceea ce înseamnă că fişierele pot fi mutate fără ca numele acestora să se schimbe.

1.5.4. Semantica partajării fişierelorAtunci când doi sau mai mulţi utilizatori partajează acelaşi fişier, este necesară definirea

unei modalitati de citire şi scriere precise pentru a evita problemele. În sistemele uniprocesor tratarea obişnuită este urmatoarea: atunci când o procedură de citire urmeaza după o procedură de scriere, procedura de citire returnează ultima versiune scrisă. Similar, atunci când 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ţă secvenţială.

6

1.5.5. AFS (Andrew File System)Au fost proiectate şi implementate mai multe tipuri de infrastructuri de comunicaţie

(middleware) bazate pe sistem de fişiere. 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 iniţial al acestui proiect a fost construirea unui sistem puternic bazat pe UNIX, cu un sistem de fişiere partajat. Sistemul de fişiere a fost folosit ca middleware pentru a transforma o colecţie de staţii de lucru într-un sistem coerent.

Fiecare utilizator AFS are o staţie de lucru proprie pe care ruleaza un sistem UNIX uşor modificat. Modificarea constă în adaugarea unei părţi de cod numită venus la nucleu (kernel) şi rularea în spaţiul utilizatorului a unui server de fişiere numit vice. Iniţial venus rula tot în spaţiul utilizatorului, dar din considerente legate de performanţă a fost mutat în nucleu. Din motive administrative, staţiile de lucru ale utilizatorilor sunt grupate în celule. O celulă poate fi o reţea locală sau o colecţie de reţele 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 fişiere. Un obiect este o colecţie 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 decât 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 maşinile client, pot invoca operaţii pe obiectele localizate (posibil la distanţă) pe maşinile 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 comunicaţie (middleware) a aplicaţiilor.

1.6.2. GlobeUn alt exemplu de sistem distribuit bazat pe obiecte, proiectat special pentru a fi folosit

de foarte mulţi 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 răspândire geografică, cu foarte mulţi utilizatori, nu există nici o modalitate de a convinge toţi utilizatorii să folosească acelaşi limbaj de programare, aceeaşi strategie de replicare, acelaşi model de securitate, şi multe altele. Sistemul trebuie să permită utilizatori diferiţi şi obiecte diferite, care au o comportare diferită şi, în acelaşi timp, trebuie să asigure un model coerent. Acest lucru este realizat de Globe. Întrucât un obiect Globe poate fi partajat de mai multe procese în acelasi timp, acesta se mai numeşte şi obiect distribuit partajat.

Pentru a folosi un obiect Globe, un proces trebuie să se conecteze mai întâi la el prin identificarea lui şi prin găsirea a cel puţin unei adrese de contact (de exemplu, adresa de IP şi port). La conectare se efectuează cel puţin o verificare de securitate şi, dacă procesul este autorizat să se conecteze la obiect, plasa obiectului (codul acestuia) este încărcată în spaţiul de adrese al procesului care a iniţiat cererea, o copie a stării obiectului este instanţiată şi este returnat un pointer la interfaţa (standard) obiectului.

Folosind pointer-ul la interfaţa, procesul poate apela metode ale instanţei obiectului respectiv. În funcţie de obiect starea poate fi cea predefinită (default) sau o copie a stării curente obţinută de la unele copii în viaţă.

7

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 păstrată doar în nodul în care are loc. Pointer-ii la aceste noduri se propagă până la rădăcina arborelui, fapt care permite găsirea înregistrării 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. LindaLinda este un sistem proiectat de Yale University pentru comunicare şi sincronizare. În

Linda procesele independente comunică prin intermediul unui spaţiu abstract de tupluri. Spaţiul de tupluri este global pentru întregul sistem şi procesele care rulează pe orice maşină pot insera sau sterge tupluri în spaţiul de tupluri, fără a ţine cont de modul în care sunt stocate sau unde sunt stocate acestea. Un tuplu este asemănător cu o structură din limbajul C sau cu o înregistrare din limbajul Pascal. Tuplul constă din unul sau mai multe câmpuri, fiecare putând avea o valoare de un anumit tip suportat de limbajul de bază (Linda este implementat prin adăugarea 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 reţea de difuzare (broadcast

network). Fiecare proces poate fi un producător de informaţii, un consumator de informaţii sau amândouă. Atunci când un producător de informaţii are o informaţie nouă, o difuzează în reţea sub forma unui tuplu. Această acţiunii se numeşte publicare. Fiecare tuplu conţine o ierarhie de linii de subiecte formată din câmpuri multiple, separate prin perioade. Procesele interesate de anumite informaţii se pot înregistra la anumite subiecte. Înregistrarea este realizată prin furnizarea subiectului căutat unui proces pentru tupluri, rezident pe maşina care controlează tuplurile înregistrate.

1.7.3. JiniAcest sistem a fost conceput de firma Sun Microsystems. Lumea Jini constă într-un

numar mare de dispozitive Jini autoincluse, fiecare putând oferi servicii celorlalte. Un dispozitiv Jini poate fi conectat într-o reţea şi începe să ofere servicii instantaneu, fără a necesita o procedură complexă de instalare. Trebuie reţinut faptul că dispozitivele sunt conectate într-o reţea ş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 reţea (chiar şi fără fir). Un sistem Jini este o colecţie de dispozitive Jini care pot apărea şi dispărea fără a avea o administrare centralizată. Atunci când un dispozitiv Jini vrea să se alăture colecţiei de dispozitive Jini, acesta difuzează un pachet, în reţeaua locală sau în celula wireless locală, testand dacă există un serviciu de identificare (lookup service). Protocolul folosit pentru a găsi serviciul de identificare este protocolul de descoperire (discovery protocol) şi este unul dintre puţinele protocoale puternic cablate (hardwired) din Jini. Atunci când serviciul de identificare descoperă un nou dispozitiv care vrea să se înregistreze îi răspunde 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 maşina virtuală Java. Un dispozitiv Jini se poate deconecta din sistem şi existenţa lui va fi curând uitată fără a fi nevoie de administrare centralizată.

8

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 când un proces de pe o maşina apelează o procedură de pe o a doua maşină, procesul apelant de pe maşina unu este suspendat şi procedura apelată se efectuează pe cealaltă maşină. Informaţiile 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 aplicaţii ş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 cât posibil un apel local. Cea mai simplă formă de apelare a procedurilor la distanţa este de a lega clientului o bibliotecă de proceduri numită stub-ul clientului.

Stub-ul clientului reprezintă procedura serverului în spaţiul 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.Comunicaţia se desfăşoară în felul următor:

• Clientul apelează stub-ul clientului. Acesta este un apel local de procedură în care parametrii sunt stocaţi î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 maşina clientului pe maşina serverului.• Nucleul sistemului de operare de pe maşina serverului trimite pachetul recepţionat stub-ului serverului (care în mod normal a cerut recepţionarea).• Stub-ul serverului apelează procedura serverului. Răspunsul urmează aceeaşi cale în sens invers.

Elementul cheie al acestei modalităţi de programare este că procedura clientului, scrisă de utilizator să apeleze stub-ul clientului, are acelaşi nume ca procedura serverului. Din moment ce procedura clientului şi stub-ul clientului sunt localizate în acelaşi spaţiu de adresă, parametrii sunt pasaţi în mod obisnuit. Similar, procedura serverului este apelată de o procedură din spaţiul său de adrese cu parametri ceruţi. Peocedura serverului nu are nimic neobişnuit. În acest fel, în loc să avem operaţii de intrare/ieşire folosind emisie şi recepţie (send and recive), comunicaţia la distanţă este realizată prin simularea unui apel de procedură obişnuit.

2.1.1. Probleme de implementareÎn ciuda eleganţei conceptului de apel al procedurii la distanţă, implementarea genereaza

o serie de probleme. O mare problemă este folosirea pointer-ilor (referinţelor). În mod normal, un pointer la o procedură nu este o problemă. Procedura apelată poate folosi pointer-ii în acelaşi mod în care îi poate folosi şi apelantul deoarece ambele proceduri sunt localizate în acelaşi spaţiu de adrese virtuale. Pasarea pointer-ilor în cazul apelului procedurilor la distanţa este imposibil întrucât clientul şi serverul sunt situaţi în spaţii de adrese diferite.

Există situaţii în care se poate folosi totuşi 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 când procedura serverului cedează controlul stub-ului serverului, acesta trimite înapoi la client întregul, unde vechea valoare a întregului este suprascrisă cu noua valoare a lui. De fapt, secvenţa standard de apelare prin referinţă a fost înlocuită prin copiere şi reactualizare (copyrestore).

9

Din păcate această metodă nu funcţionează în toate cazurile. De exemplu, dacă pointer-ul se referă la o structură complexă nu mai este posibilă această metodă. Din aceste considerente trebuie făcute anumite restricţii pentru parametrii pasaţi în apelul procedurilor la distanţa.

O a doua problemă este constituită de slăbiciunile limbajelor de programare cum ar fi C. În C, de exemplu, este permisă declararea unui vector fără 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 situaţie, împachetarea de către 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 funcţia printf, care poate avea oricâţi parametri de tipuri diferite: întregi, caractere, string-uri, etc. Încercarea de a apela la distanţa funcţia printf este practic imposibilă pentru că limbajul C este prea îngăduitor. 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 obişnuit, apelarea, procedura apelantă şi procedura apelată pot comunica folosind variabile globale ca parametri. Dacă procedura apelată este mutata pe o maşină 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 totuşi foarte utilizată. Pentru ca funcţionarea să se desfaşoare corect, trebuie impuse anumite restricţii.

2.2. Programarea bazată pe componenteCreşterea complexităţii sistemelor computaţionale a determinat programatorii să

cerceteze modalităţile de abstractizare şi de simplificare a procesului de dezvoltare a programelor. O abordare de succes o costituie aplicarea paradigmei “împarte şi cucereşte” la proiectarea şi implementarea aplicaţiilor. Ideea de bază este de a recunoaşte ş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 aplicaţiilor bazate pe componente au la baza această idee de a refolosii soluţii deja existente.

Dezvoltarea World Wide Web-ului şi a Internet-ului şi în paralel cu acestea creşterea numarului calculatoarelor personale şi a reţelelor locale de calculatoare (LAN) complică din ce în ce mai mult scenariul în care programatorii trebuiau să conceapă aplicaţii complet noi. Se face trecerea de la aplicaţii monolitice, care rulau pe o maşină izolată, la sisteme distribuite, care rulează pe platforme eterogene atât din punct de vedere hardware cât şi software. Tehnologiile de programare bazate pe componente permit celor care proiectează aplicaţii reducerea costurilor de proiectare, atât din punct de vedere al timpului cât ş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 aplicaţii întregi, la reutilizarea şi asmblarea părţilor 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 conţine facilităţi pentru realizarea sistemelor distribuite. Extensiile Java, ca RMI (Remote Method Invocation), Java-IDL, JavaBeans şi JavaSpaces completeaza distribuţia iniţială cu posibilităţi 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 atât a datelor cât şi a comportamentului, permite separarea implementării şi a interfeţei pentru orice obiect, iar clasele reprezintă o abstractizare pentru grupurile de obiecte cu acelaşi comportament. Mecanismul de moştenire permite reutilizarea specificaţiilor unei clase pentru definirea unei noi clase şi ofera o ierarhizare a relaţiilor dintre obiecte. Clasa derivată poate refolosi

10

comportamentul superclasei oferind aceleaşi operaţii asupra interfeţei sale şi permiţând crearea de noi metode sau redefinirea unora din superclasa. Polimorfismul moştenirii permite unor obiecte diferite să raspundă în mod diferit la acelaşi 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 aplicaţie 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 aplicaţii. Conceptele de obiect, componenetă, spaţiu de lucru şi document au o semnificatie strâns legată de contextul din care fac parte, dar, într-o primă aproximare, se pot defini după cum urmează:• Obiectul reprezintă un container cu operaţii de identificare şi interfaţare care partajează o stare persistentă.• Componenta este un obiect software care include o parte de algoritm logic. Componenta are capacităţile de granularitate variabilă, refolosire şi posibilitatea existenţei unei entităţi de sine stătătoare.• Spaţiul de lucru înglobează componente colaborative cu o comportare extensibilă pentru API• Documentul este o componentă prevăzută cu o interfaţă interactivă pentru navigare şi editare.• Documentul compus activ este un document format din părţi distincte programabile prin script-uri. Complexitatea unei componente poate varia de la o simplă componentă grafică cum ar fi butonul până la procesoare de text sau tabele complexe de date.

Un model de aplicaţie bazată pe componente trebuie să asigure o serie de servicii esentiale pentru crearea eficientă a unei aplicaţii. Când o componentă este legată în run-time, sunt necesare mecanisme pentru identificarea acesteia astfel încât celelalte componente să ştie să interacţioneze cu ea. Acest proces se numeşte “înregistrare şi publicare” a interfeţei componentei în cadrul spaţiului de lucru. Este necesară persistenţa pentru a putea stoca informaţiile oferite de o componentă. Aceste facilităţi sunt oferite de tipuri de componente ca OpenDoc, COM şi JavaBeans şi în acelaşi timp de anumite medii de programare cum ar fi VisualBasic sau Delphi, care oferă biblioteci extinse şi utilităţi care sunt referite tot sub numele de componente .

Spaţiile de lucru (frameworks) sunt o colecţie de componente colaborative prevăzute cu interţete extensibile specializate pe domeniu pentru clienţi. Documentele sunt componente specializate ale căror interfeţe grafice sunt prevăzute cu facilităţi de editare şi navigare. Spre deosebire de acestea, documentele compuse activ sunt formate din părţi cu funcţionare 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 prevăd 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 aplicaţiilor bazate pe Java pentru managementul componentelor şi construirea de platforme din beans-uri (clase care respectă anumite convenţii legate de interfaţă).

Comparaţia dintre modelele de document oferite de OpenDoc, ActiveX şi JavaBeans generează principii valabile pentru proiectarea şi implementarea spaţiilor de lucru bazate pe componente colaborative prevăzute cu interfeţe grafice interactive. OpenDoc, COM/OLE şi Java oferă modele foarte diferite de componente. Componentele OpenDoc au o identitate, o stare şi interfeţe vizuale, componentele COM/OLE sunt colecţii de interfeţe care asigură servicii independente de timp şi tratează identitatea şi starea ca proprietăţi ale unor interfeţe 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. Eleganţa conceptuală şi arhitecturală a acestui model oferă un punct de pornire pentru înţelegerea 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 maşina) şi interoperabilitatea Java în cadrul unui singur limbaj bine proiectat sunt mai puţin ambiţioase 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ă diferenţele datorate limbajului sunt minime şi întrebările 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 integrări a aplicaţiilor 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 fiecăreia din cele trei tehnologii. Pentru a executa cod rezident pe alte maşini distribuite în reţea, abordarea tradiţională a implementării generează confuzii şi erori. O modalitate mai bună de abordare a acestei metode este de a considera că unele obiecte rezidă pe diferite maşini din reţea şi că se pot invoca metode ale acelor obiecte prin trimiterea de mesaje către acestea, rezultatele de la ele obţinându-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 aplicaţiilor 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 răspuns la tehnologiile Microsoft COM şi DCOM.

Cele trei tehnologii au aspecte comune, folosind un fel de regiştri pentru înregistrarea obiectelor şi un limbaj de definire a interfeţelor pentru generarea stub-ului pentru codul clientului.

3.1. Java RMIInvocarea la distanţa nu este o tehnică nouă. De exemplu, programatorii au folosit RPC

(Remote Procedure Call) pentru a executa funcţii C de pe o maşină gazdă aflată la distanţă. Java a adăugat 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 reţea atât date cât şi metode, în timp ce la RPC se transferau numai structuri de date primare, iar la recepţie obiectele trebuie să poată fi interpretate corespunzator.• Avantaje:

Este foarte uşor de folosit. Există o excepţie specială pentru interfeţele care pot fi remote. Permite apelul prin valoare. Versiunile sunt serializabile.

• Dezavantaje: Este modificată semantica apelurilor Java şi din această cauză nu se menţine identitatea

thread-urilor. Răspunsurile sunt blocate în metodele sincronizate. Nu este întotdeauna intuitiv. Nu este disponibil în alte limbaje.

• Dificultăţi: Nu există prea multe programe utilitare pentru dezvoltarea aplicaţiilor. Clienţii trebuie să aibă acces la ultima versiune de stub. Performanţele pot fi scăzute.

3.2. CORBAArhitectura CORBA este probabil cel mai ambiţios şi mai important proiect middleware

realizat vreodata în industrie. Corporaţia OMG (Object Management Group) la care firma Sun a fost una din companiile fondatoare, înglobeaza un spectru larg de firme din industria de soft.• Avantaje:

13

Este o arhitectură concepută pentru dezvoltarea sistemelor. Oferă o terminologie standard pentru concepte. Interfeţele pentru declaraţii separă interfaţa ş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 con-

catenarea datelor. Asigură portabilitatea proiectelor. Este scalabil pentru sisteme mari. Oferă protocoale standard de interoperabilitate.

• Dezavantaje: Nu există nici o interfaţă pentru excepţii. Moştenirea cauzează probleme în versionare şi obiectele nu pot suporta două versiuni ale

aceleiaşi interfeţe. Limbajul IDL nu este internaţionalizat. Există mecanisme divergente pentru securitate (kerberos, SSL). Există servicii de bază, dar foarte puţine servicii avansate.

• Dificultăţi: Maparea în C++ are reguli complicate pentru managementul memoriei. Există puţine programe utilitare pentru dezvoltarea aplicaţiilor (î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. DCOMSoluţia 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 legături pentru DCOM.• Avantaje:

Există o mulţime de programe utilitare, cărti şi proiectanţi. Rezolvă multe probleme ale versionării IDL prin separarea interfetei de implementare. În VisualBASIC şi Java există o bună integrare a obiectelor automatizate. Există un set bun de interfeţe pentru documentele compuse. Microsoft depinde de folosirea lui..

• Dezavantaje: Suportul pentru alte platforme este minim. Deşi unele platforme UNIX încearcă să

integreze DCOM, această tehnologie nu s-a dovedit îndeajuns de stabilă. O referinţă la un serviciu trebuie păstrată în memorie. Este greu de menţinut consistenţa registrilor.

• Dificultăţi: Maparea în limbajul de implementare nu prevede modificarea automată a UUID

(Universal Unique IDentifier) atunci când o interfaţă este revizuită. Codul generat este amestecat cu codul scris de utilizator. Fişierele de header sunt fie în

C, fie în C++. Contorizarea referinţelor constituie o problemă. Clientul trebuie să aleagă modelul de interacţionare (creare de instanţă (CreateInstance),

obţinerea obiectului (GetObject sau Monikers)) şi nu întotdeauna se poate determina care este cel mai potrivit.Un aspect important este rularea aceluiaşi cod pe cât mai multe platforme posibil. Soluţia

Java/CORBA este mai potrivită decât DCOM atunci când se doreşte mutarea aplicaţiei pe platforme diferite fără ca acest lucru să necesite recompilare. Chiar dacă aplicaţia trebuie să

14

interacţioneze cu obiecte DCOM tot soluţia Java şi CORBA poate fi mai bună putându-se folosi o tehnologie de legatură cu interfaţa 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. Berg, C., Advanced Java Development for Enterprise Applications, Sun Microsystems Press, New York, 1999

2. Box, D., Essential COM, Addison-Wesley, 1998.3. 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.

4. Jurca, I., Programarea reţelelor de calculatoare, Editura de Vest, Timişoara, 20005. Rubin, W., Brain, M., Understanding DCOM, Prentice Hall Inc., 19996. Tanenbaum, A., Computer Networks, Third Edition, Prentice Hall, Upper Saddle River,

New Jersey, 19967. Tanenbaum, A., Modern Operating Systems, Second Edition, Prentice Hall, Upper

Saddle River, New Jersey, 20018. www.appdevadvisor.com, The house CORBA built, Component Computing9. www.cariboulake.com, Lake, C., RMI versus CORBA

10. www.java.sun.com, Java.RemoteMethodInvocation Specification, Sun Microsystems11. www.whatis.com, What is CORBA;

15