TEMĂ DE...

UNIVERSITATEA ”POLITEHNICA” BUCUREȘTI FACULTATEA DE ELECTRONICĂ, TELECOMUNICAȚII ȘI TEHNOLOGIA INFORMAȚIEI

Bucuresti

2014

TEMĂ DE CASĂ

Common Object Request Broker Architecture

Profesor coordonator : Studenți:

Conf .dr. ing Ștefan STĂNCESCU Bogdan Alin TUDORACHE

Marian Adrian CEPOI

Dragos Ciprian ENOIU

CUPRINS

I. MODELUL OBIECT …………………………………………….…….……….….……. 1

1.1. Prezentare generală …………………………………………….….……..….………. 1

1.2. Semantică ……………………………………………………..………….………….. 2

1.2.1. Obiecte ……………………………………………………………………..….. 2

1.2.2. Cereri ………………………………………………………….…..……..……. 2

1.2.3. Crearea și distrugerea obiectelor ……………………………….…..…...…….. 3

1.2.4. Tipuri ………………………………………………………….…....…………. 3

1.2.5. Interfețe ……………………………………………………………..…...……. 4

1.2.6. Operații …………………………………………………………….....………. 4

1.2.7. Atribute …………………………………………………………….....………. 4

1.3. Implementare ……………………………………………………….……..………… 5

1.3.1. Execuția ……………………………………………………..……..…………. 5

1.3.2. Construcția …………………………………………………………....………. 5

1.4. Broker-ul de cereri de obiecte …………………………………………...…..………. 6

1.4.1.Introducere în sisteme distribuite ……………………………………..………. 6

1.4.2.ORB- privire generală …………………………………….……………..……. 7

II. ARHITECTURA CORBA ………………………………………………………...……. 8

2.1. Structura Object Request Broker ……………………..………………………..……. 9

2.1.1. Implementarea obiectelor ………………………..……………………..……. 10

2.1.2. Referințele obiectelor ……………………………..…………………………. 11

2.1.3. Limbajul de definire a interfeței (OMG IDL) ……..………………...………. 11

2.1.4. Maparea OMG IDL în limbaje de programare ……..…………………...…... 12

2.1.5. Adaptoare obiect (OA) ………………………………..…………………...… 13

2.1.6. Interfața ORB …………………………………………..…………………..... 13

2.2. Exemple ORB …………………………………………………..………….………. 14

2.2.1. Server-based ORB ………………………………………..……...………….. 15

2.2.2. System-based ORB ………………………………………..………………… 15

2.2.3. Library-based ORB ……………………………………….....………………. 15

2.3. Structura implementarii unui obiect ………………………………..………………. 16

III. INTEROPERABILITATEA …………………………………………..……..………. 17

3.1. Elementele interoperabilității …………………………………………..……..……. 17

3.1.1. Arhitectura interoperabilității ORB ………………………………..…....…… 17

3.1.2. Suportul Inter-ORB Bridge ………………………………………….....……. 18

3.1.3. General Inter-ORB Protocol (GIOP) …………………………………...……. 18

3.1.4. Internet Inter-ORB Protocol (IIOP) ………………………..………..………. 19

3.2. Exemple de soluții ale interoperabilității …………………………..….……………. 20

3.3. Factori de motivare …………………………………………………...……….……. 20

3.3.1. Diversitatea implementării ORB ……………………………….....…………. 21

3.3.2. Limitele ORB ……………………………………………………..…….…… 21

3.4. Design-ul interoperabilității ………………………………………………..…...….. 22

BIBLIOGRAFIE ………………….………………………………………………....……. 23

Bogdan Alin TUDORACHE Modelul obiect

Page | 1

1. MODELUL OBIECT

In acest capitol va fi descris modelul obiect care sta la baza arhitecturii CORBA.

Denumirea de C.O.R.B.A. este o prescurtare de la Common Object Request Broker

Architecture, si acesta isi are echivalentul in romana de: Arhitectura Brokerului de Raspuns la

Cererile Obiectelor Comune. Aceasta arhitectura este un derivate al Core Object Model (

Modelul Obiectului Nucleu).

1.1. Prezentare generala

Acest model oferta o prezentare organizata a conceptelor de obiect si a definirii

acestora. Defineste un model partial pentru calcul care inglobeaza caracteristicile principale

are obiectelor, asa cum sunt acestea folosite in procesele tehnologice. Modelul descris este

un obiect model concret, care poate fi diferit de altele prin anumite caracteristici: poate

elabora modele abstracte facandu-le mai specifice ( de exemplu: definirea tipului de cereri a

parametrilor ) sau prin popularea modelului .

Un sistem obiect este o colectie de obiecte care izoleaza clientii ( solicitantii de

servicii ) de providerii de servicii printr-o interfata binedefinita, care incapsuleaza. Intr-un

mod particular , clientii sunt izolati de implemetarea serviciilor cum ar fi reprezentarea

datelor dar si a codului executabil.

Modelul obiect descrie concepte care sunt importante pentru clienti, incluzand

concepte cum ar fi crearea obiectelor si operatii de identitate si ce de cerere, tipuri si

semnaturi. Apoi descrie conceptele legate de implementarea obiectelor, incluzand conceptele

din spatele implementarii,metodele, motoarele de executie si de activare.

Cand ne referim la acesa ne gandim ca este cel mai specific si cel mai prescriptiv cand

vine vorba de definirea conceptelor importante pentru clienti. Discutia din spatele

implementarii obiectului este mai sugestiva, cu dorinta de a acorda maxima libertate

diferitelor tehnologii de creare a obiectelor pentru a reprezenta mai tarziu diferite moduri de

implementare a acestora.

Acest model este un exemplu clasic de model obiect in care clientii trimit un mesaj

unui obiect. Conceptual, obiectul interpreteaza mesajul si decide ce actiune sa indeplineasca.

Ca majoritatea modelelor obiect, un prim paramentru distins este necesar, acesta identifica

operatia care are loc; interpretarea mesajului de catre obiect implica selectarea unei metode

bazate pe operatii specifice. In mod general, metoda selectiei poate fi indeplinita fie de catre

obiect fie de catre ORB. ORB-ul reprezinta Object Request Broker, un program intermediar

care promoveaza interoperabilitatea prin sisteme de obiecte distribuite de la diferite surse. In

esenta acesta raspunde la cererile primite.


Page | 2

