CORBA

Common Object Request Broker Architecture

Timo Sillanpää, 40410u

Johdanto

CORBA on edelleen kehittyvä teollisuusstandardi hajautettujen ohjelmistojen yhteenliittämiseksi. Standardia koordinoi 1989 perustettu Object Management Group (OMG), jolla on yli 700 jäsenyritystä. Vuonna 1991 esitelty CORBA 1.1 määritteli rajapintojen kuvauskielen ja ohjelmointirajapinnan, joita käyttäen client- ja server-ohjelmat voivat kommunikoida keskenään tietyn CORBA-toteutuksen sisällä. Vuonna 1994 hyväksytty CORBA 2.0 laajensi määrittelyn koskemaan myös kommunikaatiota eri valmistajien CORBA-toteutusten välillä. [1]

Standardin mukaiset ohjelmat tai ohjelmakomponentit voivat kommunikoida keskenään, vaikka ne olisi kirjoitettu eri ohjelmointikielilillä tai toimisivat eri laitteisto- ja käyttöjärjestelmäarkkitehtuureissa. CORBA tarjoaa palvelut komponenttien rekisteröintiin, paikantamiseen, aktivointiin, virheidenkäsittelyyn ja parametrien välitykseen [2]. CORBA hoitaa tiedon formaatin muunnoksen arkkitehtuurien välillä. CORBA ei ole ohjelmointimenetelmä vaan "liima" eri ohjelmointikielillä ja laitteilla tehtyjen komponenttien välillä [3]. CORBA muistuttaa DCE RPC:tä, mutta on oliosuuntautunut.

Toimintakuvaus [4]

CORBA perustuu asiakas-palvelin -arkkitehtuuriin, jossa palvelinoliot tarjoavat palveluita asiakasolioille. Oliot voivat olla kokonaisia ohjelmia tai ohjelmakomponentteja. Olio voi olla samaan aikaan sekä palvelin että asiakas.

Asiakaskomponentti voi kutsua palvelua joko OMG IDL "stubin" avulla tai muodostomalla palvelupyynnön dynaamisesti DII:n (Dynamic Invocation interface) palveluilla.

OMG IDL (Interface Definition Language) on kommunikaatiorajapintojen kuvaamiseen tarkoitettu hiukan C:tä tai C++:aa muistuttava kieli. Se ei kuitenkaan sisällä mitään kontrollirakenteita vaan ainoastaan rajapinnan funktioiden ja tietotyyppien esittelyn. IDL-määrittely käännetään IDL-kääntäjällä, joka tuottaa siitä "stubit" asiakasta varten ja rungon (skeleton) palvelinta varten. Stub on funktio, joka hoitaa kaikki "rumat asiat" asiakkaan ja CORBA:n ytimen eli ORB:n välissä. Asiakaskomponentti kutsuu stubia kuten muitakin paikallisia funktioitaan, ja stub kutsuu palvelua ORB-rajapinnan yli.

DII on ORB:n rajapinta, jonkan avulla asiakas voi kutsua palvelua, vaikka asiakkaan toteutusvaiheessa ei tiedettäisi palvelun funktioita ja parametrejä. Asiakas voi DII:n avulla hakea palveluita yllämainitusta "rajapintavarastosta" nimen tai tyypin perusteella. Kyselyn perusteella muodostetaan dynaamisesti palvelupyyntö, joka välitetään DII:n funktioilla palvelimelle.

Palvelinkomponentti toteuttaa rajapintaansa vastaavat funktiot ja ORB kutsuu niitä rungon (skeleton) kautta. Palvelin ei näe kummalla menetelmällä (stub vai DII) asiakas on sitä kutsunut.

Rakenne [5,6]

CORBA:n rakennetta hahmottavat hyvin kuvat 2 ja 3 OMG:n "CORBA Overview":ssä [4].

Object Request Broker (ORB)

