Ohjelmistokehitys COM-komponenttien avulla

hyväksyjä: arvosana: päivämäärä: Ohjelmistokehitys COM-komponenttien avulla Isto Nikula Helsinki 05.12.2000 Ohjemistotuotantovälineet, seminaarialustus HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Ohjelmistokehitys COM-komponenttien avulla Isto Nikula Ohjelmistotuotantovälineet, seminaarialustus Tietojenkäsittelytieteen laitos Helsingin yliopisto 05.12.2000, 10 sivua Tässä seminaarialustuksessa käsitellään Microsoftin Component Object Model:ia (COM). Alustus keskittyy mallin perusteiden ja arkkitehtuurin esittelyyn yleisellä tasolla. Lisäksi esitetään COM:in ratkaisut yleisiin ongelmiin, jotka komponenttipohjaisen arkkitehtuurin tulisi ratkaista. Lopuksi tarkastellaan lyhyesti COM:in kanssa kilpailevia teknologioita. Seminaariesityksessä käsitellään edellisten lisäksi käytännön esimerkkejä COM:in käytöstä Windows-alustalla. Avainsanat: ohjelmistotuotanto, komponenttipohjaiset arkkitehtuurit, binääristandardi II

SISÄLTÖ 1 JOHDANTO...1 2 YLEISKATSAUS...1 2.1 Binääristandardi...1 2.2 Rajapinnat...2 2.3 Tunniste...3 2.4 Lyhyesti arkkitehtuurista...3 3 ONGELMAKENTTÄ...5 4 KÄYTETTÄVYYS...6 4.1 Alustat...6 4.2 Kehitysympäristö...7 4.3 Vaihtoehtoiset ratkaisut...7 5 YHTEENVETO...8 LÄHTEET...9 III

1 JOHDANTO Component Object Model (COM [Com95]) on Microsoftin määrittelemä ja toteuttama ohjelmistoarkkitehtuuri, joka helpottaa komponenttien yhteiskäyttöä. COM:in avulla eri valmistajien tekemät komponentit voidaan yhdistää toimivaksi kokonaisuudeksi. Distributed Component Object Model (DCOM [BrK98]) on COM:in laajennos, jota käyttämällä ei tarvitse rajoittua samalla koneella oleviin komponentteihin, vaan yhteiskäyttöiset komponentit voivat sijaita myös verkossa. COM kuuluu ns. keskikerrosohjelmistoihin (engl. middleware). Näiden tarkoitus on peittää ohjelmoijilta alla olevan alustan erikoisuudet ja antaa yhtenäinen rajapinta sovellusten toteuttamiseen [Mil99]. 2 YLEISKATSAUS Microsoft kehitti kehyksen dokumenttien yhdistämiseen ja hallintaan toimistosovelluspakettiaan (Microsoft Office suite) varten vuonna 1991. Myöhemmin tajuttiin, että tämä kehys, OLE versio 1, oli vain erikoistapaus komponenttien yhteiskäytöstä [Bro96]. Vuonna 1996 julkaistu OLE:n versio 2 sisälsi suuria muutoksia edeltäjäänsä nähden. Se käytti alustanaan komponenttien yhteiskäyttöä helpottavaa mekanismia, COM:ia. COM:in aikaiset versiot eivät juurikaan tukeneet komponenttien hajautusta ja tätä varten arkkitehtuuria laajennettiin vuonna 1996 hajautettujen komponenttien tuella (DCOM). COM- ja DCOM-teknologioita on järkevää käsitellä yhtenä teknologiana [MoL97], joka tarjoaa palvelut komponenttien väliseen yhteiskäyttöön. Kun jatkossa viitataan COM-teknologiaan, tarkoitetaan tällä sekä COM- että DCOM-teknologioita. 2.1 Binääristandardi COM määrittää ohjelmointirajapinnan (API), jota noudattamalla eri ohjelmointikielillä toteutetut komponentit voivat toimia yhdessä. Jotta yhteistoiminta olisi mahdollista, on komponenttien käytettävä Microsoftin määrittämää 1