1.2.Semantica

Un sistem obiect ofera servicii clientilor. Un client, al unui serviciu, reprezinta o

entitate capabila sa raspunda la cererile trimise de catre serviciu.

1.2.1 Obiecte

Acest timp de sistem contine entitati ca obiecte. Obiectul este in esenta o entitate

incapsulaibla, identificatila care ofera unul sau mai multe servicii care pot fi cerute de catre

un client.

1.2.2 Cereri

Clientii necesita servicii prin emiterea de cereri.

Termenul de cerere este folosit pentru a descrie o necesitate, o serie de evenimente au

loc intre clienti si sistem iar ultimul eveniment este cel care cauzeaza initierea cererii. Cand

ne referim la o astfel de operatiune trebuie sa tinem cont de niste informatii asociate cu

aceasta, cum ar fi obiectul tinta, niciunul sau mai multi paramentri, contextul in care s-a emis

cererea si cel mai important modul ( formularul) de emisie al cererii.

Formularul este o descriere sau un tipar care poate fi evaluat sau efectuat de mai

multe ori pentru a initia trimiterea de cereri. O alternativa a acestuia o reprezinta solicitare

trimitsa catre interfata dinamica de invocare, pentru a crea o structura de invocare, la care

adaugam argumentul.

O valoare reprezinta orice poate fi considerat ca un paramentru intr-o cerere. Mai

particular, o valoare este o instanta a OMG-Object Management Group . Exista si valori non-

obiect, care fac in esenta acelasi lucru ca si valorile referitoare la obiecte.

Referinta unui obiect, este o valoare care se refera intr-un mod fiabil la un anumit

obiect, la un obiect in particular. Speficit, un obiect referinta va apartine mereu de acelasi

obiect indiferent de cate ori referinta este folosita intr-o cerere. Un obiect poate fi definit de

mai multe referinte diferite.

O cerere, reprezinta un declansator pentru ca un serviciu sa fie efectuat in partea

clientului. Un rezultat posibil al operatiei este inapoierea rezultatelor clientului. Daca in

timpul indeplinirii acestei operatii are loc o exceptie declansata de catre o intrerupere,

exceptia este returnata, iar pe langa aceasta este posibil sa apara si paramentri aditionali.

Parametrii din cerere sunt identificati prin pozitie, acestia pot sa fie folositit atat

pentru introducerea datelor cat si la iesire sau chiar parametru de intrare si iesire. De


Page | 3

asemenea o cerere poate returna un sigura valoare rezultat, dar rezultatele pot fi stocate si in

parametrii de iesire sau intrare-iesire.

Cererile au urmatoarele caracteristici:

Orice valoare dintr-un parametru nu este pastrata permanent, aceasta putand fi

eliminata.

Ordinea in care parametrii de iesire sunt scrisi nu este mereu aceeasi.

Rezultatul si valorile care sunt stocate in parametrii de iesire sau de intrare-iesire sunt

nedefiniti daca apar exceptii.

1.2.3 Obiectele de creare si distrugere

Cand ne referim la client, pentru acesta nu exista mecanisme speciale pentru creare

sau distrugere. Obiectele fac aceste operatiuni din cauza fluxului de cereri primite, valorile

pur si simplu sunt inlocuite. Rezultatul operatiei de creare al obiectelor este primit de catre

client in forma unui obiect referinta care are legatura cu un nou obiect.

1.2.4 Tipuri

Cand ne referim la un tip, o identificam ca o entitate asociata unui predicat, definit

unor entitati. Acestea sunt folosite fie ca metode de restrictie a unor posibili parametri sau

pentru a caranteriza un rezultat anume. Tipul unui obiect este in stransa legatura cu referintele

acestuia.

Acestea pot sa fie:

Numere intregi (integer) pe 16/32/64 biti sau in baza 2 ( fara semn)

In precizie simpla(32biti), in precizie dubla(64biti) sau precizie estinsa

Caractere

Boolene: True si False

String ( litere/cifre/caractere) de orice lungime

Any

Sau pot sa fie construite:

Tipuri valoare, care specifica stari

Tipuri secventa

Tipuri array

Tipuri interfata


Page | 4

1.2.5. Interfete

O interfata reprezinta o lista continand operatiile posibile pe care un client le poate

solicita de la un obiect, prin acea interfata. Este o descriere a modului in care un serviciu este

implementat de catre obiectele care suporta interfata, accesat prin intermediul acelor posibile

operatii.

Tipul interfetelor este dat de obiectul tip, obiectul referinta va indeplini obiectul tip,

numai daca obiectul referinta va duce la capat cererile interfetei.

Interfetele functioneaza dupa Principiul Substitutiei lui Libskov, care zice:” Funcțiile

care utilizează pointări sau referințe la clase de bază trebuie să poată folosi instanțe ale

claselor derivate fără să își dea seama de acest lucru”1. Acest lucru translatat in modelul

obiect inseamna ca: daca interfata A este derivatadin interfata B, atunci referinta catre un

obiect care sustine interfata A poate fi folosita unde tipul formal al unui parametru este

declarat ca fiind B. alupigus

1.2.6.Operatii

Actul prin care se face o cerere reprezinta invocarea unei operatii. Aceasta este

identificata de catre identificatorul operatiei.

O operatie are o semnatura care descrie valorile returnate de parametrii si rezultatele

returnate.

Semnatura poate fi formata din: o specificare a parametrilor necesari pentru acea

operatie, o specificare a unui rezultat al operatiei, un indicator a unei informatii contextuale

aditionale.

Operatia raspunde doar la o singura cerere, este de sine statatoare. Are paramentri

caracterizati prin tip si mod. Modul indica cum trebuie sa fie pasata valoarea, de la client la

server(In), de la server la client(Out), sau combinat (InOut). Paramentrul reprezinta

constrangerea posibilei valori care este pasata in directia dictata de catre mod.

1.2.7.Atribute

O interfata poate avea mai multe atribute. Un atribut este echivalentul logic al

declararii unei perechi de functii: una sa retur \neze valoarea atributului si alta sa seteze

valoarea atributului. Acesta poate fi si read-only (numai pentru citire), in acest caz functia de

returnare este predefinita.

1 http://www.aut.upt.ro/staff/diercan/data/PSSC/curs-03.pdf


Page | 5

1.3.Implementarea

Implementarea unui obiect sistem intretine activitatile computationale necesare sa

