1. CORBA

1.1. Introducere. Scurt istoric. Surse de documentare. O caracteristic important a reelelor de calculatoare (Internet, Intranet) este heterogenitatea. Aceasta ofer avantajul de a putea alege cele mai potrivite componente software i hardware pentru diferite pri ale reelelor i diferite aplicaii, ca i pe acela de a putea dezvolta reelele cu echipamentele i programele cele mai importante la un moment dat. Prin contrast, majoritatea interfeelor de programare a aplicaiilor sunt orientate spre platforme omogene.

Pentru a orienta i facilita integrarea unor sisteme dezvoltate separat, ntr-un singur mediu distribuit eterogen, OMG (Object Management Group) consoriu cuprinznd peste 700 de dezvoltatori, comerciani i utilizatori de software a elaborat, adoptat i promovat standarde pentru aplicaii n medii distribuite. Unul dintre ele este CORBA Common Object Request Broker Architecture, care se constituie ntr-un cadru de dezvoltare a aplicaiilor distribuite n medii eterogene. CORBA este cel mai ambiios proiect al OMG, la care au aderat toate marile firme de software, cu excepia Microsoft, firm ce a dezvoltat propriul su model, DCOM (Distributed Component Object Model), incompatibil cu CORBA.

CORBA este elementul cheie al OMA Object Management Architecture, model propus de OMG pentu a transpune n mediu distribuit eterogen toate avantajele programrii orientate pe obiecte, incluznd: dezvoltarea rapid, reutilizabilitatea, protecia implicit, etc.

OMA include Modelul de Obiect (Object Model) care precizeaz cum vor fi descrise obiectele distribuite ntr-un mediu eterogen i Modelul de Referin (Reference Model) care caracterizeaz interaciunile dintre obiecte.

Un obiect este o grupare unitar ncapsulat de operaii i date, cu identitate distinct. Un obiect este definit prin interfaa pe care o prezint altor obiecte, prin comportarea sa la invocarea unei operaii i prin stare. Serviciile unui obiect sunt disponibile prin interfa, foarte bine definit. Un client, care la rndul su este un obiect, are acces la obiectul server prin invocarea uneia din metodele sale. Relaia dintre client i obiect este caracterizat de aspectele la cere ne referim n continuare.

1.2. Arhitectura sistemelor distribuite n modelul CORBA Un sistem tipic cuprinde programe clieni care utilizeaz obiecte distribuite n sistem. Deoarece n multe sisteme de operare prelucrrile trebuie s aib loc ntr-un proces, orice obiect trebuie s evolueze ntr-un proces. n alte cazuri, obiectele pot evolua n thread-uri sau n biblioteci cu legare dinamic (DLLs). CORBA d factor comun ntre aceste posibiliti i precizeaz c obiectele exist n servere (uneori, n loc de server se mai folosete termenul de implementare). Fiecare obiect este asociat cu un singur server. Dac, la invocarea obiectului, serverul nu este n execuie, atunci CORBA va activa serverul, automat. Codul unui server include implementarea obiectelor asociate, precum i o funcie principal care iniializeaz serverul i creaz un set iniial de obiecte. Acestea pot fi de acelai tip sau de tipuri diferite. Serverul poate include i obiecte non-CORBA, de exemplu obiecte C++ accesibile doar din server. Doar obiectele pot fi invocate de clieni, nu i serverul nsui.

Figura 1.1. Arhitectura CORBA Obiectele unui server pot invoca obiecte din alte servere. Pe durata unei invocri, serverul respectiv joac ro de client. Datorit acestei faciliti, sistemele pot avea arhitecturi foarte diverse, nefiind limitat la arhitectura stea cu un server central la care fac apel mai muli clieni. Mai multe servere pot coopera, oferind un serviciu global clienilor. Fiecare server ndeplinete o funcie specific. O alt variant este cea n care serverele au aceeai funcionalitate. Clientul este pus n contact cu serverul local (aflat n acelai sistem de calcul) sau cu serverul cel mai puin ncrcat. n multe cazuri, codul clientului poate conine obiecte CORBA, pe care serverul le poate invoca pentru transmiterea informaiilor despre anumite evenimente sau despre modificarea valorilor unor date. Referinele acestor obiecte sunt transmise de client serverului ca parametri ai unor apeluri anterioare. Invocrile fcute de clieni sunt implicit blocante: clientul ateapt ca cererea s fie transmis serverului, serverul s execute operaie invocat i rspunsul s fie returnat clientului. Sunt posibile i alte forme: ntr-un apel neblocant, clientul continu s execute operaii n paralel cu serverul i ateapt terminarea apelului mai trziu un apel store-and-forward este mai nti nregistrat ntr-o memorie persistent i apoi este transmis obiectului int ntr-un apel publish-and-subscribe se transmite un mesaj cu un anumit subiect, oricare obiect interesat de subiectul respectiv putnd primi mesajul.

1.3. Intercomunicarea obiectelor Implementarea i localizarea unui obiect sunt ascunse clientului. Comunicarea ntre client i obiect este facilitat de ORB (Object Request Broker). Aa cum sugereaz i numele, ORB permite obiectelor s se regseasc unele pe altele n reea. El ajut obiectele s fac cereri i s primeasc rspunsuri de la alte obiecte aflate n reea. Acestea se desfoar n mod transparent pentru client: el nu trebuie s tie unde este localizat obiectul, care este mecanismul utilizat pentru a comunica cu el, cum este activat sau memorat acesta, etc.

ORB este mai sofisticat dect formele alternative client/server, incluznd RPC-urile sau comunicarea peer-to-peer. ORB permite ca obiectele s se descopere reciproc la execuie i s-i invoce reciproc serviciile. Din aceste motive, ORB este caracterizat adesea ca fiind o magistral de obiecte (object bus).

1.3.1. CORBA i Middleware

Ca o parantez, serviciile CORBA fac parte dintr-o categorie denumit generic middleware. Acesta este un set de servicii independente de aplicaii care permit aplicaiilor i utilizatorilor s interacioneze prin reea. n esen, middleware este software-ul localizat ntre reele i aplicaii.

Client

Servere Obiecte Apel la distanta

MiddlewareMidlleware Middleware Middleware

Reea

Utilizator Aplicaie Aplicaie Utilizator

Figura 1.2. Rolul middleware-ului

Serviciile pot fi grupate n trei categorii: De schimb de informaie Orientate spre aplicaii (replicarea datelor, integritatea, servicii de grup pentru procese

cooperative, servicii pentru obiecte distribuite, etc.)

De management (directoare, securitate, toleran la defecte, performan). Serviciile middleware sunt disponibile aplicaiilor prin interfee de programare a aplicaiilor, API (iar operatorul uman prin GUI Graphical User Interfaces). n practic, serviciile apar ca o combinaie de componente logice (niveluri), cum sunt cele din figura 1.3.

Figura. 1.3. Servicii dezvoltate pe baza modelului Internet

1.3.2. Transparena fa de sistem Un ORB se poate executa local, pe un singur calculator, sau poate fi conectat cu orice alt ORB din Internet, folosind protocolul IIOP (Internet Inter-ORB Protocol) definit n CORBA 2.0. Un ORB

poate transmite apeluri ntre obiectele unui singur proces, ale unor procese executate pe aceeai main sau ale unor procese din sisteme diferite, cu sisteme de operare diferite.

1.3.3. Transparena limbajului

Clientul nu tie cum este implementat obiectul server, n ce limbaj de programare a fost scris. Clientul poate folosi un limbaj de programare la alegere.

CORBA separ interfaa de implementare i folosete un limbaj neutru pentru descrierea interfeelor: IDL Interface Definition Language. Acesta este un limbaj pur declarativ ce permite specificarea interfeei i structurii obiectelor, ce trebuie cunoscute de ctre clieni. Metodele specificate in IDL pot fi scrise i invocate n orice limbaj pentru care au fost definite corespondenele cu CORBA: pentru moment C, C++, Ada, Smalltalk, n lucru Cobol, Java Objective C.

Client Server

C

ORB

IDL

C++ COBOL Java C

IDL IDL IDL IDL IDL IDL IDL IDL IDL

C++ JavaCOBOL

Figura 1.4. Structura unei aplicaii client server

Programatorii lucreaz cu obiecte CORBA folosind construcii ale limbajului nativ de programare. IDL furnizeaz interfee independente de limbajul de programare i de sistemul de operare, ctre toate serviciile rezidente n magistrala CORBA. IDL permite interoperarea ntre clieni i obiecte server, scrise n limbaje diferite. IDL permite nu doar definirea serviciilor unor obiecte server, dar i mbrcarea unor aplicaii motenite astfel nct acestea s se comporte ca obiecte. De exemplu, o aplicaie scris n COBOL se poate comporta ca un obiect server att timp ct are un IDL i execut operaiile definite de aceast interfa.

1.3.4. Invocri statice i dinamice ale metodelor

ORB permite definirea static, la compilare, sau dinamic, la execuie a invocrilor de metode. Prima form beneficiaz de toate verificrile de tipuri disponibile la compilare; a doua are o mai mare flexibilitate.

1.3.5. Sisteme autodescriptibile

CORBA furnizeaz metadescrieri ale serviciilor disponibile la execuie. Acestea sunt pstrate ntr-un depozit de interfee, Interface Repository. Clienii gsesc n aceste depozite informaii despre modul n care trebuie invocate serviciile, la execuie.

1.3.6. Exemple de ORB

DSOM - Distributed System Object Model (IBM) i Neo (Sun) sunt ambele compatibile cu CORBA. Ele folosesc IIOP pentru comunicarea ntre obiecte.

DCOM Distributed Common Object Model (Microsoft) este un ORB dar nu este compatibil cu CORBA.

1.4. Modelul de referin

1.4.1. Servicii

CORBA depete nivelul facilitilor de inter-operare a obiectelor. El specific, n plus, un set cuprinztor de servicii pentru crearea i desfiinarea obiectelor, accesul lor prin nume sau proprieti, depunerea lor n memorii persistente, definirea de relaii ntre ele, etc.

Prin aceasta, CORBA permite crearea unui obiect obinuit, cu o funcionalitate legat de o anumit aplicaie, i adugarea ulterioar (prin motenire multipl de la serviciile corespunztoare) a securitii, proteciei, persistenei, tranzacionalitii, etc.

Categoriile de interfee de servicii sunt prezentate in figura 7.3.

Figura 1.5. Categorii de interfee Serviciile de obiecte completeaz funcionalitatea ORB. Au fost publicate standarde pentru 16 servicii de obiecte grupate n urmtoarele categorii: sisteme distribuite (D) baze de date (B) generale (G).

Dintre cele mai importante, amintim urmtoarele: (D) Serviciul de nume (Naming Service) permite obiectelor s gseasc alte obiecte, pe baza

numelor;

(D) Serviciul de gsire a obiectelor dup proprieti (Trading Service) (G) Serviciul ciclului de via (Life Cycle Service) definete operaiile de creare, copiere,

mutare i tergere a componentelor pe magistrala de obiecte.

(B) Serviciul de persisten (Persistence Service) ofer o singur interfa pentru memorarea persistent a obiectelor ntr-o varietate de servere de memorare, incluznd baze de date de obiecte, baze de date relaionale sau simple fiiere.