binäärirakennetta. Komponenttien funktioita tulee kutsua muistissa sijaitsevien virtuaalitaulujen kautta ja tästä johtuen käytettävän ohjelmointikielen on tuettava funktiokutsuja osoittimien kautta [WiK94]. Morrisin ja Litvakin [MoL97] mukaan riittää, että kääntäjä osaa muuttaa kielen rakenteet binäärirakennetta vastaavaksi. Toinen binääristandardin vaatimus on, että kaikkien komponenttien on toteutettava IUnknown-rajapinta [WiK94]. IUnknown sisältää metodien QueryInterface, AddRef ja Release esittelyt. QueryInterface-metodia käyttäen asiakkaan tulee voida tarkastaa tukeeko komponentti jotain tiettyä rajapintaa ja saada osoitin kyseiseen rajapintaan. Muut rajapinnan metodit liittyvät komponentin elinkaaren hallintaan. 2.2 Rajapinnat Komponenttia käytetään aina jonkun sen toteuttaman rajapinnan metodin kautta (kuvio 1). Rajapinnat noudattavat binääristandardissa kuvattuja periaatteita (ks. 2.1). Kutsujalla on siis osoitin johonkin komponentin toteuttamaan rajapintaan ja se käyttää tätä osoitinta kutsuessaan rajapinnan määrittämiä palveluja. Esimerkiksi kaikki OLEpalvelut ovat COM-rajapintoja. Williams ja Kindel [WiK94](käännös kirjoittajan) määrittelevät COM-rajapinnan seuraavasti: COM-rajapinta on vahvasti tyypitetty sopimus ohjelmistokomponenttien välillä, joka sisältää pienen mutta hyödyllisen kokoelman semanttisesti samankaltaisia operaatioita. Vahva tyypitys viittaa määritelmässä siihen, että jokaisella rajapinnalla on yksilöllinen tunniste (ks. 2.3). Lisäksi huomattavaa on, että rajapinta ei ole luokka eikä komponentti. COM-komponentti voi toteuttaa useita rajapintoja (kuvio2). Tämä piirre on olennainen sen takia, että rajapinnat ovat loogisesti muuttumattomia. Loogisuus tarkoittaa tässä sitä, että teknisesti rajapinnan muuttaminen ei ole mahdotonta, mutta komponenttien kehittäjien tulisi noudattaa rajapinnan muuttumattomuuden periaatetta [WiK94]. Muutokset johonkin olemassa olevaan rajapintaan tulisi toteuttaa uutena 2

rajapintana (tai uusina rajapintoina). Näin säilytetään yhteensopivuus vanhaa rajapintaa käyttävien komponenttien kanssa eli ratkaistaan versionhallintaan liittyvät ongelmat. Osoitin rajapintaan komponentti Kuvio 1: Asiakas käyttää COM-komponenttia rajapintaosoittimen kautta [Com95]. IClock ITimer IAlarm Asiakassovellus Kellokomponentti Kuvio 2: Kello-komponentti. IClock-rajapinta tarjoaa metodit ajan asettamiseen ja lukemiseen, IAlarm ja ITimer tarjoavat herätys- ja ajanottopalvelut [MoL97]. 2.3 Tunniste Jokainen COM-rajapinta ja -komponentti on voitava tunnistaa yksikäsitteisesti, jotta palvelupyynnöt ohjautuvat oikeille komponenteille. COM:ssa käytetään 128-bittisiä kokonaislukuja tähän tarkoitukseen. Näistä tunnisteista käytetään lyhennettä GUID (Globally Unique IDentifier). GUID:t jakaantuvat edelleen komponentti- (CLSID) ja rajapintatunnisteeseen (IID). Microsoft tarjoaa työkalun (uuidgen) tunnisteiden automaattiseen generoimiseen. Ohjelmoijat voivat generoida tunnisteita myös COM:n API-funktion CoCreateGuid avulla. 2.4 Lyhyesti arkkitehtuurista Komponentin ja komponentin käyttäjän välinen yhteistoiminta pohjautuu asiakaspalvelin-malliin [Wac98, WiK94]. Asiakas on palvelun kutsuja ja komponentti sen tarjoaja eli palvelin. Monissa käytännön toteutuksissa kaksi komponenttia käyttävät 3

