1. Uvod

U ranim sedamdesetim godinama se počelo raditi na povezivanju informatičkih sistema - nastali su standardni protokoli poput X.25, OSI protokola i TCP/IP-a. Programeri su morali sami programirati aplikacije koje su bile u skladu s odabranim protokolom.

Sredinom sedamdesetih su se počele javljati standardne mrežne aplikacije za slanje i prijem podataka i poruka – npr. X.400, X.500, Netware. Za uredan prijenos su se brinuli gotovi software paketi, no podaci su na prijemnoj strani završili u nekoj datoteci, a za daljnju obradu je opet trebalo pisati posebne programe.

Sredina osamdesetih je početak razvoja klijent-server arhitekture. Došlo je do standardizacije programskih interface-a (API) koji su omogućili da programi na raznim računarima međusobno razgovaraju i razmijenjuju podatke. Programeri na obje strane su se morali dogovoriti o izgledu i značenju poruka. Jednom dogovoreno se teško mijenjalo - jednom odabrani protokol je bilo gotovo nemoguće mijenjati.

Početkom devedesetih je učinjen četvrti korak - objektna tehnologija. Aplikacije sarađuju jedna s drugom, ali svaka govori svojim jezikom. Objektno-orijentisane applikacije se grade od komponenti (objekata). Sve što jedna komponenta (objekt) treba znati o drugima je njeno sučelje (interface).

Komponenta opisuje samo šta radi i kako je treba koristiti. Kako to radi nije važno. To omogućava da se lako zamijeni cijeli objekt nekim drugim, boljim, a da ostatak sistema to ni ne primjećuje.

Pokušajmo to pojasniti analogijom - svrha telefona je da poveže dvije stranke i omogući im glasovnu komunikaciju. Da bi mogli koristiti telefon, trebate znati telefonski broj osobe koju trebate i kako pritiskati tipke na aparatu. Za korištenje telefona nije nam potrebno znati da li je centrala crossbar ili digitalna, da li je biranje pulsno ili tonsko. Zbog takve organizacije, telekom operator mijenja centrale, tehnologiju, a jedino što korisnici vide je promjena tarife. Korisnici vide promjene tek kad se mijenja nešto u samom načinu upotrebe - kad npr. pozivni broj za Sarajevo postane 033, umjesto 071.

Zbog ovakvog pristupa, objektno-orijentisani sistemi se lakše projektuju i lakše održavaju. Kad se jednom definišu sučelja objekata, razvoj pojedinih objekata mogu raditi različite ekipe, paralelno. Gotove komponente se povezuju tek u trenutku same obrade.

1

Objektna tehnologija ne zahtijeva razvoj od samog početka – postoje razne tehnike koje omogućavaju da se kompletne postojeće aplikacije pretvore u komponente.

Arhitekturu CORBA (Common Object Request Broker Architecture) je razvila OMG (Object Management Group), sa osnovnim zadatkom da projektuje standardnu i portabilnu arhitekturu namijenjenu za razvoj objektno-orijentisanih aplikacija, implementiranih na različitim hardverskim i softverskim platformama. CORBA je objektno orijentisana distribuirana arhitektura koja je dostigla status industrijskog standarda i postala široko prihvaćena u aplikacijama upravljanja telekomunikacionim mrežama. CORBA omogućava međusobnu komunikaciju aplikativnim komponentama pisanim različitim programskim jezicima, a koje se izvršavaju unutar različitih procesa bilo na istom ili različitim računarima.CORBA umotava programski kod u paket koji sadrži informacije o tome šta je sadržaj paketa i kako se isti može izvršiti.CORBA je okruženje koje omogućava razvoj i izvršavanje distribuiranih aplikacija, a to može biti potrebno (nužno) iz slijedećih razloga:

- Podaci koji se koriste su distribuirani - podatke ne smijemo ili ne možemo imati na svim lokacijama gdje su oni potrebni;

- Potrebni računarski resursi su distribuirani - potrebno je iskoristiti procesorsku snagu većeg broja racunara kako bi se raspodijelio teret obrade podataka;

- Korisnici aplikacije su distribuirani - različiti korisnici koriste različite dijelove aplikacije ili međusobno komuniciraju pomoću aplikacije.

2

2. Razlozi primjene CORBA arhitekture

Savremene telekomunikacione mreže i servisi, koji su predmet upravljanja, dobijaju sve složeniju strukturu, njihova kompleksnost i heterogenost rastu, što takođe otvara potrebu za primjenom distribuiranih tehnika upravljanja.Istorijski gledano, pošto u informacionim tehnologijama (IT) nije postojala opšte prihvaćena infrastruktura distribuirane obrade adekvatna zadatku upravljanja telekomunikacijama, razvijeno je više proizvođačkih infrastruktura. Prverealizacije mreža za upravljanje telekomunikacijama su bile bazirane na telemetrijskoj paradigmi, po kojoj elementi mreže šalju kontinualni tok nezavisnih notifikacija centralnoj nadzornoj jedinici. Kasnije tehnologije, kao što su SNMP(Simple Network Management Protocol) i CMISE (Common Management Information Service Element) koriste menadžer/agent paradigmu koja uvodi mogućnost udaljene inteligencije i sposobnost interakcije i iniciranja operacija od strane centralnog prema udaljenom sistemu. Današnja IT industrija razvija tehnologiju distribuiranog procesiranja baziranu na distribuiranim objektima, pa industrija upravljanja telekomunikacijama migrira ka paradigmi distribuirane obrade sa ciljem da se smanje ukupni troškovi i unaprijede mogućnosti održavanja1. Ovakva orijentacija je rezultat procesa logičke i fizičke decentralizacije kroz koji prolaze telekomunikacione mreže, posebno sa uvođenjem inteligentnih mreža (IN) i distribuiranja inteligencije u okvirumreže.Zastupljenost hardverske mrežne opreme i softvera koji potiču od više različitih proizvođača takođe doprinosi distribuiranosti i heterogenosti, što nameće potrebu uvođenja distribuiranog okruženja koji bi povezao različite distribuirane elemente mreže i omogućio njihov međusobni rad. To dovodi i do uvođenja tehnologije distribuiranih obrada informacija u oblast mreža za upravljanje telekomunikacijama. Savremene telekomunikacione mreže i servisi, koji su predmet upravljanja, dobijaju sve složeniju strukturu, njihova kompleksnost i heterogenost rastu, što takođe otvara potrebu za primjenom distribuiranih tehnika upravljanja.Novi uslovi diktirani pojavom konkurencije u telekomunikacionom sektoru nameću jaku potrebu za smanjenjem troškova i organizacijom poslovnih procesa kojima se skraćuje vrijeme izlaska proizvoda-servisa na tržište. U tom svjetlu su mogućnost međusobnog rada, postepeni rast prema potrebi i višestruko korištenje, glavne karakteristike koje savremeni sistemi za upravljanje moraju da ispune.

Primena distribuirane klijent-server arhitekture zastupljene u računarskoj industriji, koja je već raspoloživa i spremna za upotrebu, smanjuje troškove razvoja i održavanja, što predstavlja značajan razlog za uvođenje principa distribuiranih tehnika i u mreže za upravljanje telekomunikacijama.Arhitektura OMA (eng. Object Management Architecture) definira modele distribuiranih objekata i njihove interakcije u platformski nezavisnim okruženjima.

1 www.telekomunikacije.rs, S. Boštjančič Rakas, M. Stojanović, N. Gospić, Automatizacija upravljanja IP mrežama

3