(D) Serviciul de evenimente (Event Service) permite obiectelor s nregistreze sau s anuleze interesul lor pentru evenimente specifice. Serviciul definete un obiect denumit event channel care colecteaz i distribuie evenimente pentru obiecte care nu se cunosc reciproc.

(B) Serviciul de proprieti (Properties Service) permite asocierea unor perechi (nume-valoare) cu obiectele.

(G) Serviciul de timp (Time Service) permite sincronizarea n funcii de timp i gestiunea evenimentelor dependente de timp.

(D) Serviciul de securitate (Security Service) ofer un cadru complet pentru securitatea obiectelor distribuite. Suport autentificarea, liste de control al accesului, confidenialitatea i ne-repudierea. De asemenea, delegarea de acreditive ntre obiecte.

ORB

Servicii de obiecte

Faciliti comune

Interfee de i i i

(B) Serviciul de control al concurenei (Concurrency Control Srrvice) permite gestiunea blocrilor/deblocrilor.

Transaction Service, Relationship Service, Querry Service reprezint alte servicii importante de baze de date.

1.4.2. Facilitile comune

Furnizeaz servicii orientate spre aplicaii. Un exemplu este DDCF Distributed Document Component Facility, bazat pe OpenDoc (Apple Computer). Acesta permite prezentarea i interschimbul de obiecte bazate pe un model de document. El faciliteaz, de exemplu, legarea unui obiect foaie de calcul ntr-un raport.

Facilitile comune aflate n construcie include: ageni mobili, interschimb de date, cadre de obiecte comerciale, internaionalizarea.

1.4.3. Interfeele de aplicaii

Se refer la obiecte specifice unei anumite aplicaii. Ele nu sunt standardizate i nu prezint interes pentru OMG dect n msura n care anumite servicii depesc (treptat) domeniul unei singure aplicaii. n acest sens, obiectele comerciale business objects reprezint o cale natural de descriere a conceptelor independente de aplicaie, cum ar fi client, ordin, bani, plat, pacient, automobil, etc. Noiunea de obiect comercial trebuie acceptat ntr-un sens larg, ea referindu-se la o component ce reprezint o entitate recognoscibil n lumea real. O colecie va consta dintr-o colecie de obiecte comerciale ale cror interaciuni i comportri imit entitile lumii reale pe care o modeleaz.

1.5. Arhitectura CORBA ORB CORBA ORB este partea ce mijlocete stabilirea relaiilor client/server ntre obiecte. n 1995, OMG a publicat CORBA 2.0, ale crui principale caracteristici sunt evideniate n continuare. Structura sa este prezentat in figura 8.1.

Folosind ORB, un obiect client poate invoca o metod a unui obiect server, n mod transparent. ORB intercepteaz apelul i este rspunztor de gsirea obiectului server, de transmiterea parametrilor i de invocarea metodei, ca i de returnarea rezultatelor.

Client Implementare de obiect

Interfa de

invocare dinamic

Interfa ORB

Stub IDL

Skeleton static IDL

Interfa dinamic

de Skeleton

Adaptor Depozit

de interfee

Depozit de implementri

ORB

Figura 1.6. Arhitectura CORBA

Clientul nu trebuie s cunoasc localizarea obiectului server, limbajul de programare n care a fost scris, sistemul de operare n care se execut sau orice alte aspecte care nu sunt cuprinse n interfaa obiectului. Este important de notat c rolurile de client i de server sunt determinate de modul de coordonare a interaciunilor ntre obiecte i se pot modifica n timp.

1.5.1. Nucleul ORB

Obiectul cruia ORB trebuie s-i transmit cererea clientului se numete obiect-int. Caracteristica ORB este transparena cu care asigur comunicarea clientului cu inta. El ascunde: Localizarea obiectului n acelai proces, n procese diferite ale aceleai maini, n noduri de

reea diferite

Implementarea obiectului (limbaj, SO, calculator) Starea de execuie: clientul nu trebuie s tie dac obiectul server este activat i gata s

primeasc cererea; dac este cazul, ORB pornete obiectul nainte de a-i da cererea.

Mecanismul de comunicare cu obiectul TCP/IP, cu memorie partajat, apelul unor metode locale, etc.

Clientul specific obiectul int printr-o referin de obiect. Aceasta se creeaz odat cu obiectul i se refer la el n mod unic, atta timp ct obiectul exist. Referina este opac pentru client, n sensul c acesta nu o poate modifica. Referinele de obiecte sunt gestionate exclusiv de ORB i au formate standard (ca n IIOP) sau proprietare (de firm).

Clienii pot obine referinele de obiecte pe mai multe ci: La crearea obiectului clientul poate crea un obiect i obine referina sa. CORBA nu are o

operaie special de creare de obiecte. Pentru a crea un obiect, clientul invoc o operaie a unui obiect fabric de obiecte. Crearea ntoarce o referin de obiect.

Prin serviciul de cataloage (directory service) ambele Naming Service si Trading Service permit obinerea de referine, dup nume, respectiv dup proprieti.

Prin conversia la/de la iruri de caractere o referin de obiect poate fi convertit n ir de caractere i napoi n referin putnd fi utilizat dup conversie, att timp ct obiectul exist.

Problema: cum se lanseaz aplicaia i cum poate obine o referin iniial de obiect. Soluia: ORB are un serviciu simplu de nume, incorporat, care furnizeaz aplicaiei referinele unor servicii mai generale (Naming Trading). Operaia resolve-initial-reference cu parametrul Name-Service furnizeaz aplicaiei referina de obiect pentru serviciul de nume cunoscut de ORB.

2. OMG IDL - Interface Definition Language Pentru ca un obiect s adreseze cereri unui obiect (server), el trebuie s cunoasc tipurile operaiilor suportate de obiect. Acestea sunt precizate de specificaia interferenei obiectului. Pentru a realiza independena fa de limbajul de programare n care este descris obiectul, interfaa este definit ntr-un limbaj neutru, IDL Interface Definition Language. Interfeele sunt similare claselor n C++ i interfeele n Java.

IDL prevede mai multe declaraii pentru: tipuri de baz (short, long, char, etc), tipuri template (string, sequence), tipuri construite (struct, union, etc)

Definiie IDL

tipuri constante

excepii

module

module constante tipuri interfee

constante tipuri

excepii

atribute operaii

Figura 2.1. Declaraii IDL

Acestea sunt folosite n declaraiile operaiilor pentru a defini tipurile argumentelor i rezultatului. La rndul lor, operaiile sunt folosite n declaraiile de interfee, pentru a defini serviciile furnizate de obiecte. Un ansamblu de interfee i definiii de tipuri poate constitui un modul, al crui rol este legat de domeniile de valabilitate ale numelor declarate. Un fiier IDL formeaz un domeniu de valabilitate al numelor (scope). Un nume poate fi definit o singur dat ntr-un domeniu. Oricum, numele poate fi re-definit ntr-un subdomeniu inclus, cum ar fi cel corespunztor unui modul. Forma general a declaraiei unui modul este urmtoarea: module modulename { interface interfacename1 {}; interface interfacename2 {}; }

O specificaie const din zero sau mai multe definiii de tip, constante, excepii sau module. Un modul poate conine, n afara interfeelor i definiii de tipuri i alte module.

2.1. Tipuri

2.1.1. Tipuri de baz IDL suport urmtoarele tipuri de baz: long (signed, unsigned) 32 bii long long (signed, unsigned) 64 bii short (signed, unsigned) 16 bii float, double, long double char, wchar (wide char caractere de 16 bii) boolean octet (8 bii) se garanteaz c nu sunt aplicate conversii la transmiterea prin reea cu ORB. enum any poate reprezenta orice tip de baz sau construit de utilizator.

2.1.2. Tipuri construite

Exemplu structur. struct catalog { course curs;

grade nota; }

Exemplu union cu discriminant: union DataItem switch (char){ case c: long count; case a: float amount;

default: char initial; }

Exemplu tablou de lungime fix, cu elemente de un singur tip: typedef char message[80];

2.1.3. Tipuri template

string i wstring mrginite i submrginite

string // un sir fr limitri de lungime string // un sir de maximum 10 caractere sequence tablou unidimensional, mrginit sau nemrginit, cu toi membrii de acelai tip

sequence MySeq; //mrginit sequence Seq; //nemrginit

2.2. Constante Se pot defini constante simbolice, ca n orice limbaj de programare, oriunde ntr-un fiier IDL. IDL calculeaz valoarea constantelor folosind:

Operatorii sunt unari -, +, ~ (bit complementat) binari *, /. %, +, -, (shift), & (i pe biI), | (sau pe biI), ^ (xor pe biI)

De exemplu: const long double_size = max_size*2; const string help_message=help;

2.3. Definiii de interfee. Motenirea. O interfa este o descriere a operaiilor pe care un obiect le poate executa. Un obiect satisface interfaa dac el poate fi specificat ca int n oricare cerere potenial descris de interfa. Forma general este: interface nume[:baza {, baza}]{ ..: declaraii de constante, tipuri, excepii, atribute, operaii, };

Fiecare interfa definete un nou tip de referin de obiect i un nou domeniu de valabilitate a numelor (scope). O definiie de interfa poate conine declaraii de: constante, tipuri, excepii, atribute i operaii. Exemple: interface Factory{ Object create(); };

definete o interfa numita Factory, care are o operaie create. Operaia nu are parametrii i ntoarce o referin de obiect de tip Object. Dat fiind o referin de obiect de tip Factory, un client poate invoca operaia pentru a crea un nou obiect CORBA.

O interfa poate moteni de la una sau mai multe alte interfee. Motenirea permite reutilizarea interfeelor existente pentru a defini servicii noi.

Exemplu interface Person { Readonly attribute string name; }; interface student: Person{ attribute Profesor advisor; Enrollments load (in semester when); };

student are atributele name i advisor i operaia load. Exemplu

interface SpredSheetFactory: Factory { Spreadsheet create_spreadsheet(); };

Aici, SpreadSheet are dou operaii, create motenit de la Factory i create_spreadsheet definit direct n interfa.

Motenirea este un concept important n CORBA, care se supune principiului Open-Close: el permite ca sistemul s fie deschis extensiilor i nchis modificrilor. O interfa poate moteni de la mai multe alte interfee, dar nu poate redefini atributele motenite sau operaiile motenite. n schimb o interfa derivat poate redefini orice constant, excepie, tip care a fost motenit.

Folosirea numelui interfeei i a operatorului de rezoluie poate rezolva ambiguitile. Exemplu: interface Foo {typedef short myType;}; interface Bar: Foo { typedef long myType; void my_op(in myType a, in Foo::myType b); };

n acest exemplu, se copiaz tipul myType definit n interfa pentru primul parametru i tipul myType definit in Foo pentru al doilea parametru. Operatorul de rezoluie poate fi folosit i n cazul n care o constant, tip sau excepie este definit n mai multe interfee specificate ca baz pentru interfaa curent. Oricum, nu se poate moteni de la dou interfee care au definit o aceeai operaie sau un acelai atribut.

OMG IDL are un caz special de motenire: toate interfeele sunr derivate din interfaa Object definit n modulul CORBA. Deoarece aceast motenire din CORBA::Object este automat, ea nu trebuie specificat explicit pentru fiecare interfa OMG IDL.

