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.

Client
Apel la distanta
Servere

Obiecte

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.

Utilizator

Midlleware

Aplicaie

Aplicaie

Middleware

Middleware

Utilizator

Middleware

Reea

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.

C
IDL

C++
IDL

COBOL
IDL

IDL

Java

IDL

IDL

Client

C++
IDL

COBOL

Java

IDL

IDL

IDL
Server

ORB

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.

Interfee
de
i
i i
ORB

Servicii de
obiecte

Faciliti
comune

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.

(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.
Implementare de
obiect

Client

Depozit
de
interfee

Interfa
de
invocare
dinamic

Stub
IDL

Interfa
ORB

Skeleton
static IDL

Interfa
dinamic
de
Skeleton

Adaptor

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

constante

constante

tipuri

excepii

excepii

module

tipuri

interfee

atribute

operaii

module

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
string<10>

// un sir fr limitri de lungime

// un sir de maximum 10 caractere

sequence tablou unidimensional, mrginit sau nemrginit, cu toi membrii de acelai tip

sequence<float, 100> MySeq;

sequence <float> Seq;

2.2.

//mrginit
//nemrginit

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<5> 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 <datatype><name>. 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

short
long
unsigned short
unsigned long
float
double
char
boolean
octet

CORBA::Short
CORBA::Long
CORBA::UShort
CORBA::ULong
CORBA::Float
CORBA::Double
CORBA::Char
CORBA::Boolean
CORBA::Octet

corespondena
n
Orbix
pentru 32 de bii
short, dac 16 bii
long, dac 32 de bii
unsigned short
unsigned long
float
double
char, dac 8 bii
unsigned char
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 funciemembr. 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.
Referin la obiect

Referin la obiect

Referin la obiect

Client

Proxy
Contor refer.=2

Server

int
Contor refer.=1

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);
... //poate folosi p2
CORBA::release (p2);

//incrementeaza contorul
//decrementeaza contorul

}
// 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.
1. Creare definiii IDL

Precompilare
Skeleton-uri
3. Adugare cod de implementare
4. Compilare

5. Interface
Repository

Client IDL
Stubs
Client

Server IDL
Skeleton

instaniere

Implementri
Object

7. Object
Adapter

6. Implementation
Repository

Server

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.

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.

Count
Attributes: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

Orbeline

Count_c.hh

Count_c.cpp
stub

Count_s.hh

Precompilare IDL -> C++

Count_s.cpp
skeleton

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 <count_s.hh>
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<<Count object created<<endl;
this->_sum=0;
}
// citeste valoarea atributului sum
CORBA::long CountImpl::sum()
{ return this->_sum; }
// scrie valoarea atributului sum
void CountImpl::sum(CORBA::long val)
{ this->sum=val; }
// incrementeaz suma
CORBA::long CountImpl::increment()
{ this->_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<<e<<endl; exit (-1);}
return (0);
}
Programul principal face urmtoarele operaii:
Iniializeaz ORB aceasta se face prin apelul unei funcii din interfaa CORBA API i are efect
obinerea unei referine de pseudo-obiect CORBA::ORB. Un pseudo-obiect este un obiect creat
de ORB, dar care poate fi invocat ca orice alt obiect. ORB nsui este un pseudo-obiect.

Iniializeaz BOA - folosind referina orb, iniializeaz BOA; iniializarea ntoarce o referin la
BOA.

creaz obiectul CountImpl. Aici serverul asociaz obiectului un nume (marker) la crearea sa.
Numele trebuie s fie unic n cadrul serverului. Dac un server creaz mai multe obiecte Count,
el trebuie s asigneze acestora nume distincte. Ca alternativ, asocierea mrcilor cu obiecte
poate fi lsat n seama ORB, aplicaia avnd posibilitatea s modifice mrcile ulterior crerii
obiectelor. Numele unui obiect este mai complicat, av\nd mai multe componente: numele
serverului, interfaa, marker-ul.

Folosind referina BOA nregistreaz n BOA noul obiect creat, CountImpl.

Anun BOA c obiectul este gata s lucreze i c ateapt primirea unor invocri de servicii.
Funcia impl_is_ready nu red controlul imediat. Ea blocheaz serverul pn la apariia unui
eveniment, trateaz evenimentul i re-blocheaz serverul n ateptarea unui alt eveniment.
Funcia se termin la apariia unui time-out (a crui durat este programabil) sau a unei
excepii.

server.cpp

CORBA API

ORB

BOA

ORB_init
BOA_init

