Dezvoltarea reţelelor de calculatoare şi interconectarea lor la nivel global (prin Internet) a pus problema unei comunicaţii cât mai eficiente între arhitecturi eterogene [5]. Diversitatea partenerilor de discuţie este explicată prin procesul natural de dezvoltare a reţelelor de-a lungul timpului. 

            La ora actuala exista patru mari arhitecturi distribuite: 

CORBA (Common Object Request Broker Architecture) 

DCE (Distributed Computing Environment) 

DCOM (Distributed Component Object) 

Java RMI (Remote Method Invocation) 

       CORBA, un standard elaborat de OMG (Object Management Group), este un cadru de dezvoltare a aplicaţiilor distribuite în medii eterogene. La acest proiect au participat toate marile companii de soft, cu excepţia Microsoft-ului, care are propriul sau model (DCOM). CORBA se bazează pe OMA (Object Management Architecture), model propus de OMG, pentru transbordarea într-un mediu distribuit a programării orientate pe obiecte, ceea ce implica o dezvoltare rapida, reutilizarea si protecţia eficientă a datelor.

        În viziunea CORBA, un sistem distribuit este alcătuit din "clienţi" ce utilizează diferite obiecte distribuite. Datorită modalităţilor diverse de comportare a obiectelor în sisteme de operare diferite (în thread-uri, biblioteci cu legare dinamica - DLL-uri ,...), CORBA lucrează cu noţiunea de "server" (fiecare obiect este asociat unui server). Rolul acestuia este de a include implementarea obiectelor asociate. Acest model impune doar invocarea de către clienţi a obiectelor de pe server şi nu a serverului însuşi. Asemeni tuturor modelelor, standardelor si produselor software, CORBA evoluează. Experienţa câştigată cu versiunile iniţiale a evidenţiat îmbunătăţirile şi modificările ce au permis creşterea utilităţii si aplicabilităţii standardului într-un număr tot mai mare de aplicaţii distribuite. Aşa stau lucrurile, de exemplu, cu POA (Portable Object Adaptor), adaptorul portabil de obiecte. Funcţiile acestuia se referă la: crearea obiectelor şi referinţelor CORBA, dirijarea invocărilor de servicii către obiectele corespunzătoare, activarea si deactivarea obiectelor, etc. O alta noutate cu care vine CORBA 3.0 este referitoare la mesajele asincrone. Invocările de servicii de natură sincronă din versiunile iniţiale sunt păstrate acum în CORBA Messaging Specification, dar sunt suplimentate de metodele de invocări asincrone, callback si polling. O alta îmbunătăţire majora este transmiterea obiectelor prin valoare. 

        DCOM (Distributed Component Object) este soluţia Microsoft, asemănătoare cu CORBA, pentru platforme Windows. Acesta permite un sistem de transmitere a mesajelor; un model de comunicare între obiecte COM (Component Object Model), un model de document compus OLE (Object Linking and Embedding), cu servicii de comunicare între documente si gestiunea lor; ActiveX, pentru aplicatii Web.

           Atât CORBA, cât si DCOM separă interfeţele obiectelor de implementările lor. Diferenţa constă în faptul ca limbajul de definire a interfeţelor de la Microsoft diferă de CORBA IDL. Moştenirii obiectelor din CORBA i se opun mecanismele de agregare si delegare DCOM pentru reutilizarea obiectelor. În agregare obiectul exterior expune interfeţele obiectelor interioare ca şi cum ar fi ale sale şi în delegare obiectul exterior retransmite delegările de metode către obiectele interioare. Practic, o interfaţă DCOM poate fi văzută ca o interfaţă de funcţii, clientului dându-i-se un pointer pentru a avea acces la respectivele funcţii, interfeţele DCOM neputând fi instanţiate si neavând stări.

       DCE (Distributed Computing Environment) este promovat de către OSF (Open Software Foundation). Facilităţi oferite: thread-uri, apeluri de procedură la distanţă, servicii de directoare. Există un standard gateway între DCE şi CORBA prin care CORBA poate lucra peste DCE (protocolul DCE CIOP). Diferenţa dintre DCE şi CORBA constă în stilurile de programare adoptate: CORBA foloseşte un model obiectual, DCE are la baza un model procedural în care se folosesc apeluri la distanţă (RPC - Remote Precedure Call).

        Java, limbajul revoluţionar al anilor '90 prin independenţa sa de platformă si totala orientare obiect nu prevedea la început servicii distribuite, obiectele Java de pe un server trebuind sa fie transferate la client pentru execuţie. Neajunsul acelui sistem consta în faptul că obiectele îşi pierdeau informaţia pe perioada de inactivitate. 