CORBA:n ydin on Object Request Broker, joka tarjoaa asiakaskomponentille läpinäkyvän menetelmän muualla sijaitsevien palveluiden kutsumiseen. ORB helpottaa hajautettujen sovellusten ohjelmointia kätkemällä tietoliikenteeseen liittyvät rutiinitoimet, niin että palvelun kutsu näyttää asiakkaalle paikalliselta funktio- tai metodikutsulta.

Kutsun aikana ORB ensin etsii palvelun toteutuksen, muuntaa ja siirtää parametrit, aktivoi tarvittaessa toteutuksen ja siirtää kontrollin palveluobjektille. Palvelun suorituksen jälkeen ORB palauttaa mahdolliset tulokset asiakkaalle.

ORB kätkee seuraavat asiat:

Palveluobjektin sijainnin: Asiakkaan ei tarvitse tietää, missä palveluobjekti sijaitsee. Se voi sijaita eri koneessa verkon takana, saman koneen toisessa prosessissa tai samassa prosessissa. Asiakas antaa ORB:lle vain haluamansa palvelun nimen tai ominaisuudet.

Palveluobjektin toteutuksen: Asiakas ei tiedä kuinka ja millä ohjelmointikielellä palvelu on toteutettu tai missä käyttöjärjestelmässä ja laitteistossa se toimii.

Palveluobjektin tilan: Kun asiakas kutsuu palvelua, se ei tiedä onko palvelu parhaillaan aktiivisena prosessina valmiina hyväksymään pyyntöjä asiakkailta. ORB käynnistää ja aktivoi palvelun tarvittaessa.

Kommunikaatiomenetelmän: Asiakas ei tiedä millä protokollalla (paikallinen funktiokutsu, jaettu muisti, TCP/IP jne.) ORB kutsuu palvelua.

ORB:n ydin tarjoaa objektien perusesityksen ja pyyntöjen välityksen. Ytimen päällä sijaitsee osa, jonka tarjoamat rajapinnat kätkevät ORB:n ydinten toteutusten eroavaisuudet.

ORB:n rajapinnat voidaan jakaa kolmeen ryhmään:

  1. Kaikille ORB-toteutuksille yhteiset rajapinnat, kuten ORB Interface, DII ja DSI (selitetään jäljempänä)
  2. Tietyn tyyppisille objekteille yhteiset rajapinnat (Object Adapters)
  3. Tietyn objektin omat rajapinnat (SII eli IDL stub- ja IDL skeleton -rajapinnat)

Samassa ympäristössä voi olla useita erilaisia ORB-toteutuksia, mutta asiakaskomponentti ei tiedä sitä. Kun asiakas viittaa johonkin palveluobjektiin, ORB-toteutusten tulee selvittää keskenään kenen objektista on kyse.

ORB Interface

ORB-rajapinta on kaikille ORB-toteutuksille sama ja sen palvelut liittyvät suoraan ORB-ytimeen. Rajapinnan palvelut eivät riipu palveluobjektista tai objektisovittimesta (object adapter).

Static Invokation Interface (SII)

OMG IDL-kääntäjä tuottaa IDL-kuvauksesta asiakaspäähän "stubin" ja palvelupäähän "skeletonin". Stub on funktio, joka kutsuu palveluobjektia asiakkaan puolesta ORB:n avulla. Skeleton on funktio, joka toimittaa kutsun ORB:lta palvelun toteuttavalle objektille. Kutsua stubin ja skeletonin avulla sanotaan staattiseksi kutsuksi ja niiden muodostamaa "rajapintaa" yhdessä Static Invokation Interface:ksi.

