CORBA si alte modele de sisteme distribuite

CORBA si alte modele de sisteme distribuite

Cateva modele de arhitectura distribuita

Dintre produsele de middleware utilizate azi, cateva atrag atentia prin modelul de arhitectura distribuita pe care se bazeaza:

CORBA - Common Object Request Broker Architecture propus de  OMG (Object Management Group)

DCE - Distributed Computing Environment elaborat de OSF (Open Software Foundation)

DCOM - Distributed Component Object Model al Microsoft-ului

Java RMI produs de JavaSoft.

Relatia intre diferitele arhitecturi distribuite este ilustrata in figura 1. Ea arata ca aceste modele aflate in competitie se completeaza reciproc si se integreaza la diferite niveluri.

Figura. 1. Relatia intre diferite arhitecturi distribuite

DCE (Distributed Computing Environment) este o propunere a OSF (Open Software Foundation) menita sa creeze un mediu-suport pentru aplicatii distribuite eterogene. Serviciilor furnizate de retea, DCE le adauga facilitati pentru thread-uri, apeluri de procedura la distanta, servicii de directoare, de timp, de securitate si de fisiere. Recunoscand importanta DCE, OMG a introdus un standard de gateway CORBA-DCE. CORBA poate opera 'peste' DCE, putand folosi facilitatile RPC prin protocolul DCE CIOP.

DCOM (Distributed Component Object Model) este modelul propus de Microsoft pentru dezvoltarea programelor distribuite orientate pe obiecte. El are multe similaritati cu CORBA, dar a fost conceput special pentru platforme Windows. DCOM se refera la:

Un sistem simplu de transmitere a mesajelor, DDE (Dynamic Data Exchange);

Un model de document compus, OLE (Object Linking and Embedding), cu servicii pentru realizarea de legaturi intre documente compuse sau pentru gestiunea documentelor compuse;

Un model de comunicare intre obiecte, COM (Component Object Model).

Pentru aplicatii Web Microsoft propune ActiveX, un set de tehnologii adaptate particularitatilor Web, incluzand ActiveX Components, ActiveX Scripting si ActiveX documents. Adaptarile vizeaza obtinerea unor componente optimizate ca dimensiune si viteza, ceea ce usureaza incarcarea lor prin retea pe masina clientului. Astfel, componentele ActiveX se conformeaza modelului COM si abordarii OLE.

Java este limbajul care a revolutionat aplicatiile Web. Abordarea standard originala prevedea posibilitatea ca obiecte Java rezidente pe un server sa fie transferate la client pentru executie. Limbajul nu prevedea servicii distribuite. Obiectele unei aplicatii trebuia sa rezide intr-un singur server, iar obiectele erau 'perisabile', pierzandu-si informatia de stare pe perioada de inactivitate. Java RMI rezolva aceste probleme, fiind inceputul dezvoltarii unei arhitecturi de obiecte distribuite. Prin el, se pot crea obiecte Java ale caror metode pot fi invocate din alte masini virtuale. Ca alternativa de evolutie, Java va trebui sa integreze capabilitatile distribuite din CORBA sau sa-si dezvolte propriile sale capabilitati. Prima varianta a si fost abordata: produsul Caffeine (produs de Netscape si Visigenic) permite descrierea obiectelor distribuite direct in Java, oferind un suport transparent al RMI peste IIOP. Caffeine genereaza automat stub-urile si skeleton-urile IIOP. Poate genera chiar si descrierile IDL din bytecode-uri Java. Java are doua avantaje importante: este usor de folosit si codul poate fi incarcat prin retea si executat. Un client poate localiza un serviciu de interes pentru el, poate incarca interfata corespunzatoare si poate interactiona apoi cu serviciul. Aceasta maniera de lucru este tipica limbajelor de programare a Web-ului.

Articolul de fata analizeaza comparativ aceste solutii, principalele rezultate fiind prezentate in tabelele urmatoare. Ca element de referinta a fost ales modelul CORBA, elaborat de OMG, care satisface cerintele unui mare numar de dezvoltatori de aplicatii distribuite.

Comparatie CORBA - DCE