OMA se sastoji od modela objekata (eng. object model) i modela referenci (eng. reference model). Model objekata propisuje kako objekti distribuirani u heterogenom okruženju mogu biti opisani, dok model referenci opisuje međudjelovanje tih objekata. U modelu OMA objekt posjeduje nepromjenljiv identitet čije usluge mogu biti korištene samo putem čvrsto definiranih sučelja. Korisnici izdaju zahtjeve objektima u svrhu obavljanja usluga. Implementacija i lokacija pojedinog objekta nisu dostupni klijentu.

2.1 Razvojni put CORBA-e

CORBA 1.x

OMG (Object Management Group) je razvila konceptualni model poznat pod nazivom referentni objektni model i referentnu arhitekturu OMA (Object Management Architecture). Referentni objektni model propisuje kako se opisuju objekti ditribuirani unutar heterogenog okruženja, a referntna arhitektura opisuje međudjelovanje (interoperabilnost) između tih objekata.Object Managment Group (OMG) osnovana je 1989 sa osam članova. Danas je to organizacija sa preko 760 članova čiji je zadatak bio da omogući jedinstveni framework za objektno orijentisane aplikacije bazirane na široko dostupnim interface specifikacijama. Konačno to i uspijevaju uspostavom OMA (Object Mangment Arhitecture) čega je i sam CORBA dio. Ovaj set standarda omogućuje jedinstveni farmework na kojem se pišu aplikacije. Ukratko OMA se sastoji:

• od funkcije ORB-a (Object Request Broker) • Object Services (Corba Services) • Common Facilities • Application Objects

CORBA 1.0 je prvi puta predstavljena u decembru 1990. Uskoro nakon nje 1991. dolazi CORBA 1.1 koja definira IDL (Interface Definition Language) kao i API za applikacije koje komuniciraju sa ORB-om. CORBA 1.x je napravila prvi važan korak prema interoperabilnosti objekta, omogućavajući objektima na različitim računarima, arhitekturama i pisanim u različitim jezicima da međusobno komuniciraju.

CORBA 2.x i IIOP

CORBA 1.x je bio prvi važan korak koji je omogućavao interoperabilnost, ali nije u potpunosti zadovoljavao kompletnu specifikaciju. Iako je pružao standarde za IDL i pristup ORB-u kroz aplikaciju, najveća mana mu je bila što nije specificirao

4

standardni protokol preko kojeg bi ORB-ovi međusobno komunicirali. Rezultat toga je bio da ORB-ovi jednog proizvođača nisu mogli komunicirati sa ORB-ovima drugog proizvođača što se uvelike kosilo sa prvobitnom namjenom i zamisli CORBA-e kao arhitekture za komunikaciju objekata na mreži. CORBA 2.0 dolazi 1994. Najvece postignuće je bilo je pružanje standardnog protokola preko kojega ORB-ovi međusobno komuniciraju. Taj protokol zove se IIOP (Internet InterORB Protocol). CORBA specifikacija zahtijeva da ga implementiraju svi proizvođači koji žele raditi CORBA 2.0 proizvode.

CORBA 2.0 arhitektura

CORBA standard nastavlja svoju evoluciju; slijedile su verzije 2.1 (1997), potom CORBA 2.2, CORBA 2.3. Ove CORBA revizije predstavljaju evolucijski napredak u CORBA Arhitekturi.

2.2 Nedostaci distribuiranih sistema

Prilikom opisa nedostataka distribuiranih računarskih sistema u prvi plan izbija snažna ovisnost o performansama komunikacijskog kanala, a koja se očituje u brzini i dostupnosti dijelova sistema:

brzina komunikacije između dva računara za otprilike dva reda veličine sporija je od komunikacije unutar sistema (komunikacije između procesa istog sistema);

zagušenjem komunikacijskog kanala drastično padaju performanse sistema; prekidom komunikacijskog kanala dijelovi sistema postaju nedostupni.

Razvoj distribuiranih aplikacija namece neke probleme (izazove) s kojima se tokom razvoja nedistribuiranih (centraliziranih) aplikacije ne susrecemo.

5

Tabela 1. Distribuirane i centralizirane aplikacije

Komunikacija - u distribuiranim sustavima je znatno sporija nego u centraliziranim sustavima, stoga je potrebno izbjegavati distribuirana rješenja kada objekti imaju intenzivnu međusobnu interakciju.

Greške - Kada se svi objekti aplikacije nalaze unutar centraliziranog sustava oni bivaju zajednički pogodeni greškama, tj. kada proces u kome se izvode prestane funkcionirati tada i svi objekti tog procesa prestaju s funkcijom. U distribuiranim sustavima je moguće izolirati procese i objekte u njima, a moguće je i realizirati sustav u kome aktivni procesi mogu preuzeti posao onih procesa koji trenutno nisu aktivni iz bilo kojeg razloga.

Raspoloživost centraliziranih sustava je uopšteno govoreci manja od raspoloživosti distribuiranih sustava. Ispadom jedne komponente centraliziranog sustava često čitav sustav postaje neupotrebljiv. Distribuirani sustavi pružaju mogućnosti paralelnog izvršavanja zadataka i preuzimanja funkcije onih komponenti koje su na udaljenom sustavu izvan funkcije.

Paralelni pristup – u cenatraliziranim sustavima je čest slucaj da se aplikativna logika izvršava unutar jedne niti izvođenja, a želimo li podržati paralelan pristup susatvu od strane više istovremenih korisnika moramo uzeti u obzir kompleksnost realizacije višenitnog izvođenja aplikacije. Kod distruibuiranih sustava nužno postoji više niti izvođenja, no one se mogu izvoditi unutar zasebnih procesa.

Sigurnost - Kada se svi objekti aplikacije fizicki nalaze na jednom mjestu i unutar istog procesa tada ne postoji problem međusobne autorizacije objekata. Kod distribuiranih sustava taj problem postoji jer objekti iz različitih okruženja (procesa) međusobno pokušavaju uspostaviti komunikaciju te ih je potrebno međusobno identificirati.

No trenutno najveći problem distribuiranih sistema čini nedostatak adekvatne programske podrške. Iako se ulažu veliki napori u svrhu pojednostavljenja oblikovanja i izrade, programska podrška distribuiranim sistemima kasni za razvojem hardvera usljed postojanja bitnih razlika u oblikovanju i implementaciji programske podrške centraliziranih i distribuiranih sistema.

6

Osnovne karakteristike distribuiranih sistema, koje se njihovom implementacijom žele postići, su transparentnost, prilagodljivost, pouzdanost, učinkovitost i skalabilnost2.

Transparentnost distribuiranog sistema očituje se u lokacijskoj transparentnosti (location transparency) pojedinih komponenti sistema, transparentnosti promjene lokacije resursa (migration transparency), transparentnosti višestrukih kopija podataka (replication transparency), transparentnosti istovremenog dijeljenja resursa (concurrency transparency) i transparentnosti usporednog rada (parallelism transparency).

Pouzdanost distribuiranog sistema, uz pravilno oblikovanje i izvedbu, značajno je veća u odnosu na centralizirane sisteme. Pravilno oblikovanje i izvedba stoga mora podrazumijevati korištenje tehnika otpornosti na greške u radu (zatajenje pojedinih komponenti sistema ne smije imati za posljedicu zatajenje čitavog sistema), oporavaka od greški (na razini komponente i na razini čitavog sistema), osiguranja redundantnosti komponenti i rješenja pitanja sigurnosti sistema (na razini komponenti i razini podataka).

Učinkovitost distribuiranog sistema uglavnom se odnosi na raspodjelu zadataka po komponentama sistema.

Na skalabilnost sistema utieču centralizacija korištenja komponenti sistema (npr. jedan mrežni datotečni sistem na veliki broj korisnika), centralizirane strukture podataka i centralizirano izvršavanje algoritama.

2.3 Pregled standardizacijskih tijela i grupa

