CORBA

CORBA

OMG (Object Management Group)

CORBA - Common Object Request Broker Architecture

OMA include

Modelul de Obiect (Object Model)

Modelul de Referinta (Reference Model).

Arhitectura sistemelor distribuite in modelul CORBA

Intercomunicarea obiectelor

ORB (Object Request Broker) = magistrala de obiecte (object bus).

CORBA si Middleware

Categorii de servicii:

De schimb de informatie

Orientate spre aplicatii (replicarea datelor, integritatea, servicii de grup pentru procese cooperative, servicii pentru obiecte distribuite, etc.)

De management (directoare, securitate, toleranta la defecte, performanta).

Transparenta fata de sistem

Transparenta limbajului

IDL - Interface Definition Language

Invocari statice si dinamice ale metodelor

Sisteme autodescriptibile

Interface Repository

Exemple de ORB

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

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

Modelul de referinta

Servicii

Serviciile - 16 servicii in categorii:

sisteme distribuite (D)

baze de date (B)

generale (G).

Servicii importante

(D) Serviciul de nume (Naming Service);

(D) Serviciul de gasire a obiectelor dupa proprietati (Trading Service)

(G) Serviciul ciclului de viata (Life Cycle Service).

(B) Serviciul de persistenta (Persistence Service).

(D) Serviciul de evenimente (Event Service).

(B) Serviciul de proprietati (Properties Service).

(G) Serviciul de timp (Time Service).

(D) Serviciul de securitate (Security Service).

(B) Serviciul de control al concurentei (Concurrency Control Service).

Transaction Service, Relationship Service, Querry Service reprezinta alte servicii.

Facilitatile comune

Interfetele de aplicatii

Arhitectura CORBA ORB

Nucleul ORB ascunde

Localizarea obiectului

Implementarea obiectului - (limbaj, SO, calculator)

Starea de executie

Mecanismul de comunicare cu obiectul.

Clientul specifica obiectul tinta printr-o referinta de obiect.

Referinta este "opaca" pentru client.

Clientii pot obtine referintele de obiecte:

La crearea obiectului -clientul invoca o operatie a unui obiect fabrica de obiecte.

Prin serviciul de cataloage (directory service).

Prin conversia la/de la siruri de caractere.

Problema: cum se lanseaza aplicatia si cum poate obtine o referinta initiala de obiect.

Solutia: operatia resolve-initial-reference cu parametrul Name-Service furnizeaza aplicatiei referinta de obiect pentru serviciul de nume cunoscut de ORB.

OMG IDL - Interface Definition Language

IDL prevede declaratii pentru: tipuri de baza (short, long, char, etc), tipuri template (string, sequence), tipuri construite (struct, union, etc)

Forma generala a declaratiei unui modul:

Tipuri

Tipuri de baza

long (signed, unsigned) - 32 biti

long long (signed, unsigned) - 64 biti

short (signed, unsigned) - 16 biti

float, double, long double

char, wchar (wide char - caractere de 16 biti)

boolean

octet (8 biti).

enum

any - poate reprezenta orice tip de baza sau construit de utilizator.

Tipuri construite

Structura.

Union cu discriminant:

Tablou de lungime fixa, cu elemente de un singur tip:

Tipuri template

string si wstring marginite si submarginite

sequence tablou unidimensional, marginit sau nemarginit, cu toti membrii de acelasi tip

Constante

Operatorii sunt

unari -, +, ~ (bit complementat)

binari *, /. %, +, -, <<, >> (shift), & (si pe bitI), | (sau pe bitI), ^ (xor pe bitI)

Exemplu:

Definitii de interfete. Mostenirea.

O interfata poate mosteni de la una sau mai multe alte interfete.

student are atributele name si advisor si operatia load.

Exemplu

Principiul Open-Close

Rezolvarea ambiguitatilor.

Operatii IDL. Operatii oneway

O operatie denota un serviciu. Poate fi descrisa prin:

identificatorul operatiei

tipul rezultatului (orice tip IDL)

descrierea fiecarui parametru

nume

tip