a) prin socket-uri;

        Metoda este destul de flexibilă, dar este primitivă, implicând o abordare la nivel de protocol de comunicaţie.

b) prin RPC;

       Comunicarea se face la nivel de procedură, evitându-se lucrul direct cu socket-urile. Pentru a apela proceduri prin RPC argumentele de intrare şi valorile rezultate trebuie să respecte anumite reprezentări standard. 

(1) Procesul client apelează stub-ul client.

(2) Stub-ul client împachetează parametrii apelului într-un mesaj pe care pe care îl trimite kernel-ului maşinii client (serializare).

(3) Kernelul client trimite mesajul kernelului maşinii server.

(4) Kernelul server primeşte mesajul şi îl trimite skeletonului de pe server.

(5) Skeletonul despachetează parametrii din mesaj şi apelează procedura dorită a serverului (deseializare).

(6) Procedura este executată şi rezulatul este întors către skeleton.

(7) Skeletonul împachetează rezultatul într-un mesaj şi face apel la kernelul maşinii server.

(8) Kernelul server trimite mesajul înapoi la maşina client.

(9) Kernelul client preia mesajul si îl pasează stubului client.

(10) Stubul client despachetează rezultatul din mesaj si îl returnează procesului client (deserializare).

c) prin Java RMI;

       Interfaţa de programare Java RMI se mulează perfect pe modelul orientat obiect oferit de Java, unde se pot crea obiecte ale căror metode pot fi invocate din alte maşini virtuale. Singura restricţie este ca obiectele ce vor fi apelate de la distanţă de către clienţi sa fie instanţiate dintr-o clasa serialializabilă. O clasa este serializabilă daca orice instanţă a sa poate fi transformată într-un şir de octeţi (şirul de octeţi putând fi salvat într-un fişier sau transmis către alta maşină virtuala Java) si restaurat. În Java o clasa este serializabilă dacă implementează una din interfeţele: "java.io.Serializable", "java.io.Externalizable".

        Relaţia între Java RMI şi CORBA este mai mult una de complementaritate decât de concurenţă, Java fiind un limbaj ideal pentru a descrie obiecte CORBA. Facilităţile de cod mobil din Java permit împărţirea unei aplicaţii la momentul execuţiei pe două niveluri: client şi server. Pe de alta parte, CORBA extinde Java cu un set de obiecte distribuite aşa încât, de exemplu, un aplet poate comunica cu orice obiect indiferent de limbajul în care este scris şi de localizarea în reţea. Alăturarea dintre Java şi CORBA implică o serie de avantaje majore, Java intrând în funcţiune acolo unde CORBA se termină (obiecte Java implementează interfeţe definite prin CORBA IDL). Java completează serviciile CORBA prin serviciile sale de colectare a gunoiului, controlând astfel ciclul de viaţă al obiectelor. Având în vedere toate cele spuse mai înainte se poate vorbi de o adevărată rivalitate între Java/CORBA pe de o parte şi DCOM de cealaltă parte.

        Funcţionarea mecanismelor Java RMI şi CORBA se bazează pe faptul ca pe maşina client exista un aşa-numit client stub, o interfaţă între programul client si kernel-ul maşinii pe care lucrează, iar pe maşina server există un aşa-numit server skeleton, care are cam aceleaşi funcţii ca şi stub-ul client. Acest mecanism este moştenit din RPC. Avantajul principal al folosirii obiectelor CORBA este dat de independenţa de limbaj, programele vechi care ofereau sau utilizau servicii nu trebuie să fie rescrise pentru a fi refolosite, ci este suficient sa fie configurate ca obiecte CORBA, de exemplu, un obiect C++ utilizat local de alte obiecte care apelau metodele sale poate fi exploatat de la distanţă şi de către un program Java, folosind CORBA. În această situaţie obiectul C++ care joacă rolul de server nu trebuie rescris, ci este suficientă scrierea unei interfeţe pentru acesta prin care să se specifice ce serviciu oferă. 

       Independenţa de limbaj este posibilă datorită construcţiei acestei interfeţe folosind limbajul IDL (Interface Definition Language). IDL permite ca toate obiectele CORBA să fie descrise în aceeaşi manieră, cerându-se în mod evident, şi o legătură între limbajul nativ (C++, Java, etc.) si IDL. Legătura este realizată prin compilatoare care mapează (transformă) codul IDL în cod nativ. Obiectele CORBA comunică între ele cu ajutorul nucleului ORB (Object Request Broker) ca un intermediar. Nucleele ORB de la furnizori diferiţi pot comunica peste TCP/IP folosind IIOP (Internet Inter-Orb Protocol). Exista multe nuclee ORB disponibile pentru diferite limbaje ca: Java, C++, SmallTalk, etc. 

       Este mecanismul de infrastructură standardizat de CORBA. Principalul său rol este acela de a uniformiza accesul la serviciile pentru aplicaţii. În acest scop el utilizează un mecanism de apel la distanţă, orientat obiectual, pentru proceduri şi metode. Structura ORB este detaliată în secţiunea următoare.

    Sunt interfeţe standardizate care pun la dispoziţia celorlalte obiecte din sistem o serie de operaţii şi servicii fundamentale. Printre operaţii şi servicii amintim: crearea obiectelor, asigurarea persistenţei, controlul concurenţei, securitatea, comportarea tranzacţională, tratarea evenimentelor etc. Trebuie remarcate două servicii de obiecte fundamentale[6]:

• Naming Service care permite clienţilor să găsească obiecte după numele acestora.

• Trading Service care permite clienţilor să găsească obiecte după proprietăţi ale acestora.

        Oferă interfeţe standard pentru operaţii comune pentru grupe de aplicaţii. O astfel de facilitate comună se referă, spre exemplu, la componenta Distributed Document  Component Facility. Ea, această componentă, permite schimbul de obiecte într-un document, cum ar fi legarea unei foi de calcul de un anumit raport, cele două fiind pe maşini diferite. 

        Reprezintă "standardele verticale" adoptate de OMG pentru diferite categorii (domenii) de aplicaţii: finanţe, medicină, telecomunicaţii, etc. 

        Sunt cele create de programatori pe specificul fiecărei aplicaţii. Din perspectiva CORBA acestea sunt considerate ca interfeţe nestandard.

        ORB pune la dispoziţie toate mecanismele necesare pentru a găsi implementarea obiectului, pentru a o pregăti sa primească cererea şi pentru transmiterea datelor ce alcătuiesc cererea. Interfaţa pe care clientul o vede este independentă de locaţia obiectului servant, de limbajul de programare în care este implementat, sau de orice alt aspect ce nu este reflectat în interfaţa obiectului.

• nucleul ORB;

• limbajul de definire a interfeţelor (IDL);

• depozit de interfeţe;

• maparea (conversia) în limbaje de programare;

• componente stub şi skeleton;

• apel dinamic şi furnizare dinamică de obiecte;

• adaptori de obiecte;

• protocoale Inter-ORB.

      Obiectele CORBA comunică între ele cu ajutorul nucleului ORB (Object Request Broker) ca un intermediar [5]. Nucleele ORB de la furnizori diferiţi pot comunica peste TCP/IP folosind IIOP (Internet Inter-Orb Protocol). Există multe nuclee ORB disponibile pentru diferite limbaje ca: Java, C++, SmallTalk, etc. 

        Funcţii îndeplinite de un nucleu ORB:

• oferirea de răspunsuri la cererile venite din partea unui client sau din partea unui alt ORB; 

• căutarea si instanţierea obiectelor de pe maşini aflate la distanţă; 

• translatarea parametrilor dintr-un limbaj în altul; 

• invocarea de metode ale unor obiecte aflate la distanţă; 

• invocarea statică sau dinamică a unor obiecte aflate la distanţă. 

      Un client al unui obiect are acces la o referinţă a obiectului şi invocă operaţii pe respectivul obiect [7]. Un client cunoaşte numai structura logică a obiectului, conformă cu interfeţele sale şi experienţele de comportament ale obiectului, prin invocări. De altfel se va considera, la modul general, că un client este un program sau un proces care iniţiază cereri pe un obiect; este important să se poată face recunoaşterea entităţilor care sunt client ale unui obiect dat. De exemplu implementarea unui obiect poate fi client pentru alte obiecte.

     Clienţii privesc, în general, obiectele şi interfeţele ORB prin perspectiva maparii limbajelor, aducând ORB-ul la nivelul programatorului. Clienţii sunt portabili şi trebuie să lucreze fără schimbări asupra sursei pe orice ORB care susţine reprezentarea limbajului ceruta, cu orice instanţă obiect care implementează interfaţa necesara. Clienţii nu au cunoştinţe despre implementarea obiectului, despre adaptorului obiect utilizat de implementare sau de natura ORB-ului utilizat pentru a-l  accesa..

        Defineşte datele pentru instanţa obiect si codul pentru metodele sale. Adesea se vor folosi şi alte obiecte sau software adiţional pentru implementarea comportamentului obiectului.