ITU i OSI su razvili tokom osamdesetih osnovne TMN standarde za sloj elementa mreže, sloj upravljanja elementima mreže i sloj upravljanja mrežom. Kako seTMN razvijao tokom vremena, postalo je očigledno da, uprkos svim naporima, TMN tehnologija nije pripremljena ili bolje rečeno proces standardizacije je vrlo spor za složene slučajeve upravljanja koji uključuju slojeve upravljanja servisima i poslovanjem. Radi toga različita formalna i neformalna tijela i grupe intenzivno rade na razvoju industrijskih standarda koji ustvari postaju de-facto standardi.Slika 1. prikazuje pojednostavljeni proces evolucije alata za upravljanje i standardizaciona tela koja su uključena u proces evolucije upravljačkih alata baziranih na TMN-u3. Osnovna standardizaciona tijela i njihove aktivnosti su:

ITU koji preporučuje TMN sa primenom CMIP principa (Common Management Information Protocol). ITU je takođe prihvatio arhitekturu distribuirane obrade ODP (Open Distributed Processing) za primjenu u telekomunikacijama, koju je definisao ISO za potrebe računarskih mreža.

2 Igor Čavrak, Magistarski rad „Prilagodljivi objektno usmjereni raspodijeljeni sustavi“, Fakultet elektrotehnike i računarstva, Zagreb, 2001. strana 73 D. Vučković, N. Gospić, R. Simić, „Primena tehnika distribuiranog upravljanja u telekomunikacijskim mrežama, 15. Telekomunikacioni forum TELFOR, Beograd, strana 2.

7

IEFT (Internet Engineering Task Force) je razvio SNMP (Simple Network Management Protocol).

ISO (International Standards Organisation) je razvio alate za DPE ( Distributed Processing Environment) radi postizanja ODP (Open Distributed Processing)

TMF (TeleManagement Forum, ranije Network Management Forum) je razvio koncept «Ensembles» da bi kasnije razvio koncepte TIM (Technology Integration Map) i TOM (Telecom Operations Map).

OMG (Object Management Group) je razvila OMA (Object Management Architecture) koja je za rezultat imala CORBA (Common Object Request Broker Architecture).

TINA–C (TINA Consortium) je razvila TINA (Telecommunications Information Networking Architecture).

SUN je razvio programski jezik JAVA koji vodi ka JMAPI (Java Management API) i JDMK (Java Dynamic Management Kit).

DMTF (Desktop Management Task Force) je razvio CIM (Common Information Model) i WBEM (WEBbased Enterprise Management).

3GPP (3G Project Partnership Project) u svom razvoju se bazira na TIP (Technology Integration Point) i IRP (Integration Reference Point).

Slika 1. Pojednostavljena slika evolucije alata za upravljanje

2.4 Prednosti CORBA rješenja

CORBA je objektno-orijentisana arhitektura i infrastruktura koju koriste računarske aplikacije za međusobnu saradnju u mreži, a nezavisna je od proizvođača. Osnovna paradigma CORBA-e se može definirati kao “zahtijev za uslugu (servis) od strane distribuiranog objekta”. Usluge (servisi) koje objekti pružaju su raspoloživi pomoću sučelja, a sučelje je definirano IDL jezikom. Distribuirani objekti se mogu identificirati pomoću objektnih referenci, a iste se također definiraju IDL jezikom.

8

Korišćenjem standardnog IIOP (Internet Inter-ORB Protocol), CORBA programi bilo kod proizvođača, na bilo kom računaru, operativnom sistemu, programskom jeziku ili mreži mogu da komuniciraju sa CORBA programima istog ili drugog proizvođača. Drugim riječima, CORBA, omogućavanja interoperabilnosti između aplikacija u heterogenim distribuiranim okruženjima, bez obzira gdje su one locirane.

Glavna ideja iza CORBA-e je da međuoperabilnost između objekata, koji se izvršavaju na određenim CORBA proizvodima različitih izvora, bude moguća jer CORBA specificira svoje vlastite standardizirane komunikacijske protokole i Interface Definition Language (IDL). Zbog navedenog, barem u teoriji, svi “srodni” CORBA proizvodi moraju biti sposobni da međusobno obavljaju određene operacije.

CORBA ima svoj jezik za opisivanje interface objekata, Interface Description Language (IDL), koji može biti preveden u mnogo jezika i za mnogo platformi. Ovako su CORBA interface-i nezavisni o programskom jeziku kojim će biti implementirani klijent i server objekti. CORBA takođe provodi svoje komunikacijske protokole koji se izvode «iznad» raznih standarnih protokola (npr. TCP/IP).

CORBA je nezavisna o platformi i programskom jeziku i zbog toga omogućava integraciju software komponenti iz različitih izvora. Integraciju omogućava preko mreže sa raznolikim tehnologijama preko svojeg komunikacijskog protokola. CORBA protokoli standardiziraju poruke i formate podataka tako da topologija i priroda mrežnih protokola nije uopšte važna. Najčešće korišteni CORBA protokol je Internet-Inter ORB Protokol (IIOP), koji specificira kako se CORBA poruke prenose na Internetu preko TCP/IP-a.

Danas je potrebno da CORBA omogućava podršku mobilnim aplikacijama, na primjer, u bežičnom okruženju sa mobilnim uređajima gdje serveri mijenjaju vrlo često svoju lokaciju.

CORBA je uvijek nastojala podržavati okruženja sa potencijalno velikim brojem objekata i korisnika. U skladu sa time, CORBA arhitektura je dizajnirana na takav način da ne omogući neki nedostatak ili zabranu zavisno o broju objekata i korisnika u sistemu.

9

3. Najčešće primjenjivani objekti kao dio telekomunikacijskog sistema

Objekt je osnovni entitet sistema CORBA određen svojim identitetom i sučeljem. Objekt kao takav je virtualni entitet, konkretna implementacija mora biti izvedena korištenjem nekog od ciljnih programskih jezika. Bitno je napomenuti da je životni vijek objekata sistema CORBA neovisan o životnom vijeku njihove konkretne implementacije (npr. objekta programskog jezika Java).Implementaciju objekta (servant) čini entitet programskog jezika kojim se realizira funkcionalnost pripadajućeg objekta ili grupe objekata istog sučelja. Programski entitet implementira sučelje i tijelo (izvršni kod) objekta. Najčešće korišteni jezici implementacije su objektno usmjereni jezici – C++, Java, Smalltalk, no mogu se koristiti i ostali jezici, npr. programski jezik C4.Referenca objekta (eng. object reference) jedinstveno opisuje objekat sistema CORBA. Koristi se u svrhu identifikacije, lociranja i adresiranja pojedinog objekta. Korisnici upotrebljavaju referencu na ciljni objekat prilikom poziva njegovih metoda ili kao argument poziva metoda drugih objekata, no ne mogu direktno utiecati na podatke smještene u njoj. Reference na objekte stvaraju se u trenutku stvaranja objekta na strani poslužitelja. Korištenje objekta transparentno je s obzirom na njegovu trenutnu lokaciju, operacijski sistem računara na kojemu se objekt nalazi i programski jezik implementacije. Korisnik može biti samostalni program (npr. korisnička aplikacija s grafičkim sučeljem) ili drugi objekt sistema CORBA.

3.1 CORBA arhitektura

OMG je definirala objektno – orjentiranu arhitekturu za interakciju aplikacija neovisno od platforme nazvanu OMA (Object Management Architecture), koja je krovna arhitektura za sve OMG specifikacije. Glavni zadatak OMG-a je da omogući jedinstveni arhitektualni framework za međusobnu komunikaciju objekata aplikacije putem heterogene hardverske platforme i operativnih sistema.

Ovaj standard pokriva četiri glavne komponente5:

ORB (Object Request Broker - "Posrednik zahtjeva za objektima", je srce sistema. Omogućava klijentima i serverima da traže i primaju zahtjeve i odgovore. Tri kategorije sučelja objekata koriste posredničku komponentu: sučelja zajedničke usluge, sučelja zajedničkih mogućnosti i sučelja aplikacija.

Objektni servisi - zbirka standardnih usluga koje osiguravaju osnovne funkcije i stoje na raspolaganju svim programerima. Čine sučelja neovisna o pojedinim domenama problema (horizontalno usmjerena), koriste se u širokom spektru

4 A. Kos, K. Krajnik, T. Grgac, Izrada CORBA client – server aplikacije, Sveučilište u Splitu, Odjel za stručne studije, Stručni studij računarstva Zagreb, strana 85 E. Filipović, CORBA rješenje software distribuiranih sistema, Naučno-stručni časopis „Telekomunikacije“, broj 17, 2007. strana 34

10

raspodijeljenih objektno usmjerenih aplikacija na razini objekta ili grupe objekata.

Aplikacijski objekti - to su aplikacijski programi za klijente ili servere, koji obavljaju poslovnu funkciju. Pišu ih programeri, svaki za svoju aplikaciju. Standard određuje pravila vanjskog ponašanja takvog objekta.

Zajedničke mogućnosti (Common Facilities) - skup korisnih objekata, koji pokrivaju uobičajene stvari koje treba uvijek raditi, a koje se mogu koristiti iz Aplikacijskih objekata. ) Sličnih su karakteristika kao i objektne usluge, no usmjerene su pružanju usluga “više razine”, na razini aplikacija. Sučelja su specijalizirana (vertikalno usmjerena) za pojedine domene (telekomunikacije, zdravstvo, itd.). Kao primjer sučelja domena mogu se navesti MASIF (eng. Mobile Agent System Interoperability Facility) i PIS (eng. Person Identification Service).

Slika 2. CORBA arhitektura

3.1.1 Object Request Broker – ORB

ORB se ponaša kao telefonska mreža iz ranije analogije - povezuje pojedine objekte koji žele komunicirati6. Da bi bila korisna, telefonska mreža mora osigurati standardne servise (npr. upiti o telefonskim brojevima), a često daje i dodatne opcijske servise (npr. tačno vrijeme). Analogno, CORBA arhitektura definira Objektne servise koji su zajednički svim aplikacijama i Zajedničke mogućnosti, koje se mogu koristiti u pojedinim konkretnim aplikacijama.

6 Igor Čavrak, Magistarski rad „Prilagodljivi objektno usmjereni raspodijeljeni sustavi“, Fakultet elektrotehnike i računarstva, Zagreb, 2001. strana 18

11

Uloga ORB-a je pružanje jedinstvenog sučelja prema višem, aplikacijskom sloju (slika 3), u svrhu stvaranja radnog okruženja koje će sakriti distribuiranu prirodu čitavog sistema.CORBA specifikacije osiguravaju da će svi ORB posrednici moći međusobno komunicirati.

Slika 3. Uloga ORB-a, jedinstveni interface prema aplikacijskom sloju

Standardizirani protokol komunikacije nužan je za ispravnu komunikaciju između instanci posredničkih komponenti na različitim serverima. Korišteni protokol naziva se GIOP (eng. General Inter-ORB Protocol), te čini viši, apstraktni sloj komunikacijskog protokola. Niži, implementacijski sloj, ovisan je o korištenom mrežnom protokolu, tj. o komunikacijskoj infrastrukturi. Jedini protokol koji standard propisuje, a koji sve posredničke komponente moraju implementirati, je IIOP (eng. Internet Inter-ORB Protocol). IIOP se koristi za komunikaciju putem TCP/IP temeljenih računalnih mreža.

ORB (Object Request Broker) je distribuirana usluga koja je zadužena za:

- Pronalaženje distribuiranog objekta;- Proslijedivanje zahtijeva od strane klijenta prema distribuiranom objektu;- Proslijedivanje rezultata izvršavanja prema klijentu.

ORB čini lokaciju distribuiranog objekta transparentnom za klijenta, tj. bez obzira na to gdje se on nalazi klijent mu pristupa na isti način. Potpuno isti mehanizam koristi se za klijenta i CORBA objekt bez obzira na to gdje se objekt nalazi. On može biti unutar samog procesa u kojem je pokrenut klijent ili na drugom kraju svijeta. Klijent ne može ustanoviti razliku.ORB je distribuirani servis koji implementira zahtjev prema udaljenom objektu. Kada komponenta aplikacije želi koristiti servis dostupan na drugoj komponenti, prvo mora dohvatiti referencu objekta čije usluge želi koristiti. Nakon što je referenca

12

dohvaćena, zadaća ORB-a je da razriješi zahtjev nad referencom traženog objekta omogućavajući pritom komunikaciju između njih.ORB locira udaljeni objekt na mreži, prosljeđuje mu zahtjev, čeka na rezultat odnosno povratnu vrijednost koju na kraju vraća klijentu. Pritom, ORB provodi sva potrebna prevođenja tipova - tzv. marshaling i unmarshaling. Marshaliranje podataka znači pretvaranje parametra u oblik koji je pogodan za transmisiju preko mreže. ORB također vrši obrnutu pretvorbu tj. vrši pretvorbu iz on-the-wire formata u format koji pozivajuća komponenta razumije. Cijeli taj postupak se odvija sam po sebi tj on je implementiran u samom ORB-u.ORB implementira neovisnost zahtjeva o programskom jeziku, tj. programski jezici u kojima su relaizirani klijent i distribuirani objekt ne moraju biti isti. Klijent koji izvršava zahtjev može biti napisan u jeziku različitom od onoga u kojem je implementiran CORBA objekt. ORB provodi svu nužnu translaciju između programskih jezika. Povezivanje jezika (mapiranje) definirano je za sve popularne programske jezike.ORB locira implementaciju objekata (servera) preko objekt reference koju dobije od klijenta. Kada je server lociran, ORB osigurava da je server spreman primiti zahtjev. ORB na klijentskoj strani prima parametre pozvane metode te ih marshalira. ORB na serverskoj strani unmarshalira paramtere s mreže te ih proslijeđuje Serveru. Povratne vrijednosti (ukoliko postoje) se marshaliraju/unmarshaliraju na isti način.

Slika ORB provedba zahtjeva

Na slici 4 detaljnije je prikazana građa ORB posrednika.

ORB ima sljedeća svojstva:

- Transparentnost lokacije pozivanog objekta - korisnik objekta nije svjestan trenutne lokacije pozivanog objekta. ORB, poznavajući lokaciju trenutnog

13

objekta, može vršiti optimiziranje poziva, ali svojstvo transparentnosti se zadržava.

- Jezička nezavisnost – korisniku nije bitno u kojem programskom jeziku je ciljani objekat implementiran, dovoljno je poznavanje njegove reference i interfejsa koji implementira.

- Nezavisnost arhitekture - korisniku nije bitno na kojoj se platformi izvodi ciljni objekat. Prilagođavanje različitim arhitekturama (različita dužina riječi, itd.) vrši se transparentno unutar posredničke komponente.

- Nezavisnost od komunikacijskog protokola - sva komunikacija između korisnika i objekta svodi se na pozive metoda, ovisno o programskom jeziku implementacije korisnika. Za komunikaciju putem računarskfe mreže zadužena je posrednička komponenta koja se brine za usklađivanje korištenih protokola između dvije posredničke komponente (na strani korisnika i na strani ciljnog objekta).

Slika 4. Građa ORB-a