(mod) directie

in client->server

out server->client

inout ambele directii

Exceptiile - clauza raises

Sintaxa unei operatii:

Exemplu:

O operatie oneway:

(1) nu poate contine parametrii out sau inout;

(2) trebuie sa nu intoarca un rezultat (tipul rezultatului, void); si

(3) sa nu contina clauza raises.

Exceptii si atribute

exceptiile arata producerea unor erori la executia unei operatii. Exceptiile pot fi clasificate in:

exceptii definite de sistem

exceptii definite de utilizator

Exceptie de sistem

consta dintr-un motiv major (CORBA:: BAD_PARAM) si

un cod minor.

Uzual, o functie de conversie exception_to_string permite conversia motivului si a codului intr-o forma descriptiva, texturala.

Exceptie utilizator este definita la fel ca o inregistrare

Un alt exemplu:

Atributele interfetei caracterizeaza starea unui obiect, intr-o maniera abstracta.

Logic, echivalent cu declararea unei perechi get/set de functii de acces la valoarea atributului.

Un atribut poate fi read-only, caz in care este accesibil doar prin get.

Forma generala este [readonly] attribute <datatype><name>. De exemplu,

Particularitati IDL

Dintre elementele pe care le gasim in limbajele de programare si nu le regasim in IDL, amintim:

toate definitiile dintr-o interfata IDL sunt publice

nu pot fi declarate variabile-membre

nu exista constructori si destructori

nu exista supraincarcarea bazata pe semnatura operatiilor

semnatura consta din

specificarea parametrilor si a rezultatului

specificarea exceptiilor si a tipului datelor care se asociaza exceptiilor

specificarea informatiei suplimentare de context, care poate afecta cererile

specificarea semanticii operatiei, asa cum apare ea clientului

nu exista tipuri parametrice

nu exista ierarhii de exceptii

aspecte semantice nu sunt incluse in interfete

domenii de valori pentru date

ordonarea legala a operatiilor

constrangeri de timp/spatiu asupra implementarilor

garantii tranzactionale ale interfetei

In particular, mentionam diferentele fata de C++:

nu exista tipurile int, unsigned int

char nu poate fi signed sau unsigned

parametrii

trebuie sa aiba nume

trebuie sa aiba directie

nu pot fi optionali

nu pot avea valori explicite

specificarea tipului rezultatului este obligatorie

nu exista structuri si uniuni anonime

nu exista pointeri

nu se poate face supraincarcarea operatorilor

Corespondenta intre IDL si C++ Tipuri de baza

Observatii.

Intre IDL si tipurile C++ se foloseste un nivel intermediar

Definitiile de tipuri sunt puse intr-o clasa C++ sau intr-un namespace (cu numele CORBA).

Pentru boolean s-a ales in Orbix unsigned char si nu bool din ANSI C++ pentru ca ANSI nu e o cerinta pentru CORBA in acest moment.

Regula de transmiterea parametrilor prntru tipurile de baza este simpla:

parametrii in si rezultatele se transmit prin valoare

parametrii out si inout se transmit prin referinta (&)

Module

Modulele IDL sunt mapate pe namespace in C++

Interfete

O interfata IDL este pusa in corespondenta cu o clasa C++.

se mapeaza in C++ pe

Referinte la obiecte

In C++, referintele la obiecte de un tip obT au tipul obT_ptr sau obT_var.

Contorul de referinte trebuie incrementat la crearea unei noi referinte la obiect si decrementat la stergerea referintei:

Gestiunea contorului de referinte este automata in cazul tipului _var. Exemplu:

CORBA static

Interfetele statice sunt generate direct, in forma unor stub-uri client, de precompilatoare IDL.

Avantaje:

programare mai usoara

verificari mai robuste de tipuri

executie simpla

autodocumentare

In schimb nu sunt la fel de flexibile ca apelurile dinamice.

Etapele de dezvoltare a aplicatiei

Figura se refera la cazul general, nu neaparat la varianta statica.

Se definesc interfete in IDL.