CORBA si DCE suporta ambele dezvoltarea aplicatiilor distribuite. Ele au fost realizate de consortii promotoare de standarde, OMG (Object Management Group pentru CORBA), respectiv OSF (Open Software Foundation pentru DCE), au fost specificate in aceeasi perioada (1991-1992) si au cunoscut materializarea in implementari comerciale in 1993.

Tabel 1.

Diferentele notabile provin din stilurile de programare adoptate: in timp ce CORBA se bazeaza pe un model de obiecte, DCE are la baza un model procedural, in care apelurile de proceduri la distanta (RPC - Remote Procedure Call) constituie 'piesa' centrala.

DCE are un scop mai restrans, fiind concentrat pe un set redus de servicii. CORBA vizeaza un set de servicii mai amplu. Ca urmare, implementarea DCE a atins un nivel de maturitate ridicat, in timp ce unele servicii CORBA sunt inca in curs de dezvoltare. Avand in vedere orientarea pietii spre tehnologiile obiect, este de presupus ca DCE va supravietui cu mare greutate.

Comparatie CORBA - DCOM

Ca si CORBA, DCOM separa interfata unui obiect de implementarea sa. Limbajul de definire a interfetelor adoptat de Microsoft difera de CORBA IDL. In timp ce in CORBA mostenirea joaca un rol esential, fiecare obiect avand o interfata care poate deriva din altele, in DCOM sunt folosite agregarea si delegarea pentru a realiza reutilizarea obiectelor. In ambele cazuri, un obiect exterior incapsuleaza interfetele obiectelor interioare si le prezinta clientului. In agregare, obiectul exterior expune interfetele obiectelor interioare ca si cum ar fi ale sale; in delegare, obiectul exterior retransmite invocarile de metode catre obiectele interioare. Un obiect poate avea mai multe interfete independente, fara relatia de mostenire intre ele.

Tabel 2.

Un obiect DCOM nu este un obiect in adevaratul sens al cuvantului. Interfetele DCOM nu pot fi instantiate si nu au stari. O interfata DCOM este un grup de functii, clientului dandu-i-se un pointer pentru a avea acces la aceste functii (mai precis un pointer la un tablou de pointeri la functii, cunoscut sub numele de vtable - virtual table). Aceasta justifica eticheta de standard de 'interconectare binara' asociata cu DCOM (respectiv OLE). Deoarece acest pointer nu este legat de vreo informatie de stare, un client nu se poate reconecta la o aceeasi instanta de obiect, la un moment ulterior. Deci, DCOM nu are notiunea de identitate a obiectului, in timp ce aceasta este foarte bine structurata in CORBA.

Ca si CORBA, DCOM ofera interfete statice si dinamice pentru invocarile metodelor, ca si depozite de interfete (Type Library). Clientii pot inspecta aceste depozite pentur a descoperi interfetele unui obiect si parametrii necesari pentru o invocare particulara.

IDL joaca un rol imporant in CORBA, atat pentru a defini sistemul de tipuri, cat si pentru a preciza modul de transmitere a datelor prin retea. Similar, ODL (Object Definition Language) din OLE defineste sistemul de tipuri, iar MIDL specifica modul in care parametrii si identificatorii operatiilor sunt specificati intr-un apel catre un obiect OLE. Compilatorul NT 4.0 MIDL extinde IDL pentru a suporta constructiile ODL, reunind astfel cele doua limbaje.

In alta ordine de idei, CORBA sufera de incetineala cu care evolueaza toate standardele multi-vanzator, aflate in atentia unor 'comitete de lucru'. Ele includ multe compromisuri, ceea ce inseamna ca sunt si ineficiente. In schimb, aceleasio compromisuri determina o mai mare inter-operabilitate.

Comparatie CORBA - Java RMI

Java s-a nascut ca un limbaj orientat-obiect destinat in principal produselor electronice de larg consum si Web-ului. Cu timpul s-a transformat im middleware pentru aplicatii distribuite. Relatia dintre Java si CORBA este mai mult de complementaritate decat de concurenta.

Tabel 3.