Stub-funktio näyttää asiakkaalle mahdollisimman paljon samalta kuin IDL-kuvauksen palvelufunktio. Stub muuntaa parametrit asiakkaan ohjelmointikielen esitysmuodosta verkon yli siirtoon sopiviksi (marshalling). Palvelinpäässä skeleton muuntaa parametrit siirrettävästä muodosta palvelinobjektin ymmärtämään muotoon (unmarshalling) ja kutsuu palvelun toteutusfunktiota. Lopulta toteutusfunktio palauttaa tulokset. Skeleton muuntaa ne verkkosiirtoon sopiviksi ja palauttaa ne ORB:n välityksellä. Asiakaspäässä stub palauttaa tulokset asiakkaalle.

Dynamic Invokation Interface (DII)

DII on SII:lle vaihtoehtoinen rajapinta. DII on palveluobjektin omasta rajapinnasta riippumaton, ja sen avulla asiakas voi kutsua objektin palveluita, vaikkei niitä olisi tiedetty asiakkaan käännösvaiheessa. Asiakas kertoo DII:lle kutsuttavan palveluobjektin, funktion sekä parametrit ja niiden tyypit. Tavallisesti nämä tiedot saadaan CORBA:n Interface Repository:sta.

Kutsu voidaan toteuttaa kolmella tavalla:

Synkroninen: asiakas kutsuu palvelua ja jää odottamaan vastausta. Tämä on tavallisin tapa, koska tätä käytetään myös SII:n IDL "stub":eissa.

Viivästetty synkroninen: asiakas kutsuu palvelua, palaa heti ja noutaa tulokset myöhemmin. Tämä on kätevä tapa, jos asiakas haluaa kutsua useita riippumattomia palveluita, joiden suoritus kestää jonkin verran.

Yksisuuntainen: asiakas lähettää vain pyynnön, mutta ei odota vastausta. Tämä onnistuu myös SII:llä.

DII on joustavampi kuin staattinen SII-kutsurajapinta, koska DII sallii useita kutsutapoja eikä palvelua tarvitse tuntea käännösvaiheessa. Toisaalta DII on myös monimutkaisempi ja hitaampi.

Dynamic Skeleton Interface (DSI)

DSI on palvelinpään vastine DII:lle. DSI mahdollistaa palvelun kirjoittamisen, vaikka sen toteuttaman objektin tyyppi ei olisi tiedossa käännösaikana. DSI:n funktioilla kerrotaan ORB:lle palvelun toteuttama funktio ja sen parametrit.

Asiakas voi kutsua DSI:llä toteutettua palvelua sekä staattisesti SII:llä että dynaamisesti DII:llä. Palveluobjekti ei tiedä kumpaa tapaa asiakas käyttää.

Object Adapter (OA)

ORB ei voi etukäteen tuntea kaikkia mahdollisia objektityyppejä ja niiden rajapintoja. Silti sen on voitava aktivoida palveluobjekti, löydettävä oikeat objekti-instanssit, osattava kutsua objektin metodeja jne. Vastaavasti objekti odottaa ORB:lta tiettyjä palveluita. OA tekee tämän mahdolliseksi toimimalla ORB:n ja objektin välissä. Jos ORB-ydin toteuttaa objektin kaipaaman palvelun, OA yksinkertaisesti kutsuu ORB-ydintä. Muussa tapauksessa OA:n täytyy toteuttaa objektin kaipaama palvelu.

CORBA määrittelee joukon perusadaptereita, jotka kattavat useimmat tarpeet. Tavallisimmat adapterityypit ovat Basic Object Adapter sekä Library Object Adapter. Ensimmäinen soveltuu useisiin tarkoituksiin, jälkimmäinen on tarkoitettu paikallisten työkalukirjastojen toteutukseen.

Muut osat

CORBA:n rakenteeseen kuuluvat myös Interface Repository ("rajapintavarasto") sekä Implementation Repository ("toteutusvarasto"). Ensimmäiseen on talletettu palvelujen rajapintakuvaukset, jälkimmäiseen tietoa palvelukomponenteista.