Pe baza descrierii IDL, un precompilator produce skeleton-uri (pentru server) si stub-uri (pentru clienti)..

Se adauga codul care implementeaza serverul.

Se face compilarea codului. Un compilator care accepta CORBA genereaza cel putin trei fisiere:

Fisiere import - care descriu obiectele pentru Interface Repository

Stub-uri client - pentru metodele definite in IDL

Skeleton-uri server ( up-call interfaces).

Leaga definitiile de interfete de InterfaceRepository.

Adaptorul de obiecte inregistreaza in Implementation Repository tipul si referinta oricarui obiect ce poate fi instantiat pe server.

Instantierea obiectelor pe server.

La aceste etape se adauga operatiile legate de client.

Pasii de programare (varianta statica):

descrierea interfetelor in IDL

implementarea interefetelor in C++

scrierea functiei principale a serverului, care creaza instante ale claselor, informeaza apoi broker-ul si adaptorul ca au fost facute initializarile si ca obiectele tinta sunt gata sa primeasca cereri

scrierea clientului care se conecteaza la server si foloseste serviciile acestuia.

Specificarea unei aplicatii elementare

Descrierea care urmeaza se refera la VisiBroker for C++ (produs de Visigenic).

Programul count folosit aici ca exemplu este o aplicatie rudimentara client/server.

Serverul suporta o singura metoda numita increment, care incrementeaza valoarea unei variabile numita sum si intoarce clientului valoarea acesteia.

Clientul trebuie sa faca urmatoarele operatii:

Sa stabileasca valoarea initiala a atributului sum

Sa invoce metoda increment de 1000 de ori

Sa afiseze valoarea finala a atributului sum, impreuna cu timpul de raspuns mediu.

Clientul trebuie sa poata trata exceptiile de sistem CORBA.

Interfata serverului (in fisierul count.idl):

Compilarea interfetei

In plus fata de generarea tipurilor in limbajul de programare dorit, un compilator IDL genereaza stub-uri client si skelton-uri server.

O invocare de operatie asupra unui obiect tinta se prezinta in C++ in forma apelului unei functii membre a unei clase. Cum se produce?

Compilatorul VisiBroker pentru C++ (numit Orbeline) produce patru fisiere, pe baza descrierii precedente.

Observatie. MICO produce doua fisiere, care reunesc continutul celor patru mentionate aici.

count_s.cpp - este skeleton-ul server pentru metodele clasei count.

count_s.hh este fisierul antet pentru server, care include definitiile de clase pentru skeleton-ul implementat in count_s.cpp.

count_c.cpp contine o clasa numita Count care serveste ca intermediar (proxy) al clientului pentru obiectul Count.

count_c.hh este fisierul antet pentru client.

Partea care intereseaza pentru implementarea serverului are urmatorul aspect:

Implementarea obiectului server

Implementarea CountImpl:

Implementarea serverului

Object Adapters. Rol:

Inregistrarea obiectelor - OA include operatii care permit unor entitati de limbaj de programare sa se inregistreze ca implementari de obiecte CORBA.

Generarea referintelor de obiecte CORBA

Activarea procesului server - daca este necesar, OA porneste procesele server in care pot fi activate obiectele

Activarea obiectelor - OA activeaza obiectele, daca ele nu sunt deja active la sosirea cererilor.

Demultiplexarea cererilor - OA coopereaza cu ORB pentru a asigura ca cererile pot fi primite prin conexiuni multiple, fara blocare nesfarsita a vreunei conexiuni

Apeluri de obiecte (object upcalls) - OA distribuie cererile catre obiectele inregistrate.

CORBA admite mai multe adaptoare dar actualmente prevede una: Basic Object Adapter (BOA).

I

Programul principal server.cpp.

Programul principal face urmatoarele operatii:

Initializeaza ORB.

Initializeaza BOA.

creaza obiectul CountImpl.

Folosind referinta BOA inregistreaza in BOA noul obiect creat, CountImpl.

Anunta BOA ca obiectul este gata sa lucreze si ca asteapta primirea unor invocari de servicii.