ORB je logički entitet koji može biti implementiran na različite načine, kao jedan ili više procesa ili skup biblioteka.Aplikacijski program klijenta napisan je u jeziku podržanom ORB-om. Svaki ORB podržava jednojezičko mapiranje (C++, Java, itd) u kojem su generirani odgovarajući proxy-ji (klijent proxy kao stub i server proxy kao skeleton).Kada je IDL aplikacija kompajlirana, ORB generira stubove i skeletone koji rade kao „ljepilo“ između klijentske i serverske aplikacije, i ORB-a, respektivno7.Za implementaciju interfejsa, CORBA IDL se prevodi (kompajlira) na programski jezik klijenta i servera. Na strani klijenta ovaj kod se naziva „stub“, a na strani servera „skeleton“. Stub metoda inicira mehanizme povezivanja na ORB-u kojima se zahtijev proslijeduje prema distribuiranom objektu. Klijent aplikacija, da bi zatražila servis od

7 E. Filipović, CORBA rješenje software distribuiranih sistema, Naučno-stručni časopis „Telekomunikacije“, broj 17, 2007. strana 35

14

servera, poziva metode „stub“. Zahtjeve zatim obrađuje ORB i prosljeđuje ih serveru preko „skeletona“. Skeleton metoda prevodi upit i parametre pristigle od strane klijenta te poziva izvršavanje metode na distribuiranom objektu. Objekat servera zatim prihvata zahtjev i klijentu vraća odgovor.Ukoliko su operacije pozvane od klijenta poznate za vrijeme kompajliranja stuba, takav tip poziva naziva se statičko pozivanje.Alternativa ovom tipu poziva se dešava kada klijent želi da pozove operaciju koja nije poznata stubu. Ova situacija može nastati, na primjer, kada je objektna implementacija promijenjena unutar servera (npr. dodavanje implementacije operacije) i IDL aplikacija nije ponovo kompajlirana da generira novi stub (koji će biti svjestan nove operacije), ili kada npr., klijent želi izvršenje operacije na objektnoj implementaciji, iako nema IDL interfejs poznat stubu (npr. klijent koji primi referencu udaljenog objekta od Trading servisa i želi pozvati operaciju nad objektom).Za takve tipove poziva, poznate kao dinamički pozivi, OMG je omogućio Dynamic Interface Invocation (DII), putem kojih klijenti mogu direktno pristupiti mehanizmu zahtjeva omogućenim od ORB-a. Aplikacije koriste DII da dinamički ispostave zahtjev bez zahtijevanja IDL interfejsno-specifičnog stuba za povezivanje. Za razliku od IDL stuba, DII takođe dozvoljava klijentima da čine neblokirajuće ogložene sinhronime i jednosmjerne pozive.Na serverskoj strani postoji nekoliko komponenti koje koristi ORB da posreduje izvršavanju operacije zatražene od klijenta, statički ili dinamički. Ukoliko je operacija zatražana koristeći Static Stub Invocation (SSI) mehanizam, tada će ORB proslijediti zahtjev objektnom adapteru, što se čini korištenjem informacije sadržane unutar reference objekta.Objektni adapter asistira ORB-u isporučivanjem zahtjeva odgovarajućoj objektnoj implementaciji i aktiviranjem odgovarajućih objekata unutar servera. Objektni adapteri su, takođe, odgovorni za primjenjivanje politike sigurnosti specificirane na objektnoj implementaciji.Dybnamic Stub Invocation (DSI) omogućava ORB-u da isporuči zahtjeve objektnoj implementaaciji koja, za vrijeme kompajliranja, nema znanje o tipu objekta koji se implementira. Klijent koji pravi zahtjev nema podatak da li implementacija koristi specifični IDL skeleton ili dinamički skeleton.

3.1.2 Objektne reference

Objektne reference (slika 5)8 jedinstveno označavaju pripadajući objekt unutar distribuiranog sistema temeljenog na CORBA-i. Struktura objektne reference prikazana je na slici 5.

8 Igor Čavrak, Magistarski rad „Prilagodljivi objektno usmjereni raspodijeljeni sustavi“, Fakultet elektrotehnike i računarstva, Zagreb, 2001. strana 23

15

Slika 5. Srtuktura objektne reference

Oznaka sučelja jedinstveno označava tip sučelja, a koristi se za dohvat opisa sučelja iz mjesta za memorisanje sučelja (Interface Repository).Podatak o adresi procesa, a time i pripadajuće posredničke komponente, nužna je unutar reference kako bi se mogla uspostaviti veza između komponente na strani korisnika objekta i komponente na strani implementacije ciljnog objekta. Ovaj podatak ovisan je o korištenom komunikacijskom protokolu. U većini slučajeva koristi se protokol IIOP, stoga su nužni podaci za uspostavljanje veze IP adresa računara i port na kojem posrednička komponenta osluškuje zahtjeve. Oba navedena podatka moraju biti dostupna svim implementacijama posredničke komponente kako bi one međusobno mogle sarađivati.Objektni ključ označava pozivani objekt unutar procesa poslužitelja. Objektni ključsastoji se od imena objektnog adaptera u kojem je objekt registrovan (koristi se odstrane posredničke komponente u svrhu prosljeđivanja poziva odgovarajućemadapteru) i imena objekta (koristi se od strane adaptera u svrhu pozivanjaodgovarajuće implementacije objekta). Oblik zapisa objektnog ključa specifičan je implementaciji sustava CORBA, te se koristi samo na strani ciljnog objekta.Objektne reference mogu biti pohranjene u postojanom obliku (npr. unutar datoteke ili imeničke usluge) radi kasnijeg korištenja. ORB nudi mehanizme pretvaranja objektne reference u niz karaktera i obratno radi lakšeg zapisa i prijenosa reference kao parametra poziva.

3.1.3 Objektni adapteri

CORBA specifikacija definira koncept object adaptera. Object Adapter je framework za implementaciju CORBA objekata i sadrži API kojeg implementacije objekta koriste za različite low-level namjene.Adapter u sistemu CORBA ispunjava tri ključne uloge:

Učestvuje u kreiranju objektnih referenci: svaki objekt sistema CORBA pripada jednom adapteru. U trenutku stvaranja reference (ne nužno istovremeno i stvaranju objekta) unutar nje zapisuje se ime pripadajućeg adaptera.

Čuva podatke o registrirovanim objektima i njihovim implementacijama: svaki objekat mora imati pripadajuću implementaciju u nekom od programskih jezika, no svaka implementacija može pripadati više od jednom objektu.

Prosljeđuje pozive metode objekata odgovarajućim implementacijama: po prijemu ORB poziv prosljeđuje odgovarajućem adapteru.

16

U prvim verzijama standarda CORBA bio je definiran samo osnovni adapter (eng. Basic Object Adapter – BOA). No njegovi nedostaci rezultirali su od verzije standarda 2.2. uvođenjem prenosivog adaptera objekata (eng. Portable Object Adapter – POA). POA sadrži listu svih u njemu registriranih objekata i odgovarajućih implementacija objekata. Prispijećem poziva metode udaljenog objekta ORB na osnovu informacija pohranjenih unutar objektne reference prosljeđuje zahtjev odgovarajućem adapteru. Adapter, također na osnovu informacija unutar objektne reference, identificira ime pozvanog objekta i unutar liste registriranih objekata pronalazi pokazivač na implementaciju objekta (eng. servant). U slučaju da je implementacija objekta neaktivna, adapter je aktivira (npr. stvori objekt odgovarajuće klase), te poziva odgovarajuću metodu implementacije. Ako implementacija objekta nije pronađena u listi registriranih objekata, koriste se mehanizmi upravljača implementacija objekata (eng. Servant Managers), čija je uloga pronalaženje odgovarajuće implementacije i njeno pokretanje (eventualno i zaustavljanje njena rada).POA omogućava hijerarhijsku organizaciju adaptera (struktura stabla), te dodjeljivanje zajedničkih karakteristika svim objektima na razini adaptera (npr. trajni ili privremeni objekti, stepen sigurnosti, korišteni model pokretanja implementacija, itd.).U adapterima namijenjenim radu u stvarnom vremenu koriste se optimizacije u svrhu postizanja što veće brzine rada sistema (korištenje bržih mehanizama komunikacije između objekata na istom računaru ili u istom procesu) ili prenošenja informacija o prioritetu izvršavanja niti ili procesa.