new
CountImpl
obj_is_ready
impl_is_ready

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 << definit pe clasa SystemException produce
o descriere textual a excepiei particulare produse. n ce privete transmiterea excepiei (declanarea
ei) ea folosete instruciunea throw n C++.
De notat c nu se utilizeaz o bucl do-forever pentru a servi cererile clienilor. CORBA i BOA
furnizeaz dedesubt aceast funcionalitate. Tot ceea ce se cere programatorului este s se
implementeze interfeele i s se nregistreze n BOA.

3.6.

Implementarea clientului

Partea client a aplicaiei const dintr-un program main i fiierul su antet. Programul trebuie s
realizeze urmtoarele operaii:
S iniializeze ORB
S localizeze un obiect Count distant
S iniializeze la zero atributul sum
S calculeze timpul de start
S invoce metoda increment de 1000 de ori
S calculeze timpul scurs
S afieze rezultatele

//Client.cpp Count static client, VisiBroker pentru C++

# include <count_c.hh>

# include <iosteam.h>
# include <stdlib.h>
# include <time.h>
# include <sys\types.h>
# include <sys\timeb.h>
struct timeb timebuff;
double startTime, stopTime;
int main (int argc, char * const* argv)
{ try
{
cout << "initialize ORB" << endl;
CORBA::ORB_ptr orb = CORBA::ORB_init(argc, argv);
//bind to the Count Object
cout << Binding to Count Object<<endl;
Counter::Count_var Counter=Counter::Count::_bind(MyCount);
/*Counter va contine un pointer la proxy intermediarul pentru
serverul CountImpl */
Counter->sum((long)0);
ftime(&timebuff);
//calcul timp de start
startTime=((double)timebuff.time+((double)timebuff.millitm)/
(double)1000);
//increment
for (int i=0; i<1000; i++)
{ Counter->increment(); }
//calcul timp stop
stopTime==((Double)timebuff.time+((double)timebuff.millitm)/
((double)1000);
cout << (stopTime startTime) <<nsecs<endl;
cout <<Sum =<<Counter->sum();
}
catch(CORBA::SystemException &excep)
{cout<<System Exception<<endl;
cout <<excep;
return(1);
}
return (0);
}
CORBA permite invocarea obiectelor distante folosind semantica uzual C++. Pentru a invoca
metodele, este mai nti necesar obinerea referinei obiectului, realizat aici cu bind. Aceast metod
este implementat automat de clasa C++ intermediar Count. Pentru referin se folosete Count_var
(n loc de count_ptr), pentru a realiza automat gestiunea memoriei.

CountImpl

counter

CORBA API

Client.cpp
ORB_init

new
_bind
Count
proxy
Sum(0)
Sum(0)

Start timer
de 1000 de ori

increment
increment
Stop Timer
Print
results
client

server

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.
client

Object

InterfaceDef

OperationDef

ORB

get_interface
Lookup_name
describe
create_list
NVList

add_item
add_value
create_request
invoke

Request

delete
free

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:

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 nonCORBA. 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.

Trader

ORB
1-Export
serviciul

2-Import
serviciul
Client
Importator

3-Invoc serviciul

Server
Exportator
ORB

ORB

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.

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.
client

Lookup

Register

ServiceTypeRepository

server

add_type
export

list_type
describe_type
query
invoke_method

Trader

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.

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).
Proces Server
invocarea unui obiect Count
Count

Client

Count

invocarea altui
obiect Count din

Count

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 printrun 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.

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).

Proces Server
invocarea unui obiect Count
Count

Client

Proces Server
invocarea altui
obiect Count din

Count

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

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.

Repository

ConstantDef

TypeDef

ModuleDef

ExceptionDef

InterfaceDef

ConstantDef

TypeDef

InterfaceDef

ModuleDef

ExceptionDef

ConstantDef

TypeDef

OperationDef

AttributeDef

ExceptionDef

ParameterDef

ExceptionDef

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.
IRObject
Contained

AttributeDef

Container

ExceptionDef
ConstantDef

TypeDef

InterfaceDef

ParameterDef

OperationDef

Repository

ModuleDef

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.

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.

C++
NEO
applet Java
C++
Joe
Java
application

Neo & Door

protocols

C++

Server Solaris

IIOP
C++

C++

IIOP ORB
Java
Sun IIOP Server

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.
C++
IIOP/Orbix
applet Java
C++

C++

IIOP /Orbix
OrbixWeb
Java
application

IIOP / Orbix
C++

C++

IIOP/Orbix
Java
OrbixWeb V2

Figura 10.2. OrbixWeb

10.3. VisiBroker
Are dou variante: VisiBroker for C++ si for Java.
VisiBroker for Java este un ORB client i server scris n Java.
Java
VisiBroker for Java
applet Java
Java