Koska CORBA:n toiminnan on tarkoitus olla toteutuksesta riippumaton, tarvitaan yhteinen protokolla, jolla eri toteutukset voivat kommunikoida. Tämä protokolla on GIOP (General Inter-ORB Protocol). Kerros nimeltä IIOP (Internet Inter-Orb Protocol) toimii yhdistäjänä GIOP:n ja TCP/IP:n välillä. TCP/IP:n lisäksi myös IPX ja SNA ovat mahdollisia.

CORBA ja Java [3]

Kun puhutaan CORBA:sta, on syytä puhua myös Javasta. CORBA oli jäämässä alakynteen taistelussa Microsoftin OLE/ActiveX:n kanssa. Java nähdään pelastuksena CORBA:lle ja vastaavasti CORBA hyvänä tukena Javalle. Javalla ja CORBA:lla on paljon yhteistä: molemmat tukevat luokkien toteutuksesta erillisten rajapintojen (interface) käsitettä, CORBA:n IDL-tietotyypit vastaavat varsin hyvin Javan tietotyyppejä, rajapintojen perintämekanismit ovat varsin samankaltaiset jne.

Javassa on monia hyvä puolia, sen siirrettävyys on hyvä ja se on saavuttanut suuren suosion. Siinä on silti puutteita ja yksi niistä on se, että Java itsessään ei täysin tue client-/server-käsitettä. Javalla voi tehdä sekä client- että server-ohjelmia, mutta tuki niiden väliseen kommunikointiin on hiukan puutteellista.

JDK 1.1:n mukana julkaistiin Javan oma sisäänrakennettu ORB nimeltä RMI (Remote Method Invocation). RMI vastaa CORBA:n ORB-käsitettä, mutta on vain kielen laajennus ts. se ei toimi muilla kielillä tehtyjen objektien kanssa. Java poistaa siis laiteympäristöjen väliset rajat, mutta sitoo vuorostaan tiettyyn ohjelmointikieleen. Hätäapu tähän on Java Native Interface (JNI), joka mahdollistaa muilla kielillä tehtyjen komponenttien kutsumisen Javasta ja päinvastoin. Se on tarkoitettu pääasiassa C:llä ja C++:lla tehtyjen komponenttien käyttöön Javan kanssa ja se sitoo ohjelman tiettyyn laitteistoarkkitehtuuriin.

CORBA ratkaisee molemmat ongelmat: palvelurajapinnan IDL-kuvauksesta voidaan tuottaa IDL-kääntäjällä esim. asiakaspään stub Javalle ja palvelinpään skeleton C++:lle. Tässä tapauksessa yhdistävä tekijä on IDL, joka on vain rajapintojen kuvauskieli ja on siten sovitettavissa helposti eri laiteympäristöille. Vaikka Java:sta on tullut hyvin suosittu, yrityksillä on vielä paljon muilla kielillä kirjoitettuja komponentteja, joita ei ole järkevää kirjoittaa uudestaan. Myös suorituskykyä vaativissa tehtävissä saatetaan tarvita muita kieliä.

CORBA ja ActiveX [7]

CORBA:sta puhuttaessa on syytä mainita myös sen kilpailija, Microsoftin ActiveX. ActiveX-tekniikkaa sanotaan joskus myös OLE:ksi (Object Linking and Embedding) tai COM:ksi (Component Object Model tai Common Object Model). Tekniikan nimeämiskäytäntö on varsin sekava eikä Microsoft itsekään tunnu aina olevan selvillä siitä. OLE-nimitys otettiin käyttöön Windowsin leikepöytätekniikasta puhuttaessa ja laajennettiin myöhemmin OLE2:ksi, joka käsittää yleisemmän kommunikaatiostandardin ohjelmien välillä. Siihen kuuluu myös drag and drop ohjelmien välillä. Kun OLE:sta tuli OLE2, sen kommunikaatiomalli nimettiin COM:ksi. COM toimii vain koneen sisällä. Windows NT 4.0:n mukana Microsoft esitteli Distributed COM:n (DCOM), joka toimii myös verkossa olevien koneiden välillä. DCOM on saatavissa myös Windows 95:lle. Kun Microsoft alkoi panostaa internetiin, tekniikoille annettiin yhteinen nimi ActiveX.