afecteze comportamentul serviciilor dorite. Aceste activitati includ procesarea rezultatelor sau

reimprospatarea starii sistemului. In timpul acestui proces, cereri aditionale pot fi

transmise.Modelul implementarii este alcatuit din doua parti: modelul de exevutie si modelul

de constuctie. Executia descrie cum serviciile au loc, dar constructia ne arata cum sunt

definite.

1.3.1.Executia

Un serviciu dorit este realizat intr-un sistem computational prin executarea unui cod

care opereaza asupra unor date. Datele reprezinta componenta a starii sistemului

computational, in timp ce codul efectueaza serviciul cerut, care poate schimba starea acestuia.

Codul care executat sa indeplineasca un serviciu se numeste metoda. Metoda este o

descriere a computatiei care poate fi interpretata si ca un motor de executie. Metoda este

definita de catre un format care caracterizeaza un set de motoare.

Motorul de executie este o masina abstracta care interpreteaza metodele de un anumit

format, lucru care duce la stabilirea carei computatie sa fie indeplinita. Executia unei metode

se numeste activare.

Cand un client face o solicitare, o metoda a unui obiect tinta este apelata. Parametrii

de intrare trimisi de la solicitant sunt pasati prin metoda si parametrii de iesire sunt returneaza

solocitantului valoarea dorita

1.3.2.Constructia

Obiectul sistemului computational pune la dispozitie metode pentru realizarea

comportarii de cerere. Aceste mecanisme inclut si definitia obiectului stare, definitia

metodelor si defilitia cum ar trebui sa fie aleasa infrastructura obiectului pentru a selecta

metoda de executie si a alege portiunile obiectului stare cele mai potrivite.

Mecanismele, de asemenea trebuie sa descrie actiuni concrete asociate crearii

obiectului, asemenea asocieri are noului obiect cu metoda potrivita.

Implementarea unui obiect, sau pur si simplu implementarea, este definitia care

confera informatia necesara pentru a crea un obiect si a-i overi posibilitatea sa parcicipe in

asigurarea unui set adecvat de servicii. O implementare tipic include, pe langa alte lucruri,

definitii ale metodelor cu care opereaza asupra starii unui obiect, dar si informatii despre

tipurile obiectului respectiv.


Page | 6

1.4.Brokerul de cereri al obiectelor

1.4.1.Introducere in sisteme distribuite

Distributia computationala este un domeniu in informatica care studiaza sistemele

distribuite. Un sistem distribuit este un sistem software in care componentele dintr-o retea de

calculatoare comunica si isi coordoneaza actiunile prin trimiterea si receptionarea de mesaje.

Echipamentele care alcatuiesc reteaua comunica intre ele, interactioneaza, pentru a putea

ajunge sa-si atinga scopul dorit.

Computatia distribuita se mai refera si la folosirea sistemelor distribuite pentru a

rezolva probleme computationale, pentru a ajunge la un rezultat problema este impartita in

mai multe task-uri, fiecare dintre ele fiind rezolvate de unul sau mai multe calculatoare,

acestea comunicand intre ele prin mesaje.2

Poza de mai jos reprezinta o comparatie intr-un sistem distribuit( a si b ) si un sistem

paralel(c ). Intr-un sistem distribuit nu exista un o magistrala de memorie comuna, fiecare

componena este o unitate de sine statatoare, acestea avand acces la date diferite si oferind

doar rezultate.

3

2 http://en.wikipedia.org/wiki/Distributed_computing 3 Imagine preluata de pe site-ul : http://en.wikipedia.org/wiki/File:Distributed-parallel.svg

http://en.wikipedia.org/wiki/Distributed_computing

http://en.wikipedia.org/wiki/File:Distributed-parallel.svg


Page | 7

1.4.2. ORB-privire generala

ORB este o prescurtare de la Object Request Broker, si anume Brokerul de raspuns la

cereri al obiectelor, este un software intermediar (middleware) care permite crearea legaturii

intre calculatoare pe reteaua de calculatoare. ORB-ul promoveaza interoperabilitatea dintre

sisteme obiect distribuite de la diferiti furnizori, in timp ce alta parti comunica intre ele tot

prin intermediul ORB.

Acesta se ocupa de transformarile din procesele structurilor de date si ale secventelor

nealterate de biti, transmisi pe retea. Procesul in sine, se numeste serializare, iar in plus fata

de aceastamai are si ale caracteristiici, de exemplu: tranzactii distribuite sau chiar programare

in timp real.

In limbaje de programare pe orientate pe obiect, ORB-ul ofera structura de rezistenta,

scheletul pe care are loc comunicarea de-a lungul retelei. Cand ne referim la client, aici se

creeaza si se invoca obiecte numite stub, cioturi, folosite ca singura parte vizibila si care

poate fi utilizata in aplicatia clientului. Dupa crearea acestora, ORB-ul serializeaza datele si

trimite o cerere catre partea-server. Aici, este localizat obiectul tinta, se executa operatia

dorita si se returneaza rezultatul.

Implementari:

CORBA- Common Object Request Broker Architecture

Ice- Internet Communications Engine – Motorul de cautare al Internetului

ORBit- un ORB CORBA folosit ca intermediat Pentru GNOME ( un mediu desktop si

o inferfata grafica pentru utilizator)

In general implementarile ORB se leaga de folosirea Arhitecturii CORBA, acesta

fiind foarte folosit iar aplicatiile foarte vaste.

Marian Adrian CEPOI Arhitectura CORBA

Page | 8

II. ARHITECTURA CORBA

Din dorința de a orienta şi facilita integrarea unor sisteme dezvoltate separat, într-un

singur mediu distribuit eterogen, OMG (Object Management Group) – consorţiu cuprinzând

peste 700 de dezvoltatori, comercianţi şi utilizatori de software – a elaborat, adoptat şi

promovat standarde pentru aplicaţii în medii distribuite. Unul dintre ele este CORBA –

Common Object Request Broker Architecture, care se constituie într-un cadru de dezvoltare a

aplicaţiilor distribuite în medii eterogene.

CORBA este cel mai ambiţios proiect al OMG, la care au aderat toate marile firme de

software, cu excepţia Microsoft, firmă ce a dezvoltat propriul său model, DCOM (Distributed

Component Object Model), incompatibil cu CORBA4.

CORBA este elementul cheie al OMA – Object Management Architecture și un model