3.1.4 Interface Definition Language – IDL

IDL interfaceom se definira protokol za komunikaciju između dvije odvojene komponente u sustavu. Pod komponentama možemo podrazumijevati različite procese, objekte, korisnike ili aplikacije odnosno bilo koja dva različita entiteta koja žele međusobno komunicurati. Interface opisuje servise koje komponenta izlaže i protokol prema kojem se ti servisi mogu koristiti.IDL nije proceduralni jezik; njime se mogu definirati samo sučelja, ali ne i implementacije.Za opis sučelja objekta sistema CORBA nužno je poznavanje:

atributa i metoda od kojih se sučelje sastoji; tipova podataka atributa, parametara metoda i povratne vrijednosti.

17

Slika 6. Prevođenje opisnog jezika sučelja u jezik implementacije

Atributi, metode i korišteni tipovi podataka moraju biti opisani nezavisno o ciljnom jeziku implementacije i korištenoj platformi, kako bi njihova upotreba mogla biti platformno i jezično nezavisna. Stoga je od strane OMG-a definisan opisni jezik sučelja (eng. Interface Definition Language – IDL). IDL definira osnovne tipove podataka putem kojih je moguće opisati složenije strukture podataka i metode sučelja sa svim pripadajućim parametrima. No uopštenost opisnog jezika i korištenih osnovnih tipova podataka nužno je dovela do određenih kompromisa, kako bi implementacija ovako opisanih sučelja bila moguća u što većoj grupi programskih jezika.Važno svojstvo OMG IDL-a je nezavisnost od programskog jezika. Objekti mogu biti konstruisani koristeći različite programske jezike a da i dalje komuniciraju jedan sa drugim.Interfejs napisan u IDL-u može biti mapiran u bilo koji programski jezik. Na taj način i CORBA aplikacije su jezički nezavisne. Klijent napisan u C ++ može komunicirati sa serverom napisanim u Javi, koji opet može komunicirati sa serverom napisanim u VB-u. Najvažnija uloga IDL-a je da definira Interfejs koji implementira te funkcionalnosti u bilo kom jeziku.

3.1.5 CORBA Servisi

Objektni servisi su kolekcija osnovnih servisa za korištenje i implementaciju objekata. Servisi su potrebni da bi se konstruisala distribuirana aplikacija i oni su nezavisni od aplikacija.

18

CORBA servisi su nezavisni od domena (horizontalno orijentisani gradivni blokovi koji su ili osnovni za razvoj distribuiranih CORBA aplokacija ili omogućavaju univerzalnu osnovu za interoperabilnost aplikacije)9. Drugim riječima, servisi objakata (CORBA servisi) pružaju funkcionalnost CORBA aplikacija, dopuštajući programerima da pozivaju servise umjesto da pišu i pozivaju svoje privatne objektne servisne funkcije.Kao i sa svim specigikacijama, OMG ne definira implementaciju za ove servise, ali određuje interfejse putem kojih se servis nudi.Dokumenti OMG CORBA services: Common Object Services Specifications definiraju različite CORBA servise, od kojih su neki opisani u nastavku rada:Servis imenovanje (Naming Service) omogućava CORBA objektima da se registriraju i da budu locirani po imenu. Zbog toga, klijenti ne moraju da se sjete referenci na objekte koje žele da koriste. Za dato ime objekta servis imenovanja vraća referencu objekta, ukoliko je isti objekat imenovan. Ovaj servis koristi notaciju naming context koji sadrži skup jedinstvenih imena. Naming servis takođe podržava (federated) sjedinjenu arhitekturu, što znači da imenovani serveri mogu biti distribuirani unutar mreže i raditi u konjukciji jedni sa drugima.Trgovački servis (Object Trader Service), kao i servis imenovanja, omogućava drugim objektima da lociraju CORBA objekte. Radije nego da koristi ime da bi locirao objekat, kao servis imenovanja, klijentski objekt traži servise na osnovu naziva operacije, parametara i tipa rezultata. Glavna razlika između Trader servisa i Naming servisa je analogna razlici između žutih i bijelih stranica telefonskog imenika. Servis imenovanja može se posmatrati kao bijele stranice, u kojima tražimo pojedinačni servis ako znamo tačno ime. Trgovački servis, sa druge strane, ima sličnosti sa žutim stranicama, u kojima se locira servis prema njihovoj lokaciji, funkciji ili čak imenu. Na primjer u bijelim stranicama može se tražiti XY hemijska čistionica, a u žutim stranicama svi servisi hemijske čistionice u, npr., Sarajevu.Sevis događaja (Event Service) omogućava mehanizam pomoću kojeg CORBA objekti mogu slati i primati događaje. Servis uključuje mogućnosti kao:

Pouzdanu isporuku, koja osigurava da će događaj dospjeti do destinacije; Podrški za push i pull modele isporuke događaja; Kanale događaja, mehanizam sličan publish/subscribe, kroz koji korisnici

mogu da se pretplate na pojedine tipove događaja.

Servis postojanosti objekta (Persistent Object Service) pruža skup interfejsa za upravljanje postojanosti objekta. Tipično, implementacije za ovaj servis osigurane su od proizvođača baza podataka. Stalni (postojani) objekti su objekti koji opstaju kroz neki period, tako da životni vijek objekta može premašiti životni vijek bilo koje aplikacije. Kada se ne koristi objekat se nalazi u stalnoj memoriji, kao npr. u bazi

9 E. Filipović, CORBA rješenje software distribuiranih sistema, Naučno-stručni časopis „Telekomunikacije“, broj 17, 2007. strana 36

19

podataka. Objakat može biti dohvaćen ili ponovno uveden kada je to potrebno. Na primjer, o dokumentu kreiranom sa word procesorom može se razmišljati kao o stalnom objektu zbog toga što aplikacije worda može biti zatvorena i pokrenuta ponovo, dopuštajuću dokumentu da bude dohvaćen.Servis upita (Query Service) omogućava korisnicima i objektima da pozovu upite na kolekciji drugih objekata. Upiti mogu da sadrže iskaze koji specificiraju objekte, a bazirane na vrijednostima atributa. Servis, takođe, podržava objektno indeksiranje kao i ugniježdene upite (nested query). Query mogućnost pruža bazi podataka slične semantike kao i CORBA objekti. Upravo kao što aplikacija može izvršiti upit nad tabelama i redovima u relacionoj bazi podataka, Servis upita omogućava aplikaciji da izvrši upit nad CORBA objektima. Može se koristiti SQL struktuirani upitni jezik, te OQL – objektno orijentisani jezik definisan od OMG-a.Servis relacija (Relationship Service) omogućava komponentama i objektima koji ne znaju ništa jedan o drugom da budu uvezani. To može biti učinjeno bez mijenjanja postojećih objekata ili zahtjeva da se dodaju novi interfejsi. Drugim riječima, dinamičke veze između nepromjenljivih objekata mogu biti kreirane. Servis održava veze između objekata. Povezani objekti čak ne moraju biti svjesni da su dio veze. Servis definira dvije nove vrste objekata: veze (relationships) i uloge. Upravljanje vezama između objekata je, naravno, moguće i bez servisa relacije, ali ovaj servis redukuje kompleksnost upravljanja složenih odnosa.Servis sigurnosti (Security Service) specificira interfejse za karakteristike sigurnosti:

Identifikacija i autentičnost korisnika, koji verificiraju da su korisnici oni koji se i predstavljaju da jesu;

Autorizacija i kontrola pristupa određuju kojim korisnicima je omogućen pristup koji servisima ili objektima;

Sigurnosno slušanje, koje omogućava snimanje korisničkih akcija; Sigurnost komunikacije, koja uključuje autentičnost korisnika prema servisima

(i obrnuto), zaštitu integriteta i zaštitu povjerljivosti; Non – repudiation, koja uključuje sposobnosti slične onim koju pružaju digitalni

potpisi, što znači porijeklo podatka ili prijem podatka može biti neoborivo dokazano;

Administracija različitih sigurnosnih politika; Sigurnost je glavno pitanje za neke aplikacije, na primjer, u bankovnoj

aplikaciji, svi aspekti sistema moraju biti sigurni, od autentičnosti do identifikacije korisnika radi sigurnosne komunikacije između banke i ATM-a.

Vremenski servis (Time Service) omogućava korisniku da dobije tačno vrijeme. On može odrediti redosljed događaja i može generirati događaj na osnovu tajmera.

20

3.2 CORBA interoperabilnost

Generalna ORB interoperabilnost arhitekture uvedena je sa CORBA 2.0, kako bi se odgovorilo zahtjevima za direktnu ORB – ORB interoperabilnost i za interoperabilnost baziranu na premoštavanju. Direktna interoperabilnost je moguća kada se dva ORB-a nalaze u istom domenu, što drugim riječima znači da ORB-ovi razumiju iste objektne reference, koriste isti OMG IDL tip, komuniciraju putem istih protokola nižeg nivoa i čak dijele iste sigurnosne informacije. Interoperabilnost premošćavanjem znači da ORB-ovi iz odvojenih domena moraju komunicirati. Pravilo takvih mostova je da prevode ORB ili specifične informacije domene od jednog ORB domena do drugog.ORB arhitektura interoperabilnosti bazirana je na apstraktnom General Inter – ORB protokolu (GIOP), koji specificira specifičnu sintaksu transfera i standardan skup formata poruka za ORB interoperabilnost preko bilo kojeg konekcijski baziranog transporta.Internet Inter – ORB protokol (IIOP) specificira kako GIOP mora ili implementirati IIOP ili omogućiti polupremošćavanje prema njemu. IIOP je daleko najzastupljeniji CORBA protokol danas.ORB arhitektura interoperabilnosti takođe specificira za druga okruženja specifični inter – ORB protokol (ESIOP – Environment Specific Inter – ORB Protocol) koji dozvoljava ORB-ovima da budu napravljeni za specijalne situacije u kojim infrastruktura već postoji. Prvi ESIO koji je usvojen je DCE Commom Inter – ORB protokol (DCE – CIOP), koji se može koristiti od ORB-ova u okruženju gdje je DCE već instaliran.

21

4. Poznata rješenja koja koriste CORBA

4.1 CORBA Event Service Objavi-pretplati paradigma je stvorena oko odašiljanja događaja. Najjednostavnija arhitektura sistema koji se temelji na takvoj paradigmi sadrži jedan izvor događaja (event producer) i nekoliko potrošača događaja (event consumer). Kada se na izvoru događaja promijeni stanje (stvoren novi događaj) šalje se poruka ili događaj potrošačima10.

Slika 7. Osnovna arhitektura objavi – pretplati

CORBA Event Service je jednostavnija izvedba paradigme objavi pretplati. Ova izvedba predviđa dvije uloge za objekte koji komuniciraju: proizvođač (supplier) i potrošač (consumer).Zanimljivost ovog modela je podržavanje push i pull metoda komunikacije kod potrošača poruka.Ova dva objekta mogu komunicirati direktno, no u punoj izvedbi između njih stoji kanal (Event Channel) koji je posrednik.Dodatni objekti potrebni za rad ove usluge su Administrator potrošača i proizvođača (Consumer Admin i Supplier Admin), te proxy consumer i proxy supplier. Ova dva zadnja objekta služe kao prividni proizvođač i potrošač poruka.Ova se arhitektura može lakše objasniti slikom (slika 8).

Slika 8. CORBA Event Channel

10 V. Stanić, „Paradigma objavi – pretplati“, Fakultet elektrotehnike i računarstva, Zagreb, 2006, strana 5

22

Na kanal su spojeni administratori potrošača i proizvođača. Ova se dva objekta ponašaju kao objekti fabrike (eng. Factory objects) i stvaraju objekte potrošače tj. proizvođače. Kao povratna vrijednost stvaranja objekta potrošača / proizvođača se vraćaju proxy proizvođač / proxy potrošač.Objekti potrošači i proizvođači komuniciraju sa proxy-ima push i pull metodama.Poruke se prosljeđuju između proxy proizvođača i proxy potrošača kroz kanal. Kanal može imati neke dodatne funkcije kvalitete usluge kao što su filtriranje, prioritetne poruke itd. Kanali se mogu kombinirati i nastavljati jedan na drugi, no ovakvo rješenje povećava kašnjenje poruka.Kroz kanal se mogu slati generičke i tipizirane poruke. Kod tipiziranih poruka se koristi OMG-ov IDL (eng. Interface Definition Language)Arhitektura CORBA-e može garantovati kvalitet usluge (kašnjenje, filtriranje, …) zbog korištenja kanala. Ovo vrijedi za sve izvedbe, no takva arhitektura donosi i jedan nedostatak. Kanal predstavlja jednu tačku u kojoj se može desiti zagušenje ili pad čime pada i cijela usluga.

4.2 CORBA Notification Service

CORBA Notification Service je unapređenje već opisanoga CORBA Event Service-a11. U Notification Service-u (u odnosu na Event Service) podržano je više administratorskih objekata po pojedinome kanalu. To se može vidjeti na slici 9.

Slika 9. CORBA Notification Channel

Podržane su funkcije administracije, filtriranja i kvalitete usluge (QoS), te strukturirani događaji što se može iskoristiti za provjeru tipa podataka kod pokretanja (Run time).Od administrativnih funkcija podržane su funkcije nadzora broja korisnika (proizvođača poruka, potrošača poruka, proxy objekata itd.). Dodate su funkcije

11 V. Stanić, „Paradigma objavi – pretplati“, Fakultet elektrotehnike i računarstva, Zagreb, 2006, strana 10

23

kojima se može mijenjati tip poruka ili nadzirati koje se poruke čitaju i time optimizirati promet.Dodani su i filteri poruka koji se mogu nalaziti na samome kanalu, administratorima ili proxy objektima. Rezultat ovakvog postavljanja filtera je hijerarhija filtriranja. Filteri mogu biti filteri usmjeravanja, koji donose odluku o usmjeravanju poruke, ili filteri mapiranja koji mogu mijenjati strukturu poruke.

4.3 CONCHA

CONCHA (CONference system based on java and corba event service CHAnnels) je nadogradnja na CORBA Event Sevice, kojima se posebno bavi višeodredišnim usmjeravanje (eng. multicast), pouzdanošću i redoslijedom. Dodatak je korištenje light-weight reliable multicast protocol (LRMP) kojemu je jedna odrednica dostavljanje paketa po redoslijedu. Slika arhitekture CONCHA-e (slika 10) je vrlo slična slici arhitekture CORBA Event Service sa dodatkom proxy-a za višeodredišnousmjeravanje.

Slika 10. CONCHA Event Service

U sistem CONCHA-e su dodana dva proxy-a za sve korisnike višeodredišnog usmjeravanja. Time je dodana alternativa usmjeravanju u obliku sigurnog višeodredišnog usmjeravanja. Dozvoljena je kombinacija metoda, jer događaj objavljen preko multicast proxy-a se prosljeđuje i običnim i višeodredišnim potrošačima. Još se može spomenuti da svi višeodredišni korisnici pripadaju jednoj grupi i stoga nije bilo potrebno implementirati upravljanje grupama.

