Oulun yliopisto
Tietojenkäsittelyopin laitos
Tomi Leppikangas
Arno Tuominen
Ohjelmistotutkimus
02/08/97
Asiakas-palvelin arkkitehtuurilla voidaan hoitaa monia nykypäivän tietojenkäsittelytehtäviä. Nykyiset nopeat tietoverkot edesauttavat luotettavien hajautettujen järjestelmien toteuttamista asiakas-palvelin arkkitehtuurilla. Uudelleenkäytettävyyden saavuttamiseksi ohjelmistosuunnittelussa on otettu käyttöön oliotekniikoita. Oliopohjaisuuden myötä on tullut tarve kehittää oliopohjaisia hajautusmenetelmiä. CORBA määrittelee pohjan, jolla eri valmistajat voivat toteuttaa keskenään yhteensopivia hajautettuja järjestelmiä.
Tutkielman tarkoituksena on selvittää CORBA:n soveltuvuus oliopohjaisten hajautettujen järjestelmien toteuttamiseeen ja miten CORBA-standardi täyttää asiakas-palvelin järjestelmälle asetetut vaatimukset. Tutkimus suoritetaan vertailemalla eri kirjallisuuslähteissä esitettyjä tietoja. Aluksi selvitetään mitä vaatimuksia hajautetuille järjestelmille on asetettu eri kirjallisuuslähteissä, ja lopuksi miten CORBA-standardi täyttää nämä vaatimukset. Tekniseen toteutukseen liittyvät yksityiskohdat ja niiden ongelmat rajataan tutkielman ulkopuolelle. Muut asiakas-palvelin järjestelmien toteutusvaihtoehdot ohitetaan käsittelemättä tarkemmin.
Johtopäätöksenä voidaan todeta CORBA:n täyttävän hyvin hajautetuille järjestelmille asetetut vaatimukset. Nykyisessä standardissa (2.0) on vielä joitakin puutteellisuuksia, mutta lisäominaisuuksia on tulossa seuraaviin versioihin. Tämänhetkinenkin standardi on riittävän kehittynyt otettavaksi käyttöön ohjelmistotuotannossa, lukuunottamatta huipputurvallisia maksujärjestelmiä. Puutteista huolimatta CORBA:a on käytetty menestyksekkäästi ohjelmistoratkaisuissa vuodesta 1992 lähtien. CORBA-standardin kypsyydestä huolimatta sen toteutuksissa on eroja, ja tämän vuoksi yhteensopivuus eri valmistajien CORBA-järjestelmien välillä ei ole taattu.
Tiivistelmä
Sisällysluettelo
1 Johdanto
1.1 Tarkoitus ja tavoitteet
2 Asiakas-palvelin arkkitehtuuri
2.1 Hajautuksen ominaispiirteitä
2.2 Hajautuksen toteutukselle asetettuja vaatimuksia
2.3 Oliopohjainen hajautus
3 CORBA
3.1 Mikä on CORBA?
3.2 Palvelut joita CORBA tarjoaa hajauttamiseen
3.3 CORBA:n rajapinnat
3.4 CORBA:n tulevaisuus
4 Yhteenveto
Lähteet
Asiakas-palvelin arkkitehtuurilla pyritään ratkaisemaan monia nykypäivän tietojenkäsittelyn ongelmia. Näitä ongelmia ovat muunmuassa kasvanut laskentatehon tarve, eri laitteistojen yhteensopivuus, helppo ylläpidettävyys sekä laajennettavuus.
Tämän päivän nopeat tietoverkkoratkaisut mahdollistavat tehokkaiden asiakas-palvelin ympäristöjen rakentamisen. Aikaisemmat hitaat tietoverkot eivät edesauttaneet asiakas-palvelin arkkitehtuurin leviämistä. Nykyiset ATM ja muut nopeat verkot mahdollistavat hajautuksen käyttöönoton monilla uusilla sovellusalueilla.
Oliopohjaisuus on tämän hetken trendi ja se on tullut myöskin uutena komponettina mukaan hajautettuihin järjestelmiin. CORBA-standardi pyrkii määrittelemään kehikon jonka pohjalta eri valmistajat voivat toteuttaa keskenään yhteensopivia hajautettuja järjestelmiä.
Monet nykypäivän tietojärjestelmät pohjautuvat asiakas-palvelin ratkaisuihin, ja oliopohjaisuus on tullut myöskin mukaan. Käytössä on erilaisia hajautettuja järjestelmiä, sekä hyvin että huonosti toteutettuja. Mistä tekijöistä sitten koostuu hyvä asiakas-palvelin järjestelmä, ja mitä lisäominaisuuksia oliotekniikat ovat tuoneet hajautukseen?
Aikaisemmat toteutusratkaisut ovat osoittautuneet vajavaisiksi. Yleistä standardia ei ole ollut ja eri valmistajat ovat kehitelleet omia ratkaisuja hajauttamiseen. Eri ratkaisumallien pohjalta toteutettujen järjestelmien saumaton yhteistoiminta on ollut vaikeaa tai mahdotonta. Epäonnistuneet hajautusratkaisut ovat osaltaan jo ajaneet valmistajia takaisin keskitettyihin järjestelmäratkaisuihin.
Tutkielmassa selvitetään, mitä vaatimuksia hajautetuille järjestelmille on määritetelty, ja miten CORBA-standardissa on nämä vaatimukset otettu huomioon, sekä miten CORBA soveltuu hajautettujen järjestelmien toteuttamiseeen. Aluksi käsitellään lyhyesti asiakas-palvelin arkkitehtuuria, ja esitellään hajautuksen ominaispiirteitä, sekä toteutukselle asetettuja vaatimuksia. CORBA-standardin vaatimuksia ja toteutusta käsitellään tarkemmin kappaleessa kolme. Tutkimus suoritetaan vertailemalla eri kirjallisuuslähteissä esitettyjä tietoja. Samalla pyritään kartoittamaan yleinen kuvaus aihealueesta ja sen problematiikasta.
Pääasiallisina lähteinä ovat Hart & Rosenberg, Client/Server Computing for Technical Professionals, sekä Coulouris & Dollimore & Kindberg, Distributed Systems. Alan lehdistä, muunmuassa Object Magazine, löytyi uutta CORBA-keskeistä tietoa. Tutkielman ulkopuolelle rajataan tekniseen toteutukseen liittyvät yksityiskohdat ja niiden ongelmat. Muut asiakas-palvelin järjestelmien toteutusvaihtoehdot ohitetaan käsittelemättä syvällisemmin.
Kaikki asiakas-palvelin järjestelmät sisältävät asiakas- ja palvelin osan. Forge S. määrittelee kirjassaan Developing Cooperative and Client Server Systems asiakas-palvelin järjestelmän seuraavasti: Asiakas-palvelin järjestelmässä määrätty palvelin tuottaa palveluita joukolle asiakaskoneita vastaamalla niiden verkon yli lähettämiin palvelupyyntöihin. Asiakkaasta ja palvelimesta voidaan käyttää myös muita termejä. Esimerkiksi asiakasta voidaan kutsua nimellä master ja palvelimeen voidaan viitata sanalla slave. Verkonhallinta käyttää termejä managerit ja agentit asiakkaan ja palvelimen sijasta. (Hart & Rosenberg) Kuvassa yksi on esimerkki yksinkertaisesta hajautetusta järjestelmästä. Neljä työasemaa hoitaa hajautetusti tietojenkäsittelytehtäviä, käyttäen yhteistä keskitettyä tiedostopalvelinta ja verkkotulostinta.
Kuva 1. Tyypillinen asiakas-palvelin järjestelmä. (mukaellusti Hart & Rosenberg)Luvussa käsitellään hajautuksen ominaispiirteitä ja sen totetutukselle asetettuja vaatimuksia. Lyhyenä johdatuksena CORBA:n oliopohjaisuuteen kappaleen loppuosa käsittelee oliopohjaista hajautusta.
Useimmat asiakas-palvelin järjestelmät ovat hajautettuja, mikä tarkoittaa että asiakas ja palvelin sijaitsevat eri koneissa, joskaan kaikki asiakas-palvelin järjestelmät eivät ole fyysisesti hajautettuja, eli näissä järjestelmissä asiakas ja palvelin ovat erillisiä prosesseja samassa koneessa. (Hart & Rosenberg) Hajautuksen taso voi vaihdella. Kuvassa kaksi on esitetty eriasteisia hajautusratkaisumalleja. Toisena ääripäänä on hajautettu esitys (remote presentation), jossa tietojenkäsittelyä on keskitetty eniten. Toisena rajana on hajautettu data, jossa kaikki tietojenkäsittely hoidetaan hajautetusti ja ainoastaan data on keskitetyssä tietovarastossa. (Low et al)
Kuva 2. Hajautuksen eri asteita (Low et al) Coulouris et al määrittelee hajautukselle kuusi pääperiaatetta: resurssien jakaminen, avoimuus, rinnakkaisuus, skaalattavuus, vikasietoisuus ja läpinäkyvyys. Avoimuus määrittelee järjestelmän laajennettavuuden. Järjestelmät voivat olla joko avoimia tai suljettuja joko laitteisto- tai ohjelmistopohjalla. Avoimuus saavutetaan määrittelemälla ja dokumentoimalla järjestelmän ohjelmistoliitynnät ja julkaisemalla ne.
Avoimille järjestelmille on tunnusomaista että niiden liitynnät ovat julkisia, eli niiden rajapinnat on dokumentoitu ja julkaistu. Hajautetut avoimet järjestelmät perustuvat yhdenmukaisille prosessien välisille kommunikaatioille, joiden kautta käytetään jaettuja resursseja. Nämä järjestelmät voidaan koota heterogeenisistä laitteistoista ja ohjelmistoista, mahdollisesti eri valmistajilta. Järjestelmän jokaisen komponentin tulee tarkoin noudattaa julkaistuja standardeja.
Resurssien jakaminen on hajautuksen perusominaisuus. Jaettavat objektit voivat olla joko dataa, ohjelmistoja tai laitteistokomponetteja. Resurssien jakoa kaytetään joko suorituskyvyn lisäämiseksi tai vikasietoisuuden parantamiseksi. Resurssien jakaminen mahdollistaa rinnakkaisuuden, mikä lisää suoritustehoa. Koska hajautetut järjestelmät toimivat tehokkaasti eri mittakaavoissa, yleiskäyttöisissä hajautetuissa järjestelmissä voidaan käyttää rinnakkaisuutta asiakas- ja palvelinprosessien välillä. Käyttöjärjestelmä ja sovellusohjelmistot eivät saisi kuitenkaan muuttua, kun järjestelmän koko kasvaa. (Coulouris et al)
Vikasietoisuus jaetaan kahteen pääosaan: laitteiston redundanttisuus ja ohjelmistojen suunnittelu virheistä toipumiseen. Hajautetussa järjestelmässä saavutetaan vikasietoisuus helpommin kuin keskitetyssä järjestelmässä johtuen resurssien jakamisesta useille laitteistoille. (Coulouris et al)
Läpinäkyvyydellä piilotetaan hajautetun järjestelmän eri yksiköt, ja järjestelmä näkyy käyttäjille ja ohjelmoijille yhtenä kokonaisuutena. Kaksi tärkeintä läpinäkyvyyden muotoa ovat saatavuus- ja paikkaläpinäkyvyys. Saatavuusläpinäkyvyys mahdollistaa paikallisten ja ulkopuolisten tietojen käsittelemisen samoilla operaatioilla. Paikkaläpinäkyvyydellä mahdollistetaan tietojen käyttö tietämättä niiden sijaintia. (Coulouris et al)
Hajautukselle asetettuja teknillisiä vaatimuksia ovat: nimeäminen, tiedonvälitys, ohjelmien osittaminen, työtaakan jakaminen ja konsistenssin ylläpitäminen.
Nimeämistavat pitää suunnitella tukemaan skaalattavuutta ja paikasta riippumattomuutta. Nimipalvelu pitää yllä tietoa, jota tarvitaan nimien selvittämiseen, sekä tarjoaa nimenselvityspalvelun asiakkaille. (Coulouris et al) Nimeämis- ja paikantamispalvelut mahdollistavat asiakkaiden ja palvelinten löytävän toisensa helposti verkon yli. Järjestelmän pitää tuottaa nimeämisjärjestelmä, joka mahdollistaa hajautettujen resurssien nimeämisen. (Hart & Rosenberg)
Tiedonvälityksen nopeus ja luotettavuus ovat kriittisiä tekijöitä hajautettujen järjestelmien suorituskyvylle. Hajautetun järjestelmän komponentit ovat sekä fyysisesti että loogisesti erillään, joten niiden täytyy pystyä kommunikoimaan toimiakseen keskenään. (Coulouris et al)
Avoimuuteen päästään ohjelmien osittamisella ja suunnittelemalla ohjelmat käyttämään hyvin määriteltyjä rajapintoja. Datan abstrahointi on hajautettujen järjestelmien tärkeä suunnitteluperiaate. Suunnitteluperiaatteena on toteuttaa järjestelmä siten että uusia palveluita voidaan lisätä muuttamatta tai toistamatta vanhoja palveluja. (Coulouris et al) Skaalattavuudesta aiheutuu kuitenkin ongelmia: toimiiko hajautettu ohjelmisto yhtä hyvin 10000 tietokoneen ympäristössä kuin kymmenen koneen verkossa? (Hart & Rosenberg) Heterogeenisuus vaatii, että järjestelmäarkkitehtuurien erilaisuudet piilotetaan ohjelmilta ja käyttäjiltä. Samalla edellytetään että erityyppiset järjestelmät toimivat yhdessä ja ovat vaihdettavissa keskenään tiettyyn rajaan asti.
Hyvä suorituskyky on vaatimuksena suurimmassa osassa järjestelmiä, ja se on suuri haaste useimmille ohjelmoijille ja systeemisuunnittelijoille. Suunnitteluongelmana hajautetuissa järjestelmissä on tiedon käsittelyn, tiedonvälityksen ja verkossa sijaitsevien palveluiden jakaminen tasaisesti vaihtelevissa kuormitustilanteissa (Coulouris et al). Hajautetun ohjelman tulisi toimia likipitäen yhtä nopeasti kuin hajauttamattoman ohjelman. (Hart & Rosenberg)
Hajautetuissa järjestelmissä luotettavuus on suurempi huolenaihe kuin hajauttamattomissa järjestelmissä. Tietoverkot voivat pettää tai toimia virheellisesti. Mitä tapahtuu asiakasohjelmistolle kun sen tiedostopalvelin kaatuu tai verkko pettää? Mitä tapahtuu jos asiakas lukitsee tiedoston kirjoitusta varten ja sitten kaatuu vapauttamatta lukkoa? Luotettavuuteen sisältyy sekä toiminnan oikeellisuus ja virheettömyys, että saatavuus, tämä takaa asiakas-palvelin järjestelmän toimivuuden. Turvallisuuden merkitys kasvaa hajautetussa järjestelmässa. Aina täytyy pitää mielessä että tieto liikkuu avoimessa verkossa. Tarvittavat palvelut tulisi olla replikoituja siten, etta joka tilanteessa olisi ainakin yksi palvelin lähellä asiakasta. Mikään palvelin ei saisi ylikuormittua, ja toiminnan pitäisi jatkua, vaikka jokin palvelin ei toimisi tai olisi saavuttamattomissa verkkovian takia. (Hart & Rosenberg) Datan replikointi asettaa vaatimuksia datan konsistenssille, konsistenssia tarvitaan myös kun jaettua dataa ja resursseja päivittää useampi toisistaan riippumaton prosessi. Monistettu data pitää olla konsistenssissa myöskin siinä erikoistapauksessa että osa datasta on asiakkaan välimuistissa. Konsistenssin pitää säilyä myöskin vikatilanteissa. (Coulouris et al)
Hajautetun järjestelmän tulisi näyttää yhdeltä järjestelmältä niin pitkälle kuin mahdollista. Käyttäjät ja ylläpitäjät haluavat nähdä järjestelmän yhdenmukaisena entiteettinä, jota on helppo ylläpitää ja jonka resurssit, kuten tiedostojärjestelmä, käyttäytyvät ikäänkuin ne olisivat yhdessä isossa tietokoneessa. Yhdenmukaisuus tarkoittaa myös sitä että ideaalisesti käyttäjä voi kirjoittautua sisään miltä tahansa työasemalta tai päätteeltä ja saada käyttöönsä oma käyttöympäristönsä (Hart & Rosenberg)
Hajautettujen järjestelmien kehittämiseen oliopohjaisilla tekniikoilla on suurta kiinnostusta. Ennen kuin organisaatiot investoivat suuria summia hajautettujen oliopohjaisten järjestelmien kehittämiseen, olio-metodologioiden täytyy vastata hajautuksen näkökohtia. (Low et al)
Olioita voidaan käyttää esittämään hajautuksen yksiköitä, prosessin liikettä ja kommunikointia hajautettussa järjestelmässä. Olio kuvaa hajautuksen yksikköä hyvin, koska se on samankaltainen prosessin esitystapaan nähden: samoin kuin prosessi piilottaa paikalliset muuttujat ja toiminnallisuuden, olio piilottaa tilan ja toiminnallisuuden. Olion liikettä voidaan käyttää esittämään prosessin liikettä hajautetussa järjestelmässä, eli olio siirtyy koneesta toiseen samoin kuin prosessin suoritus hajautetussa järjestelmässä Tätä liikettä voidaan edelleen hyödyntää dynaamiseen uudelleenkonfigurointiin saavuttamaan joko vikasietoisuus tai tasaamaan kuormitusta koneiden välillä. Olioiden viestit ja niiden liittymät esittävät prosessien välistä kommunikointia. (Low et al)
Oliopohjaisuuden vahva puoli on voimakas tuki modulaarisuudelle ja informaation piilottamiselle. Tämä rohkaisee hajauttamaan ohjelmistokomponetteja, joita tarvitaan avoimen järjestelmän kehittämiseen. Komponentit voidaan toteuttaa eri alustoilla ja eri kielillä, mutta ne voidaan integroida yhdeksi heterogeeniseksi järjestelmäksi. Edelleen yhdessä komponentissa tehdyt luokkamuutokset ovat eristetty muista komponenteista, olettaen ettei muutetun luokan liittymään ole tehty muutoksia. Tästä seuraa komponettiautonomia. (Low et al)
Oliot luovat hyvän pohjan järjestelmän osittamiseen komponenteiksi. Olioryhmät voidaan ajatella autonomisiksi yksiköiksi, joita voidaan kutsua myöskin clustereiksi, alijärjestelmiksi tai kategorioiksi. Tämä korkeamman tason abstraktisuus, jolla on oma modulaarisuus, on jo sisällytetty moniin olio-pohjaisiin analyysi- ja suunnittelumetodologioihin. Tämänhetkisissä oliokielissä ei ole kuitenkaan vielä tukea näille metodologioille. Oliopohjaiset suunnittelumetodologiat tukevat saumatonta siirtymää loogisista oliomalleista ohjelmakoodin fyysisiksi oliomalleiksi. Tämä sallii loogisen järjestelmän suunnittelun itsenäisesti ottamatta huomioon toteutusympäristöä. Toteutusympäristön ongelmat voidaan ottaa huomioon myöhemmin, samalla säilyttäen fyysisen järjestelmän ja loogisen suunnittelun yhtenäisyys. (Low et al)
CORBA (Common Object Request Broker Architecture) on määritelmä erilaisille ORB (Object Request Broker) toteutuksille. ORB:t tuottavat infrastruktuurin, jonka avulla olioiden metodeja voidaan käyttää riippumatta siitä, missä ne verkossa sijaitsevat, millä laitteistollla niitä suoritetaan ja millä ohjelmointikielillä ne on toteutettu. (Brando T.)
OMG (Object Management Group), jonka tarkoituksena on edistää oliotekniikoita hajautettujen järjestelmien käyttöön, julkaisi CORBA 1.0 spesifikaation vuonna 1991. Ensimmäiset CORBA-standardin mukaiset ORB:t ilmestyivät 1993 vuoden lopulla. Kahden pienemmän muutoksen jälkeen OMG julkaisi vuonna 1994 CORBA:n 2.0 version. 2.0 versiossa oli korjattu 1.0:n pahin puute: miten eri valmistajien ORB:t toimivat yhdessä. (Brando T.) CORBA:a on käytetty ohjelmistotuotteissa vuodesta 1992 lähtien: Jotkin CORBA-toteutukset ovat menestyneet hyvin, mutta lopputuotteiden laatu vaihtelee silti suuresti. (Roy & Ewald)
OMG:n määritelmän mukaan ORB tuottaa mekanismit, joilla oliot läpinäkyvästi tekevät palvelupyyntöjä ja vastaanottavat tuloksia. ORB mahdollistaa sovellusten keskenään toimivuuden heterogeenisissä hajautetuissa ympäristöissä, ja saumattomasti kytkee yhteen useampia oliojärjestelmiä. CORBA spesifikaatio määrittelee kehyksen erilaisille ORB toteutuksille ja tuottaa yhteiset ORB -palvelut ja -liittymät siirrettäville asiakkaille ja olioiden toteutukselle. Liittymä on kuvaus joukosta operaatioita, joita asiakas voi pyytää oliolta. Olio täyttää liitynnän vaatimukset, jos se voidaan määritellä kohdeobjektiksi jokaisessa potentiaalisessa palvelupyynnössä, jotka liityntä määrittelee. (Object Management Group).
Koska hajautetuissa järjestelmissä tarvitaan tarkka tieto abstrakteista datatyypeistä, on CORBA:ssa oma kieli määrittelemään näitä tyyppejä. Historiallisista syistä näitä tyyppimäärittelykieliä kutsutaan liitynnänmäärittelykieliksi (IDL, Interface Definition Language). IDL ei kerro mitään olioiden todellisesta esityksestä, sen tarkoitus on kuvata olioiden abstraktit tietotyypit ja liitynnät. (Watson A.)
CORBA:n pääperiaatteet:
Sekä asiakkaan että olion toteutus on eristetty ORB:stä OMG:n IDL-liitynnällä. CORBA vaatii että jokaisen olion liityntä on määritelty OMG:n IDL:llä. Asiakkaat näkevät vain olion liitynnän, eivät koskaan toteutuksen yksityiskohtia. Tämä takaa toteutuksen vaihdettavuuden liitynnän takana – todellinen 'plug-and-play'- ohjelmistokomponenttiympäristö
Palvelupyynnöt eivät välity suoraan asiakkaalta oliolle, vaan palvelupyynnöt hoitaa aina ORB (Kuva 3). Jokainen CORBA-kutsu välitetään ORB:lle. Kutsun muoto on sama riippumatta siitä onko kohdeolio paikallinen vai ulkopuolinen. (jos kohdeolio on ulkopuolinen, niin kutsu välittyy asiakkaan ORB:ltä olion toteutuksen ORB:lle). Hajautuksen yksityiskohdat ovat nähtävissä ainoastaan ORB:n sisällä, missä hajautuksen ongelmat on ratkaistu ohjelmointiympäristön toimesta. Sovellusohjelmakoodi, joka näin vapautuu ylläpito-ongelmista, keskittyy käsiteltävään ongelmaan. (Siegel J.)
Kuva 3. CORBA:n kutsujenvälitys. (Siegel J.)CORBA pohjautuu OMA (Object Management Architecture) määritelmälle. OMA:n yksinkertainen päämäärä on: Kun sovellusohjelmat tuottavat perustoimintoja, tehdään ne samantien standardin rajapinnan avulla. Tämä mahdollistaa ohjelmistokomponenttien markkinat rajapinnan ala- ja yläpuolella. (Siegel J.) Palvelut joita CORBA tarjoaa hajauttamiseen ORB tuottaa infrastruktuurin operaatioiden käynnistämiseen läpinäkyvästi. ORB:llä on tieto siitä, missä palvelut sijaitsevat verkossa, ja minkä tyyppisillä laitteisto- ja käyttöjärjestelmäalustoilla palvelut suoritetaan. Lisäksi tiedetään erot datan esitysmuodoissa eri laitteistoalustoilla, ohjelmointikielet, joilla oliot on toteutettu, sekä verkkoyhteydet, joiden avulla kommunikointi toteutetaan. CORBA määrittelee palvelut, jotka ORB:n täytyy toteuttaa, ja standardit rajapinnat näille palveluille. (Siegel J.)
CORBA:n tarjoamat lisäpalvelut jaetaan kahteen ryhmään, horisontaalisiin ja vertikaalisiin. Horisontaaliset CORBA:n lisäpalvelut sisältävät palveluita, joita tarvitaan lähes kaikilla markkina-alueilla. Näitä palveluita ovat esimerkiksi: käyttöliittymä, tiedonhallinta, järjestelmänhallinta ja prosessinhallinta. Vertikaaliset CORBA lisäpalvelut jaotellaan markkina-alueittain, esimerkiksi terveydenhoidon ja taloushallinon palveluihin. (Siegel J.) Kuvassa neljä on esitetty CORBA:n tarjoamia palveluita ja lisäpalveluita. Jokaisen CORBA-standardin mukaisen ORB-järjestelman ei tarvitse toteuttaa kaikkia määriteltyjä palveluita, vaan toteutetaan ainoastaan ne palvelut, joita kulloinkin sovellusohjelma tarvitsee.
Kuva 4. CORBA:n tarjoamia palveluita (Siegel J.)CORBA:n palvelujen tehokkuus riippuu toteutuksesta, ja siten tehokkuuden arvioiminen on vaikeaa. Täsmälliseen vertailuun tarvittaisiin tietyt versiot tietystä tuotteesta. (Roy & Ewald)
Liittymärajapintojen määritelmä määrittelee ne operaatiot, jotka olio suorittaa, syöttö- ja tulostusparametrit ja poikkeukset (exeptions), joita voi tapahtua. Tämä liityntä muodostaa sopimuksen asiakkaan ja olion välille, jotka käyttävät samaa rajapintaa. Asiakas käyttää tätä rajapintaa kutsujen lähettämiseen ja olio käyttää sitä kutsujen vastaanottamiseen sekä niihin vastaamiseen. Tämä pakottaa käyttämään paketointia ja mahdollistaa asiakkaiden käyttää olioita riippumatta ohjelmointikielestä, käyttöjärjestelmästä, laitteistosta, tiedon esityksestä, sijainnista verkossa tai käytetystä protokollasta. (Siegel J.)
Vaikkakin CORBA:n rajapinnat on kuvattu tarkoin, on mahdollista että eri valmistajien CORBA-toteutukset eivät ole täysin yhteensopivia. Yhteensopivuuden varmistamiseksi on tällähetkellä valittava tietty CORBA-toimittaja, tai sellaiset CORBA-toteutukset, jotka tiedetään yhteensopiviksi. (Roy & Ewald)
Ovum Ltd ennustaa raportissaan, että vuosikymmenen lopussa yli yhdeksän miljoonaa tietokonejärjestelmää tulee käyttämään hajautuksen pohjana CORBA-arkkitehtuuria. Tämä on 75% koko hajautettujen oliojärjestelmien markkinoista. CORBA spesifikaatiota laajennetaan uusille ohjelmistoalueille eli lisätään vertikaalisia palveluita. Suurin osa tulevaisuudessa tehtävästä työstä OMG määrittelyssä tulee olemaan CORBAn palvelujen standardointi. (OMG After CORBA 2)
CORBA ei vielä ole täydellinen asiakas-palvelin ympäristö, vaan siitä puuttuu turvallisuus- ja aikapalvelut jotka OMG on määritellyt Common Object Services Specification -määrittelyssä. Turvallisuuspalvelut tukevat olioiden tunnistamista ja käyttöoikeuskontrollia, ja aikapalvelut tukevat ajan tahdistamista. (Hart & Rosenberg) Näiden palveluiden toteuttaminen on tekeillä. (Brando T.) CORBA:n turvallisuusmäärittelyjä pohtii kansainvälinen joukko tietoturva-asiantuntijoita ja järjestelmäsuunnittelijoita. Turvallisuuspalveluiden suunnitelussa on kiinnitetty erityistä huomiota laajennettavuuteen ja ylläpidettävyyteen. (Drahota T.)
Nykyään CORBA:n IDL liityntä on saatavilla C, C++, Smalltalk ja Ada kielille, toteutukset Javalle ja Cobolille ovat tulossa. (Siegel J.)
Yleisesti CORBA täyttää hyvin hajautetuille järjestelmille asetetut vaatimukset. Tämänhetkisessä standardissa (2.0) on vielä joitakin puutteita, mutta niiden korjaaminen on työn alla.
Laajennettavuus on CORBA-standardin perusominaisuus. Hyvä standardointi ja oliopohjaisuus takaavat laajennettavuuden. Oliopohjaisuuden tuoma tiedon kätkentä ja ORB:n tuoma 'olioiden kätkentä' toteuttavat aidon yhdenjärjestelmän näkymän. Eri valmistajien järjestelmien heterogeenisuus on saavutettu CORBA 2.0 -standardissa.
CORBA tarjoaa monia palveluita luotettavan hajautetun järjestelmän rakentamiseeen. Versiossa 2.0 tulleet nimeämis- ja paikantamispalvelut, sekä replikointi mahdollistavat tehokkaan hajautuksen ja lisäävät täten luotettavuutta. Tietoturvaominaisuudet ovat vielä puutteellisia, mutta ovat valmisteilla. Standardi tukee ajan tahdistamista, turvallinen aikapalvelu on tulossa.
Kirjallisuudessa ei ole esitetty tarkkoja arvioita suorituskyvystä, koska sen mittaaminen on vaikeaa johtuen erilaisista toteutuksista. Myöskään CORBA:n suosiosta ei vielä ole tarkkoja tilastotietoja, mutta sen suosiosta on esitetty joitain suuntaviivoja. Tämän vuoksi tutkielmassa esitettyyn arvioon (75% markkinaosuus) tulee suhtautua varauksella. Muilta osin esitetyt tulokset ovat yleistettävissä.
Tutkimusta voisi jatkaa CORBA-järjestelmän tehokkuuden analysoinnilla ja eri toimittajien järjestelmien yhteensopivuuden testauksella. CORBA-järjestelmien tehokkuutta voisi verrata muihin oliopohjaisiin ja perinteisiin hajautusratkaisuihin. CORBA 2.0 -standardin tuoma järjestelmien heterogeenisuus tulisi testata tarkoin, jotta selviäisi onko standardista todellista hyötyä monimutkaisissa, usean eri ORB-toimittajan ympäristössä.
Brando, T., Comparing CORBA & DCE, Object Magazine, March 1996
Coulouris, G.Dollimore, J. Kindberg, T., Distributed Systems, Consepts and design 2nd edition, Addison-Wesley 1995
Drahota, T., 1996. The CORBA Security Specification. First Class, The Magazine For Object Technology Professionals. Vol. 6, no. 32., 7-8.
Forge, S., Developing Cooperative and Client Server Systems: A Manager's Guide. St Ives plc: McGraw-Hill Book Company Europe, 1995
Hart, J., Rosenberg, B., Client/Server Computing for Technical Professionals, Consepts and Solutions, Addison-Wesley 1995
Low, G. C., Rasmussen, G., Henderson-Sellers, B., Incorporation of distributed computing concerns into object-oriented methodologies, Journal Of Object Oriented Programming, June 1996
Object Management Group, The Common Object Request Broker: Architecture and Specification,
Roy, M., Ewald, A., Choosing Between CORBA and DCOM, Object Magazine, October 1996
Siegel, J., CORBA Getting To The Fundamentals, Object Magazine, October 1996
Watson, A., The OMG After CORBA 2, Object Magazine, March 1996
Watson, A., Types & Distributed Objects: Interface Definition Languages, Object Expert, November-December 1996