Java

IIOP
Orice server Java

VisiBroker for Java

Java
application

IIOP
C++

C++

VisiBroker for C++

C++
NT, UNIX, altele

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.

Nivel 1

Nivel 2

ORB
ORB
CORBA
IIOP

O
R
B

DBMS

Lotus
Notes

ORB
Obiecte de
vizualizare

Nivel 3

obiecte

Pagin
i
HTM
L
Aplicaii tradiionale

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 hiperlegtura 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

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
Suport pentru
Servicii comune
Servicii diferite

Model de
programare
Interfa
Extensibilitate
Standardizare
Implementri
disponibile n

CORBA
Dezvoltarea aplicaiilor client-server
eterogene
Cataloage, timp, threads, securitate,
evenimente, gestiune reea
Persisten, query, trader, tranzacii,
gestiunea
informaiilor
i
a
sistemelor, servicii n finane,
simulare distribuit, CIM
Obiect, cu suport pentru ncapsulare,
abstractizare, polimorfism, motenire
Invocare static i dinamic
Da
CORBA 1.0 n 1991
1993

DCE
Dezvoltarea aplicaiilor client-server
eterogene
Cataloage, timp, threads, securitate,
evenimente, gestiune reea
Sistem de fiiere distribuit

Procedural; modelul obiect nu este

direct suportat
Invocare static
Nu
DCE 1.0 n 1992
1993

Diferenele notabile provin din stilurile de programare adoptate: n timp ce CORBA se bazeaz pe un
model de obiecte, DCE are la baz un model procedural, n care apelurile de proceduri la distan
(RPC - Remote Procedure Call) constituie "piesa" central.
DCE are un scop mai restrns, fiind concentrat pe un set redus de servicii. CORBA vizeaz un set de
servicii mai amplu. Ca urmare, implementarea DCE a atins un nivel de maturitate ridicat, n timp ce
unele servicii CORBA sunt nc n curs de dezvoltare.

12.2. Comparaie CORBA - DCOM

Ca i CORBA, DCOM separ interfaa unui obiect de implementarea sa. Limbajul de definire a
interfeelor adoptat de Microsoft difer de CORBA IDL. n timp ce n CORBA motenirea joac un rol

esenial, fiecare obiect avnd o interfa care poate deriva din altele, n DCOM agregarea este mai des
folosit. Un obiect poate avea mai multe interfee independente, fr relaia de motenire ntre ele.
Caracteristic
Concepie

CORBA
Ca schem de interoperare eficient a
aplicaiilor scrise n diferite limbaje
pentru platfome diferite (eterogene)
MVS, UNIX (diferite versiuni),
Windows
(toate
versiunile),
Macintosh

DCOM
Schem de integrare a documentelor
compuse i extins la prelucrare
distribuit
Platforme
Bine integrat ntr-o singur platform,
Windows NT; n perspectiv
extindere la toate versiunile de
Windows, Macintosh, UNIX, MVS
Servicii
Orientat pe anumite categorii de Poate folosi orice servicii oferite de
servicii bine definite: persisten, Windows (ActiveX)
query, trader, tranzacii, gestiunea
informaiilor i a sistemelor, servicii
n finane, simulare distribuit, CIM
Limbaje
C, C++, Smalltalk, Ada95, Java, C, C++; n curs - Java, Visual Basic,
suportate
COBOL
Ada
Model de baz Obiect; cu accent pentru persistena i Obiect
identitatea obiectelor
Interfee
Separare interfa de implementare
Similar, Type Library
Depozit de interfee
Independen Da
Da
de limbaj
Transparen
Da
Da
la localizarea
obiectelor
Model
de OpenDoc
OLE
document
compus
Uurina
de Mai greu de folosit - util pentru Uor de folosit pentru mediul
folosire
probleme complexe (nu este nativ pe Windows
un mediu particular i cere
acomodarea
programatorului
n
fiecare mediu)
Un obiect DCOM nu este un obiect n adevratul sens al cuvntului. Interfeele DCOM nu pot fi
instaniate i nu au stri. O interfa DCOM este un grup de funcii, clientului dndu-i-se un pointer
pentru a avea acces la aceste funcii (mai precis un pointer la un tablou de pointeri la funcii, cunoscut
sub numele de vtable - virtual table). Aceasta justific eticheta de standard de "interconectare binar"
asociat cu DCOM (respectiv OLE). Deoarece acest pointer nu este legat de vreo informaie de stare,
un client nu se poate reconecta la o aceeai instan de obiect, la un moment ulterior. Deci, DCOM nu
are noiunea de identitate a obiectului, n timp ce aceasta este foarte bine structurat n CORBA.
Ca i CORBA, DCOM ofer interfee statice i dinamice pentru invocrile metodelor, ca i depozite de
interfee (Type Library). Clienii pot inspecta aceste depozite pentur a descoperi interfeele unui obiect
i parametrii necesari pentru o invocare particular.
IDL joac un rol imporant n CORBA, att pentru a defini sistemul de tipuri, ct i pentru a preciza
modul de transmitere a datelor prin reea. Similar, ODL (Object Definition Language) din OLE
definete sistemul de tipuri, iar MIDL specific modul n care parametrii i identificatorii operaiilor
sunt specificai ntr-un apel ctre un obiect OLE. Compilatorul NT 4.0 MIDL extinde IDL pentru a
suporta construciile ODL, reunind astfel cele dou limbaje.