2.4. Operaii IDL. Operaii oneway Operaiile sunt similare declaraiilor de funcii C/C++. O operaie denot un serviciu care poate fi cerut obiectului i este descris prin: identificatorul operaiei tipul rezultatului (orice tip IDL) descrierea fiecrui parametru nume tip (mod) direcie

in client->server out server->client inout ambele direcii

Excepiile pe care operaia le poate provoca (clauza raises), ele constituie indicaii c operaia care le-a generat nu a fost executat corect. Sintaxa unei operaii este urmtoarea: result_type op_name ( [direction type name {, directions type name} ]) [raises ([exception {, exception }])]

unde exception este o excepie definit anterior. De exemplu: Students roster (in Semester when); void enroll (in Course course_to_take, out Course prereqs);

long pop() raises (underflow);

Oneway este o caracteristic suplimentar a unei operaii. Ea precizeaz c utilizatorul nu se blocheaz n operaie i c sistemul nu garanteaz c cererea este transmis obiectului int. O operaie oneway: (1) nu poate conine parametrii out sau inout; (2) trebuie s nu ntoarc un rezultat (tipul rezultatului, void); i (3) s nu conin clauza raises.

2.5. Excepii i atribute n ce privete excepiile, ele arat producerea unor erori la execuia unei operaii. Excepiile pot fi clasificate n: excepii definite de sistem excepii definite de utilizator

O excepie de sistem, este generat cnd se produce o eroare n infrastructura ORB sau la producerea unei noi erori generice n timp ce serverul ncearc s prelucreze o cerere. De xemplu, Out of memory sau Illegal parameter.

O excepie de sistem const dintr-un motiv major (CORBA:: BAD_PARAM) i un cod minor. Uzual, o funcie de conversie exception_to_string permite conversia motivului i a codului ntr-o form descriptiv, textural.

O excepie utilizator este definit la fel ca o nregistrare. De exemplu, exception UnknownId {}: exception NotInterested {string explanation}; Un alt exemplu: interface FrontOffice{ ... exception NoSuchPlace{ Place where }; Exception InvalidDate{ Date when; }; Places getPrice (in Place chosenPlace, in Date when) raises (NoSuchPlace, InvalidDate); };

Atributele interfeei. Pe lng operaii, o interfa poate avea atribute. Un atribut caracterizeaz starea unui obiect, ntr-o manier abstract. El este logic echivalent cu declararea unei perechi get/set de funcii de acces la valoarea atributului. Un atribut poate fi read-only, caz n care este accesibil doar prin get. Forma general este [readonly] attribute . De exemplu, interface Adder { readonly attribute long sum; };

2.6. Particulariti IDL OMG IDL are un sistem de tipuri simplu, pentru a facilita corespondena cu multe limbaje de programare. Cu toate acestea, sistemul de tipuri este suficient pentru cele mai multe aplicaii distribuite. Simplitatea este critic pentru utilizarea CORBA ca o tehnologie integratoare. Dintre elementele pe care le gsim n limbajele de programare i nu le regsim in IDL, amintim:

toate definiiile dintr-o interfa IDL sunt publice (nu exist conceptul de private sau protected, acestea fiind legate de implementare nu de specificare)

nu pot fi declarate variabile-membre; atributele sunt diferite de variabile, ele reprezentnd cererile pe care un client le poate adresa obiectului i nu memoria pe care obiectul trebuie s o aib; un atribut poate fi implementat ca o variabil, dar i ca o funcie de alte variabile din sistem

nu exist constructori i destructori nu exist suprancrcarea bazat pe semntura operaiilor

semntura const din specificarea parametrilor i a rezultatului specificarea excepiilor i a tipului datelor care se asociaz excepiilor specificarea informaiei suplimentare de context, care poate afecta cererile specificarea semanticii operaiei, aa cum apare ea clientului

nu exist tipuri parametrice nu exist ierarhii de excepii aspecte semantice nu sunt incluse n interfee

domenii de valori pentru date ordonarea legal a operaiilor constrngeri de timp/spaiu asupra implementrilor garanii tranzacionale ale interfeei

n particular, menionm diferenele fa de C++: nu exist tipurile int, unsigned int char nu poate fi signed sau unsigned parametrii

trebuie sa aib nume trebuie s aib direcie nu pot fi opionali nu pot avea valori explicite

specificarea tipului rezultatului este obligatorie nu exist structuri i uniuni anonime nu exist pointeri nu se poate face suprancrcarea operatorilor

2.7. Corespondena ntre IDL i C++ Corespondena ntre IDL i C++ este definit de standardul CORBA. Ea se refer la modul n care definiiile IDL sunt traduse n C++ i la regulile pe care clienii i serverele C++ trebuie s le respecte la utilizarea, respectiv implementarea interfeelor.

2.7.1. Tipuri de baz Corespondenele sunt prezentate n tabelul 2.1.

IDL C++ typedefs corespondena n Orbix

pentru 32 de bii short CORBA::Short short, dac 16 bii long CORBA::Long long, dac 32 de bii unsigned short CORBA::UShort unsigned short unsigned long CORBA::ULong unsigned long float CORBA::Float float double CORBA::Double double char CORBA::Char char, dac 8 bii boolean CORBA::Boolean unsigned char octet CORBA::Octet unsigned char, dac 8 bii

Tabel 2.1. Corespondena IDL - C++ pentru tipurile de baz Observaii. ntre IDL i tipurile C++ se foosete un nivel intermediar, deoarece limbajul C++ nu definete

detalii despre cerinele de memorie ale multor tipuri (de exemplu, faptul c short ocup 16 bii), n timp ce IDL cere aceste detalii pentru ca aplicaiile s poat inter-opera pe maini diferite. Corespondena ntre IDL i C++ folosete deci typedefs, cum e CORBA::Short, urmnd ca implementarea ORB pe fiecare platform s asigure corespondena corect.

Definiiile de tipuri sunt puse ntr-o clas C++ sau ntr-un namespace (cu numele CORBA). Pentru boolean s-a ales n Orbix unsigned char i nu bool din ANSI C++ pentru c ANSI nu e o

cerin pentru CORBA n acest moment. Regula de transmiterea parametrilor prntru tipurile de baz este simpl: parametrii in i rezultatele se transmit prin valoare parametrii out i inout se transmit prin referin (&)

2.7.2. Module Modulele IDL sunt mapate pe namespace n C++ (o tratare special este necesar cnd compilatorul nu suport namespace). De exemplu: module M{ typedef float money; interface I{... } }; se traduce prin: namespace M{ typedef CORBA::Float money; class I: public virtual CORBA::Object{... }; };

2.7.3. Interfee O interfa IDL este pus n coresponden cu o clas C++. Fiecare operaie este mapat pe o funcie-membr. Un atribut este mapat pe dou funcii (de citire i de modificare a valorii). Un atribut readonly este mapat pe o funcie de citire a valorii. De exemplu:

