CORBA

U ovom poglavlju biće reči o CORBA-i, jednoj od najpopularnijih i

najboljih specifikacija za rad sa distribuiranim objektnim sistemima.

Predstaviće se izumitelji CORBA specifikacije i ideje kojima su se

oni vodili u kreiranju ove specifikacije, daće se pregled najvažnijih
komponenata arhitekture CORBA-e, razvoj CORBA specifikacije
kroz njene verzije.

U petom poglavlju pažnja je posvećena distribuiranim i usađenim

sistemima koji rade u realnom vremenu, dok šesto poglavlje daje
pregled smernica daljeg razvoja CORBA specifikacija.

U Prilogu je data lista svih skraćenica koje su korišćene u radu,

njihov puni naziv na engleskom jeziku i prevod na srpski jezik.
12.1.1 GRUPA ZA OBJEKTNO UPRAVLJANJE

Posmatrajući karakteristike mreža poput Interneta, World Wide Web-

a, raznih korporativnih intranetova, može se uočiti da sve one imaju
jednu zajedničku osobinu, a to je heterogenost.

Na primer, jedan korporativni intranet, može da bude sačinjen od

UNIX radnih stanica i servera, PC sistema koji rade pod raznim
verzijama Microsoft-ovog Windows-a, IBM-ovog OS/2, Apple
Mackintosh-a,... Mrežni protokoli pod kojima bi ovakav intranet
radio, opet mogu da se razlikuju. Samo neki od njih su: TCP/IP
protokol, razne vrste udaljenih poziva procedura (RPC),...

Međutim, ono što je fundamentalno jeste da se mora omogućiti

razmena informacija i sadržaja i kod mreža koje nisu istog tipa i ne
koriste iste operativne sisteme i softvere.
Grupa za objektno upravljanje (Object
Management Group-OMG), je neprofitabilni
konzorcijum formiran aprila 1989. godine u cilju
razvoja, usvajanja i promovisanja standarda za
razvoj aplikacija koje bi radile u distribuiranim
heterogenim i objektnim okolinama. Iako je OMG
u početku brojala trinaest kompanija osnivača,
do danas je prerasla u grupu od preko 800
članova i korisnika. OMG je osnovana u SAD-u,
ali sada već ima predstavništva i u Velikoj
Britaniji, Nemačkoj, Australiji, Japanu i Indiji.
 Glavna misija OMG-a je da razvije jedistvenu ahitekturu za
integraciju distribuiranih aplikacija u objektno orjentisanom
okruženju, koja će garantovati sledeće:
• interoperabilnost i prenosivost,
• ponovno korišćenje komponenata,
• mogućnost formiranja baze za komercijalne softvere.

Gledajući pojedinačne komponente, OMG je ustanovila i standard

za komponente koji obuhvata:
• jedinstvenu terminologiju za objektnu orjentaciju,
• zajednički apstraktni okvir,
• zajedničke interfejse i protokole.
Snaga i značaj OMG-a, su i u tome što
ova grupa usvaja nove standarde na
osnovu zahteva za predlozima (Request
For Proposals – RFP), koji ustvari
predstavljaju sveže ideje i tehnologije, a
predlažu ih sami članovi OMG-a. Time se
postiže neprekidan razvoj standarda za
distribuirane objektne sisteme.
 12.1.2 ARHITEKTURA
OBJEKTNOG UPRAVLJANJA
Arhitektura objektnog upravljanja (Object
Management Architecture – OMA),
predstavlja pokušaj, da se na visokom
nivou apstrakcije, definišu različiti načini
za opisivanje i formiranje distribuiranih
objektnih sistema.
OMA je sastavljena iz objektnog i referentnog modela.

Objektni model definiše kako se mogu opisati objekti koji su

distribuirani u heterogenoj okolini, dok referentni model daje
karakteristike mogućih interakcija između tih objekata.

OMG-ov RFP proces se koristi za usvajanje specifikacija tehnologija

koje se uklapaju u objektni i referentni model i koje sarađuju sa već
usvojenim tehnologijama.

Spajanjem ovakvih tehnologija sa OMA, omogućen je konstantan

razvoj distribuiranih objektnih sistema u heterogenim okruženjima.
U OMA objektnom modelu, objekat je
enkapsulirani entitet sa jedinstvenim
identitetom koji se ne može menjati, i čijim
operacijama sa može pristupiti samo
preko dobro definisanih interfejsa. Klijent
izdaje zahtev objektu, za izvršenje
određene operacije. Implementacija i
lokacija svakog objekta ostaju skrivene za
klijenta koji upućuje zahtev.
Na slici se mogu videti komponente referentnog modela OMA. Centralni deo ovog
modela je ORB (Object Request Broker), koji je odgovoran za sprovođenje
komunikacije između klijenata i objekata. Pored ORB-a, ovaj model sadrži još četiri
komponente: interfejse aplikacije (Application Interfaces), domenske interfejse
(Domain Interfaces), zajedničke strukture (Common Facilities) i objektne servise
(Object Services).
 Objektni servisi (Object Services) predstavljaju interfejse koji ne
zavise od domena i koje koriste mnogi distribuirani objektni
programi. Primer za to bi bio servis koji je zadužen za otkrivanje
drugih raspoloživih servisa, on je uvek neophodan, bez obzira na
domen aplikacije. Dva najpoznatija objektna servisa koji ispunjavaju
ovu ulogu su:
• servis koji omogućava klijentima da pronađu traženi objekat na
osnovu njegovog imena (The Naming Service)
• servis koji omogućava klijentima da pronađu traženi objekat na
osnovu njegovih osobina (The Trading Service)