propus de OMG pentu a transpune în mediu distribuit eterogen toate avantajele programării

orientate pe obiecte, incluzând: dezvoltarea rapidă, reutilizabilitatea, protecţia implicită, etc.

Arhitectura fundamentală a standardului CORBA conține 4 categorii de obiecte și o

magistrală prin care se realizează legătura acestora:

1) Serviciile CORBA (CORBA services) sunt obiecte standardizate ce pun la dispoziția

celorlate obiecte din sistem operații și servicii fundamentale: serviciul de nume, serviciul de

persistență, serviciul de concurență, serviciul de securitate, serviciul de tranzacții, etc.

2) Domeniile CORBA (CORBA domains) reprezintă ˜standardele verticale˜ adoptate de

OMG pentru diferite categorii (domenii) de aplicații: economie, medicină, telecomunicații, etc.

3) Facilitățile CORBA (CORBA facilities) standardizează interfețe comune mai multor

domenii (ca de exemplu: gestiunea unor documente complexe, gestiunea sistemului, etc.). Se

pot extinde în domeniile verticale.

4) Aplicațiile sunt considerate tot ca obiecte, cu interfețe definite de programator5.

Avantajele CORBA:

- Independență de sistemul de operare și de limbajul de programare;

- Integrarea apliacțiilor existente;

- Infrastructura bogată în obiecte distribuite;

- Transparența locației;

- Transparența rețelei;

- Interfața de invocare dinamică.

Dezavantajele CORBA:

- Investiție inițială ridicată. Aplicațiile bazate pe CORBA necesită investiții enorme

în ceea ce privește training-ul și lansarea arhitecturii, chiar și pentru aplicații de

dimensiuni mici;

- Disponibilitatea serviciilor CORBA. Serviciile obiect specificate de OMG lipsesc

încă în produse care implementeazaă conceptele;

4 Curs: Sisteme de Programe pentru Rețele de Calculatoare, Valentin Cristea, Facultatea de Automatică și

Calculatoare, UPB 5 Curs: Programarea rețelelor de calculatoare, Ioan Jurca, Universitatea Politehnica din Timișoara


Page | 9

- Scalabilitatea. Datorită naturii strâns cuplate a arhitecturii CORBA orientate pe

legături, scalabilitatea înaltă așteptată în aplicațiile companiilor poate să nu fie

atinsă6.

Figura 2.0. Arhitectura CORBA7

2.1. Structura Object Request Broker

ORB este serviciul distribuit care implementeaza cererea obiectului la distanţă:

- localizează obiectul la distanţă din reţea;

- comunică solicitarea la obiect;

- aşteaptă rezultatele şi, atunci când sunt disponibile,

- comunică aceste rezultate înapoi la client.

ORB implementează transparent locaţia. Exact acelaşi mecanism de solicitare este

utilizat de către client şi obiectul CORBA, indiferent unde se află obiectul. ORB

implementează independenţa limbajului de programare pentru solicitări şi pentru obiectul

CORBA și face translația necesară dintre limbajele de programare (pentru cele mai utilizate

limbaje)8.

ORB este o magistrală pentru obiecte care oferă un mecanism transparent pentru

expedierea cererilor și recepționarea răspunsurilor către și de la obiecte, indiferent de mediu și

locația lor.

6 Sisteme distribuite – Tehnologii, Dana Petcu, Universitatea de Vest din Timișoara, 2009 7 Curs: Sisteme de Programe pentru Rețele de Calculatoare, Valentin Cristea, Facultatea de Automatică și

Calculatoare, UPB 8 Curs: Medii de proiectare şi programare, Vasile Cioban, Universitatea Babes-Bolyai din Cluj-Napoca


Page | 10

Figura 2.1. Structura de bază a unui ORB9

2.1.1. Implementarea obiectelor

O implementare obiect oferă semantica obiectului, de obicei, prin definirea datelor

pentru instanța obiect și codului pentru metodele obiectului. De multe ori implementarea va

folosi alte obiecte sau software suplimentar pentru a pune în aplicare comportamentul

obiectului. În unele cazuri, funcția principală a obiectului este de a avea efecte secundare asupra

altor lucruri care nu sunt obiecte.

O varietate de implementări de obiecte pot fi susținute, inclusiv servere separate,

biblioteci, un program pe metodă, o aplicație încapsulată, o bază de date orientată pe obiecte,

etc. Prin utilizarea de adaptoare obiect suplimentare, putem să asigurăm practic orice stil de

implementare a obiectului.

Figura 2.1.1. Arhitectura CORBA ORB

9 Laborator: Sisteme de Programe pentru Rețele de Calculatoare, Valentin Cristea, Facultatea de Automatică și

Calculatoare, UPB


Page | 11

În general, implementările obiect nu depind de ORB sau modul cum clientul invocă

obiectul. Implementările obiect pot selecta interfețe de servicii dependente de ORB prin

alegerea de adaptoare obiect10.

2.1.2. Referințele obiectelor

Clientul specifică obiectul ţintă printr-o referinţă de obiect. Aceasta se creează odată cu

obiectul şi se referă la acesta în mod unic, atâta timp cât obiectul există. Referinţa este “opacă”

pentru client, în sensul că acesta nu o poate modifica. Referinţele de obiecte sunt gestionate

exclusiv de ORB şi au formate standard (ca în IIOP) sau proprietare (de firmă).

Clienţii pot obţine referinţele de obiecte pe mai multe căi:

• La crearea obiectului – clientul poate crea un obiect şi obţine referinţa sa. CORBA

nu are o operaţie specială de creare de obiecte. Pentru a crea un obiect, clientul

invocă o operaţie a unui obiect fabrică de obiecte. Crearea întoarce o referinţă de

obiect;

• Prin serviciul de cataloage (directory service) – ambele Naming Service și Trading

Service permit obţinerea de referinţe, după nume, respectiv după proprietăţi;

• Prin conversia la/de la şiruri de caractere – o referinţă de obiect poate fi convertită

în şir de caractere şi înapoi în referinţă putând fi utilizată după conversie, atât timp

cât obiectul există11.

2.1.3. Limbajul de definire a interfeței (OMG IDL)

Pentru ca un obiect (client) să adreseze cereri unui obiect (server), acesta trebuie să

cunoască tipurile operaţiilor suportate de obiect. Acestea sunt precizate de specificaţia

interferenţei obiectului.