interface T{ attribute long l; readonly attribute char c; void op1(); }; se mapeaz n C++ pe class T: public virtual CORBA::Object{ CORBA::Long l() //get throw (CORBA::SystemException); void l (CORBA::Long) //modify throw (CORBA::SystemException); CORBA::Char c() //get throw (CORBA::SystemException); virtual void op1() throw (CORBA::SystemException); }; Clasa T motenete din CORBA::Object care este clasa rdcin pentru toate obiectele CORBA. Tipul (referin) CORBA::Objectptr sau CORBA::Objectvar corespunde referinei oricrui obiect CORBA.

2.7.4. Referine la obiecte n C++, referinele la obiecte de un tip obT au tipul obT_ptr sau obT_var. O variabil de tip obT_ptr se compoirt ca un pointer normal, deci referinele la obiect pot fi invocate cu operatorul ->. Utilizarea acestui tip (_ptr) reclam gestiunea explicit a contorului de referine asociat fiecrui obiect CORBA. Contorul de referine se pstreaz local, separat pentru obiectul int (din server) i separat pentru reprezentantul su (proxy) din client.

Figura 2.2. Referine la obiecte Contorul de referine trebuie incrementat la crearea unei noi referine la obiect i decrementat la tergerea referinei: obT_ptr p1=...; { obT_ptr p2; p2 = obT::_duplicate(p1); //incrementeaza contorul ... //poate folosi p2 CORBA::release (p2); //decrementeaza contorul

Referin la obiect Referin la obiect

Referin la obiect

Proxy Contor refer.=2

int Contor refer.=1

Client Server

} // foloseste apoi p1 CORBA::release(p1) Gestiunea contorului de referine este automat n cazul tipului _var, considerat ca un pointer inteligent. De exemplu: obT_var p1=...; { obT_var p2; p2=p1; //incrementeaz automat contorul ... //poate folosi p2 } ...// fooseste p1, apoi decrementeaza automat contorul cand p1 iese //din domeniul de valabilitate

3. CORBA static CORBA ORB suport dou tipuri de apeluri client/server: statice i dinamice. n ambele cazuri, clientul execut o cerere atunci cnd are acces la o referin a obiectului i specific metoda care corespunde serviciului. Serverul nu poate face diferenierea ntre invocrile statice i dinamice. Ne referim aici la prima form.

Figura 3.1. CORBA Static

Clienii vd interfeele obiectelor prin perspectiva corespondenei ntre limbajul de implementare i IDL. Interfeele statice sunt generate direct, n forma unor stub-uri client, de precompilatoare IDL. Ele au unele avantaje: programare mai uoar verificri mai robuste de tipuri execuie simpl autodocumentare n schimb nu sunt la fel de flexibile ca apelurile dinamice.

1. Creare definiii IDL

Skeleton-uri

3. Adugare cod de implementare

5. Interface Repository

Client IDL Stubs

Server IDL Skeleton

Implementri Object

Client Server

7. Object Adapter

6. Implementation Repository

instaniere

Precompilare

4. Compilare

3.1. Etapele de dezvoltare a aplicaiei Figura 3.1 arat paii necesari pentru crearea unui server i a unui client care comunic prin ORB. Figura se refer la cazul general, nu neaprat la varianta static.

1. Se definesc interfee n IDL; acestea precizeaz ce operaii sunt disponibile la un server i cum pot fi invocate.

2. Pe baza descrierii IDL, un precompilator produce skeleton-uri (pentru server) i stub-uri (pentru clieni). Cnd clientul i obiectul int sunt n acelai spaiu de adrese, comunicarea lor se poate face direct, nefiind necesar un cod suplimentar. Cnd acetia sunt n spaii diferite, este necesar un cod suplimentar la client (stub) pentru transmiterea invocrilor, i la obiectul int (skeleton), pentru recepia lor i transmiterea lor ctre obiectul int.

3. Se adaug codul care implementeaz serverul. 4. Se face compilarea codului. Un compilator care accept CORBA este, n mod obinuit, capabil

s genereze cel puin trei fiiere: a. Fiiere import care descriu obiectele pentru Interface Repository b. Stub-uri client pentru metodele definite n IDL; ele sunt invocate de clieni pentru

acces la server c. Skeleton-uri server care apeleaz metodele serverului (mai sunt numite up-call

interfaces). 5. Leag definiiile de interfee de InterfaceRepository (se folosete un utilizator). Informaia din

IR este accesibil clienilor la execuie.

6. Adaptorul de obiecte nregistreaz n Implementation Repository tipul i referina oricrui obiect ce poate fi instaniat pe server. ORB folosete aceste informaii pentru a localiza obiectele active sau s cear activarea unor obiecte.

7. Instanierea obiectelor pe server cerut de object adapter conform unei anumite strategii.

La aceste etape se adaug operaiile legate de client, la care ne referim n exemplul care urmeaz.

Paii de programare ce corespund dezvoltrii unei aplicaii client-server n CORBA i C++, n varianta static, sunt urmtorii: descrierea interfeelor n IDL implementarea interefeelor n C++ scrierea funciei principale a serverului, care creaz instane ale claselor, informeaz apoi

broker-ul i adaptorul c au fost fcute iniializrile i c obiectele int sunt gata s primeasc cereri

scrierea clientului care se conecteaz la server i folosete serviciile acestuia. 3.2. Specificarea unei aplicaii elementare

Descrierea care urmeaz se refer la VisiBroker for C++ (produs de Visigenic), dar ea corespunde, cu mici modifcri i altor implementri CORBA 2.0 (vezi Mico de la Universitatea Frankfurt, Germania).

Programul Count folosit aici ca exemplu este o aplicaie rudimentar client/server. Serverul suport o singur metod numit increment, care incrementeaz valoarea unei variabile numit sum i ntoarce clientului valoarea acesteia.

CountAttributes:sum

O Increment

Figura 3.2. Serverul

Sum este declarat ca un atribut read/write. Ca urmare, valoarea sa este accesibil prin funcii predefinite. Clienii folosesc aceste funcii pentru a stabili valoarea iniial pentru sum i pentru a gsi valoarea final.

Clientul trebuie s fac urmtoarele operaii: S stabileasc valoarea iniial a atributului sum S invoce metoda increment de 1000 de ori S afieze valoarea final a atributului sum, mpreun cu timpul de rspuns mediu.

Clientul trebuie s poat trata excepiile de sistem CORBA.

Primul pas este definirea n IDL a interfeei serverului. Fiierul count.idl conine aceast descriere: module Counter { interface Count { attribute long sum; long increment(); }; };

3.3. Compilarea interfeei n plus fa de generarea tipurilor n limbajul de programare dorit, un compilator IDL genereaz stub-uri client i skelton-uri server. Stub-ul este un mecanism care creeaz efectiv i genereaz cereri n numele clientului. Skeleton-ul este un mecanism care livreaz cererile ctre implementarea obiectului. Deoarece sunt obinute direct din interfaa IDL, ambele sunt (n mod natural) specifice interfeei. O invocare de operaie asupra unui obiect int se prezint n C++ n forma apelului unei funcii membre a unei clase. Acest apel invoc un stub. Deoarece stub-ul este un reprezentant local al unui obiect int (posibil) distant, el se mai numete intermediar (proxy) sau surogat. Stub-ul lucreaz direct cu ORB pentru a aranja (marshal) cererea, adic pentru a converti de la forma proprie limbajului de programare la una potrivit pentru transmitere prin magistrala de obiecte, ctre int.

Odat ajuns la int, ORB i skeleton-ul coopereaz pentru a re-aranja (unmarshal) cererea, deci pentru a o converti de la forma transmisibil la forma unui limbaj de programare. ndat ce obiectul termin cererea, rspunsul este transmis pe calea invers: prin skeleton, ORB-ul serverului, conexiune, ORB-ul clientului, stub, aplicaie client.

Compilatorul VisiBroker pentru C++ (numit Orbeline) produce patru fiiere, pe baza descrierii precedente (vezi Figura 3.3).

Observaie. MICO produce dou fiiere, care reunesc coninutul celor patru menionate aici. Count.idl

Count_c.hh Count_c.cppstub

Count_s.hh Count_s.cppskeleton

Precompilare IDL -> C++ Orbeline

Figura 3.3. Fiiere produse de compilatorul Orbeline

count_s.cpp este skeleton-ul server pentru metodele clasei count. Acesta reprezint codul care se re-aranjeaz (unmarshals) apelurile pentru obiectul Count i invoc implementarea obiectului.

count_s.hh este fiierul antet pentru server, care include definiiile de clase pentru skeleton-ul implementat n count_s.cpp.

count_c.cpp conine o clas numita Count care servete ca intermediar (proxy) al clientului pentru obiectul Count. El conine funcii stub i de aranjare (marshaling) pentru toate metodele definite n interfaa Count. n plus, implementeaz o metod bind care ajut clientul s localizeze serverul Count.

count_c.hh este fiierul antet pentru client, care include declaraiile i definiiile de clase pentru stub-ul implementat n count_c.cpp.

Cele patru fiiere generate de compilatorul IDL conin n cea mai mare parte funcii private ale VisiBroker-ului. Ele nu trebuie modificate de programator. Cu toate acestea, programatorul trebuie s inspecteze count_s.hh, unde gsete declaraiile funciilor virtuale abstracte ale interfeei Count. (O soluie mai bun ar fi fost ca declaraiile de funcii ce trebuie implementate de programator s fie furnizate ntr-un fiier separat, aa cum VisiBroker face pentru Java). Partea care intereseaz pentru implementarea serverului are urmtorul aspect: Class _sk_Counter // corespunde modulului Counter modelat aici ca o clasa { public: class _sk_Count: public Counter::Count // corespunde interfetei Count

{ virtual CORBA::long sum() = 0; //citeste atribut virtual void sum (CORBA::long val) = 0; //scrie atribut virtual CORBA::long increment() = 0; //op. incrementare

//alte operatii skeleton implementate automat . . . };

};

3.4. Implementarea obiectului server Orice server CORBA trebuie s aib un program principal care iniializeaz mediul ORB i pornete obiectele. n plus, serverul trebuie s prevad i implementri ale interfeelor CORBA care sunt definite n IDL. n acest exemplu, trebuie implementat o singur interfa, Counter.Count. Scriem o clas C++ numita CountImpl pentru a implementa aceast interfa. Implementarea clasei CountImpl se deriveaz din clasa skeleton corespunztoare. n acest fel, clasa server motenete funcionalitatea modelului obiectelor CORBA. De asemenea, astfel clasa server obine funciile skeleton ce permit ORB s invoce automat metodele obiectului (up-calls). Sarcina este, deci, s se implementeze CountImpl i funcia main pentru server. // countimpl.h definiia clasei pentru implementarea lui Count // VisiBroker pentru C++ # include class CountImpl:public _sk_Counter:: _sk_Count { private: long _sum; public: CountImpl (const char * object_name=NULL); CORBA::long sum(); void sum(CORBA::long val); CORBA::long increment(); };

Definiia clasei CountImpl este realizat pornind de la codul generat de compilatorul IDL, la care s-a adugat un constructor al clasei. Ca de obicei, clasa este derivat din skeleton-ul su, _sk_Count.

n ce privete implementarea CountImpl, ea are urmtoarea descriere: // countimpl.cpp Count Implementation, VisiBroker pentru C++ # include "countimp.h" // Constructor CountImpl::CountImpl (const char *object_name) :_sk_Counter :: _sk_Count (object_name) { cout_sum++; return this->_sum; }

Constructorul CountImpl apeleaz printele (skeleton-ul) pentru a crea un obiect cu nume. Fiecare instan a clasei CountImpl va avea un nume persistent. Dac se invoc superclasa fr argument, atunci el va crea un obiect anonim (sau tranzitoriu).

3.5. Implementarea serverului nainte de a continua implementarea serverului, s ne referim la un alt element CORBA care intervine n realizarea apelurilor de operaii. Este vorba de adaptoarele de obiecte, Object Adapters. Rolul lor este multiplu: nregistrarea obiectelor OA include operaii care permit unor entiti de limbaj de

programare s se nregistreze ca implementri de obiecte CORBA.

Generarea referinelor de obiecte CORBA Activarea procesului server dac este necesar, OA pornete procesele server n care pot fi

activate obiectele

Activarea obiectelor OA activeaz obiectele, dac ele nu sunt deja active la sosirea cererilor. Demultiplexarea cererilor OA coopereaz cu ORB pentru a asigura ca cererile pot fi primite

prin conexiuni multiple, fr blocare nesfrit a vreunei conexiuni

Apeluri de obiecte (object upcalls) - OA distribuie cererile ctre obiectele nregistrate. n mod normal, un OA este necesar pentru fiecare limbaj de programare. De exemplu, un obiect implementat in C s-ar nregistra n OS furniznd un pointer de struct care s in starea obiectelor i pointerii de funcii corespunztoare operaiilor obiectului, aa cum sunt definite de interfeele IDL. Pentru C++, o implementare de obiect poate fi derivat dintr-o clas de baz standard care include interfaa pentru apelurile de operaii.

n consecin, CORBA admite mai multe adaptoare dar actualmente prevede una: Basic Object Adapter (BOA). Credina iniial a fost c un singur BOA ar fi suficient. Pentru a suporta mai multe limbaje de programare, specificaia acestuia a fost pstrat la un nivel destul de vag n anumite privine, cum ar fi i aceea a nregistrrii obiectelor. Aceasta a generat probleme de portabilitate a

implementrii BOA, fiecare furnizor de ORB completnd prile absente cu soluii proprii. Problema portabilitii BOA este nc n studiul OMG.

Urmeaz elaborarea programului principal server.cpp. // server.cpp Count server, VisiBroker pentru C++ # include countimp.h int main (int argc, char * const * argv) { try { // initializare ORB CORBA::ORB_ptr orb = CORBA::ORB_init(argc, argv); // init BOA CORBA:: BOA_ptr boa = orb->BOA_init(argc, argv); // creeaz obiect Count Counter::Count_ptr count = new CountImpl (MyCount); // export noul obiect nregistreaz cu BOA boa->obj_is_ready (count); // gata s serveasc cererile boa->impl_is_ready(); } catch (const CORBA::Exception& e) { cerr

Figura 3.4. Aciunile programului server

Dup cum se vede, referinele la obiecte CORBA se pun n coresponden cu tipuri-pointeri n C++: CORBA::ORB_ptr, CORBA::BOA_ptr. Acestea au semantica unor pointeri C++, ceea ce nseamn (printre altele) c programatorul trebuie s includ n program un CORBA::release() explicit pentru a elibera obiectul.

O alt form de referin este _var, ca n CORBA::ORB_var, care elibereaz automat memoria obiectului referit atunci cnd referina este distrus sau folosit pentru un alt obiect.

n alt ordine de idei, este de remarcat modul de tratare a excepiilor n CORBA. Ea se bazeaz pe mecanismul try-throw-catch. Aa cum se arat i n exemplu, tratarea excepiilor este o parte generic a programrii client/server, fiind reprezentat n program prin perechea try-catch.

Instruciunea try are semnificaia ncearc aceste instruciuni i vezi dac obii o eroare. Ea trebuie urmat de o clauz catch care spune voi trata orice eroare care corespunde argumentului meu. O excepie IDL este tradus printr-o clas C++. n exemplul dat, producerea unei excepii de sistem determin afiarea ei i oprirea programului. Operatorul

# include # include # include # include # include struct timeb timebuff; double startTime, stopTime; int main (int argc, char * const* argv) { try

{ cout

Client.cpp

Countproxy

counter CountImplCORBA API

ORB_init

_bind

Sum(0)

Sum(0)

increment

Start timer

increment

Stop TimerPrint

results

de 1000 de ori

client server

new

Figura 3.5. Aciunile programului client

Funcia membru Count::_bind() cere ORB s caute un obiect care ofer interfaa Count. Parametrul MyCount este o informaie suplimentar pentru ORB, care indic numele (sau marker-ul) obiectului cutat. Marca este parte a referinei obiectului i este un nume unic n cadrul serverului. Dac un server creaz mai multe obiecte Count, el trebuie s dea un nume distinct fiecruia. Ca alternativ, asocierea mrcilor cu obiectele poate fi lsat n seama ORB, aplicaia avnd posibilitatea s modifice mrcile ulteriror crerii obiectelor. Prin specificarea mrcii, clientul opteaz pentru un anumit obiect Count, n situaia n care exist mai multe astfel de obiecte ntr-un server (nu este cazul aplicaiei de fa). n acest caz, legarea se face la un obiect din afara spaiului de adrese al apelantului. Ca urmare, ORB va construi un proxy pentru acest obiect n spaiul de adrese al clientului. Funcia _bind() ntoarce o referin la obiectul proxy. n exemplul dat, referina este asignat unei variabile de tip Count_var (care gestioneaz memoria pentru proxy). Apelul lui _bind() nu este singura cale prin care un client poate obine referina unui obiect cu care s comunice. Alte soluii sunt: serverul poate nregistra obiectul cu Naming Service, asociindu-i un nume; clientul care cunoate

numele poate cere referina obiectului de la Naming Service; un client poate primi o referin de obiect ca rezultat sau ca parmetru out al unui apel de operaie

IDL; aceasta va nsemna totodat crearea unui proxy n spaiul de adrese al clientului.

4. CORBA dinamic Exemplele date pn n prezent folosesc invocarea static a serviciilor prin intermediul stub-urilor i skeleton-urilor precompilate. Un client necesit un stub pentru fiecare interfa pe care o folosete. Aceast cerin devine limitativ n cazul Internetului, unde clienii pot apela, teoretic, la milioane de obiecte din reea i unde apar frecvent noi servicii i interfee.

Un alt exemplu unde soluia este limitativ este cel al unei pori (gateway) ntre dou sisteme de obiecte diferite: CORBA i un sistem strin. Atunci cnd primete o invocare de la un sistem strin de obiecte, poarta trebuie s o converteasc ntr-o cerere ctre obiectul CORBA solicitat. Recompilarea programului porii odat cu adugarea fiecrui nou obiect este o soluie complet nepractic. Din fericire, CORBA suport dou interfee pentru invocri dinamice:

Dynamic Invocation Interface (DII) pentru invocrile dinamice de cereri ale clienilor i Dynamic Skeleton Interface (DSI) care realizeaz dispecerizrile dinamice ctre obiecte.

DII i DSI pot fi vzute ca stub-uri si skeleton-uri generice. Fiecare este o interfa prevzut direct de ORB i independent de interfeele OMG IDL ale obiectelor invocate.

Cu DII, un client poate invoca orice operaie, a oricrui obiect, fr a avea nevoie de informaii despre acestea la momentul compilrii. Informaiile necesare sunt descoperite n momentul invocrii.

4.1. Construirea unei invocri dinamice Cum descoper clienii obiectele distante? Sunt posibile mai multe mecanisme. n cea mai simpl abordare, clientului i se poate da o referin de obiect, convertit n ir de

caractere. Referinele de obiecte n mediile CORBA sunt robuste, n sensul c ele pot fi memorate persistent ntr-un fiier, n forma de ir de caractere. (stringified object reference). Referinele pot fi regsite ulterior i pot fi folosite pentru invocarea obiectelor, cu condiia ca acestea s mai existe. ORB garanteaz c referinele rmn valide, chiar dac se produc erori de reea ce conduc la pierderea comunicaiei cu obiectele, caz n care ORB va realiza automat refacerea legturii. Clientul face conversia de la ir la referin de obiect folosind una din metodele interfeei ORB (string-to-object) i realizeaz apoi invocri ale obiectului.

Clienii pot cuta obiectele dup nume, folosind Naming Service. n fine, pot afla obiectele dup atribute, folosind Trader Service. La acestea adugm posibilitatea ca un client s obin o referin de obiect ca rezultat sau

parametru out al unei invocri anterioare.

Odat dispunnd de referina obiectului, clientul o poate folosi pentru a regsi interfaa obiectului i a realiza construcia dinamic a cererii. n cerere, trebuie specificat metoda invocat i parametrii corespunztori. Aceste informaii sunt obinute uzuala din depozitul de interfee Interface Repository (IR). n consecin, construcia dinamic a unei invocri reclam etapele descrise n continuare.

(1) Obinerea numelui interfeei.

Odat ce dispunem de o referin la obiectul server, putem cere acestuia numele interfeei sale. Pentru asta se invoc metoda get_interface (figura 4.1). Acest apel ntoarce o referin la un obiect InterfaceDef din IR, care descrie interfaa necesar clientului. (2) Obinerea descrierii metodei, din IR.

Putem folosi InterfaceDef ca un punct de intrare pentru navigarea n Interface Repository, IR. Putem obine astfel o mulime de detalii despre interfa i despre metodele sale. CORBA specific aproape zece apeluri pentru inspectarea IR. De exemplu, clientul poate apela lookup_name pentru a gsi metoda pe care vrea s o invoce (de fapt o referin la un obiect OperationDef care descrie operaia), iar apoi describe pentru a obine definiia IDL complet a metodei. Ca alternativ, se poate apela describe_interface pentru a obine o definiie complet a interfeei i pentru a gsi metoda care trebuie invocat.

(3) Crearea listei de argumente.

(3a) CORBA specific o structur de date autodefinit pentru transmiterea parametrilor, anume Named Value List. Pentru implementarea acestei liste se folosete un pseudo-obiect NVList. Pentru crearea listei se invoc create_list i apoi add_item, n mod repetat, pentru a aduga listei fiecare argument. (3b) Ca alternativ, clientul poate invoca create_operation_list pe un obiect CORBA::ORB, ca urmare a creia lista este creat de ORB. Acestei metode trebuie s i se dea numele operaiei pentru care trebuie creat lista de argumente.

(4) Crearea cererii.

O cerere este un pseudo-obiect CORBA care conine numele metodei, lista de argumente i valoarea returnat ca rezultat.

(4a) Pentru aceasta se invoc create_request, creia i se transmite numele metodei, NVList i un pointer la valoarea returnat.

Figura 4.1. Construuirea unui apel dinamic

(4b) Ca alternativ, se poate crea o versiune scurt a cererii, apelnd request, creia i se paseaz doar numele metodei. Soluia se folosete pentru metodele fr parametri.

(5) Invocarea cererii.

Invocarea cererii se poate face printr-una din urmtoarele trei metode: Apelnd invoke; se transmite cererea i clientul se blocheaz pn se obin rezultatele; aceast

form se numete invocare sincron

Apelnd send_deferred; clientul invoc cererea i continu prelucrarea n timp ce cererea i continu prelucrarea n timp ce cererea este dat serverului i tratat; clientul trebuie s colecteze ulterior rspunsul apelnd poll_response sau get_response; aceast form se numete invocare sincron amnat.

Clientul invoc cererea i continu apoi prelucrarea; nu exist rspuns, deci apelul este definit ca o datagram; pentru asta se apeleaz send_oneway.

4.2. Interfeele de invocare dinamic Pentru invocarea dinamic a metodelor se folosesc servicii din nucleul CORBA. Serviciile sunt dispersate n patru interfee din modulul CORBA:

CORBA::Object. Este o interfa de pseudo-obiect care definete operaiile ce trebuie suportate de orice obiect CORBA. Aceste operaii sunt executate de ORB i sunt motenite la crearea unui obiect. Interfaa include trei metode folosite n invocarea dinamic: get_interface - obine o referin la un obiect din IR care descrie interfaa create_request - creaz un obiect Request _request - creaz o versiune "scurt" a cererii

CORBA::Request este o interfa de pseudo-obiect care definete operaiile asupra unui obiect distant. Sunt incluse aic:

client Object InterfaceDef OperationDef

get_interface

Lookup_name

describe

delete

Request

ORB

NVList add_item

add_value

create_request

invoke

create_list

free

add_arg - adaug un argument cererii invoke - apel sincron send_oneway - apel datagram send_deffered - apel sincron ntrziat get_response - ateapt rspunsul poll_response - testeaz sosirea rspunsului delete - terge obiectul Request din memorie

CORBA::NVList este o interfa de pseudo-obiect care faciliteaz construirea listei de parametri: add_item - adaug un parametru add_value - seteaz valoarea parametrului get_count - afl numrul total de parametri alocai n list remove - terge un element din list free - terge structura de list free_memory - elibereaz memoria alocat dinamic argumentelor out

CORBA::ORB este o interfa de pseudo-obiect ce definete metode ORB generale. ase metode sunt specifice construciei dinamice a cererilor: create_list - creaz o list vid ce urmeaz a fi populat create_operation_list - creaz o list iniializat de ORB send_multiple_requests_oneway - trimite cereri datagram multiple send_multiple_requests_deferred - trimite cereri ntrziate multiple poll_next_response - tesetaz urmtorul rspuns get_reset_response - ateapt urmtorul rspuns

n afara acestor interfee, pentru a construi o invocare se mai folosesc obiecte din Interface Repository.

4.3. Dynamic Skeleton Interface Analogul DII de partea serverului este DSI. Aa cum DII permite clienilor s invoce cereri, fr a fi necesare stub-uri statice, DSI permit ca serverele s fie scrise fr a avea skeleton-uri compilate static n program.

Pentru aceasta, serverul poate defini o funcie care va fi informat de orice invocare de operaie sau atribut i care: determin identitatea obiectului invocat determin numele operaiei, tipurile i valorile argumentelor ndeplinete aciunea cerut de client construiete i ntoarce rezultatul.

Principala sa utilizare este construcia porilor (gateways) ntre sisteme de obiecte CORBA i non-CORBA. Iniial, DSI a fost gndit pentru a fi utilizat n porile dintre diferite ORB se folosesc protocoale diferite. Odat cu adaptarea IIOP aceast funcie s-a dovedit inutil.

5. Iniializarea S ne reamintim din exemplul de invocare static a metodelor de obiecte-server c n CORBA 2.0 sunt definite metode de iniializare pe care orice ORB trebuie s le furnizeze pentru a permite unui obiect s se integreze ntr-un mediu distribuit. Aceste metode sunt implementate de pseudo-obiectul CORBA::ORB.

Un pseudo_obiect este un obiect creat direct de ORB, dar care poate fi invocat ca oricare alt obiect. ORB nsui este un pseudo-obiect.

Trei metode sunt specifice iniializrii unui obiect i sunt disponibile dup execuia unui apel ORB_init: BOA_init list_initial_services resolve_initial_references

Un scenariu posibil de iniializare include urmtoarele faze: Obinerea unei referine de obiect pentru propriul ORB. Apelul CORBA API, ORB_init permite

unui obiect s informeze ORB despre existena sa i s obin o referin la un pseudo-obiect ORB. De accentuat c ORB_init este un apel API i nu o invocare de metod.

Obinerea unui pointer la BOA. Invocarea metodei BOA_init pe obiectul ORB permite obiectului s informeze adaptorul despre

existena sa i s obin referina pseudo-obiectului BOA.

Descoperirea serviciilor iniiale disponibile. Invocarea metodei list_initial_services pe pseudo-obiectul ORB permite obinerea unei liste cu

numele obiectelor cunoscute, ca de exemplu, Interface Repository, Trader Service si Naming Service. Acestea sunt returnate ca o list de referine convertite la iruri de caractere.

Obinerea referinelor de obiecte pentru serviciile dorite. Prin invocarea metodei resove_initial_references se obin referinele de obiecte pentru serviciile dorite, din referinele convertite la iruri de caractere.

Serviciul de iniializare este un fel de Naming Service elementar. El permite obinerea unei liste de servicii binecunoscute: Naming Service, Trading Service, precum i alte servicii de navigare, cutare, ageni, etc. Utilizarea acestora permite gsirea altor obiecte din universul ORB.

5.1. Serviciul de nume (Naming Service) Naming Service pstreaz p baz de date de legturi (bindings) ntre nume i referine de obiecte. Serviciul are operaii pentru: rezolvarea unui nume crearea, tergerea, listarea unor legturi.

Un nume este o secven IDL de componente de nume. O component este o structur de dou iruri: primul este numele componentei; al doilea este un atribut care nu este interpretat de Naming Service, fiind destinat utilizrii de ctre aplicaie. De exemplu, el poate preciza c numele trebuie interpretat ca numele unui catalog, sau al unui disc.

Fiecare component, cu excepia ultimeia, definete un NamingContext (similar unui director ntr-un sistem de fiiere). Aceasta confer sistemului de nume o structur ierarhic ce ordoneaz cutarea pentru rezolvarea numelor: prima component d numele unui context n care se caut al doilea nume; procesul continu pn la ultima component.

5.2. Serviciul de Trading Fa de aceast funcionare simpl, un Trader este mult mai complex. Oricum, i funcia sa este mai complex, Trader-ul permind cutarea obiectului cel mai potrivit ntr-un set larg de obiecte similare.

Cum funcioneaz un serviciu Trader? Exportatorii sau furnizorii de servicii anun Trader-ul despre serviciile oferite. Importatorii sau consumatorii de servicii folosesc Trader-ul pentru a gsi serviciile care satisfac nevoile lor.

Figura 5.1. Funcionarea unui Trader

Mai nti, un nou furnizor de servicii nregistreaz serviciile la trader, cruia i furnizeaz urmtoarele informaii relevante: O referin de obiect pe care clienii o vor folosi pentru a se conecta la serviciu i a invoca

operaiile. Ea reprezint referina de obiect a interfeei care furnizeaz serviciul.

Tipul serviciului care include informaii asupra numelor operaiilor (sau metodelor) apelabile mpreun cu tipurile parametrilor i rezultatului.

Propritile serviciului care sunt perechi nume-valoare care definesc oferta. Ele descriu capabilitile serviciului i se plaseaz n dou categorii: obligatorii i opionale.

Trader-ul pstreaz un depozit de tipuri de servicii. Putem avea, de exemplu, un tip restaurant, pentru care proprietile serviciului pot fi: meniul, specialitile, adresa, numrul de locuri, orarul, etc.

Trader-ul pstreaz descrierile n ServiceTypeRepository. Totodat, pstreaz o baz de date de obiecte server, care sunt instane ale acestor tipuri. Clienii pot intra n contact cu Trader-ul cerndu-i s gseasc serviciile care se potrivesc cel mai bine unui anumit set de cerine. Un serviciu care ar corespunde cererii trebuie s aib un tip care se potrivete cu cererea clientului i proprietile care satisfac criteriile impuse de client.

Descrierea criteriilor se face ntr-un limbaj de constrngeri ce precizeaz: tipurile de proprieti ce pot apare n cosntrngeri (de exemplu, ntregi, reali, char etc.) operatorii admii (comparaii, apartenena la o secven, existena unei proprieti etc.)

Clientul poate preciza preferinele asupra ordinii n care trader-ul ar trebui s furnizeze ofertele care se potrivesc cererii (de exemplu, mai nti oferta care are un anumit parametru, sau o valoare maxim pentru un parametru, sau o ordine oarecare, sau ordinea n care ofertele sunt gsite de trader). Clientul poate specifica i o politic pe care s o urmeze trader-ul i care fixeaz elemente ca numruil maxim de oferte furnizate sau amploarea cutrii.

Trader-i din domenii diferite pot crea federaii. Un Trader poate oferi serviciile de care rspunde, dar i servicii ale trader-ilor cu care este n federaie.

n scenariul prezentat n continuare intervin urmtoarele interefe: Lookup - permite clienilor i trader-ilor s descopere i s importe servicii; are o singur

operaie, query;

Register - folosit de furnizorii de servicii pentru a anuna serviciile lor; ServiceTypeRepository - depozitul tipurilor de servicii.

Scenariul cuprinde urmtoarele etape: 1. serverul creaz un nou tip de serviciu cu add_type 2. serverul avertizeaz Trader-ul despre serviciul su, invocnd export; el comunic numele

tipului de serviciu, referina de obiect care va servi cererea, valorile parametrilor.

Trader

Client Importator

Server Exportator

1-Export serviciul

3-Invoc serviciul

ORB

ORB

ORB

2-Importserviciul

3. clientul obine o list de tipuri de seervicii existente n depozit (list_types) 4. clientul obine descrierea unui anumit tip (describe_type); descrierea include parametrii tipului

i interfaa de obiect

5. clientul invoc query pentru a obine o list a obiectelor care pot furniza acest serviciu 6. clientul invoc serviciul.

Figura 5.2. Scenariu de funcionare a serviciului Trading

6. Activarea obiectelor n exemplul dat, la discutarea invocrii statice a seviciilor, obiectele count trebuiau pornite manual nainte de a servi cererile clienilor. Cu excepia cazului crerii unui nou obiect, care este implicit pornit de CORBA, standardul nu prevede o comand explicit de pornire a unui obiect server. Filozofia CORBA este de a pstra clientul ct mai simplu: acesta trebuie s vad obiectele server ca fiind ntotdeauna pregtite s accepte invocrile operaiilor lor. Ca urmare, ORB trebuie s fie capabil s porneasc n avans un obiect sau s-l porneasc la cerere, atunci cnd un client invoc obiectul. Aceasta presupune c serverului i se adaug o parte de cod care coopereaz cu ORB la pornirea sau oprirea lor.

n principiu, interfaa CORBA::BOA este folosit pentru a crea i distruge referine de obiecte i pentru a afla ori actualiza informaia pe care BOA o pstreaz despre referinele la obiecte. BOA pstreaz evidena obiectelor active i a implementrilor pe care le controleaz. Interfaa BOA este folosit pentru a avea acces la aceast eviden, pentru a afla sau aduga informaii despre obiecte. Iat o scurt descriere a metodelor CORBA::BOA. create este invocat pentru a descrie implementarea unei noi instane de obiect i a obine o

referin de obiect pentru ea. ORB i se paseaz mai multe informaii:

un nume de interfa care este descris n Interface Repository un nume de implementare care este descris n Implementation Repository un identificator unic (nu este folosit de ORB ci este specific implementrii i permite

diferenierea obiectelor sau specificarea unor identificatori persisteni Persistent ID).

change_implementation permite actualizarea implementrii asociate cu un obiect existent. get_id permite obinerea identificatorului asociat cu obiectul. dispose distruge referina obiectului. Separat trebuie distruse resursele obiectului.

client Lookup Register ServiceTypeRepository server

add_type

export list_type

describe_type

query invoke_method

Trader

Exist i alte metode care permit activarea i dezactivarea implementrilor i a obiectelor care ruleaz n aceste implementri. CORBA cere ca urmtoarele funcii s fie disponibile ntr-o implementare BOA: Un Implementation Repository care permite instalarea i nregistrarea implementrii unui obiect Mecanisme pentru generarea i interpretarea referinelor de obiecte, activarea i dezactivarea

implementrilor de obiecte, invocarea metodelor i pasarea parametrilor.

Activarea i dezactivarea obiectelor implementrii Invocarea metodelor prin skeleton.

CORBA face o distincie clar ntre un server i obiectele sale. Un server este un proces, o unitate de execuie. Un obiect implementeaz o interfa. Un server poate conine unul sau mai multe obiecte, eventual de clase diferite. La cealalt extrem se afl un server care conine codul pentru implementarea unei singure metode. n toate cazurile, obiectele sunt activate n serverele lor. CORBA definete patru politici de activare: server partajat (shared server), server ne-partajat, server-per-metod i server persistent.

6.1. Server partajat Toate obiectele cu acelai nume de server rezid n acelai proces. BOA activeaz serverul la prima invocare de metod a unuia din aceste obiecte. Dup ce serverul s-a iniializat, el anun BOA c poate prelucra cereri prin apelul impl_is_ready. Toate cererile ulterioare (de metode ale obiectelor acestui server) sunt livrate acestui proces. BOA nu activeaz un alt proces server pentru aceast implementare. (Cnd un alt client execut un obiect, legarea se face la aceeai copie de server).

Figura 6.1. Server partajat

n detaliu, lucrurile se petrec dup scenariul urmtor:

1) Serverul creeaz instane de obiecte, fie prin invocarea unei fabrici de obiecte CORBA, fie printr-un constructor (Java, C++, )

2) Noile obiecte se nregistreaz n BOA. Dac obiectul este nou, el invoc BOA::create care ntoarce o referin de obiect. Aceast referin este folosit ntr-un apel BOA::Object_is_ready, anuntnd OBJ c obiectul este pregtit. Dac obiectul exist deja, el are starea nregistrat undeva ntr-o memorie permanent. Folosind referina la obiect (care exist deja!) se poate obine identificatorul unic (get_id) i apoi PersistentID asociat cu obiectul. Pe baza acestuia se regsete i ncarc starea obiectului. Obiectul invoc apoi obj_is_ready anuntnd ORB c e pregtit.