Java este un excelent limbaj pentru a descrie obiecte CORBA. Apoi, Java complementeaza serviciul de componente din CORBA, bazat pe OpenDoc. In timp ce CORBA defineste containere vizuale pentru componente si containere de memorare mobile, Java poate furniza 'boabele' care evolueaza in aceste containere. Mai mult, facilitatile de cod mobil din Java permit partitionarea unei aplicatii intre client si server, la momentul executiei. Java simplifica distributia codului in sisteme CORBA mari, printr-o gestiune centralizata a codului pe server si difuzarea codului la clienti, cand si unde este necesar.

In celalalt sens, printre avantajele obtinute de Java prin conlucrarea cu CORBA gasim urmatoarele:

CORBA evita gatuirea produsa de CGI pe server, deoarece clientii invoca direct metode de pe server. Se pot transfera astfel si parametri care nu sunt siruri de caractere, se poate memora starea serverului intre doua apeluri.

CORBA asigura o infrastructura scalabila server-server, putandu-se folosi colectii de obiecte server identice care sa echilibreze incarcarea.

CORBA extinde Java cu o infrastructura de obiecte distribuite, astfel incat un applet este in stare sa comunice cu orice obiect, indiferent de limbajul in care este scris si de localizarea in retea.

CORBA nu este singura solutie de arhitectura distribuita, competitorii sai fiind DCOM/ActiveX, WebObjects si RMI. Insa alaturarea dintre Java si CORBA aduce o serie de avantaje si pentru CORBA, Java intrand in functiune acolo unde CORBA se termina:

Java permite CORBA deplasari de "inteligenta", prin folosirea codului mobil atat clientii cat si serverele putand sa-si imbogateasca cunostintele.

Java completeaza serviciile CORBA referitoare la controlul ciclului de viata al obiectelor.

Java simplifica distribuirea codului in sistemele CORBA de dimensiuni mari.

Java complementeaza facilitatile CORBA de lucru cu agenti mobili.

Java este limbajul cvasi-ideal pentru scrierea obiectelor CORBA.

DCOM (Distributed Component Object Model) este principalul rival al aliantei Java/CORBA, considerat actualmente un standard "de facto", datorita raspandirii sale. Este fundamentul viziunii Microsoft asupra Internet-ului.

DCOM, la fel ca si CORBA, separa interfata de implementare cerand ca toate interfetele sa fie descrise folosind un IDL, dar Microsoft IDL nu este compatibil cu CORBA (asa cum era de asteptat). In timp ce CORBA se bazeaza pe modelul clasic de obiecte, DCOM nu face acest lucru. O componenta DCOM nu suporta mostenire multipla, insa poate implementa mai multe interfete, astfel incat reutilizarea codului nu se obtine prin mostenire, ci prin agregare.

Sintetizand, principalele aspecte legate de comparatia Java/CORBA - DCOM sunt prezentate in tabelul 4:

Tabel 4.

Desi CORBA a luat un start promitator, DCOM este o amenintare serioasa la suprematia Web-ului.

Facand acum sinteza tehnologiilor Internet existente, putem vedea ca, per ansamblu, CORBA detine cele mai bune performante. Acest lucru este ilustrat in tabelul urmator, unde se foloseste un sistem de notare asemanator celui de apreciere a filmelor: cinci stele maxim, o stea minim.

Tabel 5.

CORBA 3.0

Ca mai toate modelele, standardele si produsele software, CORBA evolueaza. Experienta castigata cu versiunile initiale a evidentiat imbunatatirile si modificarile ce au permis cresterea utilitatii si aplicabilitatii standardului intr-un numar tot mai mare de aplicatii distribuite. In unele situatii, corectiile si adaugirile aduse modelului au urmarit repararea unor lipsuri ale versiunilor anterioare. Asa stau lucrurile, de exemplu, cu POA (Portable Object Adapter), adaptorul portabil de obiecte.