Takođe postoje i specifikacije objektnih servisa koji su zaduženi za

životni ciklus upravljanja, sigurnost, transakcije,...
Zajedničke strukture (Common Facilities) su
takođe interfejsi koji su horizontalno orjentisani
poput objektnih servisa, ali za razliku od njih, oni
su orjentisani ka aplikacijama krajnjih korisnika.
Primer za zajedničke strukture bi bila struktura
komponente distribuiranog dokumenta
(Distributed Document Component Facility-
DDCF), koja omogućava prezentaciju i razmenu
objekata koji su bazirani na modelu dokumenta.
Domenski interfejsi (Domain Interfaces)
igraju ulogu koja je slična onoj kod
objektnih servisa i zajedničkih struktura, ali
su ovi interfejsi orijentisani ka domenima
specifičnih aplikacija. Njih može biti i više,
jer tako prikaziju mogućnost egzistencije
više različitih domena neke aplikacije.
Interfejsi aplikacije (Application Interfaces) su
interfejsi koji su razvijeni za specifične aplikacije.
Ovi interfejsi nisu standardizovani, jer su
specifični za svaku aplikaciju, ali i zbog toga što
OMG ne razvija aplikacije već samo standarde.
Međutim, ako se nekada desi da se neki od ovih
servisa toliko često koristi i da počinje da ne
zavisi od domena aplikacije, tada se takav servis
može smatrati budućim kandidatom za OMG
standardizaciju.
Tokom svog dosadašnjeg postojanja, sva
pažnja OMG-a je bila usmerena ka razvoju
centralne komponente arhitekture objektog
opravljanja-OMA, a to je ORB. Jedna od
prvih specifikacija, koju je usvojila OMG,
bila je CORBA (Common Object Request
Broker Architecture). CORBA, što ćemo
videti kasnije, u detalje definiše interfejse i
karakteristike ORB-a.
 12.2. CORBA I NJENA
ARHITEKTURA
CORBA je standardna arhitektura za distribuirane
objektne sisteme, koja je standardizovana od strane
OMG-a. Ona omogućava da distribuirani i heterogeni
objekti zajedno funkcionišu i komuniciraju. Pri tome,
vrsta računara, programskog jezika, proizvođača, mreže,
uopšte nisu relevantni, ako su programi bazirani na
CORBA specifikaciji. Svi oni među sobom mogu da
sarađuju i razmenjuju informacije. CORBA se može
pronaći u pozadini najvećih svetskih web-sajtova, a
posebno je korisna u radu na serverima koji opslužuju
veliki broj klijenata i od kojih se zahteva velika
pouzdanost.
Slika 12.2 daje pregled arhitekture CORBA-e, sa svim njenim komponentama.
 12.2.1 ORB JEZGRO

ORB jezgro je na slici označeno sa ORB CORE. Šta je

prava svrha ORB-a?

ORB je centralni deo CORBA-e, zadužen za

komunikaciju klijenata i objekata. Kada klijent uputi neki
zahtev, ORB ga isporučuje objektu koji taj zahtev može
da ispuni i vraća odgovor klijentu, ako ga ima. Objekat
kome klijent želi da uputi zahtev preko ORB-a se zove
ciljni objekat. Glavna odlika ORB-a je da on uspeva da
komunikaciju između klijenta i objekta učini nevidljivom.
Generalno, ORB skriva sledeće:
• lokaciju objekta – klijent ne zna gde se nalazi ciljni objekat.
Objekat se može nalaziti u drugom procesu na drugom računaru ,
može biti deo istog procesa, ili biti na istom računaru ali u drugom
procesu,...
• implementaciju objekta – klijent ne poznaje implementaciju
objekta, ne zna u kom je programskom jeziku pisan, pod kojim
operativnim sistemom radi ili koji hardver koristi.
• izvršno stanje objekta – kada klijent uputi zahtev objektu, on ne
zna da li je objekat aktivan ili se nalazi u stanju pripremnom za
izvršenje zahteva klijenata. Ako je potrebno ORB skriveno od
korisnika aktivira objekat i pre nego što mu uputi zahtev od klijenta.
• mehanizmi komunikacije objekta – klijent ne može da vidi koje
mehanizme komunikacije koristi ORB kada poziva ciljni objekat (npr.
TCP/IP, poziv lokalne metode,...) i vraća odgovor korisniku.
 Da bi klijent uputio zahtev objektu, on mora
koristiti referencu tog objekta. Svaki put kada se
kreira CORBA objekat, kreira se i njegova
referenca. Ona postoji dok postoji i objekat na
koji ona ukazuje i jedinstvena je u smislu da
uvek ukazuje na objekat za koji je i kreirana.

.
 Klijenti ne mogu menjati referencu
objekta. Jedino ORB zna šta se nalazi
unutar reference objekta. Objektne
reference imaju standardizovane formate
od strane OMG-a. ORB koristi reference
objekta da identifikuje i locira objekte, tako
da može direktno da im pristupi.
Objektne reference se mogu sačuvati ako se
uputi zahtev ORB-u da ih konvertuje u stringove,
i kao takve klijent ih može čuvati kao podatke.
Kasnije, klijent može zahtevati od ORB-a da
stringove prebaci nazad u objektne reference i
onda ih koristiti za upućivanje novih zahteva.

Ovaj princip se može koristiti za održavanje

konstantnih veza između objekata i aplikacija
koje ih koriste.