12.3. Comparaie CORBA - Java RMI

Relaia dintre Java i CORBA este mai mult de complementaritate dect de concuren.

Caracteristic
Model
Creare de obiecte la distan
Faciliti de broker
Limbaje suportate
Obiecte autodescrise
Depozite de obiecte
Invocri dinamice
Servicii
de
securitate,
tranzacii etc.

CORBA
Obiect
Da
Da
C, C++, Smalltalk, Ada95, Java, COBOL
da
da
da
da

Java RMI
Obiect
Da
Da
Java
nu
nu
nu
nu

Java este un excelent limbaj pentru a descrie obiecte CORBA. Apoi, Java complementeaz serviciul de
componente din CORBA, bazat pe OpenDoc. n timp ce CORBA definete containere vizuale pentru
componente, i containere de memorare mobile, Java poate furniza "boabele" care evolueaz n aceste
containere. Mai mult, facilitile de cod mobil din Java permit partiionarea unei aplicaii ntre client i
server, la momentul execuiei. Java simplific distribuia codului n sistemem CORBA mari, printr-o
gestiune centralizat a cosului pe server i difuzarea codului la clieni, cnd i unde este necesar.
n compensaie CORBA aduce trei beneficii imediate aplicaiilor Web:

Permite evitarea gtuirilor CGI prin invocarea direct, de ctre client, a metodelor serverelor;

Faciliteaz o infrastructur scalabil de servere (obiectele server pot comunica folosind CORBA
ORB)

Extinde Java cu o infrastructur de obiecte distribuite (posibilitatea de comunicaie ntre spaii

diferite de adrese).

Avantajele obinute de Java prin conlucrarea cu CORBA sunt urmtoarele:

CORBA evit gtuirea produs de CGI pe server, deoarece clienii invoc direct metode de pe
server. Se pot transfera astfel i parametri care nu sunt iruri de caractere, se poate memora
starea serverului ntre dou apeluri.

CORBA asigur o infrastructur scalabil server-server, putndu-se folosi colecii de obiecte

server identice care s echilibreze ncrcarea.

CORBA extinde Java cu o infrastructur de obiecte distribuite, astfel nct un applet este n stare
s comunice cu orice obiect, indiferent de limbajul n care este scris i de localizarea n reea.

Sintetiznd, diferenele dintre abordarea HTTP i CORBA sunt prezentate n urmtorul tabel:
Caracteristic
Pstrarea strii ntre invocri
IDL, Interface Repository
Suport metadate
Invocare dinamic
Tranzacii
Securitate
Servicii bazate pe obiecte
Callbacks
Infrastructur server-server
Scalabilitate
Metode IDL

Java CORBA
DA
DA
DA
DA
DA
DA
DA
DA
DA
DA
DA

Java - CGI
NU
NU
NU
NU
NU
DA
NU
NU
NU
NU
NU

CORBA nu este singura alternativ, competitorii si fiind DCOM/ActiveX, WebObjects i RMI. ns

alturarea dintre Java i CORBA aduce o serie de avantaje i pentru CORBA, Java intrnd n funciune
acolo unde CORBA se termin:
Java permite CORBA deplasri de inteligen, prin folosirea codului mobil att clienii ct i
serverele putnd s-i mbogeasc cunotinele.

Java completeaz serviciile CORBA referitoare la controlul ciclului de via al obiectelor.

Java simplific distribuirea codului n sistemele CORBA de dimensiuni mari.

Java complementeaz facilitile CORBA de lucru cu ageni mobili.

Java este limbajul cvasi-ideal pentru scrierea obiectelor CORBA.