3) Dup ce a pornit toate obiectele, serverul invoc impl_is_ready, anuntnd c este gata s accepte invocri de la clieni.

4) Cnd un obiect nu mai este referit, el poate fi dezactivat prin deactivate_obj. 5) Cnd un proces server se termin, el anun BOA printr-un apel deactivate_impl.

Client

Proces Server

Count

Count

Count

invocarea unui obiect Count

invocarea altui obiect Count din

6.2. Server nepartajat Fiecare obiect rezid ntr-un proces separat. La prima invocare a unui obiect este pornit procesul corespunztor. Cnd obiectul a ncheiat faza de iniializare, el anun BOA prin obj_is_ready. Obiectul rmne activ pn la un apel dezactivate_obj. Ori de cte ori se apeleaz un obiect care nu este activ se pornete un alt obiect cu aceeai implementare. Acest mod se folosete: atunci cnd obiectele necesit cantiti mari de resurse cnd se dorete mrirea gradului de paralelism (ca alternativ la thread-uri).

Figura 6.2. Server nepartajat

6.3. Server-per-metod Un nou server este activat odat cu fiecare cerere i dezactivat odat cu satisfacerea cererii. Nu este deci nevoie ca implementarea s anune BOA cnd un obiect este activat/dezactivat.

6.4. Server persistent Serverul este activat prin mijloace din afara adaptorului BOA. Odat activat, serverul anun BOA, printr-un apel impl_is_ready, c poate primi cereri de la clieni fiind tratat n continuare ca un server partajat.