Pentru a realiza independenţa faţă de limbajul de programare în care este descris

obiectul, interfaţa este definită într-un limbaj neutru, IDL – Interface Definition Language.

Interfeţele sunt asemănătoare claselor în limbajul C++ şi interfeţelor în limbajul Java.

OMG IDL definește tipurile obiectelor prin specificarea interfețelor acestora. De

asemenea, dispune de mai multe declaraţii pentru: tipuri de bază (short, long, char, etc), tipuri

template (string, sequence), tipuri construite (struct, union, etc).

10 Common Object Request Broker Architecture: Core Specification, Object Management Group, Inc., 2004 11 Curs: Sisteme de Programe pentru Rețele de Calculatoare, Valentin Cristea, Facultatea de Automatică și

Calculatoare, UPB


Page | 12

Figura 2.1.3. Declarații IDL

2.1.4. Maparea OMG IDL în limbaje de programare

Diferite limbaje de programare structurată sau orientate pe obiecte ar putea prefera să

acceseze obiectele CORBA în moduri diferite. Pentru limbajele orientate pe obiecte, poate fi

de dorit ca obiectele CORBA să fie văzute ca obiecte de limbaj de programare. Chiar pentru

limbaje de programare structurată, aceasta este o idee bună pentru a ascunde reprezentarea

exactă ORB a referinței obiectului, numele metodei, etc.

Există un limbaj de mapare care definește modul în care tipurile IDL sunt mapate pe

tipul sistem al limbajului țintă. Suplimentar, maparea specifică modul în care anumite interfețe

ORB trebuie să apară la programatorii care utilizează limbajul. Sunt definite astfel de mapari

cel puțin pentru limbajele: C, C++, Smalltalk, Ada.

O mapare particulară a OMG IDL pentru un limbaj de programare ar trebui să fie

aceeași pentru toate implementarile ORB. Limbajul de mapare include definirea tipurilor de

date specifice limbajului și interfețele de procedură pentru a accesa obiecte prin ORB. Acesta

include structura interfeței stub client (nu este necesară pentru limbaje orientate pe obiecte),

interfața invocare dinamică, scheletul de implementare, adaptoarele obiect și interfața ORB

directă.

Un limbaj de mapare definește, de asemenea, interacțiunea dintre invocațiile obiectului

și firele de control din client ori implementare. Cele mai frecvente mapări furnizează convorbiri

sincrone, în care se întoarce o rutină în cazul în care operațiunile obiectului sunt complete.

Mapările suplimentare pot fi furnizate pentru a permite inițierea unui apel, iar controlul să

revină programului. În astfel de cazuri, rutine suplimentare, specifice limbajului, trebuie să fie

furnizate pentru a sincroniza fire de control ale programului cu invocarea obiect12.

12 Common Object Request Broker Architecture: Core Specification, Object Management Group, Inc., 2004


Page | 13

2.1.5. Adaptoare obiect (OA)

Un adaptor obiect este o funcționalitate a server-ului, ce oferă un mecanism pentru

implementări obiect CORBA cu scopul de a comunica cu ORB şi vice-versa.

Un adaptor obiect extinde, de asemenea, funcţionalitatea ORB. Este întins pe suprafaţa

ORB pentru a furniza o interfaţă între ORB şi implementarea obiectului.

Adaptoarele obiect pot fi de asemenea folosite pentru a furniza servicii specializate

optimizate pentru un mediu particular, platformă, sau implementarea unui obiect13.

Adaptorul de obiecte face ca o metodă a obiectului la distanță să fie invocabilă

clientului: face înregistrările implementărilor în depozit și le accesează la nevoie.

Unele dintre serviciile oferite de un adaptor obiect sunt:

- înregistrarea de implementări obiect ale server-ului;

- activarea și dezactivarea implementărilor de obiecte;

- instanțierea obiectelor în timpul rulării;

- generarea şi gestionarea referinţelor obiect;

- maparea referinţelor obiect la implementarea lor.

În timp ce multe implementări de adaptor obiect pot exista pentru situaţii unice, o

specificaţie CORBA necesită doar implementări pentru un Adaptor Obiect de Bază (BOA) sau

un Adaptor Obiect Portabil (POA), care este o versiune portabilă a BOA.

2.1.6. Interfața ORB

Interfața ORB este interfața care merge direct la ORB, care este aceeași pentru toate

ORB-urile și nu depinde de interfața obiectului sau a adaptorului obiect. Deoarece cea mai

mare parte a funcționalității ORB este asigurată prin intermediul adaptorului obiect, stub-uri,

skeleton, sau invocarea dinamică, există doar câteva operațiuni care sunt comune pentru toate

obiectele. Aceste operațiuni sunt utile atât clienților cât și implementării de obiecte.

Interfețele ORB sunt specificate în IDL cu o descriere în limba engleză a semanticilor

fiecărei operații definite pe interfață. Implementări diferite pot interpreta diferit specificația

redactată în engleză.

Interfața ORB furnizează un număr de operații care pot fi aplicate oricărui obiect.

Operațiile furnizate de interfața ORB includ:

- operații care acoperă referințele obiectelor la șiruri și invers;

- operații de release() și duplicate() pentru gestiunea memoriei utilizate de obiecte

și de referințele obiect;

- operația get_interface() necesară pentru interfața de stocare;

- operația de create_request() utilizată în conjuncție cu interfața de invocare

dinamică.

13 Curs: Medii de proiectare şi programare, Vasile Cioban, Universitatea Babes-Bolyai din Cluj-Napoca


Page | 14

2.2. Exemple ORB

Există o mare varietate de implementări posibile în cadrul CORBA. Această secțiune

va ilustra unele dintre diferitele opțiuni. Rețineți că un anumit ORB poate sprijini mai multe

opțiuni și protocoale de comunicare.

Etapele de dezvoltare a aplicaţiei:

Figura 2.2. Paşii necesari pentru crearea unui server şi a unui client care comunică prin ORB.

1. Se definesc interfeţe în IDL; acestea precizează ce operaţii sunt disponibile la un server

şi cum pot fi invocate;

2. Conform descrierii IDL, un precompilator produce skeleton-uri (pentru server) şi stub-

uri (pentru clienţi). Când clientul şi obiectul ţintă sunt în acelaşi spaţiu de adrese,

comunicarea lor se poate face direct, nefiind necesar un cod suplimentar. Când aceştia