toistensa palveluja ristiin eli toimivat samaan aikaan sekä asiakkaana että palvelimena. Käyttöjärjestelmän osana tulee olla toteutettu komponenttikirjasto, jotta COM:ia voidaan käyttää. Esimerkiksi Windows 9x - ja NT -järjestelmissä komponenttikirjasto on toteutettu tiedostossa ole32.dll. Komponenttikirjaston ansiosta komponenttien yhteiskäyttö on mahdollista ja ohjelmoijan kannalta samanlaista komponentin sijainnista riippumatta. Jokainen komponentti on rekisteröitävä, jotta sitä voidaan kutsua. Komponentin luominen tapahtuu seuraavien askelien kautta (kuvio 3) [MoL97]: 1. Asiakas käynnistää COM API:n luodakseen uuden komponentin. 2. COM paikallistaa komponentin toteutuksen ja käynnistään palvelinprosessin komponenttia varten 3. Palvelinprosessi luo komponentin ja palauttaa osoittimen pyydettyyn rajapintaan. 4. Asiakas voi tämän jälkeen käyttää luotua komponenttia saamansa osoittimen kautta. 4) komponentti asiakas 3) palvelin 1) COM 2) Kuvio 3: Komponentin luominen [Com95]. Jokainen komponentti suoritetaan palvelimessa ja yksi palvelin voi tukea useita komponentteja. Asiakkaan ja palvelimen väliseen kommunikaatioon on 3 erilaista tapaa [MoL97] (taulukko 1). 4

Taulukko 1: Asiakkaan ja palvelimen kommunikontitavat. Palvelimen sijainti asiakkaaseen verrattuna Kommunikointimekanismi Palvelintiedoston muoto (Windows) samassa prosessissa Funktiokutsut.DLL samalla koneella eri prosesseissa RPC.EXE eri koneilla DCE RPC (DCOM).EXE 3 ONGELMAKENTTÄ Tässä kappaleessa keskitytään ongelmiin, jotka yleiskäyttöisen komponenttipohjaisen arkkitehtuurin tulisi ratkaista. Jokaisen ongelman kohdalla kuvataan, miten ongelma on ratkaistu COM:ssa. Ongelma - Yhteiskäyttöisyys: miten ohjelmistosuunnittelijat voivat luoda omia yksilöllisiä komponentteja ja silti olla varmoja siitä, että näitä komponentteja voidaan käyttää yhdessä toisten ohjelmistosuunnittelijoiden tekemien komponenttien kanssa? Ratkaisu: Komponenttien metodeja kutsutaan COM:ssa aina rajapintojen kautta ja rajapinnat noudattavat binääristandardia (ks. 2.1, 2.2) [WiK94]. Näin ollen eri ohjelmistosuunnittelijoiden tekemät komponentit toimivat yhdessä, jos ne noudattavat COM:in määrityksiä. Ongelma Versiointi: Miten voidaan päivittää yksi järjestelmän komponentti ilman, että tarvitsee päivittää kaikki järjestelmän komponentit? Ratkaisu: Rajapinnat ovat muuttumattomia ja uudet ominaisuudet toteutetaan uusina rajapintoina. Jos komponentin toteutusta muutetaan, niin komponentin on edelleen toteutettava vanhat rajapinnat. Asiakas aloittaa kommunikoinnin palvelimen kanssa aina tiedustelemalla tukeeko palvelin haluttua rajapintaa metodilla QueryInterface. Näin sekä uudet asiakkaat, jotka osaavat tiedustella uusia rajapintoja että vanhat asiakkaat, jotka käyttävät vanhoja rajapintoja, tulevat palvelluiksi oikealla tavalla [WaC98]. 5