Tratarea exceptiilor se bazeaza pe mecanismul try-throw-catch.

Implementarea clientului

Partea client a aplicatiei consta dintr-un program main si fisierul sau antet. Programul trebuie sa realizeze urmatoarele operatii:

Sa initializeze ORB

Sa localizeze un obiect Count distant

Sa initializeze la zero atributul sum

Sa calculeze timpul de start

Sa invoce metoda increment de 1000 de ori

Sa calculeze timpul scurs

Sa afiseze rezultatele

Apelul lui _bind() nu este singura cale prin care un client poate obtine referinta unui obiect cu care sa comunice.

Alte solutii sunt:

serverul poate inregistra obiectul cu Naming Service;

un client poate primi o referinta de obiect ca rezultat sau ca parmetru out al unui apel de operatie IDL; aceasta va insemna totodata crearea unui "proxy" in spatiul de adrese al clientului.

CORBA dinamic

Invocarea statica - limitari

In cazul Internetului - sunt milioane de obiecte si apar frecvent noi servicii si interfete.

Exemplul unei porti (gateway) intre CORBA si un sistem strain.

CORBA suporta doua interfete pentru invocari dinamice:

Dynamic Invocation Interface (DII) pentru invocarile dinamice de cereri ale clientilor si

Dynamic Skeleton Interface (DSI) care realizeaza dispecerizarile dinamice catre obiecte.

Construirea unei invocari dinamice

Cum descopera clientii obiectele distante?

referinta de obiect, convertita in sir de caractere.

dupa nume, folosind Naming Service.

dupa atribute, folosind Trader Service.

referinta - rezultat sau parametru out al unei invocari anterioare.

Regasirea interfetei obiectului si constructia dinamica a cererii - Interface Repository (IR).

Etape:

(1) Obtinerea numelui interfetei.

get_interface intoarce o referinta la un obiect InterfaceDef din IR, care descrie interfata necesara clientului.

(2) Obtinerea descrierii metodei, din IR.

Putem folosi InterfaceDef pentru detalii despre interfata si metode.

lookup_name gaseste metoda - o referinta la un obiect OperationDef care descrie operatia

describe obtine definitia IDL completa a metodei.

Ca alternativa, describe_interface pentru a obtine o definitie completa a interfetei si pentru a gasi metoda care trebuie invocata.

(3) Crearea listei de argumente.

(3a) CORBA specifica Named Value List.

Pentru implementarea listei se foloseste pseudo-obiectul NVList.

Pentru crearea listei create_list si apoi add_item pentru a adauga listei fiecare argument.

(3b) Ca alternativa, create_operation_list pe un obiect CORBA::ORB, ca urmare a careia lista este creata de ORB.

(4) Crearea cererii.

(4a) se invoca create_request, cu numele metodei, NVList si un pointer la valoarea returnata.

(4b) Ca alternativa, versiune scurta a cererii, prin request.

(5) Invocarea cererii.

Apeland invoke

Apeland send_deferred; ulterior poll_response sau get_response; (invocare sincrona amanata).

Clientul invoca cererea si continua apoi prelucrarea; se apeleaza send_oneway.

Interfetele de invocare dinamica

Servicii din nucleul CORBA in patru interfete din modulul CORBA:

Dynamic Skeleton Interface

DSI permit ca serverele sa fie scrise fara a avea skeleton-uri compilate static in program.

Serverul poate defini o functie care va fi informata de orice invocare de operatie sau atribut si care:

determina identitatea obiectului invocat

determina numele operatiei, tipurile si valorile argumentelor

indeplineste actiunea ceruta de client

construieste si intoarce rezultatul.

Utilizare: constructia portilor (gateways) intre sisteme de obiecte CORBA si non-CORBA.

Initializarea

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

Initializare obiect: trei metode:

BOA_init

list_initial_services

resolve_initial_references

Scenariu

Obtinerea unei referinte de obiect pentru propriul ORB: ORB_init.

Obtinerea unui pointer la BOA.

Invocarea metodei BOA_init pe obiectul ORB.