Asa cum am aratat intr-unul din articolele anterioare, functiile adaptorului se refera la: crearea obiectelor si referintelor CORBA, dirijarea invocarilor de servicii catre obiectele corespunzatoare, activarea si dezactivarea obiectelor, etc. Desi a fost evidenta, din capul locului, necesitatea mai multor adaptoare de obiecte, care sa satisfaca cerintele unor conditii de functionare diverse, versiunile initiale pana la CORBA 2.1 inclusiv au definit, destul de sumar, un singur adaptor standard minimal, BOA (Basic Object Adapter). Multe omisiuni si ambiguitati ale acestei definitii au fost compensate de solutii particulare diverse ale implementatorilor, ceea ce a condus la scaderea portabilitatii produsului. In replica la acest fapt, CORBA 2.2 defineste POA care permite portarea aplicatiilor si a implementarilor de obiecte (servants) intre ORB-uri provenind de la vanzatori diferiti. POA introduce obiectele tranzitorii (pe langa obiectele CORBA persistente prezente inca din prima versiune a standardului), clarifica problemele legate de activarea explicita si la cerere a obiectelor, expliciteaza mai multe politici pentru firele de executie, defineste controlul aplicatiei asupra existentei obiectelor si altele.

O alta noutate pe calea spre CORBA 3.0 este referitoare la mesajele asincrone. In esenta, invocarile de servicii prevazute de versiunile initiale sunt de natura sincrona. Ele sunt pastrate in noua CORBA Messaging Specification, dar sunt suplimentate de modele de invocari asincrone, callback si polling. In modelul callback, clientul furnizeaza o referinta de obiect ca parametru al fiecarei invocari. La sosirea raspunsului, ORB foloseste referinta pentru livrarea acestuia. In modelul polling, clientul reprimeste controlul dupa lansarea invocarii, dar poate ulterior testa sau astepta sosirea raspunsului.

O alta facilitate introdusa de CORBA Messaging Specification este memorarea si retransmiterea mesajelor, prin agenti de dirijare intermediari. Aceasta permite pastrarea mesajelor, pe perioada cand tintele sunt temporar nedisponibile sau clientii sunt deconectati, si transmiterea lor spre destinatari, atunci cand aceasta operatie devine realizabila.

A treia imbunatatire majora la care ne referim aici este transmiterea obiectelor prin valoare. In acest sens, o noua constructie, numita valuetype, a fost adaugata limbajului OMG IDL. Ea descrie atat date cat si operatii si seamana cu definitiile de clase C++ si Java. La transmiterea unei valuetype ca argument al invocarii unei operatii la distanta, se creaza o copie a acesteia in spatiul de adrese al tintei. Identitatea copiei este complet independenta de cea a originalului, iar toate operatiile adresate unei valuetype se executa local, in procesul in care valuetype exista. Utilizarile curente se refera la tipuri incapsulate simple, precum liste, arbori, grafuri.

O definitie valuetype pentru o lista simplu inlantuita ar putea avea urmatorul aspect:

valuetype Element

Specificatia defineste Element ca o valuetype care include un constructor, doua operatii si doua date membre. Constructorul, introdus prin cuvantul cheie init, permite crearea de noi instante de Element. Cele doua operatii permit aflarea, respectiv fixarea urmatorului element din lista inlantuita.

Membrul ref_data, care contine o referinta la datele asociate fiecarui element al listei, este public si permite accesul liber al aplicatiei la aceste date. Al doilea membru, next_element, este privat si, ca urmare, accesibil doar prin operatiile specificate pentru Element.

Desigur, lucrurile nu sunt nici pe departe atat de simple cum au fost prezentate aici. Daca avem in vedere ca un client scris in Java poate comunica cu un server scris in C++, comunicarea unei valuetype cu operatii cu tot poate fi imposibila. Aplicatia C++ ar trebui sa aiba cunostinte despre respectiva valuetype, inca la compilare sau in forma unei DLL. Cu totul altfel stau lucrurile intr-o implementare uniforma in Java, caz in care incarcarea implementarilor de valuetype se face relativ simplu si sigur.

Ce s-ar mai putea adauga? Ca si in alte extensii CORBA, specificatia OBV (Object By Value) nu este lipsita de goluri. Aceasta nu inseamna ca, in timp, lucrurile nu se vor rezolva. Evolutiile actuale sunt indreptate spre o convergenta CORBA-Java, dar viitorul este inca greu de prevazut.