6.5. Concluzii Dup cum se vede, rolul BOA n pstrarea evidenei obiectelor active sau activabile la cerere este esenial. BOA folosete aceste informaii pentru a putea realiza dispecerizarea cererilor clienilor.

Pentru actualizarea evidenei, BOA cere tuturor obiectelor server s se autodescrie i s-i nregistreze permanent starea. n principiu, fiecare obiect i anun pornirea prin obj_is_ready. Cnd toate obiectele gestionate de un proces server sunt active, acesta apeleaz impl_is_ready. Ce se ntmpl dac un proces are foarte multe obiecte? Instanierea tuturor obiectelor n memorie, la pornire ar putea fi prea costisitoare. Este mult mai eficient s se fac instanierea unui obiect doar atunci cnd un client are nevoie de el. VisiBroker folosete o versiune modificat pentru obj_is_ready, transmind ca argument un Activator pentru obiect. Acesta este o clas special care implementeaz dou metode: activate i deactivate. Prima este apelat de BOA cnd obiectul este invocat. A doua este apelat cnd serverul i termin execuia.

7. Pstrarea descrierilor interfeelor CORBA se deosebete de sistemele client-server tradiionale prin faptul c este auto-descriptibil, dinamic i reconfigurabil. IDL este limbajul metadatelor CORBA, iar IR (Interface Repository) este depozitul metadatelor CORBA, o baz de date care conine specificaiile de interfa ale oricrui obiect recunoscut de CORBA. Aceste elemente permit descrierea consistent a tuturor seviciilor, componentelor i datelor disponibile. Astfel, componente dezvoltate independent se pot descoperi