sunt în spaţii diferite, este necesar un cod suplimentar la client (stub) pentru

transmiterea invocărilor, şi la obiectul ţintă (skeleton), pentru recepţia lor şi

transmiterea lor către obiectul ţintă;

3. Se adaugă codul care implementează serverul;

4. Se face compilarea codului. Un compilator care acceptă CORBA este, în mod obişnuit,

capabil să genereze cel puţin trei fişiere:

- Fişiere import – care descriu obiectele pentru Interface Repository;

- Stub-uri client – pentru metodele definite în IDL; ele sunt invocate de clienţi pentru

acces la server;

- Skeleton-uri server – care apelează metodele serverului (mai sunt numite up-call

interfaces);


Page | 15

5. Se leagă definiţiile de interfeţe de Interface Repository (se foloseşte un utilizator).

Informaţia din IR este accesibilă clienţilor la execuţie;

6. Adaptorul de obiecte înregistrează în Implementation Repository tipul şi referinţa

oricărui obiect ce poate fi instanţiat pe server. ORB foloseşte aceste informaţii pentru a

localiza obiectele active sau să ceară activarea unor obiecte;

7. Instanţierea obiectelor pe server – cerută de object adapter conform unei anumite

strategii.

La aceste etape se adaugă operaţiile legate de client14.

2.2.1. Server-based ORB

Pentru a centraliza managementul ORB, toți clienții și implementările pot comunica cu

unul sau mai multe servere a căror sarcină este de a ruta cereri de la clienți la implementări.

ORB ar putea fi un program normal în ceea ce privește sistemul de operare de bază, iar IPC

normală ar putea fi utilizată pentru a comunica cu ORB.

2.2.2. System-based ORB

Pentru a spori securitatea, robustețea, și performanța, ORB ar putea fi furnizat ca un

serviciu de bază al sistemului de operare. Referințele ar putea fi falsificate, reducând

cheltuielile de autentificare pentru fiecare cerere. Deoarece sistemul de operare poate ști locația

și structura clienților și implementărilor, ar fi posibil pentru o varietate de optimizări să se

implementeze, de exemplu, evitarea colectării atunci când ambele sunt pe aceeași mașină.

2.2.3. Library-based ORB

Pentru obiectele care sunt ușoare și ale căror implementări pot fi partajate,

implementarea ar putea fi de fapt, într-o bibliotecă. În acest caz, taloanele ar putea fi metodele

actuale. Acest lucru presupune că este posibil ca un program client să aibă acces la datele

obiectelor și că implementarea are încredere în client pentru a nu deteriora datele15.

14 Curs: Sisteme de Programe pentru Rețele de Calculatoare, Valentin Cristea, Facultatea de Automatică și

Calculatoare, UPB 15 Common Object Request Broker Architecture: Core Specification, Object Management Group, Inc., 2004


Page | 16

2.3. Structura implementării unui obiect

O implementare obiect oferă starea și comportamentul unui obiect real. Implementarea

obiectului poate fi structurată într-o varietate de moduri. Pe langă definirea metodelor pentru

operațiunile în sine, o implementare va defini, de obicei, procedurile de activare și dezactivare

a obiectelor și va folosi alte obiecte sau facilități non-obiect pentru a face starea obiectului

persistentă, pentru a controla accesul la obiect, precum și pentru a implementa metodele.

Implementarea obiectului (a se vedea figura 2.3.), interactionează cu ORB într-o

varietate de moduri pentru a-și stabili identitatea, de a crea noi obiecte, și de a obține servicii

dependente de ORB. Ea face acest lucru în primul rând prin intermediul accesului la un adaptor

obiect, care oferă o interfață pentru serviciile ORB și care este convenabil pentru un anumit stil

de implementare obiect.

Figura 2.3. Structura unei implementări tipice a obiectului

Datorită gamei de posibile implementări obiect, este dificil de a fi definitiv cu privire

la modul în care este structurată o implementare obiect.

Atunci când are loc o invocare, nucleul ORB, adaptorul obiect, și skeleton asigură că

este făcut un apel la metoda adecvată implementării. Un parametru a-l acestei metode indică

obiectul invocat, care metodă se poate utiliza pentru a localiza datele obiectului. Parametri

suplimentari sunt furnizați în conformitate cu definiția skeleton.

Atunci când este creat un obiect nou, ORB poate fi anunțat astfel încât să știe unde să

găsească aplicare pentru acel obiect. De obicei, punerea în aplicare, de asemenea, se

înregistrează ca implementarea obiectului unei anumite interfețe, și specifică modul în care

începe implementarea în cazul în care aceasta nu este deja în execuție.

Cele mai multe implementări obiect asigură comportamentul lor, folosind facilități în

plus față de ORB și adaptorul obiect. De exemplu, deși adaptorul obiect portabil oferă unele

date persistente asociate cu un obiect (OID sale sau Object ID), această sumă relativ mică de

date este de obicei folosită ca un identificator pentru datele obiectelor reale stocate într-un

serviciu de depozitare a implementării obiectului ales16.

16 Common Object Request Broker Architecture: Core Specification, Object Management Group, Inc., 2004

Dragos Ciprian ENOIU INTEROPERABILITATEA

Page | 17

III. INTEROPERABILITATEA

3.1. Elementele interoperabilitatii

Elementrele interoperabilitatii sunt urmatoarele :

Arhitectura interoperabila ORB

Suportul Inter-ORB Bridge

Protocolul General si Internet inter-ORB

In plus, arhitectura se acomodeaza cu protocoale specifice inter-ORB (ESIOPs) ce

sunt optimizate pentru medii specifice cum sunt cele DCE.

3.1.1. Arhitectura interoperabilitatii ORB

Arhitectura interoperabila ORB overa un cadru conceptual pentru definirea

elementelor de interoperabilitate si pentru identificarea punctelor sale de conformitate.

Desemenea, caracterizeaza noi mecanisme si specifica conversatii necesare pentru a stabili

interoperabilitatea intre ORB-urile produse in mod independent.

In mod specific, arhitectura introduce conceptul de immediate si mediated bridging

pentru domeniile de ORB. Protocolul de internet inter-ORB formeaza o baza comunca pentru

mediate bridging. Suportul pentru inter-orb bridge poate fi folosit pentru a implementa atat

immediate bridges si sa contruiasca “jumatati de bridges” pana la domeniile de mediated

bridge.