4.4 Ericssonov sistem za naplatu u stvarnom vremenu

Ericssonov PrePaid sistem (PPS – PrePaid System) naplate omogućava svakom potencijalnom pretplatniku trenutni pristup ličnim mobilnim uslugama uz visoki integritet i potpunu kontrolu potrošnje. PPS sistem naplate je vodeće GSM i 3G rješenje velikog kapaciteta bazirano na arhitekturi inteligentne mreže koje nudi

24

naplatu u stvarnom vremenu za glasovne (voice) i podatkovne (data) usluge te sadržaj12.Prije nego se uspostavi poziv ili podatkovna veza provodi se kontrola kredita. Ukoliko nema dovoljno sredstava na korisničkom računu poziv ili podatkovna veza se odbija i korisnik se obavještava da nema dovoljno kredita na računu. PPS sistem naplate koristi u svojoj arhitekturi komponente koje je moguće proširiti, omogućava jednostavnu integraciju novih tehnologija te nudi visoku kvalitetu usluge. Sistem nudi PrePaid korisnicima iste mogućnosti te usluge s dodatnom vrijednošću i PostPaid korisnicima. Naplata tih usluga može biti zavisna o vremenu, količini podataka ili o sadržaju pruženom korisniku.Uz otvoreni protokol, sistem naplate u stvarnom vremenu raspolaže i s 3GPP standardiziranim Parlay/OSA aplikacijskim programskim sučeljem za podršku naplate aplikacija prema Parlay konceptu. Parlay/OSA koncept nudi standardizirano okruženje za kreiranje usluga pa je podržanost Parlay aplikacijsko programskog sučelja u sistemu naplate postala nužnost. Parlay/OSA aplikacijsko programsko sučelje podržano je u PPS sistemu naplate preko CORBA arhitekture te nudi izuzetno jednostavnu i brzu integraciju aplikacija s PPS sistemom naplate kako bi se omogućila naplata izvršenih usluga korisniku.

4.5 DAIS proizvod

DAIS je ICL-ova implementacija CORBA standarda. DAIS se brine za upravljanje, sigurnost, zaštitu13.

Proizvod se sastoji od:

SDK-a (Software Development Kit) - komplet alata za razvoj aplikacijskih komponenti

RTL-a (Run Time Librarries) - biblioteka u kojima se nalazi ORB i Objektne Servise. (SDK sadrži RTL)

Opcijskih dodataka - Zajedničke mogućnosti za pristup postojećim TP aplikacijama i bazama

SDK-ovi i RTL-ovi ovise o sistemu na kojem će DAIS raditi, tako da postoji SDK za Windows, UNIX SVR4, SCO UNIX, VME, VMS itd. Isto vrijedi i za RTL-ove. Za svaki procesor na kojem će se vršiti obrada treba po jedan odgovarajući RTL.

Tipična DAIS aplikacija će se sastojati od klijentskih dijelova, koji će koristiti jedan ili više servera. Svaki sever opet može biti klijent daljnjim serverima. Klijentima stoje na

12 S. Lučić, Telekomunikacijska uslužna platforma, Ericsson Nikola Tesla, Revija, broj 15, 2003, strana 3813 www.bccservices.com, ICL novosti

25

raspolaganju bilo koji od servera u DAIS mreži. DAIS se brine za komuniciranje među njima.

Za izradu pojedinih komponenti, koriste se alati koji najviše odgovaraju. Npr., klijent aplikacija se može napisati u visual Basic-u, a serverska u nekom od popularnih RDBMS paketa.

Jedna od bitnih karakteristika DAIS-a, za razliku od nekih drugih CORBA proizvoda je da ima distribuirani ORB. OMG namjerno nije specificirala kako treba sagraditi ORB. To je ostavljeno proizvođačima, kako bi napravili proizvod najbolje prilagođen okolišu u kojem će raditi. Neki ORB-ovi su ugrađeni u glavni objekt, neki su napravljeni kao zaseban program, koji se može vrtjeti čak i na zasebnom procesoru.

Pošto je princip rada takav da svaki klijent-server poziv mora proći kroz ORB, sistem s jednim ORB objektom, pa makar bio i na posebnom uređaju, odgovara samo za relativno male mreže. Kod velikih komercijalnih mreža takav pristup vrlo brzo dovodi do problema uskog grla.

DAIS je namijenjen za velike komercijalne mreže, pa je kod njega i sam ORB distribuiran. Svaki klijent sadrži dovoljno veliki komad ORB-a da može direktno komunicirati s bilo kojim serverom u mreži, pa ne postoji mogućnost uskog grla.

26

5. Zaključak

CORBA je otvorena arhitektura distribuiranih objekata. Njen cilj je da automatizira mnoge zajedničke mrežne programske taskove, kao što su registracija objekata, lokacija i aktiviranje, uokvirivanje i otpremanje aktivnosti. Ova automatizacija uobičajenih funkcija u mreži urađena je putem mrežnog posrednika nazvanog Object Request Broker (ORB). On se nalazi na hostu između sloja podataka i aplikacijskig sloja u OSI modelu te manipulira na transparentan način porukama zahtijeva klijenata i servera.CORBA paradigma je bazirana na kombinaciji dviju postojećih metodologija: distribuirani client – server kompijuterski sistemi i metodologiji objektno – orijentisanog programiranja.Prisutnost objektno – orijentirane metodologije u CORBA je neophodno, s obzirom na to da perdstavlja prikladan način za tumačenje i razvoj programa motivirano željom programera da međusobno dijele komponente programa putem dobro definiranih interfejsa.Od CORBA 2.0, ORB-ovi različitih proizvođača mogu međusobno komunicirati: specificiran je protokol koji treba biti korišten za ORB – to – ORB komunikaciju. Najpopularniji takav protokol je IIOP (Interent Inter ORB Protocol). Temeljen je na TCP/IP-u, a predstavlja specijaliziranu verziju GIOP-a (General Inter ORB Protocol), tako da je CORBA arhitektura nezavisna o proizvođaču, nezavisna od platforme na kojoj se upotrebljava i nezavisna od programskog jezika u kome se aplikacija razvija. IDL (Interface Definition Language) kao specificirani jezik za opisivanje interfacea je „ljepilo“ koje povezuje različite proizvođače, platforme i jezike.CORBA je sa aspekta telekom operatera posebno interesantna kao middleware koji ima mogućnost primjene u SDP-u (Service Delivery Platform), WLAN-u te dominantna u sferi NML-a (Network Management Layer).

27

Literatura

Igor Čavrak, Magistarski rad „Prilagodljivi objektno usmjereni raspodijeljeni

sustavi“, Fakultet elektrotehnike i računarstva, Zagreb, 2001.

D. Vučković, N. Gospić, R. Simić, „Primena tehnika distribuiranog upravljanja

u telekomunikacijskim mrežama, 15. Telekomunikacioni forum TELFOR, Beograd, 2007.

A. Kos, K. Krajnik, T. Grgac, Izrada CORBA client – server aplikacije,

Sveučilište u Splitu, Odjel za stručne studije, Stručni studij računarstva Zagreb, 2006.

E. Filipović, CORBA rješenje software distribuiranih sistema, Naučno-stručni

časopis „Telekomunikacije“, broj 17, 2007.

V. Stanić, „Paradigma objavi – pretplati“, Fakultet elektrotehnike i računarstva,

Zagreb, 2006.

Interneto www.bccservices.com , ICL novosti

o www.telekomunikacije.rs , S. Boštjančič Rakas, M. Stojanović, N. Gospić,

Automatizacija upravljanja IP mrežama

28