Ongelma Kieliriippumattomuus: Miten eri ohjelmointikielillä kirjoitetut komponentin voivat toimia yhdessä? Ratkaisu: COM määrittelee binäärisen komponenttistandardin eikä lähdekoodistandardia. Tästä johtuen komponentteja voidaan toteuttaa lukuisilla erilaisilla ohjelmointikielillä ja silti käyttää komponentteja yhdessä. Ongelma Läpinäkyvyys: Miten saadaan ohjelmoijan kannalta samankaltaiseksi komoponentin käyttö sen sijainnista riippumatta? Ratkaisu: COM tukee prosessien välistä yhteiskäyttöisyyttä ja sisältää kaikki tarvittavat mekanismit komponenttien paikallistamiseen ja kutsumiseen. Nämä mekanismit sijaitsevat komponenttikirjastossa, joka on toteutettu käyttöjärjestelmän palveluna (ks. 2.4). Komponenttia käytetään aina osoittimen kautta ja osoitin sisältää kaikki asiakkaan ja komponentin väliseen yhteydenpitoon tarvittavat tiedot: IP-osoite, portti ja komponentin ID [WaC98]. 4 KÄYTETTÄVYYS Tässä kappaleessa tarkastellaan COM:in käytön kannalta tärkeitä seikkoja. Näihin kuuluvat alustat, joilla COM:ia voidaan käyttää ja alustan COM:ia tukevat palvelut. Lisäksi tarkastellaan yleisimpiä vaihtoehtoja COM-arkkitehtuurille. 4.1 Alustat Komponentit eivät ole suoraan siirrettävissä alustalta toiselle, koska COM-perustuu binääristandardiin. Komponentit on käännettävä uudelleen tai vaihtoehtoisesti käytettävä binäärikooditulkkia. Binäärimuodon etuja ovat suoritusnopeus ja tehokas alustakohtaisten ominaisuuksien käyttö. Windows 9x ja NT -alustat tukevat COM:ia parhaiten [MoL97]. Microsoft on julkaissut COM:sta version myös MacOS:lle ja UNIX-versiota on kehittänyt Microsoftin kumppani Software AG. COM on saanut yleisen hyväksynnän 6

teollisuudessa Windows-alustoille tehtävässä ohjelmistokehityksessä ja COMyhteensopivia palveluja on kehitetty Windows-alustoille laajasti. 4.2 Kehitysympäristö Kehitysympäristöjen ja käyttöjärjestelmän tukipalveluiden olemassaolo ja niiden hankkimiskustannukset ovat ratkaisevia tekijöitä ohjelmistokehityksen tehokkuuden ja mielekkyyden kannalta. Microsoftin tarjoamat halvat kehitysvälineet, kuten Visual C++ ja Visual Basic, tekevät COM-komponenttien kehityksen ja käytön Windowsalustoilla helpoksi. Lisäksi Windows-alustoilla voidaan käyttää Microsoftin komponenttipalveluja [Mic98], jotka laajentavat komponenttien käyttömahdollisuuksia (taulukko 2). Muilla alustoilla tilanne ei ole yhtä hyvä. Taulukko 2: Microsoftin komponenttipalveluiden COM-komponenttien käyttöön tuomat lisäominaisuudet. Ominaisuus Transaktiot, tietoturva Komponenttien käyttö www-palveluissa Asynkroninen kommunikointi sovellusten välillä Mahdollistava tukipalvelu Microsoft Transaction Server Interner Information Server Microsoft Message Queue 4.3 Vaihtoehtoiset ratkaisut Hajautetuista komponenttiarkkitehtuurimalleista läheisesti Microsoftin COMarkkitehtuuria muistuttaa Object Management Group:in Common Object Request Broker Architecture (CORBA). Plášilin ja Stalin [PlS98] mukaan COM, CORBA ja Java RMI -tekniikat perustuvat samoihin periaatteisiin suunnittelumallien [Gam95] tasolla. Heidän mukaan nämä tekniikat jakavat yhteisen ongelma-avaruuden ja on toteutettu samojen periaatteiden pohjalta, mutta niiden kuvaukset puhuvat eri kieltä. Chung et al. [Chu98] yhtyy edellisten näkemykseen COM:n ja CORBA:n osalta. COM:in eduksi CORBA:an nähden voidaan katsoa myös alustakohtainen yhtenäisyys: COM:lle on yleensä yksi toteutus alustaa kohti kun taas CORBA:lle useita erilaisia. 7