Descoperirea serviciilor initiale disponibile: Invocarea list_initial_services pe pseudo-obiectul ORB.

Obtinerea referintelor de obiecte pentru serviciile dorite resove_initial_references.

Serviciul de nume (Naming Service)

Naming Service pastreaza p baza de date de legaturi (bindings) intre nume si referinte de obiecte. Serviciul are operatii pentru:

rezolvarea unui nume

crearea, stergerea, listarea unor legaturi.

Serviciul de Trading

Furnizor de servicii inregistreaza serviciile la trader:

O referinta de obiect

Tipul serviciului

Propritatile serviciului

Trader-ul pastreaza ServiceTypeRepository.

Clientul poate preciza

preferintele asupra ordinii ofertelor

politica (nr maxim oferte furnizate, amploarea cautarii).

Trader-i din domenii diferite pot crea federatii.

Scenariu - intervin urmatoarele interfete:

Lookup - permite clientilor si trader-ilor sa descopere si sa importe servicii; are o singura operatie, query;

Register - furnizorii de servicii anunta serviciile lor;

ServiceTypeRepository - depozitul tipurilor de servicii.

Scenariu:

serverul creaza un nou tip de serviciu cu add_type

serverul avertizeaza Trader-ul despre serviciul sau - export;

clientul obtine o lista de tipuri de servicii in depozit (list_types)

clientul obtine descrierea unui anumit tip (describe_type)

clientul invoca query pentru a obtine o lista a obiectelor

clientul invoca serviciul.

Activarea obiectelor

Standardul nu prevede o comanda explicita de pornire a unui obiect server

Interfata CORBA::BOA folosita pentru

a crea si distruge referinte de obiecte

a afla ori actualiza informatia despre referintele la obiecte.

BOA pastreaza evidenta obiectelor active si a implementarilor pe care le controleaza. Interfata BOA este folosita pentru

a avea acces la aceasta evidenta

a afla sau adauga informatii despre obiecte.

Metode CORBA::BOA.

create a unei noi instante de obiect si a obtine o referinta de obiect pentru ea. ORB-ului i se paseaza:

un nume de interfata care este descrisa in Interface Repository

un nume de implementare care este descrisa in Implementation Repository

un identificator unic (persistent - Persistent ID).

change_implementation actualizarea implementarii unui obiect existent.

get_id obtine identificatorul asociat cu obiectul.

dispose distruge referinta obiectului.

CORBA cere ca urmatoarele functii sa fie disponibile intr-o implementare BOA:

Un Implementation Repository care permite instalarea si inregistrarea implementarii unui obiect

Mecanisme pentru

o      generarea si interpretarea referintelor de obiecte,

o      activarea si dezactivarea implementarilor de obiecte,

o      invocarea metodelor si pasarea parametrilor.

Activarea si dezactivarea obiectelor implementarii

Invocarea metodelor prin skeleton.

CORBA face distinctie intre un server si obiectele sale.

Un server este un proces, o unitate de executie.

Un obiect implementeaza o interfata.

Un server poate contine

o      unul sau mai multe obiecte, eventual de clase diferite.

o      codul pentru implementarea unei singure metode.

In toate cazurile, obiectele sunt activate in serverele lor. CORBA defineste patru politici de activare:

Server partajat

Scenariu:

Serverul creeaza instante de obiecte (invocare fabrica de obiecte CORBA, sau constructor Java, C++, .)

Noile obiecte se inregistreaza in BOA.

o      obiect nou - invoca BOA::create apoi BOA::Object_is_ready.

o      obiect exista - el are starea inregistrata in memorie permanenta. Cu referinta la obiect, se obtine id unic (get_id) si apoi PersistentID. Pe baza lui se regaseste si incarca starea obiectului. Obiectul invoca apoi obj_is_ready.

Dupa ce a pornit toate obiectele, serverul invoca impl_is_ready.

Un obiect poate fi dezactivat prin deactivate_obj.

Un proces server care se termina anunta BOA prin deactivate_impl.

Server nepartajat