Client

Proces Server

Count invocarea unui obiect Count

invocarea altui obiect Count din

Proces Server

Count

reciproc n mod dinamic i pot coopera. Nu este deci necesar ca programul unui client s includ apeluri la servere particulare, stabilite la compilare i nemodificabile ulterior. n plus, metadatele disponibile pot fi folosite de instrumente de creare i gestiune a diferitelor componente de aplicaii.

IDL este un limbaj declarativ care permite specificarea interfeelor unor componente cu diveri clieni. IR conine metadate identice cu descrierile IDL, dar n forma compilat. CORBA definete coduri de tip care reprezint diverse tipuri de date definite n IDL. Codurile sunt folosite pentru a crea structuri auto-descrise ce pot fi comunicate prin sisteme de operare, ORB-uri si IR_uri. Codurile sunt utilizate: de IR pentru a crea descrieri IDL independente de ORB de DII (Interfeel.e de invocare dinamic) pentru a indica tipurile diferitelor argumente de protocoalele Inter-ORB pentru a descrie cmpurile mesajelor communicate ntre ORB-uri de tipul any pentru a furniza un parametru generic auto-descris. any se folosete pentru un

parametru al crui tip nu este fixat la compilare. La execuie, pentru un parametru any se poate transmite o valoare de orice tip. Obiectul int care primete un any poate obine TypeCode-ul su i din el poate determina tipul valorii transmise. Concret, clasa CORBA::Any are o funcie membr type() care ntoarce o valoare de tip CORBA::TypeCode_ptr. Aceast valoare poate fi inspectat la execuie pentru a se afla tipul valorii transmise ca any.

Interfaa CORBA TypeCode definete un set de metode ce permit operarea cu coduri de tip, compararea lor, obinerea descriilor, etc.

Fiecare cod de tip are un identificator global unic Repository ID care poate fi folosit ntr-un spaiu de nume distribuit. Asocierea dintre cod i identificator se face la compilarea descrierilor IDL, sau la integrarea lor n IR folosind alte instrumente. Un Repository ID este un ir de caractere cu trei componente, separate de ":" reflectnd o ierarhie de nume cu trei niveluri. Forma este standardizat i are o structur foarte general.

Prima component identific formatul i poate fi IDL sau DCE (doar aceste dou formate sunt definite n CORBA 2.0).

Pentru IDL, a doua component este o list de identificatori desprii prin /. Primul este un prefix unic, reprezentnd numele unei organizaii, un nume Internet, etc. Celelalte sunt identificatori IDL care alctuiesc mpreun numele (complet al) tipului. De exemplu, interfaa Itrf a modulului Mdl are numele Mdl/Interf.

A treia component este o pereche de numere de versiune major i minor, desprite prin punct, v_majora.v_minora

7.1. Interface Repository Interface Repository, IR este o baz de date de definiii de obiecte, generate de un compilator IDL sau introduse prin funciile de scriere specifice IR. Obiectele din IR sunt versiuni compilate ale informaiei care se afl n sursele IDL. Altfel spus, pentru fiecare definiie IDL gsim n IR un obiect care ncapsuleaz descrierea corespunztoare. Specificaia CORBA se refer explicit doar la modul n care informaia din IR este organizat i poate fi regsit. Obiectele din IR suport interfee IDL care reflect construcia IDL pe care o descrie: ModuleDef, InterfaceDef, AttributeDef, etc. n plus, interfaa Repository servete ca rdcin pentru toate celelalte. Fiecare IR este reprezentat de un obiect Repository. Figura 7.1 arat ierarhia de interfee din punct de vedere al coninutului obiectelor care suport aceste interfee.

Figura 7.1. Ierarhia de clase

Obiectele corespunztoare acestor tipuri se grupeaz dup cum: sunt containere de alte obiecte (Repository) sunt coninute de alte obiecte (ConstantDef) sunt att containere ct i coninute (ModuleDef).

Pornind de la aceast relaie, CORBA stabilete ierarhia de motenire pentru tipurile IR, introducnd trei interfee abstracte (interfee ce nu pot fi instaniate): IRObject, Contained si Container. Aceast ierarhie este reprezentat n figura 7.2.

Figura 7.2. Ierarhia IRObject

Obiectele care conin alte obiecte motenesc operaiile de navigare din container. Obiectele coninute motenesc comportarea comun din contained. Toate obiectele motenesc din IRObject. Interfeele IR definesc operaii care permit citirea, scrierea i distrugerea metadatelor pstrate n IR. Folosind doar 9 metode, se poate naviga n IR i se pot extrage informaiile de descriere a obiectelor cutate.

De exemplu, invocarea metodei contents a unui obiect container ntoarce lista obiectelor coninute direct sau motenite de obiectul respectiv. Folosind aceast metod se poate naviga printr-o ierarhie de obiecte. Metoda lookup-name aplicat unui obiect container permite localizarea unui obiect dup nume.

Metoda lookup_id aplicat unui obiect Repository permite cutarea unui obiect ntr-un depozit, cunoscnd identificatorul su, Repository ID.

Repository

ModuleDefConstantDef TypeDef

ModuleDef

ExceptionDef

AttributeDefOperationDef

InterfaceDef

InterfaceDefConstantDef TypeDef ExceptionDef

ExceptionDef ConstantDef TypeDef

ExceptionDefParameterDef

IRObject

Contained Container

AttributeDef

ConstantDef

ExceptionDef

ParameterDef

OperationDef RepositoryTypeDef InterfaceDef

ModuleDef

8. Protocoale Inter-ORB nainte de CORBA 2.0, produsele ORB comerciale nu puteau inter-opera. CORBA 2.0 introduce conceptul de inter-operabilitate i definete dou moduri de inter-operabilitate: cea direct i cea bazat pe o punte. Inter-operabilitatea direct este posibil ntre dou ORB-uri din acelai domeniu: care neleg aceleai referine de obiecte, acelai sistem de tipuri IDL i care partajeaz aceei informaie de securitate. Inter-operabilitatea bazat pe o punte (bridge) se folosete atunci cnd dou ORB-uri din domenii diferite trebuie s coopereze.

Inter-operabilitatea se bazeaz pe un protocol general: GIUP General Inter-ORB Protocol, care specific sintaxa de transfer i un set standard de formate de mesaje pentru inter-operarea ORB peste o legtur de transport orientat pe conexiuni. IIOP Internet Inter-ORB Protocol descrie construcia GIOP pe legturi de transport TCP/IP.

9. Cteva servicii CORBA importante

9.1. Serviciul ciclului de via

9.2. Serviciul de evenimente

9.3. Serviciul de securitate

10. Implementri ORB Java ORB este un ORB scris n ntregime n Java. Cu Java ORB, un applet obinuit poate invoca metode ale obiectelor CORBA folosind IIOP. Appletul ocolete complet CGI i HTTP, ntre client i server stabilindu-se o legtur direct. Trei dintre cele mai cunoscute Java ORB sunt: Joe de la Sun OrbixWeb de la Iona VisiBroker for Java de la Visigenic/Netscape. 10.1. Joe

Produsul NEO de la Sun include: Solaris NEO mediu ce conine suportul de execuie necesar pentru aplicaiile NEO/JOE Solstice NEO instrumente de gestiune a obiectelor n sisteme distribuite NEOworks instrumente de dezvoltare a aplicaiilor (incluznd compilatorul IDL, un

depanator, etc).

Joe este un Java ORB pentru clieni. El poate fi ncrcat odat cu un applet Java sau poate fi instalat permanent pe maina client. Joe include un compilator IDL-TO-Java care genereaz automat stub-uri Java din descrieri IDL. n prezent, obiectele server trebuie scrise pentru platforma NEO, care suport C i C++. Versiunea IIOP pentru Joe va fi capabil s comunice cu orice Java ORB care suport IIOP.

Figura 10.1. Joe

10.2. Orbix Iona este liderul furnizorilor de tehnologie CORBA. Produsul su Orbix ORB este executat pe 20 de sisteme de operare (Unix, OS/2, NT, Windows 95, Macintosh, VMS).

OrbixWeb V1 este o implementare Java pentru clieni; care permite applet-urilor i aplicaiilor Java s comunice cu servere Orbix folosind fie protocolul IIOP, fie protocolul Orbix (Iona).

n prezent, obiectele server trebuie scrise n C++. Oricum, OrbixWeb V2 va permite elaborarea lor n Java.

Figura 10.2. OrbixWeb

IIOP

Sun IIOP Server

Server Solaris

C++

Java

C++

Joe

Java application

Neo & Door protocols

NEO

applet Java

IIOP ORB

C++

C++ C++

IIOP / Orbix

OrbixWeb V2

C++

Java

C++

OrbixWeb

Java application

IIOP /Orbix

IIOP/Orbix

applet Java

IIOP/Orbix

C++

C++ C++

10.3. VisiBroker Are dou variante: VisiBroker for C++ si for Java.

VisiBroker for Java este un ORB client i server scris n Java.

Figura 10.3. VisiBroker

El implementeaz protocolul IIOP, care permite ca obiectele C++ s apeleze metode Java i reciproc. Caracteristici: permite apeluri statice i dinamice include un IR scris n Java include OSAgent, un serviciu de nume tolerant la defecte