Web-sovelluskehityksessä on havaittu jakaantumista kahteen teknologialeiriin, joista toinen on keskittynyt Microsoftin COM:in, Internet Exprolorer:in ja ActiveX:n ympärille, ja toinen taas CORBAn, Netscapen ja Java-teknologian ympärille [MoL97]. Selvyyttä siitä, kumpi näistä on parempi, ei kuitenkaan ole. 5 YHTEENVETO Microsoftin COM määrittelee arkkitehtuurin, binääristandardin ja infrastruktuurin komponenttiperustaisten ohjelmistojen kehittämiseen ja käyttöön. Malli erottaa toteutukset niiden rajapinnoista. COM on kieliriippumaton ja ratkaisee versioinnin ongelman komponenttien monirajapintaisuuden avulla. COM:in avulla hajautettujen komponenttiperustaisten palvelujen kehittäminen on helppoa, sillä ohjelmoijien ei tarvitse välittää komponenttien sijainnista. COM on tehokas ja toimiva ratkaisu Windows-alustalla. Windows-alustan lukuisat tukipalvelut ja erinomainen kehitysympäristö tekevät COM-komponenttien käytöstä ja kehityksestä helppoa ja nopeaa. COM:in käytettävyys muilla alustoilla riippuu alustakohtaisesta kehitysympäristöstä. Pelkkä mahdollisuus COM:in käyttöön jollakin alustalla ei välttämättä riitä, vaan myös tukipalveluja tarvitaan. Tärkeiksi seikoiksi käyttöönoton kannalta nousevat alkukustannukset. Windows-alustalla käyttöönottokustannukset ovat alhaiset. COM:in kanssa kilpailevat tekniikat kuten CORBA ja Java RMI keskittyvät samaan ongelma-avaruuteen. Selvää paremmuutta ei näiden välillä ole ja jokaisella näistä on omat etunsa ja ongelmansa. 8

LÄHTEET [BrK98] Brown, N., Kindel, C., The Distributed Component Object Model Protocol DCOM/1.0. Homepage for Microsoft COM/Resourses/Specs, http://www.microsoft.com/com/resources/specs.asp. [25.11.2000] [Bro96] Brockschmidt, K., What OLE is Really About. MSDN Online Library/Technical Articles/Component Object Model/OLE, http://msdn.microsoft.com/library/techart/msdn_aboutole.htm. [25.11.2000] [Chu98] Chung, P. et al., DCOM and CORBA. C++ Report 10, 1 (January 1998), 18-29. [Com95] The Component Object Model Specification. Homepage for Microsoft COM/Resourses/Specs, http://www.microsoft.com/com/resources/specs.asp. [25.11.2000] [Gam95] Gamma, E. et al., Design Patterns : elements of reusable objectoriented software. Addison-Wesley professional computing series, Addison-Wesley, 1995. [Mic98] Microsoft Component Services a Technical Overview. Homepage for Microsoft COM/White Papers, http://www.microsoft.com/com/wpaper/compsvcs.asp. [08.11.2000] [Mil99] Milojicic, D., Middleware s role, today and tomorrow. IEEE Concurrency 7, 2 (April-June 1999), 70-80. 9

[MoL97] Morris, E., Litvak, E., Component Object Model (COM), DCOM, and Related Capabilities. Carnegie Mellon Software Engineering Institute [online]/products and Services/Information Repositories/Software Technology Review/Technology Descriptions, http://www.sei.cmu.edu/str/descriptions/com_body.html. [08.11.2000] [PlS98] Plášil, F., Stal, M., An architectural view of distributed objects and components in CORBA, Java RMI and COM/DCOM. Software Concepts and Tools 19, 1 (June 1998), 14-28. [WaC98] Wang, Y., Chung, P., Exploring Customization of Distributed Systems using COM. IEEE Concurrency Magazine, (July/August/September 1998), -. http://research.microsoft.com/~ymwang/papers/html/comessay/s.htm. [08.11.2000] [WiK94] Williams, S., Kindel, C., The Component Object Model: A Technical Overview. MSDN Online Library/Technical Articles/Component Object Model, http://msdn.microsoft.com/library/techart/msdn_comppr.htm. [08.11.2000] 10