Folosirea tehnicilor de bridging, ORB poate interopera fara a sti detalii despre

implemantarea ORB, cum sunt protocoalele implementate de specificarile CORBA.

IIOP poate fi folosit in bridging doua sau mai multe ORB-uri implementant “jumatati

de bridges” ce comunica folosind IIOP. Aceasta abordare functioneaza pentru retele ce

folosesc un ESIOP si pentru versiunile de stand-alone ale ORB-ului.

IIOP ar putea fi folosit deasemenea pentru a implementa un sistem de mesajerie daca

dorim. Deoacere ORB-ul nu necesita folosirea internala a IIOP-ului.


Page | 18

3.1.2. Suportul Inter-ORB Bridge

Arhitectura interoperabila identifica intrun mod clar rolul a diferitelor modele a

domeniilor ORB specifice informatiei. Astfel de domenii pot include obiecte de referinte,

tipuri de domenii, domenii de securitate, domeniu de tranzactie si multe altele.

Cand doua ORBuri sunt in acelasi domeniu, acestea pot comunica intrun mod direct.

In multe cazuri, acest lucru este de dorit. Acest lucru nu este adevarat tot timpul, totusi,

deoarece organizatiile trebuie sa stabilieasca domenii de control locale.

Cand informatia trebuie sa paraseasca domeniul ei, invocatia trebuie sa traverseze un

pod. Rolul podului este sa asigure semantica si continutul ce este mapate de la un ORB

specific astfel utilizatorii al oricarui ORB sa vada doar continutul si semantica potrivita.

Deoarece extensiile necesita suportul Inter-ORB Bridges sunt in mod general in

natura, ele nu au impact in alte operatii ORB si pot fi folosite pentru alte scopuri pe langa

constructia de poduri, ele sunt potrivite pentru tot suportul ORB-ului. Alte aplicatii includ

depanarea, interpostarea obiectelor, implementarea obiectelor cu interpreti si limbaj de

scriptare si implementari generate in mod dinamic.

Suportul inter-ORB bridge poate fi folosit pentru a oferi interoperabilitatea cu sisteme

diferite de cele CORBA cum ar fi Microsoft Component Object Model (COM). Usurinta

acestui lucru va depinde de extensia sistemelor conform modelul obiect CORBA.

3.1.3. General Inter-ORB Protocol (GIOP)

Protocolul General Inter-ORB (GIOP) specifica standardul de sintaxa a transferului si

un set de mesaje de tip format pentru comunicatii intre ORB-uri. GIOP-ul este specific

construit pentru ORB pentru interactiuni de tip ORB si este creat pentru a lucra direct peste

orice protocol de transport orientat pe conexiune ce atinge un set minimal de ipoteze.

Protocolul este simplu, scalabil si in mod general usor de implementat. Este creat pentru

permite implementari portabile cu memorii mici si pentru performante rezonabile cu o

dependenta minimala pentru software ce suporta alt layer de transport.

In timp ce versiunile a GIOP ului ruleaza pe diferite straturi de transport ce nu sunt in

mod direct interoperabile, elementele lor comune ar permite folosirea eficienta a podetelor

intre domeniile de retelistica.


Page | 19

3.1.4. Internet Inter-ORB Protocol (IIOP)

Protocolul de Internet Inter-ORB specifica cum mesajele GIOP sunt schimbate

folosind conexiunile TCP/IP. IIOP specifica protocolul standardizat de interoperabilitate

pentru internet, ofera o interoperare iesita din comun cu alte ORBuri compatibile bazate pe

cele mai populare produse si vanzatori neutrali pe stratul de transport. Poate fi folosit si

protocoale intre jumatati de punti.

Protocolul a fost creat pentru a fi adecvate si corespunzatoare pentru folosirea oricarui

ORB pentru interoperare in domeniile protocoalelelor de internet doar daca un alt protocol

alternativ este dorit de un model specific sau un mediu de operare destinat ORBului. In acest

sens este reprezentat protocolul inter-ORB pentru mediul TCP/IP, un strat de transport

universal.

Relatiile intre IIOP si GIOP sunt similare unui limbaj de mapare specific OMG IDL;

GIOP ar putea fi mapat intrun numar diferit de transporturi si sa specifice protocoalele ce

sunt mapate intrun mod comun.Totusi, GIOPul in sine nu ofera interoperabilitate completa,

cum un IDL nu poate fi folosit sa contruiasca programe complete. IIOPul si alte mapari

similare sunt realizari solide a definitiilor abstracte ale GIOPului.

Fig 3.1.4 Relatiile Protocolului Inter-ORB.


Page | 20

3.2. Exemple de solutii ale interoperabilitatii

Elementele interoperabilitatii (puntile Inter-ORB, protocoalele General and Internet

Inter-ORB) pot fi combinate intro varietate de moduri pentru a satisface un produs particular

si necesitatile cumparatorului. Oferim cateva exemple.

Ex1.

Produsul ORB “A” este creat pentru a ajuta obiecte distribuite intr o retea si ofera

interoperabilitate cu ORBuri compatibile de la alti comercianti. In plus ofera cladirea puntilor

catre el si alte ORBuri ce sunt specifice mediului sau protocoale proprietatilor. Pentru a

atinge acesc lucru, ORBul “A” foloseste IIOP si ofera suport pentru puntea inter-ORB.

Ex2.

Produsul ORB “B” este creat pentru a oferi suport optimizat de inalta viteza pentru un

obiect localizat pe o singura statie. De exemplu, sa suporte mii de obiecte GUI Fresco

operate pe viteze diferite. In plus, unele obiecte vor avea nevoie de acces de la alte masini si

obiecte aflate pe alte masini ce vor fi accesate intrun mod des. Pentru a realiza acest lucru,

ORB “A” ofera suport de tip “jumatate de punte” la IOP pentru comunicari cu alte ORBuri

distribuite.

Ex3.

Produsul ORB “C” este optimizat pentru a lucra in particular in medii de operare.

Foloseste un protocol de mediu specific bazat pe serviciile distribuite computerizate ce sunt

valabile in mod comun pe site. In plus, ne asteptam ca ORBul “C” sa interopereze cu alte

ORBuri de la alti producatori. Pentru a se ajunge la acest lucru, ORBul “C” ofer suport inter-