VisiBroker va suporta versiuni Java pentru serviciile Naming, Event, Transactions. Suport, de asemenea, Caffeine un mediu de dezvoltare Java peste CORBA/IIOP. Caffeine face CORBA transparent pentru programatorii Java: obiecte Java pot invoca alte obiecte prin CORBA IIOP ORB, fr a fi necesare descrieri IDL.

11. Aplicaii CORBA n Internet

11.1. Modelul cu trei straturi (3-Tiers) Obiectele CORBA sunt ideale pentru aplicaiile client-server scalabile, structurate pe trei niveluri.

Primul nivel l reprezint aspectele vizuale ale obiectelor comerciale (vezi figura 7.4.). Unul sau mai multe obiecte de vizualizare pot oferi una sau mai multe vederi ale unui obiect comercial. Aceste obiecte vizuale sunt localizate, de regul, la client.

Al doilea nivel este cel al obiectelor-server, care ncapsuleaz datele persistente i funcionalitatea aplicaiei. Obiectele server interacioneaz cu clienii (obiectele vizuale) precum i cu sursele de date (baze de date SQL, fiiere HTML, Lotus Notes, Monitoare de tranzacii) care constituie al treilea nivel al aplicaiilor. Obiectele server ofer un model coerent i integrat al unor surse de date disparate i ale aplicaiilor din fundal. Ele ascund fa de clieni (obiectele vizuale) toate detaliile de implementare ale procedurilor i bazelor de date din al treilea nivel.

IIOP

Java

C++

C++

VisiBroker for Java

Java application

IIOP

applet Java

C++

Java Java

VisiBroker for Java

VisiBroker for C++

Orice server Java

NT, UNIX, altele

Figura 11.1. Folosirea CORBA n aplicaiile client server

Clienii nu interacioneaz niciodat direct cu aplicaiile din nivelul trei. Ei comunic cu obiectele server folosind ORB. Serverele pot comunica ntre ele folosind, de asemenea, ORB. Ele pot, astfel, partaja prelucrrile, echilibra ncrcarea, etc. Obiectele server comunic cu nivelul trei folosind mijloace tradiionale (mesaje, RPC, etc.). n ce privete Internet-ul, CORBA este o alternativ eficient la modelul cu trei nivele folosit astzi, HTTP Hyper Text Transport Protocol, CGI Common Gateway Interface (Interfa comun de conversie).

11.2. HTTP / CGI i CORBA Reamintim aici, succint, ideea HTTP/CGI. Ea urmrete lrgirea funcionalitii serverelor Web, adugnd rolului de depozitar de pagini HTML, Hyper Text Markup Language, pe acela de executant al unor prelucrri. O astfel de prelucrare este descris printr-un fiier de comenzi (script), cruia i se atribuie un URL. La invocarea unei astfel de pagini speciale, atunci cnd clientul selecteaz hiper-legtura respectiv, serverul lanseaz n execuie programul (sau fiierul de comenzi). Programul poate inspecta sau actualiza o baz de date sau poate realiza diverse alte prelucrri. Uzual, programul de prelucrare produce i un fiier de ieire HTML, care este transmis spre interpretare programului de navigare (clientul). Adugnd la acestea posibilitatea ca un utilizator s transmit informaii serverului, prin intermediul clientului (navigatorului) se ajunge la un suport de dezvoltare de aplicaii ce beneficiaz de toate mecanismele Web pentru interfaarea cu utilizatorii.

Figura 11.2. Folosirea HTTP/CGI

ORB

CORBA

IIOP

Obiecte de vizualizare

Nivel 3

Aplicaii tradiionale obiecte

ORB

ORB

ORB

Nivel 2Nivel 1

DBMS

Lotus Notes

Pagini HTML

CGI Gateway program rezident n serverul Web script (Unix shell, Perl, etc) sau program executabil (C, C++, etc.) single step include i funciile aplicaiei, care uzual sunt foarte simple (scurte) two step un program de aplicaie ruleaz ca un proces daemon, iar CGI Gateway joac rolul

de dispecer.

Acest mod de utilizare se bazeaz pe faciliti de form pe care HTML le include i care permit transmiterea unor informaii de la browser la server.

Soluia este lent i greoaie.

Java introduce un model nou al interaciunilor client/server pentru Web. El permite scrierea unor programe, applets, care pot fi ncrcate din server n clieni (ce sunt Java-compatibili) i executate de clieni. Se mrete astfel interactivitatea i inteligena clienilor. Java permite crearea unor aplicaii client independente de platform, ce pot fi distribuite prin Internet.

Java este la fel de bun pentru servere. Se pot scrie programe pentru servere mobile, utilizabile n combinaii foarte diverse.

11.3. Java i CORBA Permite realizarea unor aplicaii distribuite portabile. Are RMI (Remote Method Invocation), care permite comunicarea prin Internet ntre applet-uri: un obiect aflat pe un sistem poate invoca o metod a unui alt obiect situat ntr-un alt sistem din reea. Aplicaii sunt programe complete, de sine stttoare, care includ metoda main(), ope cnd un Applet este un mic program executat ca parte a unui browser Java-enabled. Programul conine metode invocate de browser.

Figura 11.3. Modelul de apel al unui server

Motive pentru utilizarea CORBA: Independena de limbaj Este mai dezvoltat dect RMI (CORBA este nainte de Java). mbogirea infrastructurii Web cu CORBA are multe beneficii: Permite evitarea gtuirilor CGI la server; clienii pot invoca direct metode pe un server; pot fi

communicate date cu tip nu doar iruri de octei; CORBA pstreaz starea ntre dou invocri ale unui client (CGI nu!).

Permite realizarea unei infrastructuri flexibile de servere, obiectele pot rula pe mai multe servere i se poate face echilibrarea ncrcrii.

CORBA furnizeaz o infrastructur de obiecte distribuite (serviciile de obiecte i facilitile comune).

Exist mai multe abordri de a extinde HTTP/CGI cu CORBA IIOP. Realizarea unui convertor CGI->CORBA nu rezolv gtuirea CGI deci nu amelioreaz

performanele i nu extinde Java cu o infrastructur distribuit de obiecte.

Realizarea unor convertoare bidirecionale HTTP-IIOP i a unui server CORBA HTTP care servete cererile HTTP (aici, CORBA nlocuiete total HTTP).

Coexistena CORBA/IIOP i HTTP presupune un server CORBA-IIOP alturi de serverul HTTP existent; de partea clientului, trebuie s existe un CORBA ORB. Aceasta se poate face fie prin incorporarea unui (Java) ORB ntr-un program de navigare Web, fie prin ncrcarea n client a unui ORB lent (un ORB scris n bytecodes).

Funcionarea corespunztoare celei de a treia variente este descris n figura 11.4.

Figura 11.4. Interaciunea HTTP-CORBA

Interaciunea ar cuprinde urmtoarele faze: Navigatorul ncarc o pagin HTML, care conine referine la applets Java. Navigatorul preia applet-ul de la serverul HTTP. Applet-ul este testat i apoi ncrcat n memorie. Applet-ul invoc obiecte server CORBA. Sesiunea ntre ele persist pn cnd una din pri

decide s se deconecteze.

CORBA reprezint nc o contribuie la dezvoltarea Web-ului spre o arhitectur de calcul centrat pe reea. O astfel de abordare este mbriat de multe firme. Pe aceast linie se nscrie NCA Network Computing Architecture, model propus de Oracle pentru medii de calcul distribuite bazate pe Web.

12. Comparaie cu alte modele Dintre produsele de middleware utilizate azi, cteva atrag atenia prin modelul de arhitectur distribuit pe care se bazeaz: CORBA - Common Object Request Broker Architecture al OMG (Object Management Group) DCE - Distributed Computing Environment al OSF (Open Software Foundation) DCOM - Distributed Component Object Model al Microsoft Java RMI al JavaSoft.

Relaia ntre diferitele arhitecturi distribuite este ilustrat n figura 2. Ea arat c aceste modele aflate n competiie se completeaz reciproc i se integreaz la diferite niveluri.

Figura. 12.1. Relaia ntre diferite arhitecturi distribuite

DCE (Distributed Computing Environment) este o propunere a OSF (Open Software Foundation) menit s creeze un mediu-suport pentru aplicaii distribuite eterogene. Serviciilor furnizate de reea, DCE le adaug faciliti pentru thread-uri, apeluri de procedur la distan, servicii de directoare, de timp, de securitate i de fiiere. Recunoscnd importana DCE, OMG a introdus un standard de gateway CORBA-DCE. CORBA poate deja opera "peste" DCE, putnd folosi facilitile 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 similariti cu CORBA, dar a fost conceput special pentru platforme Windows. DCOM se refer 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 legturi ntre documente compuse sau pentru gestiunea documentelor compuse;

Un model de comunicare ntre obiecte, COM (Component Object Model). Pentru aplicaii Web Microsoft propune ActiveX, un set de tehnologii adaptate particularitilor Web, incluznd ActiveX Componentns, ActiveX Scripting i ActiveX documents. Adaptrile vizeaz obinerea unor componente optimizate ca dimensiune i vitez, ceea ce uureaz ncrcarea lor prin

reea pe maina clientului. Astfel, componentele ActiveX se conformeaz modelului COM i abordrii OLE.

Java este limbajul care a revoluionat aplicaiile Web. Abordarea standard original prevedea posibilitatea ca obiecte Java rezidente pe un server s fie transferate la un client pentru execuie. Limbajul nu prevedea servicii distribuite. Obiectele unei aplicaii trebuia s rezide ntr-un singur server, iar obiectele erau "perisabile", pierzndu-i informaia de stare pe perioada de inactivitate. Java RMI rezolv aceste probleme, fiind nceputul dezvoltrii unei arhitecturi de obiecte distribuite. Prin el, se pot crea obiecte Java ale cror metode pot fi invocate din alte maini virtuale. Ca alternativ de evoluie, Java va trebui s integreze capabilitile distribuite din CORBA sau s-i dezvolte propriile sale capabiliti. Prima variant a i fost abordat: produsul Caffeine (produs de Netscape i Visigenic) permite descrierea obiectelor distribuite direct n Java, oferind un suport transparent al RMI peste IIOP. Caffeine genereaz automat stub-urile i skeleton-urile IIOP. Poate genera chiar i descrierile IDL din bytecode-uri Java. Java are dou avantaje importante: este uor de folosit i codul poate fi ncrcat prin reea i executat. Un client poate localiza un serviciu de interes pentru el, poate ncrca interfaa corespunztoare i poate interaciona apoi cu serviciul. Aceast manier de lucru este tipic limbajelor de programare a Web-ului.

Lucrarea de fa analizeaz comparativ aceste soluii, principalele rezultate fiind prezentate n tabelele urmtoare. Ca element de referin a fost ales modelul CORBA, elaborat de OMG, care satisface cerinele unui mare numr de dezvoltatori de aplicaii distribuite.

12.1. Comparaie CORBA - DCE CORBA i DCE suport ambele dezvoltarea aplicaiilor distribuite. Ele au fost realizate de consorii promotoare de standarde, OMG (Object Management Group pentru CORBA), respectiv OSF (Open Software Foundation pentru DCE), au fost specificate n aceeai perioad (1991-1992) i au cunoscut materializarea n implementri comerciale n 1993.

Caracteristic CORBA DCE

Suport pentru Dezvoltarea aplicaiilor client-server eterogene

Dezvoltarea aplicaii