Fiecare obiect rezida intr-un proces separat. La prima invocare a unui obiect este pornit procesul corespunzator. Cand obiectul a incheiat faza de initializare, el anunta BOA prin obj_is_ready. Obiectul ramane activ pana la un apel dezactivate_obj. Ori de cate ori se apeleaza un obiect care nu este activ se porneste un alt obiect cu aceeasi implementare.

Acest mod se foloseste:

atunci cand obiectele necesita cantitati mari de resurse

cand se doreste marirea gradului de paralelism (ca alternativa la thread-uri).

Server-per-metoda

Un nou server este activat odata cu fiecare cerere si dezactivat odata cu satisfacerea cererii.

Nu este deci nevoie ca implementarea sa anunte BOA cand un obiect este activat/dezactivat.

Server persistent

Serverul este activat prin mijloace din afara adaptorului BOA.

Odata activat, serverul anunta BOA, printr-un apel impl_is_ready, ca poate primi cereri de la clienti fiind tratat in continuare ca un server partajat.

Pastrarea descrierilor interfetelor

CORBA este auto-descriptibil, dinamic si reconfigurabil.

IDL = limbajul metadatelor CORBA; IR (Interface Repository) = depozitul metadatelor CORBA (contine metadate identice cu descrierile IDL, dar in forma compilata).

CORBA defineste coduri de tip (tipuri de date definite in IDL) folosite pentru a crea structuri auto-descrise, utilizate:

de IR pentru a crea descrieri IDL independente de ORB

de DII pentru tipurile diferitelor argumente

de protocoalele Inter-ORB pentru campurile mesajelor inter ORB

de tipul any pentru a furniza un parametru generic auto-descris (clasa CORBA::Any are o functie membra type() care intoarce o valoare de tip CORBA::TypeCode_ptr).

Interfata CORBA TypeCode defineste metode de operare cu coduri de tip, compararea lor, obtinerea descriilor, etc.

Fiecare cod de tip are un identificator global unic - Repository ID care poate fi folosit intr-un spatiu de nume distribuit.

Asocierea cod <=> identificator se face la compilarea descrierilor IDL sau la integrarea lor in IR cu alte instrumente.

Structura Repository ID.

Prima componenta: identifica formatul si poate fi IDL sau DCE (doar aceste doua formate sunt definite In CORBA 2.0).

Pentru IDL, a doua componenta este o lista de identificatori despartiti prin /. De exemplu, interfata Itrf a modulului Mdl are numele Mdl/Interf.

A treia componenta = v_majora.v_minora

Interface Repository = baza de date de definitii de obiecte

Obiectele:

sunt containere de alte obiecte (Repository)

sunt continute de alte obiecte (ConstantDef)

sunt atat containere cat si continute (ModuleDef).

Implementari ORB

Joe

Produsul NEO de la Sun include:

Solaris NEO - mediu cu suportul de executie aplicatii NEO/JOE

Solstice NEO - instrumente gestiune obiecte sisteme distribuite

NEOworks - instrumente de dezvoltare a aplicatiilor (incluzand compilatorul IDL, un depanator, etc).

Joe este un Java ORB pentru clienti. Poate fi incarcat odata cu un applet Java sau poate fi instalat permanent pe masina client.

Joe include un compilator IDL-TO-Java care genereaza automat stub-uri Java din descrieri IDL. In prezent, obiectele server trebuie scrise pentru platforma NEO, care suporta C si C++. Versiunea IIOP pentru Joe va fi capabila sa comunice cu orice Java ORB care suporta IIOP.

Orbix

OrbixWeb V1 = implementare Java pentru clienti. Permite applet-urilor si aplicatiilor Java sa comunice cu servere Orbix folosind fie IIOP, fie protocolul Orbix (Iona).

VisiBroker for C++ si for Java

VisiBroker for Java = ORB client si server scris in Java.

Aplicatii CORBA in Internet - Modelul cu trei straturi (3-Tiers)

Nivel 1 = aspectele vizuale ale obiectelor comerciale.

Nivel 2 = al obiectelor-server (date persistente si funct. aplicatie).

Nivel 3 = aplicatiile.