DCOM (Distributed Component Object Model) este principalul rival al alianei Java/CORBA,
considerat actualmente un standard de facto, datorit rspndirii sale. Este fundamentul viziunii
Microsoft asupra Internet-ului.
DCOM, la fel ca i CORBA, separ interfaa de implementare cernd ca toate interfeele s fie descrise
folosind un IDL. Microsoft IDL se bazeaz pe DCE i nu este compatibil cu CORBA (aa cum era de
ateptat). n timp ce CORBA se bazeaz pe modelul clasic de obiecte, DCOM nu face acest lucru. O
component DCOM nu suport motenire multipl, ns poate implementa mai multe interfee, astfel
nct reutilizarea codului nu se obine prin motenire, ci prin agregare.
Sintetiznd, principalele aspecte legate de comparaia Java/CORBA DCOM sunt prezentate n
tabelul urmtor:
Caracteristic
ORB scris n java
Platforme suportate
Transfer de parametri
Configurare
Descrcare dinamic a stub-urilor
Descrcare dinamic a claselor
Transfer obiecte prin valoare
Interfaa - IDL
Aflare dinamic a informaiilor
Invocare dinamic
Performane
Securitate
Serviciu de nume
Recunoate URL
Referine persistente la obiecte
Invocaii multilimbaj
Scalabilitate
Protocol ORB standard

Java/CORBA
DA
Toate
In, out, in/out
Uoar
NU
NU
DA
DA
DA
DA
F. rapid
DA
DA
DA
DA
DA
DA
DA

DCOM
NU
Windows
In, out, in/out
Grea
NU
NU
NU
DA
DA
DA
Rapid
DA, pe NT
NU
NU
NU
DA
NU
Posibil

Dei CORBA a luat un start promitor, DCOM este o ameninare serioas la supremaia Web-ului.
Fcnd acum sinteza tehnologiilor Internet existente, putem vedea c, per ansamblu, CORBA deine
cele mai bune performane. Acest lucru este ilustrat n tabelul urmtor, unde se folosete un sistem de
notare asemntor celui de apreciere a filmelor: cinci stele maxim, o stea minim.
Caracteristic
Nivel de abstractizare
Integrare Java
Sisteme de operare suportate
Implemenatare Java
Parametri cu tip
Uurin de configurare
Invocare de metode distribuite
Salvare stare ntr invocri
Invocare dinamic

CORBA
*****
*****
*****
*****
*****
****
*****
*****
*****

DCOM
*****
****
***
**
*****
*
****
****
*****

RMI
*****
*****
*****
*****
*****
****
****
****
**

HTTP/ CGI
***
***
*****
*****
**
****
*
*
*

Sockets
**
***
*****
*****
**
****
*
***
*

Caracteristic
Performane
Securitate
Tranzacii
Obiecte persistente
Recunoatere UTL
Invocare multilimbaj
Scalabilitate
Standard deschis

13.

CORBA
*****
*****
*****
*****
****
*****
*****
*****

DCOM
****
*****
****
**
**
****
**
***

RMI
****
****
*
*
***
*
**
***

HTTP/ CGI
*
****
*
*
*****
****
***
*****

Sockets
*****
****
*
*
****
*****
*****
*****

Concluzii

n lucrare sunt discutate motivele pentru utilizarea tehnologiei CORBA:

Independena de limbaj i de platform

Tehnologia este mai dezvoltat dect RMI (CORBA este propus nainte de Java).

mbogirea infrastructurii Web cu CORBA are mai multe avantaje:

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).

Bibliografie selectiv
1. S.Baker, CORBA Distributed Objects Using Orbix, Addison Wesley 1997
2. T.J.Mowbray, W.A.Ruh, Inside CORBA, Distributed Object Standards and Applications, Addison
Wesley 1997
3. D.E. Comer, D.L. Stevens Internetworking With TCP/IP Prentice Hall, 1993
4. S. Beaker, V.Cahill, P.Nixon, Bridging Boundaries: CORBA in Perspective, n IEEE Internet
Computing Vol.1, No.5, Sept/Oct 1997
5. E.Evans, D.Rogers, Using Java applets and CORBA for Multi-User Distributed Applications, n
IEEE Internet Computing Vol.1, No.3, May/June 1997
6. C. McFall, An Object Infrastructure for Internet Middleware; IBM on Component Broker, n IEEE
Internet Computing Vol.2, No.2, March/April 1998
7. R. Ben Natan Objects on the Web, McGraw Hill 1997
8. A. Umar, Object Oriented Client/Server Internet Environments, Prentice Hall 1997
9. www.microsoft.com, DCOM Architecture
10. www.sun.com, Java RMI Specification
11. J. Boutell , CGI Programming in C and Perl, Addison Wesley, 1997