ORB bridge si un produs de tip half-bridge (oferit de un vanzator ORB sau alt sistem third-

party) ofera o conexiune altor ORBuri. Jumatatile de poduri folosesc de IIOP pentru a oferi

interoperabilitate cu alte ORBuri compatibile.

3.3. Factori de motivare

In aceasca sectiune vom explica factorii ce motiveaza crearea specifica a

interoperabilitatii.


Page | 21

3.3.1. Diversitatea implementarii ORB

Astazi, sunt multe produse ORB diferite ce se adreseaza unei game largi de necesitati

a utilizatorilor. O gama larga de tehnici de implementare este necesara in mod evident. De

exemplu, timpul pentru o cerere poate varia la o magnitudine de 5 ordine de marime, de la

cateva microsecunde la cateva secunde. Unele ORBuri au securitate de nivel inalt, altele sunt

mult mai deschise publicului. Unele ORBuri sunt stratificate pe un protocol folosit intrun

mod particular des, altele sunt optimizate puternic cum sunt protocoalele de proprietare.

Piata pentru sistemele de tip obiect si aplicatii ce le folosesc pentru a creste ca obiect

de sistem sunt capabile de a aplica mai multe tipuri de computerizare. De la aplicatii integrate

cu procese de control, de la sisteme de operare cuplate slab pana la superreteaua de

informatie, sistemele obiect bazate pe CORBA pot fi infrastructura comuna.

3.3.2. Limitele ORB

Chiar si atunci cand nu este necesara implementarea diferentiala, sunt alte motive

pentru a partitiona un mediu in ORBuri diferite.

Din motive de securitate, este important sa stim ca nu este in mod general posibil sa

accesam obiecte intrun domeniu din altul. De exemplu, un Internet ORB ar putea sa faca

publica informatia dar un ORB dintro companie va dori sa restrictioneze informatia, aceste

doua ORBuri ar fi separate astfel incat compania sa acceseze obiectele publice din interiorul

companiei fara a permite acces la obiectele private din interior. Chiar daca obiectele

individuale ar trebui protejate, administratorii de sistem prudenti vor dori sa evite expunerea

obiectelor delicate la atacuri din afara companiei.

Suportul mai mulot ORBuri ajuta, deasemenea, la manevrarea problemelor dificile

pentru testare si de upgrade obiectul sistemului. Ar fi nefiresc sa testam o noua infrastructura

fara a limita un set de obiecte ce ar putea fi avariate de bugs(erori) si ar fi nepractic sa

inlocuim “ORBul” de peste tot simultan. Un nou ORB ar putea fi testat si plasat in acelasi

mediu, interoperand cu ORBul existent pana cand fie un buton este creat in mod complet fie

pana cand unul din ORBuri il inlocuieste pe celalalt.

Problemele managementului ar putea motiva partitionarea unui ORB. Cum si retelele

sunt subdivizate in domenii ce permit controlul bazelor de date necentralizat, configurare de

resurse, managementul starii unui ORB.


Page | 22

3.4. Design-ul interoperabilitatii

Datorita diversitatii implementarilor ORB, mai multe abordari sunt necesare

interoperabilitatii. Optiunile identificate in versiunile de CORBA precedente includ :

Protocoale de Translatie, unde un gateway aflat undeva in hartile sistemului,

necesita de la formatul folosit de un ORB la unul folosit de altul.

Referintele Integrate unde invocarea folosindu-se un obiect referinta nativ trimite

un obiect special a carui munca este sa trimita o invocare de la un ORB la altul.

ORBuri Alternative unde implementarile ORB sunt deacord sa coexiste in acealasi

spatiu de adrese atat de usor ca un client sau o implementare sa le poate folosi

intrun mod transparent si sa treaca de referintele obiectului create de un ORB la

altul fara a pierde functionalitate.

In general nu este un singur protocol ce poate satisface necesitatile tuturora si nu este

o modalitate de a interopera intre doua protocoale diferite. Sunt multe medii in care

protocoale multiple exista si sunt cai de a crea punti intre medii ce nu au protocoale in

comun.

Aceasca specificare adopta o arhitectura flexibila ce permite o varietate larga de

implementari ORB pentru a incorpora atat protocolul comun de elemente cat si cel de

bridging.

Urmatoarele teluri ne ghideaza la crearea specificata a interoperabilitatii :

Arhitectura si specificarea ar trebui sa permita performante inalte, cai scurte si

solutii de interoperabilitate usoare

Designul ar trebui sa fie scalat, sa nu fie greu de implementat si nu ar trebui sa

restrictioneze alegerile implementarii intrun mod inutil.

Solutiile de interoperabilitate ar trebui sa functioneze cu orice comerciant ce ofera

implementari ORB ce respecta modelul CORBA; aceste implementari sunt

diverse.

Toate operatiile implicate de modelul obiect CORBA ar trebui sa fie suportate

Page | 23

BIBLIOGRAFIE

1. Curs: Sisteme de Programe pentru Rețele de Calculatoare, Valentin Cristea, Facultatea

de Automatică și Calculatoare, UPB;

2. Curs: Programarea rețelelor de calculatoare, Ioan Jurca, Universitatea Politehnica din

Timișoara;

3. Sisteme distribuite – Tehnologii, Dana Petcu, Universitatea de Vest din Timișoara, 2009;

4. Curs: Medii de proiectare şi programare, Vasile Cioban, Universitatea Babes-Bolyai din

Cluj-Napoca;

5. Laborator: Sisteme de Programe pentru Rețele de Calculatoare, Valentin Cristea,

Facultatea de Automatică și Calculatoare, UPB;

6. Common Object Request Broker Architecture: Core Specification, Object Management

Group, Inc., 2004;

7. http://www.site.uottawa.ca/~tcl/gradtheses/mnojoumian/ThesisFiles/FinalSpec/CORBA.p

df

8. http://www.ing.iac.es/~docs/external/corba/CorbaServices.pdf

9. http://en.wikipedia.org/wiki/Distributed_computing

http://www.site.uottawa.ca/~tcl/gradtheses/mnojoumian/ThesisFiles/FinalSpec/CORBA.pdf

http://www.site.uottawa.ca/~tcl/gradtheses/mnojoumian/ThesisFiles/FinalSpec/CORBA.pdf

http://www.ing.iac.es/~docs/external/corba/CorbaServices.pdf

http://en.wikipedia.org/wiki/Distributed_computing

TEMĂ DE...

Documents

Transcript of TEMĂ DE...