ActiveX:n heikkoutena voidaan pitää sitoutuneisuutta Windowsiin sekä monimutkaista API:a. Monimutkaisuus johtuu pääasiassa siitä, että tekniikan käyttötarkoitus oli alunperin varsin erilainen kuin nykyään. CORBA-toteutuksia taas on moitittu epäyhteensopivuudesta [8].

Puolueettomuuden varmistamiseksi on CORBA:n ja ActiveX:n vertailuja lukiessa on syytä tarkastella mahdollisimman monen tahon kirjoituksia. Tämä kappale perustuu pääasiassa OMG:n sivuilta löytyvään dokumenttiin, jota oma 6 kuukauden kokemukseni ActiveX-ohjelmoinnista tukee.

Tulevaisuus

DCOM tekniikka on hallitseva Windows-maailmassa, johtuen mm. siitä, että se tulee Windows NT 4.0:n mukana, kun taas CORBA pitää hankkia erikseen. CORBA:n takana on monia suuria yrityksiä, joukossa mm. IBM, Sun ja Oracle. Pääasiassa siis samoja yrityksiä, jotka ovat yhdistäneet voimansa Microsoftia ja Inteliä vastaan Javaa ja NetPC:tä rummuttamalla. CORBA:n tulevaisuus riippuu paljon Javan kohtalosta.

Viitteet

[1] Object Management Group: What IS CORBA???? *****
< http://www.omg.org/about/wicorba.htm >

[2] Douglas C. Schmidt: Overview of CORBA - 20.7.1997 ****
< http://www.cs.wustl.edu/~schmidt/corba-overview.html >

[3] David Curtis: OMG: Java, RMI and CORBA; Programming or Integration? - 1997 ***
< http://www.omg.org/news/wpjava.htm >

[4] Object Management Group: CORBA Overview - 1995 ***
< http://www.infosys.tuwien.ac.at/Research/Corba/OMG/arch2.htm >

[5] Object Management Group: CORBA 2.0 Specification - 1995 *****
< http://hobbes.informatik.rwth-aachen.de/docs/OMG/ptc/corba2.new/cover.htm >

[6] Alan L. Pope: ? - 1997 ***
< http://www.qds.com/people/apope/ap_TheObject.html >

[7] Object Management Group: Comparing ActiveX and CORBA/IIOP **
< http://www.omg.org/news/activex.htm >

[8] Object Management Group: CORBA Doesn't Work OMG - [no date] *
< http://www.omg.org/news/pr97/ovumpr.htm >

Lisätietoja aiheesta

[9] Object Management Group:n kotisivu *****
< http://www.omg.org/ >

[10] <monia kirjoittajia>: DCOM and CORBA Side by Side, Step by Step, and Layer by Layer - 3.9.1997 *****
< http://www.research.att.com/~ymwang/papers/HTML/DCOMnCORBA/S.html >

[11] Thomas J. Brando: Comparing DCE and CORBA- maaliskuu 1995 ***
< http://www.mitre.org/research/domis/reports/DCEvCORBA.html >

[12] ?: Java CORBA Integration Strategies ****
< http://nittany.ca.sandia.gov:8001/java.corba.html >

[13] Object Management Group: CORBA/IIOP 2.1 Specification - elokuu 1997 ****
< http://www.omg.org/corba/corbiiop.htm >

[14] Douglas C. Schmidt (?) - 20.7.1997 ***
< http://www.cs.wustl.edu/~schmidt/corba.html >

[15] Anders Arnholm: RPCguide **
< http://www.ts.umu.se/~balp/rpcunix/ >

[16] DCE InfoCenter **
< http://www.digital.com/dce/ >

[17] Tom Welsh, ComputerWire - 1997 *
< http://www.omg.org/news/welsh.htm >