Strokovne raz h have Objektni model porazdeljenega procesiranja Matjaž B. Jurif, Marjan Heričko. Ivan Rozman Povzetek: Tehnologija porazdeljenih objektov omogoča izgradnjo programske opreme z integracijo komponent objektov. Objekti se osvobodijo oklepa programskega jezika, v katerem so bili oblikovani in svobodno zaživijo v omrežju, Z zmožnostjo ponovne uporabe, prenosljivosti in povezljivosti v distribuiranem, heterogenem omrežju rešujejo večino težav, s katerimi se danes srečujejo razvijalci programske opreme in uporabniki računalnikov. V prispevku opisujemo model Common Object Request Broker Architecture (CORBA). Temelji na posredniku zahtev objektov, ki ima vlogo neke vrste vodila in je zadolžen za zagotavljanje komunikacije med aplikacijami, objektnimi storitvami in skupnimi sredstvi. Predstavlja »de-facto« standard med distribuiranimi objektnimi modeli. Tehnologija porazdeljenih objektov bo sčasoma izpodrinila ostale tehnologije in nepovratno vplivala na način uporabe in izgradnje programske opreme. Abstract: Distributed object technology enables building software with integration of components - objects. Objects become independent of programming language they were designed in and can live in the network. With reuse, portability and interoperability in distributed heterogen network they address the majority of problems developers and end-users are dealing with today. In this article the Common Object Request Broker Architecture (CORBA) is described. It is based upon an object request broker, which acts as a bus and is responsible for communication between applications, object sen/ices and common facilities. CORBA is "de-facto" standard for distributed object models. Over time distributed object technology will supersede other technologies and will have irreversible impact on the way software is used and built. 1. UVOD Danes se srečujemo z množico različnih računalnikov, povezanih v omrežje. Najmočnejši super-računalniki izvajajo zapletene znanstvene izračune ali delujejo kot strežniki glomaznih podatkovnih baz. V sredini najdemo strežnike in namizne računalnike, ki nudijo kompleksno množico storitev. O najmanjših sistemih mnogokrat nili ne razmišljamo kot o računalnikih. To so televizijski aparati, termostati in alarmi, telefoni in elektronske beležnice. Vsi ti sistemi uporabljajo različne operacijske sisteme in programske jezike. Želimo si, da bi bili računalniki povezani ne glede na tip, velikost ali operacijski sistem. Poglaviten problem današnjih računalniških omrežij, sestavljenih iz različnih računalnikov, operacijskih sistemov in aplikacij, je nezmožnost povezave. l.e-ta preprečuje boljšo so-uporabo podatkov in večjo produktivnost uporabnikov. Vemo pa, da se je računalniška paradigma spremenila. Podjetja niso več zadovoljna z uporabo računalnikov zgolj za štetje denarja, ki so ga zaslužila, Računalnike želijo uporabiti kot orodje za služenje denarja. Poglejmo, kateri problemi izvirajo iz omenjenega okolja: a) težko je zagotoviti integracijo računalniške strojne opreme, b) še težje je zagotoviti integracijo računalniške programske opreme, c) razvoj programske opreme traja predolgo in stane preveč. Potrebujemo nov način pogleda na celoten problem, od definicije problema in analize, skozi potek načrtovanja in implementacije do uporabe, vzdrževanja in dopolnjevanja. Objektna tehnologija je tak nov način. V prispevku si seveda ne bomo mogli ogledati celotne tematike. Osredotočili se bomo na področje implementacije, 1.1. Porazdeljeni objekti V preteklosti je računalništvo temeljilo na podatkih, namesto na njihovi uporabi, in na računalniških procesih, namesto na poslovnih procesih. Uporabniki so se morali prilagajati računalnikom. Strojna oprema ji' v tem Času postala veliko zmogljivejša. To nam daje možnost, da računalnike prilagodimo svojim zahtevam in ne 1997 številka t - letnik v »j «iHiin ml NFO RM AT IK A Strokovne raz h have ustanovitev OMG Začetni ORB predlogi Izdana knjiga OMA ČORBA 2 RFP request for proposal) Dopolnjevanj« objektnih ČORBA 1 1 izdana Sprejet« pive storitve storitev m skupni h sredstev 1989 1990 1991 1992 1993 1994 1995 1996 Prvo srečanje ČORBA t 1 sprejeta RFP ČORBA 2 0 izdana Izdan RFP za ORB a objektne storitve SiG končnin uporabnikov Sprejeti ČORBA 2.0. preslikava v C++ Slika 1: Kronologija dosežkov OMG-ja obratni). Uporabniki no želijo več velikih, monolitnih aplikacij, ki znajo vse, ampak iščejo majhne komponente - objekte, ki jih lahko sami združujejo in tako oblikujejo orodja, prilagojena njihovim tipičnim poslovnim potrebam. Objekti pa delujejo skupaj le, če so načrtovani in oblikovani na osnovi standarda. Objekti so enote kode in podatkov, ki komunicirajo s pošiljanjem in sprejemanjem sporočil. Če so zgrajeni korektno, so v sistemu visoko povezljivi in relativno enostavno je zamenjati lokalne objekte z oddaljenimi in tako razširiti komunikacijo skozi omrežje. Narava objektov radikalno spreminja način razmišljanja o tem, kje so naši podatki. Podatki, ograjeni v objekte, lahko pridejo tja, kjer so najbolj potrebni. Trenutno razmišljamo, da so dokumenti enostavno shranjeni na določenem trdem disku. Distribuirani objektni sistemi zavračajo to tezo in nudijo moč in fleksibilnost shrambe, neodvisne od lokacije. Naš ullimalivni cilj je integracija objektov. Za dosego tega cilja pa moramo najprej rešiti problem povezljivosti objektov v distribuiranih, heterogenih okoljih. Rešitve obstajajo v obliki modelov porazdeljenega procesiranja. V prispevku se bomo osredotočili na najpomembnejši objektni model, model ČORBA (Common Object Request Broker Architecture). Prehod na tehnologijo porazdeljenih objektov se ne bo zgodil čez noč; pot bo dolga in evolucijska. Pomembno pa je razumeti, kako tehnologije, ki so na voljo danes in tisle, ki bodo na voljo kmalu, pripravljajo uporabnike na življenje v svetu distribuiranih objektov. 1.2. Objektni modeli Od leta 1989 obstaja konzorcij objektnih dobaviteljev. Imenuje se Object Management Group1 (OMG). Ukvarja se s specifikacijo arhitekture odprtega programskega vodila, na osnovi katerega lahko povežemo objektne komponente različnih dobaviteljev prek omrežja. Or- Od jamarja 1996jo član OMG tudi Univerza v Manboiv, Fakulteta za elektrotehniko, računalništvo in informatiko, Institut za informatiko. ganizacija OMG določa smernice in specifikacije upravljanja z objekti in določa okvir za razvoj aplikacij. Osnovni cilji so ponovna uporaba, prenosljivost in povezljivost objektno osnovane programske opreme v distribuiranih, heterogenih okoljih. Ujemanje s specifikacijami omogoča razvoj heterogenih aplikacij za vse pomembnejše računalniške platforme in operacijske sisteme Danes pomeni OMG-jeva specifikacija arhitekture upravljanja z objekti (objecl management arehiteeture -OMA) »de-faeto« standard med distribuiranimi objektnimi modeli [14], OMA je konceptualna infrastruktura, na kateri temelji porazdeljeni objektni model ČORBA (Comiuw Object Reqttest Broker Arehiteeture). Siika I prikazuje kronološki razvoj skupine OM(i in njene pomembnejše dosežke. Omenimo naj še obstoj drugih porazdeljenih objektnih modelov. Microsoftov OLE 2.0/CC) M (Objecl Linking miti Embedding/Component Object Model) je objektni model, ki pa ni distribuirán. Microsoftov DCQM (D/s-tributed Componen! Object Model) je ugledal luč sveta v Windows NT 4.0. lBM-ov SOM (System Object Model), bil jc prvič uporabljen v OS/2, služi kot osnova Opcn-Dac-u. Ojien Doc podpirajo Apple, Novell, Sun, Xerox, Oracle, IBM in Taligent Zastavljen je bil neodvisno od operacijskega sistema, vendar je z razvojem daleč konkurenco. Razširjeni model SOM omogoča dostop do distribuiranih objektov. DSOM (Distribuícd SOM) je skladen s specifikacijo COliRA. Vso funkcionalnost objektnih sistemov pa že nudi NextStep 115]. Od distribuiranih ne-objektnih modelov naj omenimo samo OSE DCE (Open Stotem Foundation Distributed Computing Enviranment). Le-ta služi kot podlaga številnim ČORBA implementacijam in kot osnova Microsoftovega Distribuí cd Componen t Objecl Modelu. 2. Arhitektura upravljanja z objekti Referenčni model identificira in določa značilnosti komponent, vmesnikov in protokolov, ki sestavljajo arhitek- upon/btuAHFORMATIKA 1997-itevilka t ■ letnik V Strokovne raz h have turo upravljanja z objekti, vendar jih natančno ne definira. Referenčni model [12] ima naslednje funkcije: ■ Predstavlja ogrodje za pisanje specifikacij. ■ Identificira komponente arhitekture upravljanja z objekti, m Karakterizira funkcije, ki jih nudijo komponente, ■ Razlaga relacije med komponentami in zunanjim operacijskim okoljem, m Identificira protokole in vmesnike za dostop do komponent Aplikacija, skladna z arhitekturo upravljanja z objekti, je sestavljena iz. množice povezljivih objektov, ki komunicirajo skozi posrednik zahtev objektov (object rajucst broker ORB). Referenčni model določa, kako objekti pošiljajo zahteve in sprejemajo odgovore, določa ključne operacije za vsak objekt in vmesnike objektov, ki nudijo skupna sredstva, uporabna v večini aplikacij. Referenčni model je sestavljen iz naslednjih komponent (slika 2): ■ Posrednik zahtev objektov (object rcijuest broker) je ključ do povezljivosti. Objektom omogoča transparentno oblikovanje in sprejemanje zahtev in odgovorov v distribuiranem okolju. Je osnova za izgradnjo aplikacij iz dlstribuiranih objektov in za povezljivost med aplikacijami v heterogenih in homogenih okoljih. ■ Objektne storitve (object serviccs) so zbirka storitev (vmesnikov in objektov), ki podpirajo osnovne funkcije za uporabo in oblikovanje objektov. Storitve so potrebne za konstrukcijo vsake distribu-irane aplikacije in so vedno neodvisne od aplikacijske domene. ■ Skupna sredstva (common facilities) so zbirka storitev, skupnih mnogim aplikacijam, ki pa niso fundamen-talne, kakor so objektne storitve. aplikacijski objekti skupna sredstva < C ) "1 C p C p Posrednik zahtev objektov - ORB 1 ( ) ( j c jI > objektne storitve Slika 2; Referenčni model arhitekture upravljanja z objekti ■ Aplikacijski objekti so izdelki posameznega dobavitelja. Aplikacijski objekti sovpadajo s tradicionalnim izrazom aplikacija in niso standardizirani s strani OMG. Aplikacijski objekti sestavljajo najvišji nivo referenčnega modela. V splošnem so aplikacijski objekti in skupna sredstva aplikacijsko orientirani. Posrednik zahtev objektov in objektne storitve so orientirane na infrastrukturo sistema. Od štirih komponent referenčnega modela težijo tri k standardizaciji: posrednik zahtev objektov, objektne storitve in skupna sredstva. Četrta komponenta predstavlja aplikacijske objekte, ki so preveč specializirani za standardizacijo. Pomembno je poudariti, da morajo aplikacije za sodelovanje v arhitekturi upravljanja z objekti zagotoviti samo vmesnike, skladne z OMA. Ni nujno, da je njihova konstrukcija objektno orientirana. Na sliki 2 so take aplikacije prikazane v obliki pravokotnika, medtem ko krogi ponazarjajo objektno orientirane aplikacije. 3. OBJEKTNI MODEL ČORBA Common Object Request Broker Architecture (ČORBA) je konkreten objektni model. Izpeljan je bil iz referenčnega modela arhitekture upravljanja z objekti. Sestavljen je iz jedra in komponent [4], Objektni model najprej opiše koncepte, razumljive odjemalcem, kot npr. oblikovanje objektov, zahteve in operacije, tipe in podpise. Nato opiše koncepte, povezane z implementacijo objektov strežnikov, med drugim metode in izvršna okolja. Objektni model je najbolj specifičen pri definiciji konceptov, razumljivih odjemalcem. Ta objektni model je primer klasičnega objektnega modela, kjer odjemalec pošlje sporočilo objektu strežniku. Konceptualno gledano, objekt interpretira sporočilo in se odloČi, katero storitev bo izvršil. V klasičnem modelu sporočilo identificira objekt in nič ali več dejanskih parametrov. Kot v večini klasičnih objektnih modelov, tudi tukaj zahtevamo enoličen prvi parameter, ki identificira operacijo, ki jo je potrebno izvesti. Objekt interpretira sporočilo z izbiro metode, bazirane na specifični operaciji. Objekt je lahko odjemalec, strežnik, ali pa oboje. V določenem trenutku uporablja storitve drugih objektov, v določenem trenutku nudi storitve drugim objektom. Za konkretno akcijo pa so vloge točno definirane. Obstajati mora način specifikacije storitev, ki jih nudi objekt strežnik. ČORBA zato definira jezik /a definicijo vmesnikov (OMG Interface Définition Language - IDL). Definicija vmesnika specificira operacije, ki jih je objekt pripravljen izvršiti, in vhodne ter izhodne parametre, ki jih potrebuje. Poleg tega so v definiciji navedene izjemne situacije, ki lahko nastopijo. Odjemalci lahko pristopajo do strežnikov samo prek vmesnika. 1997-številka i - letnik V uporabruA NFORMAT IK A 31 Strokovne raz h have Arhitektura ČORBA torej strogo loči vmesnik objekta od njegove implementacije. Implementacijo objekta napišemo v poljubnem programskem jeziku, za katerega obstaja ustrezna preslikava. Specifikacija modela ČORBA |7| obsega: ■ jedro - posrednik zahtev objektov, m povezljivost, ■ preslikave jezika /.a definicijo vmesnikov v C, C+ +, Smalltalkin Ado2, ■ objektne storitve, ■ skupna sredstva. Minimalni zahtevi za sistem, združljiv s ČORBA, sta upoštevanje specifikacij jedra in ene preslikave IDI.-a v programski jezik. Vsaka nadaljnja preslikava v programski jezik je ločena, opcijska točka združljivosti. 3.1. Posrednik zahtev objektov Odjemalec je entiteta, ki želi, da objekt izvrši operacijo. Implementacija objekta je kombinacija kode in podatkov, ki predstavljajo objekt. ORIS je odgovoren za vse mehanizme, potrebne za iskanje implementacije objekta, za pripravo le-te za sprejem zahteve in za komunikacijo. Vmesnik, ki ga vidi odjemalec, je popolnoma neodvisen od tega, kje je objekt lociran, v katerem programskem jeziku je implementiran, ali od česarkoli drugega, kar se ne odraža v vmesniku objekta. V pripravi so preslikave za Javo in COBOL. Slika 3 predstavlja strukturo posameznega ORB. Vmesniki k GRB sn prikazani v obliki škatel, puščice pa nakazujejo, ali je klican ORB, ali pa ORB izvaja klic navzgor v vmesniku. Za izvedbo zahteve lahko odjemalec uporabi vmesnik za dinamično proženje (vmesnik, neodvisen od vmesnika ciljnega objekta) ali pa kontrolni odrezek IDL (specifični kontrolni odrezek, odvisen od vmesnika ciljnega objekta). Za nekatere funkcije lahko odjemalec direktno komunicira z ORB skozi vmesnik ORB. Implementacija objekta dobi zahtevo kot klic navzgor skozi skelet OMG IDI. ali skozi dinamični skelet. Med procesiranjem zahteve ali drugače lahko kliče objektni adapter in ORB. Vmesniki k objektom so lahko definirani na dva načina. Statično v IDI., kar imenujemo OMG IDI. - jezik za definicijo vmesnikov. Ta jezik definira tipe objektov glede na operacije, ki jih lahko izvajamo nad njimi, in parametre teli operacij. Vmesniki so lahko dodani v vmesniški rep oz i torij (interface repositon/), Ta predstavlja komponente vmesnika kot objekte, kar dovoljuje dostop do njih v času izvajanja. V vsaki implementaciji ORB imata IDL in vmesniški repozitorij enako izrazno moč. Odjemalec izvrši zahtevo. Pri tem ima dostop do reference objekta in pozna tip in zaželeno operacijo za izvedbo. Odjemalec inicira zahtevo s klicem rutin kontrolnega odrezka, specifičnih objektu ali z dinamično konstrukcijo zahteve. Dinamični vmesnik in vmesnik kontrolnega odrezr dinamično proženje kontrolni od rezki IDL vmesnik OKB statični skelet IDL dinamični skelet objektni « adapter jedro ORB implementacijski repozitorij vmesnik, odvisen od ORB vmesnik, identičen za vse implementacije ORB ] za vsak tip objekta in skelet obstajajo kontrolni odrezki obstaja več objektnih adapterjev Slika 3: Struktura posrednika zahtev objektov 22 «T*™Í»'"INFORMATÍKA 1997 ■ številka t - letnik V Strokovne raz h have ka za proženje zahteve zadovoljijo isto semantiko zahtev, zato Sprejemnik sporočila ne more ugotoviti, kako je bila zahteva prožena. ORB locira ustrezno implementacijsko kodo, pošlje parametre in prenese kontrolo na implementacijo objekta prek skeleta IDI ali dinamičnega skeleta. Skelet je specifičen vmesniku in objektnemu adapterju. Pri izvršitvi zahteve lahko implementacija objekta uporabi storitve ORB-ja skozi objektni adapter. Ko je zahteva popolna, se kontrolne in izhodne vrednosti vrnejo odjemalcu. V implementaciji objekta se lahko izbere, kateri adapter bo uporabljen. Ta odločitev bazira na tipu storitev, ki jih implementacija objekta zahteva. Informacije o implementaciji objekta se shranijo med njegovo instalacijo v implementacijski repozitorij za uporabo med izvajanjem zahtev. Vmesniške in im-plementacijske informacije, shranjene v ustreznih re-pozitorijih, so na voljo odjemalcu in implementaciji objekta. Vmesnik definira OMC 1DL oziroma vmesniški repozitorij. Definicija se uporablja za oblikovanje udjemalčevih kontrolnih odrezkov in skeletov implementacije objekta. 3.2. Povezljivost posrednikov zahtev Arhitektura povezljivosti med posredniki zahtev objektov je okvir za definicijo elementov povezljivosti. Opisuje nove mehanizme in specificira konvencije za dosego povezljivosti med neodvisno izdelanimi ORB-ji. Arhitektura povezljivosti jasno definira vloge različnih tipov domen za specifične informacije. Kjer sta ORB-ja v isti domeni, lahko komunicirata direktno. Navadno je to najbolj zaželen način. Ko mora informacija proženja zapustiti domeno, pravimo, da gre prek mosta (slika 4). Vloga mosta je zagotoviti preslikavo vsebine in semanlike iz oblike enega ORB-ja v drugo tako, da vsak ORB vidi samo ustrezno vsebino in semantiko. Podporo mostovom med ORB-ji specificira ORB API (application progranmiing intcrfacc) in konvencije za zagotavljanje enostavne konstrukcije mostov med dome- nami ORB. Takšne mostove lahko razvije dobavitelj ORB-ja ali kdo drug. Slika 4 prikazuje splošen most med ORB-jema. Razširitve, potrebne za podporo mostov med ORB-ji, so splošne in ne vplivajo na druge operacije. Uporabne so hldi v druge namene, kot npr. /a čiščenje programov. Most med ORB-ji je uporaben tudi za povezavo s sistemi, ki niso kompatibUni s ČORBA, kot je Microsoftov Cotnponent Object Model - COM. Enostavnost takega početja je odvisna od teh sistemov in njihove podpore modela ČORBA. Protokoli za komunikacijo med ORB-ji so: m Splošen protokol med ORB-ji (General Inter-ORH Protocol - (7/OPJ specificira sintakso prenosa na nizkem nivoju in množico oblik sporočil za komunikacijo med ORB-ji. Oblikovan je namensko za interakcije med ORB-ji in deluje preko vsakega transportnega protokola, ki ustreza minimalnim zahtevam. Protokol je enostaven, skalabilen in relativno enostaven za implementacijo. Omogoča prenosljive implementacije z majhno porabo pomnilnika in zglednimi zmogljivostmi, z minimalno odvisnostjo od podrejene programske opreme. ■ Internet protokol med ORfi-ji (Internet ¡ttter-ORB Protocol - IIOP) specificira, kako se izmenjujejo GIOP sporočila z uporabo TCP/IP (Transport Conlrol Pra-tocol/internct Protocol) povezav. IIOP specificira standardiziran protokol povezljivosti prek Interneta in omogoča povezljivost z drugimi kompatibilnimi ORB-ji. Uporaben je tudi kot protokol med pol-mostovi. Predstavlja osnovni protokol med ORB-ji za TCP/IP okolja. m Protokoli med ORB ji, odvisni od okolja (Enviroiiment Specific Intcr-ORH Protocol - ESIOP) slonijo na sredstvih, ki jih nudijo določena okolja. Podpirajo lahko specialna področja, kot npr. varnost in administracijo. Lahko so optimizirani za določeno okolje. Skladati pa se morajo s splošno arhitekturo povezljivosti ORB-jev za omogočanje enostavne povezave z mostovi, 3.3. Objektne storitve Posrednik zahtev objektov ne more zagotavljati povezljivosti na nivoju semantike aplikacij. ORB lahko primerjamo s telefonsko centralo, ki nudi osnovne mehanizme komunikacije, ne zagotavlja pa pomenske komunikacije med naročniki. Zato so potrebni dodatni vmesniki in protokoli zunaj telefonskega sistema kot so telefonski aparati, modemi in telefonski imeniki. Le-ti so ekvivalentni vlogi objektnih storitev. Zahtova odjcmalca k strežniku C Vmesnik dinamičnega skeleta Vmesnik dinamičneg proženja ORB A D C ORB B j> Slika 4; Splošen most metJORB-jema 1997 - Številka 1 - letnik V i iponlfa m!NfOR M ATIKA 23 Strokovne raz h have Specifikacija objektnih storitev je ponavadi sestavljena iz množice vmesnikov in opisa obnašanja storitev. Za opis vmesnika je uporabljen OMG IDI., Trenutno SO standardizirane naslednje objektne storitve [6]: n storitve poimenovanja, ki nudijo standardni pristop za oblikovanje imenskih kontekstov objektov, m dogodkovnestoritve, ki razgradijo komunikacijo med objekti, m storitve trajnih objektov ponujajo skupen vmesnik za mehanizem, ki se uporablja za ohranjanje in upravljanje trajnega stanja objektov, ■ storitve življenjskega eikla definirajo storitve in konvencije za oblikovanje, brisanje, kopiranje in premikanje objektov, ■ storitiig kontrole hkratnosti omogočajo koordiniranje dostopa več odjemalcev do deljenih virov, ■ storitve eksternalizncije definira njo protokole in konvencije za eksternaiizacijo in internalizacijo objektov ■ relacijske storitve omogočajo ekspliciten prikaz entitet in relacij za modeliranje entitet realnega sveta, ■ tmnsakcijske storitve združujejo transakcijski in objektni vzor in naslavljajo probleme komercialnega procesiranja transakcij, m storitve povpraševanja omogočajo uporabnikom in objektom sprožiti povpraševanja na zbirki objektov, m licenčne storitve nudijo mehanizme za nadzor uporabe intelektualne lastnine proizvajalcev. V prihodnosti pričakujemo razvoj novih objektnih storitev, kot npr. storitev trgovanja in varnostnih storitev. 3.4. Skupna sredstva Skupna sredstva obsegajo specifikacije višje nivojskih storitev in vertikalnih tržnih področij. Nekateri splošni primeri skupnih sredstev so elektronska pošta, tiskanje, ipd. Ta sredstva so potrebna v večini aplikacijskih domen. Skupna sredstva so primerno področje za standarde pri povezljivosti med neodvisnimi dobavitelji programske opreme f5j. Skupna sredstva so razdeljena v dve kategoriji: ■ Horizontalna skupna sredstva, ki si jih deli večina ali vsi sistemi. Obstajajo štiri poglavitne množice sredstev: uporabniški vmesnik, upravljanje informacij, Upravljanje sistema in upravljanje poslov. ■ Vertikalna tržna sredstva, ki podpirajo specifična področja, povezana z vertikalnimi tržnimi segmenti (npr. informacijske avtoceste, proizvodnja, računovodstvo, idr.). Ločnice med skupnimi sredstvi, aplikacijskimi objekti in objektnimi storitvami niso ostre in jasne, ampak odražajo evolucijo tehnologije objektnih sistemov, trenutna postavitev ločnic predstavlja trenutne ukrepe standardizacije OMG. Z večanjem izkušenj in zrelostjo aplikacij bomo odkrili in definirali nova skupna sredstva. Prav tako se bodo deli skupnih sredstev preselili v objektne storitve. 3.5. Praktična uporaba ČORBA 2.0 je ugledala luč sveta 15. avgusta 1995 na Object Worid-u v San Franciscu. Takrat je petnajst podjetij predstavilo svoje neodvisne implementacije ČORBA, na katerih je delovala ena distribuirana aplikacija. Ta demonstracija je prikazala zrelost in dostopnost tehnologije. Pričakujemo, da bo do konca tisočletja uporabljalo arhitekturo CORDA prek devet milijonov računalnikov, kar bo predstavljalo nekako 75% trga d is tribu i-ranih objektov |3¡, Pomembnejši dobavitelji posrednikov zahtev objektov, ki so skladni s ČORBA, so I íewlett Packard, DEC, Sun, Iona, Expersoft in Visigenic. Danes uporabljajo posrednike zahtev objektov, ki so skladni s ČORBA, številna podjetja [9]: banke (Bank of Boston, Chemical Ran k, IBM C redi t Corp), zavarovalnice (Travelers), letalstvo (Atlied Signal Aerospace Technology, Space Telescope Science Institute - Hubbhrv teleskí)])), transport (NarfolkSouthern Railroad, Wheels), telekomunikacije (Bell SYCMA Telecom Solutions, British Telecom Labs, Time Warner Communications) in mnogi drugi. V večini primerov se je z novimi aplikacijami povečala produktivnost in stroški so se znižali. Prav tako je tehnologija porazdeljenih objektov omogočila prehod iz velikih računalnikov na omrežje osebnih računalnikov. 4. Nadaljnji razvoj Kljub splošnem sprejemu specifikacije ČORBA delo OMG-ja ni končano. Trenutno poteka razvoj na standardizaciji jezikovnih preslikav za COBOI in Javo, Čeprav lahko jezikovno preslikavo oblikuje vsak, je zelo pomembna standardizacija. Tako model ČORBA že uporabljajo z Objective C, Eiffel, Common I.isp, Scheme in drugimi jeziki, za katere še ne obstajajo standardne preslikave. Mnogo razprav je o podpori novih področij / razširitvijo specifikacije ORB, Vendar je ključni kriterij zmožnost realizirati funkcionalnost kot objektno storitev, ki ORB uporablja, namesto modifikacije samega ORB-ja [13¡. Večina nadaljnjega dela na specifikaciji OMG bo standardizacija storitev, ki delujejo s modelom ČORBA. Tako bo programerju na voljo široka paleta sredstev za izgradnjo aplikacij. V tem pogledu je struktura modela ČORBA podobna strukturi operacijskega sistema z mikrojedrom: ČORBA je jedro, sredstva, ki naredijo distribuirán o objektno okolje uporabno, so zbrana v objektnih storitvah. V razvoju sta specifikacija varnostnih (securih/) storitev ÍK| in storitev trgovanja (trading). uprnulniiANFORMATtKA 1997 Številka 1 letnik V Strokovne raz h have 4.1. Povezava z objektnimi podatkovnimi bazami Upravljanje distribuiranih objektov in objektne podatkovne baze sta trenutno vodilni tehnologiji objektne revolucije. Objektne podatkovne baze so komercialno na voljo že skoraj pet let in so našle uporabo v številnih aplikacijskih domenah. V povezavi z upravljanjem distribuiranih objektov jih lahko uporabimo za implementacijo unificiranih distribuiranih rešitev. Zelo poenostavljeno lahko rečemo, da je objektna podatkovna baza odgovorna za podaljšanje življenjske dobe objekta onstran procesa, ki je objekt oblikoval. Rečemo lahko, da objektna podatkovna baza upravlja z lokalnimi objekti 111. Naslednji stavek najlepše oriše pomensko razliko med posredniki zahtev objektov (OKB) in objektnimi podatkovnimi bazami: posrednik zahtev objektov izroči zahtevo objektu, medtem ko objektna podatkovna baza izroči objekt zahtevi. Posrednik zahtev objektov (ORB) osnovni objektni adapter knjižnični objektni adapter adapter objektne pod. baze -T ODBMS Sliki) 5; ODBMS kot upravitelj objektov znotraj 0M6 arhitekture Obstaja več načinov povezave ORB-jev z objektnimi podatkovnimi bazami. Katero bomo izbrali, je odvisno od zahtevane funkcionalnosti. V najenostavnejšem primeru lahko objektna podatkovna baza nudi trajnost Spletni pregledovalnik Spletni strežnik 1. Pridobivanje strani HTML 4. Izvajanje applet-a 2, Zahteva po npplot-u 3, Pridobivanje applet-a strežnik ORB 5. Klic objektov ORB Slika 6: Integracija WWW i modelom ČORBA in Javo objektom 0RB[11]. Drugi način integracije je definicija objektnega adapter]a za podatkovne baze (slika 5). Tretja možnost integracije je vmesnik 1DL k API-ju objektne podatkovne baze ali h knjižnici razredov. 4.2. Porazdeljeni objekti in Internet Danes sta pojma Internet in Svetovni splet (WWW) zelo popularna. Pomeni Svetovni splet smrt klasičnih arhitektur distribuiranih objektov, kot je ČORBA? Odgovor je vsekakor ne. Pravzaprav je prav integracija spleta / arhitekturo ČORBA idealno priložnost, da prevzame tehnologija distribuiranih objektov vodilno vlogo [2,10], ČORBA je v osnovi strežniško orientirana arhitektura, ki veže stanje objekta in njegovo obnašanje s strežniškim procesom. Odjemalci pošiljajo zahteve objektom, ki so lahko kjerkoli. Odjemalci in strežniki lahko zamenjujejo vloge, kolikokrat želijo. Za določeno zahtevo pa so vloge odjemalca in strežnika strogo definirane. Alternativa strežniško orientirani arhitekturi je takšna, kjer se objekti prosto premikajo med strežnikom in odjemalcem, s ciljem delovati lokalno. Odjema!no orientirani sistemi so uporabni pri aplikacijah, kjer samo beremo, ali je sprememb malo. Prednost je v tem, da lahko povezavo med strežnikom in odjemalcem prekinemo, kar je zelo ugodno za globalno distribucijo. Največja pomanjkljivost pri implementaciji arhitekture ČORBA je, da morajo biti odjemalcu metode objekta znane vnaprej. Z drugimi besedami, ko pridobivamo stanje objekta iz strežnika, mora biti nekaj kode na voljo lokalno, da lahko objekt uporabimo. Ravno tukaj pa vskoči WWW, ki zapolni praznino z Javo, Visual Basi-com in drugimi jeziki, ki omogočajo, da iz strežnika naložimo kodo in podatke in jo izvedemo lokalno (glej sliko (i). Razvijemo lahko splošnega odjemalca z minimalnim Vgrajenim znanjem. Znati mora samo pridobivati oddaljene objekte in jih interpretirati. Istočasno lahko naložene skripte znova pokličejo strežnik, kar daje svobodo mešanja arhitekturnih stilov. Za možnost integracije distribuiranih objektov in svetovnega spleta se zavzema SunSoft, ki želi standardizirati jezikovno preslikavo med OMG IDI. in javo. Proces je v teku, medtem pa so številni dobavitelji izdali razvojne komplete, med drugimi: JavaSoft Joe, PostModern BlackWidow in Iona OrbixWeb. Vsa ta orodja zagotavljajo Integracijo na podobnem principu. Java program (applet), ki se naloži iz spleta, lahko vsebuje odjemalčeve kontrolne odrezke, oblikovane iz IDI.. Na ta način nudi vmesnik odjemalca nazaj objektu, implementiranemu na strežniku ORB. Alternativno se lahko uporabi tudi JavaScript. V vsakem primeru je odjemalčevi strani na voljo podlaga za izvajan je, ki zagotovi povezavo kode Java z objekti, ki so na voljo skozi OR13. To, skupaj z integracijo s splošnimi namiznimi orodji (npr. spletnimi pregledovalniki), napravi Javo idealnega odjemalca ČORBA. 1997 - šlevilka 1 -lelnikV r^jcroJjTidNFOPMATIKA Jg Strokovne raz h have Kombinacija arhitekture ČORBA in spleta torej obljublja veliko prilagodljivost za razvijalce, kakor tuili jasno začrtano pot k množični uporabi distribuiranih objektov. 5. Sklep Tehnologija porazdeljenih objektov naslavlja ključne probleme razvoja programske opreme, kot so ponovna uporaba, prenosljivost in povezljivost programske opreme. Vodilo, v obliki posrednika zahtev (OKB), omogoča objektom življenje kjerkoli v omrežju in zagotavlja komunikacijo med njimi. Odjemalci dostopajo do njih s proženjem metod. Vmesnik in implementacija objekta sta ločeni, odjemalci soodvisni samo od vmesnika. Programski jezik in prevajalnik, uporabljena za oblikovanje porazdeljenih objektov, sta popolnoma transparencia za odjemalce. Odjemalcem ni potrebno vedeti, kje je distribuirán objekt, ali na kakšnem operacijskem sistemu se izvaja. Porazdeljeni objekti so »pametni« koščki programske opreme, ki lahko med seboj komunicirajo, ne glede na lokacijo. Ko govorimo o porazdeljenih objektih, govorimo dejansko o neodvisnih programskih komponentah. Komponenta je torej objekt, ki ni vezan na določen program, programski jezik ali implementacijo. Komponenta je dovolj majhna, da jo lahko oblikujemo in vzdržujemo, dovolj velika, da jo uporabljamo in podpiramo ter ima standardni vmesnik za povezljivost. Objekti, zgrajeni kot komponente, so gradniki distribuiranih aplikacij naslednje generacije. Pomagajo nam zgraditi aplikacije, ki so boljše, hitrejše in uporabnejše od današnjih. Zgrajene so z manj napora in so zanesljivejše. Objekti so del revolucije komponent, ki smo jo že doživeli pri strojni opremi. Predstavljajo programski ekvivalent mikro Čipa in posledično osebnega računalnika 131. Tehnologija komponent, kot nadaljevanje distribuiranih objektov, bo sčasoma izpodrinila vse ostale tehnologije, saj zna vse, kar znajo druge tehnologije, in to bolje. Uporabljene kratice: API Application Programming Interface COM Component Object Model (Microsoft) CORSA Common Object Request Broker Architecture DCE Distributed Computing Environment OCOM Distributed Component Object Model (Microsott) DEC Digital Equipment Corporation DSOM Distributed System Object Model (IBM) ES!0P Environment Specific Inter-ORB Protocol ■ protokol meri OKB-ji, odvisen od okolja G/OP General In ter-ORB Protocol • splošen protokol med ORB-jl HTML Hyper Text Markup Language IBM International Business Machines IDL Interface Definition Language - jezik za definicijo vmesnikov HOP Internet Inter-ORB Protocol - Internet protokol med ORB-jr. ODBMS Object Database Management System - sistem za upravljanje z objektno podatkovno bazo OLE Object Linking and Embedding (Microsoft) OMA Object Management Architecture arhitektura upravljanja z objekti OMG Object Management Group ORB Object Request Broker - posrednik zahtev objektov OSF Open System Foundation RFP Request for Proposai SOM System Object Model (IBM) TCP/IP Transport Control Protocol/internet Protocol WWW World Wide Web ■ svetovni splet Literatura: Object 11| Barry D„ "ODBMSs and Distributed Systems" Magazine. August 1996, str. 28- 30 |2j Chauvet J. M., "ORB Spiders On The Web", Object Expert. Sept/Oct 96, str. 29-31 [31 Guttman M., Matthews J. R., The Object Technology Revolution, John Wiley & Sons, Inc., USA 1995 141 Juric M. 8,. CORBA objektna zasnova porazdeljenega pmeesiranja, FERI Manbor, oktober 1996 |5| OMG, CORBAfacililies: Common Facilities Architecture, Revision 4.0, November 1995 |6| OMG, CORBAsenrfces: Common Object Services Specif ¡ration. Revised Edition March 31, 1995, Updated: March 28, 1996 |7[ OMG, The Common Object Request Grower: Architecture and Specification. Revision 2.0, July 1995 |3j OMG; "CORBA Security", First Ciass, Jun Jul 1996 |9| OMG: "Meeting the Challenge of Vertical Industries", First Class, Aug-Sep 1996 110] OMG: "Surfin' the Net with CORBA", First Ciass. Jan-Feb 1996 ¡11| Reddy M., "ORBs & ODBMSs: Two complementary ways to distribute objects", Object Magazine, jun 1995, str. 24-31 |12J Soley R. M., Ph.D.. Object Management Architecture Guide, OMG. John Wiley & Sons. Inc., Revision 3,0, Third Edition, Jun 15, 1995 ¡131 Watson A., "The OMG After CORBA 2", Ob/ect Magazine, Mar 1996, str, 58-60 [14J Watson A., "The OMG Story", Object Expert. Jan-Feh 1996, str. 51-53 115| Wayner R, "Objects on the March", Byte, Jon 1994, str. 139-150 ♦ Matjaž iS. Jurič je diplomira I leta 1996. Študij nadaljuje po enovitem doktorskem programu na Fakulteti za elektrotehniko, računalništvo in informatiko v Mariboru kot štipendist Slovenske znanstvene fundacije. Njegovo raziskovalno delo obsega področje objektne tehnologije s poudarkom na porazdeljenih objektnih sistemih, kar bo tudi tema njegove doktorske disertacije. Mag. Marjan Heriiko je asistent stažist na Fakulteti za elektrotehniko, računalništvo in in forma t/k o v Mariboru. Naziv magistra je pridobil leta 1993 z uspešnim zagovorom magistrske naloge "Objektno orientirane metode načrtovanja informacijskih sistemov". Njegovo raziskovalno razvojno delo obsega vse vidike objektne tehnologije, s poudarkom na metodologijah razvoja, orodjih CASE, razvojnih okoljih in metrikah. Pripravlja doktorsko disertacijo na temo Kakovost objektno orientiranega razvoja informacijskih sistemov. Aktivno sodeluje pri delu Centra za objektno tehnologijo. Dr. Ivan Rozman je diplomiral na Fakulteti za elektrotehniko v Ljubljani, magistriral in doktoriral pa na Tehniški fakulteti Univerze v Mariboru. Je redni profesor Univerze v Mariboru in ustanovitelj Laboratorija za informacijske sisteme, ki ga vodi ie danes Je avtor več fcof 200 publikacij, vodil je številne znanstveno raziskovalne projekte 36 i if*™f ji url NFORM ATI KA 1997 - Številka i letnik V