Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto toiminnallisuus, arkkitehtuuri, siirtymästrategiat ja välineet

Transkriptio

1 Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7 Kuopio University Occasional Reports C. Natural and Environmental Sciences 7 Juha Mykkänen Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto toiminnallisuus, arkkitehtuuri, siirtymästrategiat ja välineet Atk-keskus Kuopion yliopisto Kuopio 2000

2 Myynti: Atk-keskus Kuopion yliopisto PL KUOPIO Puh. (017) Telefax (017) Sarjan toimittaja: Lauri Kärenlampi, FT, professori Ekologisen ympäristötieteen laitos Tekijän osoite: Atk-keskus Kuopion yliopisto PL KUOPIO ISBN X ISSN Kuopion yliopiston painatuskeskus Kuopio 2000 Finland

3 Mykkänen, Juha. Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto toiminnallisuus, arkkitehtuuri, siirtymästrategiat ja välineet. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet s. ISBN X ISSN TIIVISTELMÄ Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto toiminnallisuus, arkkitehtuuri, siirtymästrategiat ja välineet. Selvityksessä tarkastellaan komponenttipohjaisen sovellustuotannon edellytyksiä ja välineitä suhteessa terveydenhuollon tietojärjestelmien kehittämiseen. Erityisesti lähtökohtana ovat Mustipohjaiset terveydenhuollon tietojärjestelmät. Tarkasteltavia kokonaisuuksia ovat komponenttipohjaisen järjestelmätuotannon peruskäsitteet, komponenttiarkkitehtuurit, ohjelmistotuotantoprosessi, komponenttien mallintaminen ja suunnittelu sekä järjestelmien hajauttamiseen, komponenttipohjaiseen integrointiin, käyttöliittymiin sekä pysyvien tietojen hallintaan liittyvät kysymykset. Järjestelmätuotannon tehostamiseen ja kehittämiseen liittyviä asiakokonaisuuksia selvityksessä ovat terveydenhuollon yleisten palvelujen standardit, sovellusten yleisen toiminnallisuuden kokonaisuudet sekä vaatimukset ja komponenttipohjaisten järjestelmien tuottamiseen tarkoitetut välineet sekä näiden välineiden kehittäminen olemassa olevien asiakas-palvelin-arkkitehtuurissa käytettyjen sovelluskehitysvälineiden pohjalta. Terveydenhuollon tietojärjestelmien kehittämiseen määritellään vuoteen 2005 kohdistettu tavoitearkkitehtuuri sekä kolme vaihtoehtoista siirtymäpolkua, joilla Musti-pohjaisista järjestelmistä siirrytään kohti tavoitearkkitehtuuria. Selvitys liittyy Kuopion yliopiston atk-keskuksen Komponentti-FixIT projektiin, jonka tavoitteena on kehittää Musti-järjestelmissä käytetyn teknologian pohjalta siirtymästrategia vuoteen 2005 sekä sitä toteuttava nopea sovelluskehitysteknologia, sovellusten perustuminen uudelleenkäytettäviin toimialakomponentteihin, ja oliopohjaisen sovellusintegraation sekä aluearkkitehtuurin tukeminen. National Library of Medicine Classification: W 26.5, W S6 Yleinen kymmenluokittelu UDK: , , Yleinen suomalainen asiasanasto: tiedonhallinta; tietojärjestelmät; tietokannat; systeemityö; tiedonhallintajärjestelmät; ohjelmointi; oliokeskeisyys; terveydenhuolto; tietoteollisuus Medical Subject Headings: medical informatics; information systems; information management; database management systems; software; health care sector; hospital information systems

4

5 Esipuhe Tämä selvitys on tehty Kuopion yliopiston atk-keskuksen Komponentti-FixIT -projektille vuonna Kiitän yliopiston atk-keskusta sekä projektin rahoittajia saamastani tuesta. Komponentti-FixIT projektin rahoittavat TEKES, BEA Systems Oy, Oy Compaq Computer Ab, Computer Associates Finland Oy, InterSystems B.V. Finland, Medici Data Oy, Medigroup Oy, Mylab Oy, Novo Group Oyj, Oracle Finland Oy, Helsingin-Uudenmaan sairaanhoitopiiri HUS, Kuopion yliopistollinen sairaala KYS ja Turun yliopistollinen sairaala TYKS. Kiitän projektiin osallistuvien yritysten ja sairaaloiden edustajia hyvistä ideoista ja näkökulmista. Erityiskiitokset Mikko Korpelalle ja Anne Eerolalle runsaista ideoista ja kommenteista. Kiitokset myös atk-keskuksen tietojärjestelmäryhmälle palautteesta. Myös Katille rakkaat kiitokset. Kuopiossa 1. joulukuuta 2000 Juha Mykkänen

6

7 SISÄLLYS OSA I: PERUSTEET 1 JOHDANTO Taustaa Projektin tavoitteet Dokumentin sisällöstä KOMPONENTTIPOHJAINEN JÄRJESTELMÄTUOTANTO Peruskäsitteet Sovellustuotannon tarpeet ja komponenttien lupaukset Ohjelmistoteollisuuden kehitysnäkymät Miksi komponentteja terveydenhuoltoon? OHJELMISTOTUOTANTOPROSESSI Prosessin vaiheet ja vaihtoehdot Komponenttipohjainen ohjelmistotuotantoprosessi ja sen tehtäväkentät...27 OSA II: TAUSTASELVITYKSET 4 KOMPONENTTIMALLIT JA -VÄLIOHJELMISTOT Komponenttimallien vaatimukset Komponenttimallien vertailua: COM+, CORBA, ja EJB SELVITYS KOMPONENTTIARKKITEHTUURIMALLEISTA Yleinen viitearkkitehtuuri CCS-SIS RC Business Object Architecture NAC Business Services Architecture IBM SanFrancisco Johtopäätökset...52

8 6 KOMPONENTTIARKKITEHTUURI Hajautettu komponentti Hajautusarkkitehtuuri Toimialakomponentti Komponenttijärjestelmä KOMPONENTTIEN MALLINTAMINEN JA SUUNNITTELU Sovellusalueen ja komponenttien mallintaminen Suunnittelumallit ja sovelluskehykset ARKKITEHTUURITYYLIT Tyyppi-, esiintymä- ja tapahtumaperusteiset tyylit Koordinaattorit ja yhdenvertaiset komponentit TEKNINEN ARKKITEHTUURI Teknisen arkkitehtuurin osat Teknisen arkkitehtuurin toteutus KOMPONENTTIEN PYSYVIEN TIETOJEN HALLINTA Toimialakomponentin tiedon säilytys Tiedon tallennus komponentin vastuulla Pysyvyyspalvelut Pysyvä oliomalli Tiedon yhdenmukaisuus ja muut tietokantojen tarjoamat palvelut KÄYTTÖLIITTYMÄT Käyttöliittymien suunnittelu Komponenttijärjestelmien käyttöliittymät Työpöytäintegraatio ja portaalit JÄRJESTELMÄINTEGRAATIO Integrointitasot Integrointitavat Komponenttipohjainen integrointi Merkattu data ja XML...100

9 13 TERVEYDENHUOLLON YLEISTEN PALVELUJEN STANDARDIT CORBAmed HISA (Healthcare Information Systems Architecture) YLEISEN TOIMINNALLISUUDEN SOVELLUSKEHYKSET Toimintapalvelut Integraatiopalvelut SOVELLUKSEN RAKENTAMINEN Hajautetun komponentin käyttö toimialakomponentin rakentamisessa Komponenttiliittymä Toimialan tietotyypit Hajautetun komponentin sisäinen toteutus Hajautetun komponentin rakentamisessa käytetyt luokkatyypit LÄHTÖTILAN KUVAUS Kehittyvä palveluketjuajattelu ja uusi teknologia Järjestelmäympäristö ja järjestelmien yhteistoiminnallisuus Komponenttitekniikalta odotetavat hyödyt ja tarvittavat välineet Tekninen tilanne: FixIT-välineet Siirtyminen FixIT-sovelluksista komponenttisovelluksiin OSA III: TAVOITTEET JA SUUNNITELMAT 17 TAVOITEARKKITEHTUURI Tavoitearkkitehtuurin kuvaus Sovellusarkkitehtuurin kerrokset Sovelluksen sisäinen arkkitehtuuri Sovellusten välinen arkkitehtuuri Alueellinen arkkitehtuuri Tekninen tavoitearkkitehtuuri...143

10 18 SIIRTYMÄPOLUT Kerroksittainen uusiminen Rinnakkainen kehitys Web-lähtöinen "Naapurien polut" Siirtymäpolku sovellusintegraatiossa KERROKSITTAISEN UUSIMISEN SIIRTYMÄPOLKU Ensimmäinen vaihe: sovelluspalvelin ja monitasoarkkitehtuuri Toinen vaihe: komponentit sovelluspalvelimelle Kolmas vaihe: komponenttisovellukset ja toimialakomponentit KOMPONENTTIMALLI Sovellusarkkitehtuuri Komponenttimalli Käytettävät tekniikat Jatkokehitys VÄLINEISTÖSUUNNITELMA Välineistötavoitteet Välineistön kuvaus Metadata Hajautettujen komponenttien määrittely- ja rakennustyökalut Suunnittelumallit ja sovelluskehykset Yleiset palvelut Toimialakomponentin rakennusvälineet Toimialakomponenttisovelluksen rakennusvälineet YHTEENVETO Liite 1: Sanasto peruskäsitteistöstä Liite 2: Hakemisto

11 JOHDANTO 11 OSA I: PERUSTEET 1 JOHDANTO 1.1 Taustaa Komponenttipohjainen ohjelmistotuotanto on oliopohjaisten systeemityömenetelmien jatke, joka keskittyy tuottamaan suhteellisen suuria, itsenäisiä ja uudelleen käytettäviä ohjelmisto-osia eli komponentteja. Varsinkin suurten tietojärjestelmien toteutuksessa komponenttitekniikasta odotetaan yleisesti saatavan hyötyjä järjestelmän paremman hallittavuuden, tehostuneen uudelleenkäytön ja arkkitehtuurikeskeisyyden ansiosta. Tässä selvityksessä tarkastellaan komponenttipohjaisen ohjelmistotuotannon tekniikoita ja mahdollisuuksia terveydenhuollon tietojärjestelmien kehittämisessä. Erityisesti kiinnitetään huomiota tavoitteiden ja siirtymäpolkujen määrittelyyn siten, että olemassa olevia elinkelpoisia järjestelmiä määrätietoisesti ja asteittain uusimalla päästään siirtymään uusiin komponenttipohjaisiin sovelluksiin, joiden lupaukset tukevat terveydenhuollon organisaatioiden sisäisten ja niiden yhteisten kehitystavoitteiden täyttymistä. Suomen sairaaloissa ovat edelleen yleisimpiä nk. Musti-perheeseen kuuluvat tietojärjestelmät. Järjestelmät ovat peräisin 1980-luvun puolivälin tienoilta ja käyttävät Yhdysvaltain veteraaniasiain ministeriön (VA) kehittämiä työkaluja: FileMan-tietokannanhallintajärjestelmää ja Kernel-työvälineohjelmistoja. Sairaaloiden kannalta nämä tekniikat ovat olleet kiinnostavia, koska ne ovat ilmaisia ja vapaasti levitettäviä, pohjautuvat helposti laitteistoalustalta toiselle siirrettävään M-tekniikkaan (ks. sanasto) ja skaalautuvat hyvin pc-pohjaisista työasemista suuriin palvelimiin. Suomen lisäksi samaan teknologiaan perustuvia järjestelmiä on laajasti käytössä varsinkin Yhdysvaltain veteraaniasiain ministeriössä ja puolustusministeriössä, joissa suuri osa myös terveydenhuollon ydinsovelluksista perustuu M-tekniikoilla toteutettuihin järjestelmiin. Musti-sovellukset ovat vuosien mittaan hioutuneet jokapäiväisessä käytössä esiin tulleisiin tarpeisiin sopiviksi ja sulautuneet terveydenhuollon ydintoimintoihin. Toisaalta varsinkin keskuskonearkkitehtuuri ja käyttöliittymä ovat niin vanhentuneita, että sairaalat ovat laajasti etsimässä korvaavia järjestelmiä, joita ei kuitenkaan ole löytynyt. Kertakaikkisen korvaamisen sijaan tarvitaankin siirtymästrategia ja -tekniikka, joka hyödyntää järjestelmien vahvuudet ja elinkelpoiset osat, mutta antaa mahdollisuuden uusia vanhentuneet osat vähitellen (Korpela ym., 2000). Lähtökohtana on se, että ydinjärjestelmät tullaan korvaamaan muita tekniikoita käyttävillä järjestelmillä, mutta sairaalat tarvitsevat myös niiden kanssa yhteistoiminnallisia erillisjärjestelmiä, joita voidaan kehittää myös Musti-tekniikan pohjalta. Tämä tekninen lähtökohta näkyy läpi tämän selvityksen käsiteltävien asioiden vertailuina ja projektointina jo kehitettyihin FixIT-välineisiin. Sekä M-pohjaisten sovellusten sisäisen arkkitehtuurin uudistamiseen että kasvaviin sovellusintegraation tarpeisiin lupauksia herättäviä teknologioita ovat hajautettuihin komponenttiarkkitehtuureihin perustuvat tekniikat (Räsänen, 1999). Komponenttipohjaisen ohjelmistotuotannon keskeisiä lupauksia ovat tuki heterogeenisille ympäristöille, parantunut uudelleenkäytettävyys, laajojen järjestelmien hallittava ja vähittäinen toteutus ja sopeutuminen muutoksiin. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

12 12 JOHDANTO 1.2 Projektin tavoitteet Komponentti-FixIT -projektin tavoitteena on kehittää siirtymästrategia vuoteen 2005 asti sekä sitä toteuttava nopea sovelluskehitysteknologia, jotka soveltuvat kotimaiselle "Musti-ryppäälle" ja kansainväliselle "VA-ryppäälle", perustuvat uudelleenkäytettäviin toimialakomponentteihin ja tukevat oliopohjaista sovellusintegraatiota (HL7 v. 3) ja aluearkkitehtuuria. Komponentti-FixIT -projektin tavoitteena on kehittää "Musti-ryppään" ja "VA-ryppään" sairaaloiden ja sovellustoimittajien tarpeisiin soveltuen ja niiden kanssa tiiviissä yhteistyössä seuraavat tulokset: 1. Siirtymästrategia, joka määrittelee karkeasti noin vuonna 2005 tavoitteena olevan sovellusarkkitehtuurin (sovelluksen sisäisen, sovellusten välisen ja alueellisen) pääpiirteet sekä vaiheet, joiden kautta siihen siirrytään nykyiseltä FileMan/FixIT -pohjalta. 2. FixIT-välineistön seuraava sukupolvi, joka toteuttaa siirtymästrategian ensimmäisen vaiheen. 3. Koulutus- ja käyttöönottoprosessi, jolla välineistö saatetaan tehokkaasti nykyisten ja uusien yritysten ja sairaaloiden sovelluskehittäjien käyttöön. Suomessa tavoitteena on tuottaa ydinjärjestelmien kanssa yhteistoiminnallisia, teknisesti kilpailukykyisiä ja vientikelpoisia erillisjärjestelmiä, ei kilpailla ydinjärjestelmämarkkinoilla. Muualla, esim. VA:lla, missä FileMan-tekniikkaan perustuvat ydinjärjestelmät ovat säilyneet kilpailukykyisinä, projektin tuottamaa tekniikkaa voidaan mahdollisesti käyttää laajemminkin. Projektin yksityiskohtaisia tavoitteita käsitellään selvityksen myöhemmissä luvuissa tarkemmin. 1.3 Dokumentin sisällöstä Tämän dokumentin tavoitteena on koota Komponentti-FixIT projektissa kerättyä selvitysmateriaalia yhtenäiseksi kokoelmaksi, jota käytetään jatkosuunnitelmien ja teknisten toteutusten yhteydessä kehysmateriaalina. Dokumentti muodostaa pohjan jatkokeskusteluille eri osapuolten kesken, ja nostaa esiin useita tärkeitä kysymyksiä komponenttipohjaiseen sovellustuotantoon siirtymistä ajatellen. Dokumentista on jätetty ulkopuolelle kovin yksityiskohtaiset kuvaukset suunnitelluista teknisistä toteutuksista niiden muuttuvan luonteen vuoksi, mutta pyritään kuvaamaan toimintaperiaatetasolla useita käyttökelpoisia kehyksiä ja malleja sovelluksista yleisesti löydettävän toiminnallisuuden toteuttamiseen sekä siirtymiseen nykyisistä järjestelmistä kohti komponenttipohjaista sovellustuotantoa. Dokumentti toimii myös vaatimusmäärittely- ja analyysidokumenttina Komponentti-FixIT projektissa kehitettäville ja arvioitaville välineille. Esitellyt ratkaisut ja toimenpiteet eivät ole Komponentti-FixIT projektin tai sen johtoryhmän virallinen kanta, vaan kirjoittajan esitystä, joka muodostaa pohjan jatkosuunnitelmille ja päätöksille. On huomattava, että vaikka Komponentti-FixIT projektilla onkin selvä tekninen lähtötilanne Musti-järjestelmien modernisoinnin pohjalta, tässä dokumentissa esiteltävät ratkaisut eivät ole M- tekniikkasidonnaisia, vaan niitä voidaan soveltaa myös täysin uusien järjestelmien rakentamisessa tai osin suunniteltaessa toiselta tekniseltä pohjalta siirtymistä komponenttipohjaiseen sovellustuotantoon. Kuopion yliopiston selvityksiä C. Luonnontieeet ja ympäristötieteet 7

13 JOHDANTO 13 Dokumentti on tekniikkapainotteinen, vaikka siinä arvioidaan ja perustellaan eri tekniikoiden käyttöä myös terveydenhuollon organisaatioiden näkökulmasta. Muutokset ja lisärajaukset ovat todennäköisiä projektin työn edetessä. Dokumentti on jaettu karkeasti kolmeen pääosaan. Yleiskuvan saamiseksi riittää osan I sekä osan III tavoite- ja yhteenvetolukujen lukeminen. Osassa II on tarkempia selvityksiä eri osa-alueilta, joihin syventyminen ei ole tarpeen kokonaislinjojen ymmärtämisen kannalta. Ensimmäinen osa on johdantoa ja perusasioiden määrittelyä. Luvuissa 2 ja 3 käsitellään yleisesti komponenttitekniikkaa ja ohjelmistotuotantoprosessia. Toinen osa muodostaa selvitysosuuden, jossa käsitellään tarkemmin muutamia osa-alueita komponenttipohjaisten järjestelmien tuotannossa. Luvussa 4 esitellään lyhyesti CORBA:n, DCOM:n ja EJB:n komponenttimallit. Luvussa 5 luodaan katsaus muutamiin toteutettuihin komponenttiarkkitehtuureihin ja -sovelluksiin. Luvussa 6 esitellään käytettävä monitasoinen viitearkkitehtuuri komponenttipohjaisille sovelluksille. Luvussa 7 tarkastellaan komponenttien suunnittelua. Luvuissa 8-12 käsitellään muutamia komponenttisovelluksien osa-alueita erityisesti: arkkitehtuurityylejä, teknistä arkkitehtuuria, tiedon pysyvyyttä, käyttöliittymiä ja järjestelmäintegraatiota. Luvussa 13 esitellään kaksi terveydenhuollon toimialalle kehitettyä yleisten palvelujen spesifikaatiota. Luvussa 14 jaetaan komponenttisovelluksen yleistä toiminnallisuutta erillisiin osakehyksiin, joille voidaan luoda omia sovelluskehyksiään ja suunnittelumallejaan. Luvussa 15 tarkastellaan lähemmin komponenttien sisäistä toteutusta. Lopuksi luvussa 16 suhteutetaan Musti-pohjaisten järjestelmien nykytilanne selvityksen aikaisempien lukujen näkymiin ja luodaan katsaus Musti-järjestelmien ulkopuolella tapahtuvaan kehitykseen, trendeihin ja standardeihin. Loppuosan luvut muodostavat soveltavan suunnitelmaosuuden. Luvussa 17 esitellään vuodelle 2005 tavoitearkkitehtuuri, jota kohti Komponentti-FixIT projektissa pyritään. Luvuissa 18, 19 ja 20 esitetään vaihtoehtoiset siirtymästrategiat kohti vuoden 2005 tavoitearkkitehtuuria ja esitellään tarkemmalla tasolla Komponentti-FixIT -projektin ensimmäisen vaiheen (vuoteen 2002) tavoitetilaa. Lopuksi luvussa 21 hahmotellaan tarkemmin suunnitelmaa Komponentti-FixIT -projektin tuottamista välineistä, sovelluskehyksistä ja malleista. Dokumentin viimeisessä luvussa arvioidaan Komponentti-FixIT -projektin tavoitteita ja suunnitelmia suhteessa nykytilaan ja esitellään eri painopistealueita, joille työtä voidaan suunnata. Voidaan pitää jopa tavoitteellisena tilannetta, että varsinkin selvityksen loppuosan välineistöä koskevat luvut vanhenisivat tai korvautuisivat tarkoilla välinekohtaisilla ohjeistuksilla suhteellisen nopeasti, kun komponenttipohjaisten sovellusten kehitysvälineitä etsitään ja kehitetään. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

14 14 OSA I: Perusteet 2 KOMPONENTTIPOHJAINEN JÄRJESTELMÄTUOTANTO Tässä luvussa selvennetään ensimmäisenä muutamia selvityksessä käytettyjä peruskäsitteitä. Sen jälkeen luodaan katsaus komponenttipohjaisille tekniikoille ja menetelmille asetettuihin odotuksiin sekä pohditaan komponenttitekniikoiden mahdollisuuksia vastata näihin lupauksiin. Lopuksi tarkastellaan komponenttitekniikoiden mahdollisuuksia nimenomaan terveydenhuollon tietojärjestelmien käyttäjien ja tekijöiden näkökulmasta. 2.1 Peruskäsitteet Monilla tässä selvityksessä käytettävillä termeillä ei ole vakiintuneita suomenkielisiä vastineita. Selvityksessä pyritäänkin esittämään myös englanninkielinen, täsmällinen termi siinä yhteydessä, kun uusi suomenkielinen termi esiintyy ensimmäisen kerran. Tässä luvussa selvennetään muutamia selvityksessä yleisesti käytettyjen termien merkityksiä. Komponentti on itsenäinen, uudelleenkäytettävä ja selvästi rajattu ohjelmistokokonaisuus. Uudelleenkäytettävät ohjelmistokomponentit ovat itseriittoisia, ja selkeästi tunnistettavia ja kuvaavat tai suorittavat tiettyjä tehtäviä. Komponentin tarkoitus, rajaus ja vuorovaikutus muun järjestelmän kanssa on määriteltävä tarkasti. Komponentilla on selkeät rajapinnat, riittävä dokumentaatio ja tarkoin määritelty status uudelleenkäytön kannalta. Kirjallisuudessa esitettyjä runsaasti toisistaan poikkeavia komponentin määritelmiä on esitelty ja vertailtu kootusti lähteessä Kuusi (1997). Komponentteja on olemassa hyvin eri kokoisina, jolloin puhutaan komponenttien karkeajakoisuudesta (granularity). Karkeajakoisuuden mukaan komponentit voidaan jakaa eri luokkiin esim. seuraavasti (Herzum, Sims 2000): alkeistason komponentit, esim. käyttöliittymäkirjasto, palvelutason komponentit: vertikaalisesti (tietyllä sovellusalalla) tai horisontaalisesti (tietyn tyyppisissä sovelluksissa) yleiskäyttöinen palvelu, liiketoimintapalvelutason komponentit: sovellusaluekohtainen, toimialakomponentti ja sovellustason komponentit: itsessään sovellus. Tässä selvityksessä keskitytään lähinnä palvelu- ja liiketoimintapalvelutason komponentteihin, joilla pyritään toteuttamaan melko suuria sovellusten toiminnallisuuskokonaisuuksia. Näihin komponenttityyppeihin palataan tarkemmin selvityksen luvussa 6. Alkeistason komponentteja on käytetty ja käytetään jatkossakin tehokkaasti mm. käyttöliittymien rakentamisessa. Rajapinta on järjestelmän toimijoiden tai osien välinen kosketuspinta, eli rajapinnan avulla eri osia pyritään liittämään yhteen. Komponentit voidaan jaotella esim. neljän rajapintatason mukaan (Sametinger 1997). Nämä tasot on otettava huomioon komponenttien suunnittelussa ja toteutuksessa: käyttäjärajapinta: komponentin ja loppukäyttäjän välinen rajapinta, datarajapinta: komponentin ja sen käyttämän tietovaraston välinen rajapinta, kompositiorajapinta: komponentin ja muiden komponenttien välinen rajapinta, sisältää: Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

15 KOMPONENTTIPOHJAINEN JÄRJESTELMÄTUOTANTO komponenttiliittymän (interface), jolla komponentti tarjoaa palveluitaan (usein komponentteja käsiteltäessä rajapinnalla tarkoitetaan pelkästään tätä rajapintaa) ja 2. rajapinnan, jolla komponentti käyttää muiden komponenttien palveluja (proxy); komponenttialusta: ohjelmisto, jota komponentti tarvitsee toimiakseen. Näiden rajapintojen avulla voidaan arvioida sitä, kuinka uudelleenkäytettävä komponentti on. Komponenttiliittymä (interface) on kompositiorajapinta, jonka kautta komponentti tarjoaa palvelujaan ulkopuolisille käyttäjille. Komponenttiliittymä on yleensä määritelty liittymän määrittelykielellä (IDL, Interface Definition Language), joka ei sido mihinkään yksittäiseen toteutustekniikkaan. Komponenttien mielekkään käytön edellytyksenä on se, että toimintaprosessit eli reaalimaailman toiminnot on mallinnettu komponentteina, joiden palveluja kuvaavat yleiskäyttöiset, julkiset komponenttiliittymät. Yhdellä komponentilla voi olla useita komponenttiliittymiä. Käyttöliittymä (user interface) on tässä selvityksessä järjestelmän ja loppukäyttäjän välinen rajapinta. Komponenttiliittymän kuvaus on uudelleenkäytettävä, ja sen avulla voidaan jakaa informaatiota eri sovellusten ja käyttäjien välillä. On mahdollista integroida erilaisia järjestelmäympäristöjä komponenttiliittymiä käyttäen, esim. voidaan yhdistää työasemilla toimivia käyttöliittymiä palvelimilla toimivien toimintaprosessien ja transaktio- ja tietokantapalveluiden kanssa. Komponenttiliittymän merkitys ja hyöty perustuu kolmeen seikkaan: 1. Sisäisen toteutuksen piilottaminen: komponentin palveluja käytetään vain komponenttiliittymän kautta, ja sisäinen toteutus voi perustua mihin tahansa tekniikkaan, kunhan liittymälle tulleet palvelupyynnöt toteutetaan sovitulla tavalla. 2. Palvelujen saatavuus määritellystä paikasta: komponentti voi sisältää runsaastikin erilaisia palveluita, ja kutakin palvelua voidaan kutsua, kunhan komponenttiin saadaan yhteys ja komponenttiliittymän tarjoamat palvelut saadaan selville. Komponenttien väliset riippuvuudet hoidetaan keskitetysti komponenttiliittymien kautta. 3. Sisäisen toteutuksen vaihdettavuus: mikäli komponenttiliittymä säilyy muuttumattomana, voidaan komponentin sisäinen toteutus vaihtaa vaikuttamatta komponentin käyttäjiin. Liittymän taakse kätkeytyvän toteutuskoodin muuttaminen ja kehittäminen on mahdollista rajapintaa muuttamatta. Tämä mahdollistaa esim. toteutuksessa käytetyn tietokantatekniikan muuttamisen, jos liittymä ei paljasta tietokantakohtaisia piirteitä. Komponenttiliittymä toteuttaa operaatioita, jotka tyypillisesti toteuttavat yhden komponentin tarjoamista palveluista. Kukin komponenttiliittymä voi toteuttaa useita operaatioita. Käytettävien karkeajakoisten komponenttien suomenkieliset nimitykset eivät ole vakiintuneet. Business Object tai Business Component -käsitteet ovat epämääräisiä myös kansainvälisessä kirjallisuudessa. Tässä selvityksessä toimialakomponentti (Business component) (ks. luku 6.3) tarkoittaa suurta, mahdollisesti useita hajautuskerroksia sisältävää komponenttia. Toimintatason komponentti (Enterprise component) (ks. luku 6.1) tarkoittaa monitasoarkkitehtuurissa (ks. luku 6) sovelluspalvelimella sijaitsevaa komponenttia, jolla on komponenttimallin (ks. luku 4) mukainen komponenttiliittymä ja joka voi olla jonkin toimialakomponentin osa. Enterprise käsitteen suomennoksena on käytetty läpi selvityksen toimintatasoa, joka viittaa arkkitehtuurissa sovelluspalvelimella toimivaan komponenttiin. Business on suomennettu toimialaksi. Komponenttien sopeuttaminen tarkoittaa toimenpiteitä, joita komponentille on tehtävä, jotta sitä voidaan käyttää tietyn ohjelmiston rakentamisessa. Sopeuttaminen pyritään tekemään läpinäkyvästi, eli sopeutettu komponentti voidaan sijoittaa alkuperäisen komponentin ilmentymän paikalle. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

16 16 OSA I: Perusteet Sopeuttamista tarvitaan, jos rakennettavassa sovelluksessa on tarve muuttaa komponentin toimintaa, tai yhteen sovitettavat komponentit käyttäytyvät halutulla tavalla, mutta rajapinnoissa on syntaktisia eroja. Sopeuttaminen voi olla mukauttamista tai muokkaamista. Mukauttamisessa komponentin kehittäjä on määritellyt etukäteen optioita, joiden avulla komponentin toimintaa voi konfiguroida (esim. parametrisointi). Jos sopeuttaminen tapahtuu täysin käyttäjän toimesta perustuen käytettävissä olevaan komponenttiteknologiaan, on kyseessä muokkaaminen (esim. periyttäminen). Sopeuttamismenetelmät riippuvat siitä, onko komponentin toteutus jokin seuraavista vaihtoehdoista: musta laatikko: alkuperäistä komponenttia ei muuteta eikä sen toteutus ole saatavilla, vain komponenttiliittymät ovat käytettävissä valkea laatikko: komponentin toteutus on muutettavissa ja saatavilla lasilaatikko: komponentin toteutus on tarkasteltavissa, mutta ei muutettavissa Komponentin sopeuttamisen tulisi olla läpinäkyvää, tapahtua konfiguroimalla ja olla uudelleenkäytettävä, käsitellä komponenttia mustana laatikkona sekä olla yhteydessä muihin sopeuttamistekniikoihin. Mikään perinteinen sopeuttamismenetelmä ei täytä kaikkia vaatimuksia. Oliopohjaisessa suunnittelussa ja ohjelmoinnissa käytettävät luokat on myös erotettava käsitteellisesti komponenteista. Komponentin sisäinen toteutus voi perustua luokkiin, mutta asia on sinänsä merkityksetön, koska palvelun toteutus voi yhtä hyvin perustua proseduraalisiin ohjelmointikieliin tai vaikka sanomapohjaiseen kyselyyn toisesta järjestelmästä. Luokka edustaa loogista abstraktiota komponentti edustaa fyysistä asiaa, joka toimii jollakin suorittimella verkossa. Luokkien tarjoamat palvelut ovat metodeja. Mallintamisessa eräs käytetty sääntö kuuluu: jos mallintamisen kohde on jossakin verkon solmussa, käytä komponenttia - muuten käytä luokkaa. Oliot (ks. myös sanasto) ovat luokkien esiintymiä (instance, instanssi). Yhdellä luokalla voi yleensä olla useita esiintymiä. Mallinnuksessa komponentit edustavat usein luokkien fyysistä pakkausta. Luokilla voi olla attribuutteja ja metodeja, kun taas komponenteilla on vain operaatioita, jotka ovat vain niiden liittymien kautta käytettävissä. Komponentin liittymän operaatiot voi esim. toteuttaa jokin luokka omissa metodeissaan. Luokkien suunnittelu sekä oliopohjaisilla menetelmillä tapahtuva toteutus ovat erittäin käyttökelpoisia menetelmiä komponenttipohjaisessa ohjelmistotuotannossa. Komponenttien yhteydessä käytetään usein juuri tietyn tyyppisiä luokkia, joihin palataan luvussa Tietojärjestelmän hajauttamisella voidaan mallintaa eri kohteissa sijaitsevien yksiköiden toimintoja tietojärjestelmässä. Kun organisaation toiminta on hajautettua, on luontevaa toteuttaa myös tietojärjestelmät hajautettuina. Hajautuksen perusteena on usein parempi laitekapasiteetin ja prosessointitehon hyödyntäminen, ja se, että voidaan valita sopivimmat työkalut kunkin järjestelmän osan toteuttamiseen. Järjestelmien kuormaa voidaan tasata eri laitteiden kesken hajautuksen ansiosta. Myös käyttö hajautuu luontevasti hajautetuissa järjestelmissä, koska hajautettujen komponenttien palvelut ovat verkkokäyttöisiä. Tietojärjestelmän arkkitehtuuri määrittelee järjestelmän osat sekä osien väliset suhteet (Bass ym. 1999). Arkkitehtuuri on järjestelmän abstraktio ja yleiskuva, joka piilottaa suuren osan toteutuksen yksityiskohdista. Järjestelmät voivat kuitenkin sisältää useampia kuin yhden niitä kuvaavan rakenteen, joita kutakin voidaan esitellä omana arkkitehtuurinaan. Onkin syytä tarkentaa, millaista arkkitehtuuria kulloinkin tarkoitetaan. Tässä dokumentissa nähtäviä arkkitehtuurityyppejä ovat: Hajautusarkkitehtuuri, joka kuvaa järjestelmän osien hajautuksen eri koneille verkossa, eli järjestelmän kerrokset (tiers). Tässä dokumentissa esitettävä nelikerroksinen viitearkkitehtuuri on looginen hajautusarkkitehtuuri, joka ei sido lopullisesti eri asioita hoitavia kerroksia nimetyille koneille, vaan esittää loogiset kerrokset, jotka vastaavat järjestelmän jonkin osan toteuttamisesta. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

17 KOMPONENTTIPOHJAINEN JÄRJESTELMÄTUOTANTO 17 Toiminnallinen arkkitehtuuri, joka kuvaa järjestelmän toiminnallisia osia ja niiden suhteita. Toiminnallisessa arkkitehtuurissa eivät näy järjestelmän hajautus eivätkä tekniset yksityiskohdat. Tekninen arkkitehtuuri, joka voi olla yhdistetty hajautusarkkitehtuuriin. Tekninen arkkitehtuuri on usein yksityiskohtainen, suoraan järjestelmän toteutusta tukeva arkkitehtuuri, jossa voivat näkyä esim. komponenttien sisäiseen toteutukseen kuuluvat luokat. Tässä selvityksessä käytetään eri merkityksessä termejä transaktio ja tapahtuma. Transaktio (transaction) (Whatis 2000) on sekvenssi, johon liittyy tietojen vaihtoa ja prosessointia, kuten tietokantaan tallennus. Koko transaktiota käsitellään yhtenä yksikkönä, joko toteutuu joko kokonaan tai ei ollenkaan (ks. myös luku 14.2, transaktiopalvelu). Tapahtuma (event) (Webopedia 2000) on ohjelmoinnissa käytettävä mekanismi, jossa ohjelmisto havaitsee jonkin toimenpiteen tai esiintymisen. Tapahtuma voi olla esim. käyttäjän tekemä (napin painaminen, hiiren liikuttaminen) tai järjestelmälähtöinen (muistin loppuminen, viestin saapuminen). Useimmat nykyaikaiset sovellukset, kuten graafiset käyttöjärjestelmät ovat tapahtumapohjaisia (event-driven), koska ne on suunniteltu nimen omaisesti vastaamaan erilaisiin tapahtumiin. Operaatio on tässä selvityksessä komponenttiliittymässä tarjottava palvelu. Metodi on olio-ohjelmointikielellä toteutetun luokan palvelu. Aktiviteetti on jokin luokkaan, komponenttiin tai työhön liittyvä toiminto. Työhön liittyvät aktiviteetit (esim. tilauksen lisääminen) voivat muodostaa työprosesseja (esim. tilauksen käsittely), joista puolestaan muodostuvat (liike)toimintaprosessit (esim. asiakaspalvelu). 2.2 Sovellustuotannon tarpeet ja komponenttien lupaukset Sovellustuotannon keskeisiä tarpeita, joihin pyritään vastaamaan komponenttipohjaisilla menetelmillä ovat mm.: järjestelmien uudelleenkäytettävyys helpottuu parantaen ohjelmistotyön tuottavuutta, vähentäen kahdennettua tietoa ja operaatioita, tarjoten yhdenmukaisia palveluita ja mahdollistaen jo tehdyn työn hyväksikäytön, kun sovellukset kootaan joko itse tehdyistä tai valmiina ostetuista komponenteista, heterogeenisten ratkaisujen tuki, suurten ja monimuotoisten laite- ja käyttöjärjestelmäympäristöjen hyväksikäyttö sekä eri tekniikoilla tehtyjen sovellusten integrointi, komponenttimarkkinoiden synty, joka mahdollistaa valmiiden, organisaation sovellustarpeita vastaavien komponenttien hankkimisen ulkopuolelta, vaihtoehtoisten toteutusten vertailun ja sopivimman valinnan, tai komponenttien tuottamisessa erilaiset markkinastrategiat yrityksen koosta tai toimintatavasta riippuen, laajojen järjestelmien hallinta; järjestelmät sisältävät yhä enemmän toimintoja, niillä on yhä enemmän käyttäjiä ja skaalattavuustarpeet ovat entistä tärkeämpiä ja järjestelmien kyky sopeutua nopeasti sekä toiminnallisiin että teknisiin muutoksiin. Komponenttitekniikoihin sisältyviä keinoja ja komponenttipohjaisessa sovellustuotannossa yleisesti käytettyjä menetelmiä ovat: komponenttiliittymät ja kapselointi (ks. luku 2.1), järjestelmien hajautus ja monitasoarkkitehtuurit (ks. luku 6), Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

18 18 OSA I: Perusteet komponenttien rakentaminen erillään sovelluksen rakentamisesta (ks. luku 3.2), suunnittelumallien, sovelluskehysten ja standardien runsas käyttö (ks. esim. luku 7.2) ja toimintaprosesseihin perustuva järjestelmän suunnittelu (ks. luku 7). Kuva 1 ja taulukko 1 sittelevät komponenttipohjaisen sovellustuotannon lupauksia ja menetelmiä suhteessa keskeisiin tarpeisiin joihin sen odotetaan vastaavan. A. Uudelleenkäytettävyys -olemassaolevan kapselointi -päällekkäisyyksien vähentäminen -yhtenäisten palvelujen tarjoaminen -ohjelmistotyön tuottavuus B. Heterogeenisten ratkaisujen tukeminen -erilaisia käyttöjärjestelmiä, käyttöliittymiä, palvelimia -eri tekniikoilla tehtyjä sovelluksia C. Komponenttimarkkinat -mahdollisuus myydä ja hankkia valmiita, testattuja osia -mahdollisuus valita itselle sopivin D. Laajojen järjestelmien hallittavuus -suuria toiminnallisuuskokonaisuuksia -paljon yhtäaikaista käyttöä -skaalautuvuus E. Muutoksiin varautuminen ja nopea sopeutuminen -toimintaprosessien ja palveluketjujen muutoksiin -tekniikan muutoksiin 1. Liittymät, kapselointi 2. Järjestelmien hajautus + monitasoarkkitehtuurit 3. Komponenttien rakentaminen erillään sovelluksen kokoamisesta 4. Valmiiden komponenttien, kehysten ja mallien uudelleenkäyttö 5. Toimintaprosessilähtöinen suunnittelu Kuva 1. Komponenttituotannon tarpeiden ja sen lupausten sekä menetelmien suhteet Kuvasta nähdään, että monet komponenttipohjaisen sovellustuotannon lupaukset ja menetelmät tukevat tarpeiden täyttämistä. Taulukossa 1 on esitetty kuvan hyötyjen (suhteiden) perustelut siten, että kirjain tarkoittaa kuvan yläosassa esitettyä tarvetta, numero komponenttipohjaisen ohjelmistotuotannon lupausta tai menetelmää. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

19 KOMPONENTTIPOHJAINEN JÄRJESTELMÄTUOTANTO 19 Liittymät, kapselointi Hajautus ja monitasoarkkitehtuurit Taulukko 1. Komponenttipohjaisen ohjelmistotuotannon menetelmien potentiaaliset hyödyt Suhde Hyödyn perustelu Selkeät komponenttiliittymät, joiden taakse toteutus kapseloidaan, mahdollistavat sekä vanhojen järjestelmien uudelleenkäytön että samojen peruspalvelujen rakentamisen eri järjestelmiin. Yhtenäisten ja yleiskäyttöisten liittymien avulla voidaan vähentää eri järjestelmien päällekkäistä toiminnallisuutta ja lisätä sovellustyön tuottavuutta, koska uudelleenkäyttö mahdollistuu. 1-A: Uudelleenkäyttö 1-B: Tuki heterogeenisyydelle 1-C: Komponenttimarkkinat 1-D: Hallittavuus 1-E: Muutoksiin varautuminen 2-A: Uudelleenkäyttö 2-B: Tuki heterogeenisyydelle 2-D: Hallittavuus 2-E: Muutoksiin varautuminen Komponenttiliittymät mahdollistavat sopivan järjestelmäympäristön tai toteutusteknologian valinnan kunkin komponentin tai kerroksen toteuttamiselle. Komponenttimallit tukevat yleensä useita erilaisia laite- ja käyttöjärjestelmäympäristöjä sekä palvelimilla että työasemilla. Komponenttimarkkinoiden kehittymisen perusedellytys ovat yleiset, yhä enemmän standardoidut liittymät, jotka varmistavat, että komponenttien tarvitsijat tietävät mitä saavat myös tilatessaan komponentteja ulkopuolisilta toimittajilta. Varsinkin suurissa järjestelmissä komponenttiliittymien avulla tapahtuva järjestelmän jakaminen loogisiin ja hallittavan kokoisiin osakokonaisuuksiin helpottaa kokonaisjärjestelmän hallintaa. Järjestelmä voidaan suunnitella, toteuttaa ja testata hallittavan kokoisina osina, jopa hajautetusti, joskin integrointitestaus voi vaikeutua, jos komponentin lopullista käyttöympäristöä ei tunneta. Toteutuksen kapselointi komponenttiliittymän taa mahdollistaa operaatioiden toteutuksen muuttamisen sen käyttäjiin vaikuttamatta, mikäli liittymä säilyy ennallaan. Jos joskus on tarpeen esim. vaihtaa komponenttimallia, on samat liittymät yleensä mahdollista toteuttaa vaihtoehtoisella komponenttitekniikalla. Lisäjoustavuutta saavutetaan liittymien versioinnilla, tai merkatun datan (esim. XML) käytöllä liittymissä. Järjestelmän monitasoisuus mahdollistaa järjestelmän uusimisen kerroksittain siten, että aiemmin toteutetut kerrokset, esim. vanha tietokanta voidaan säilyttää. Jos kerroksille toteutetaan yleiskäyttöiset liittymät, voidaan nämä kerrokset korvata myöhemmin toiseen toteutustekniikkaan perustuvilla kerroksilla ilman vaikutuksia muihin kerroksiin. Sovelluksia voidaan uusia vähitellen. Järjestelmän hajautus perustuu heterogeenisyyteen: eri tehtäviä ja tasoja hoitavat eri tasoiset laitteet ja ympäristöt, joiden ominaisuudet sopivat kunkin tehtävän hoitamiseen. Esimerkiksi runsaasti laskentaa vaativia tehtäviä ei kannata yleensä suorittaa käyttäjän työasemalla, vaan ne on järkevää sijoittaa tarkoitukseen sopivalle palvelimelle. Vaikka järjestelmän hajautus yleensä lisääkin järjestelmän monimutkaisuutta, hajautusta tarvitaan nimen omaan suurissa järjestelmissä, joissa skaalattavuus on usein järjestelmän elinehto ja myös toiminta on hajautettua. Kun järjestelmän infrastruktuuri ottaa vastuulleen yhä enemmän suurten järjestelmien tarvitsemia palveluita, sisältää se myös työkalut palveluiden hallintaan vapauttaen järjestelmän suunnittelijat suunnittelemaan itse sovelluksia. Järjestelmien hajautuksella voidaan tekniset muutokset eristää koskemaan vain tiettyä osaa järjestelmästä. Suuret toiminnalliset muutokset sen sijaan voivat vaikuttaa järjestelmän useisiin osiin. Tällöin hajautus ja joustavat komponenttiliittymät tukevat eri osien uudelleenjakelua vain, jos ne on alun perin suunniteltu riittävän joustaviksi, esim. käyttöliittymäkerros voi jopa sopeutua automaattisesti alemmissa kerroksissa tapahtuviin muutoksiin. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

20 20 OSA I: Perusteet Komponenttien rakentaminen erillään sovelluksen kokoamisesta Suunnittelumallit, sovelluskehykset ja standardit 3-A: Uudelleenkäyttö 3-B: Tuki heterogeenisyydelle 3-C: Komponenttimarkkinat 3-D: Hallittavuus 3-E: Muutoksiin varautuminen 4-A: Uudelleenkäyttö 4-B: Tuki heterogeenisyydelle 4-C: Komponenttimarkkinat 4-D: Hallittavuus 4-E: Muutoksiin varautuminen Komponenttien rakentaminen itsenäisiksi ja omista operaatioistaan vastaaviksi yksiköiksi, joilla on selvästi määritellyt riippuvuudet on edellytys uudelleenkäytölle. Suunnitteluvaiheessa käytetään yleistämistä uudelleenkäytettävyyden parantamiseksi. Yleistämiseen ja yleisten piirteiden etsimiseen on kuitenkin panostettava. Komponentteja voidaan käyttää piilottamaan olemassa olevien järjestelmien toteutusten tai alustavaatimusten erot, jolloin eri tekniikoilla toteutettujen järjestelmien integrointi helpottuu. Komponenttimarkkinoiden saavuttamiseksi komponenttien ja sovellusten rakentaminen on erotettava toisistaan. Komponenttimarkkinat kehittyvät hienojakoisista komponenteista kohti yhä suuremman toiminnallisuuden toteuttavia komponentteja. Eri komponenttien tarkasti määriteltyjen vastuiden erottaminen koko järjestelmän osatoiminnoiksi helpottaa suurten järjestelmien modulaarista suunnittelua ja toteutusta. Komponentin toteuttaja voi toteuttaa vaadittavan liittymän mukaiset palvelut haluamallaan toteutustekniikalla. Itsenäiset komponentit, joilla on määritellyt riippuvuudet on helpompaa toteuttaa uudelleen tarvittaessa, esim. tekniikan tai toimintaympäristön muuttuessa kuin monoliittiset sovellukset. Komponentin liittymä voi jopa piilottaa pienet muutokset lisäten kokonaisjärjestelmän joustavuutta. Suunnittelumallit ja sovelluskehykset ovat sinällään uudelleenkäytettäviä. Suunnittelumalleja käytetään vähentämään järjestelmän osien riippuvuuksia. Standardeja käyttämällä varmistetaan komponenttien uudelleenkäytettävyys esim. eri alustoilla, ja toiminnallisia standardeja käyttämällä voidaan siirtyä eri sovelluksissa käytettävien yleisten palvelujen käyttöön. Suunnittelumallit ja liittymästandardit ovat yleensä sovellettavissa hyvin erilaisiin ympäristöihin. Myös sovelluskehykset voidaan suunnitella tukemaan useita erilaisia ympäristöjä yleisiä standardeja käyttämällä. Standardien on kuitenkin oltava järkeviä, joustavia ja käytännöllisiä. Sovelluskehykset ovat erittäin käyttökelpoisia komponenttimarkkinoiden kehittymisessä. Erityisesti prosessikehysten yleisiin määrittelyihin voidaan suoraan rakentaa komponentteja, jotka täyttävät tietyn prosessin osan toiminnallisuustarpeet. Komponenttimarkkinoille pohjan muodostaa alemman tason standardien käyttö. Suurten järjestelmien hallitsemisessa on hyötyä selkeistä sovelluskehyksistä tietty järjestelmän osa toimii kehyksessä määritellyllä, yhtenäisellä tavalla. Myös järjestelmien standardin mukaisuus voidaan yleensä varmistaa, mikä lisää luottamusta järjestelmän hallittavuuteen. Yleisten suunnittelumallien ja sovelluskehysten käyttö lisää järjestelmän joustavuutta ja ymmärrettävyyttä, mistä on hyötyä sekä teknisissä että toiminnallisissa muutoksissa. Standardien käyttö teknisissä toteutuksissa voi mahdollistaa toteutuksessa käytettyjen tuotteiden vaihtamisen tarvittaessa. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

21 KOMPONENTTIPOHJAINEN JÄRJESTELMÄTUOTANTO 21 Toimintaprosessilähtöinen järjestelmän suunnittelu 5-A: Uudelleenkäyttö C-5: Komponenttimarkkinat 5-D: Hallittavuus 5-E: Muutoksiin varautuminen Toimintaprosessilähtöisessä suunnittelussa tunnistettuja kokonaisuuksia käytetään uudelleenkäytettävien, suhteellisen muuttumattomien osien tunnistamiseen. Nämä osat kannattaa toteuttaa komponentteina. Hyvin määritellyt toimintaprosessit mahdollistavat komponenttimarkkinoiden syntymisen. Jos toimintaprosesseista on saavutettu tarkka sopimus, voidaan komponenttien toteuttaminen hajauttaa tai etsiä sopivia komponentteja osaprosessien toteuttamiseen. Varsinkin analyysi- ja suunnitteluvaiheessa toimintaprosessilähtöinen suunnittelu auttaa suunnittelijoita hahmottamaan, rajaamaan ja hallitsemaan järjestelmää ja sen toimintaympäristöä. Dokumentoidut prosessit muodostavat järjestelmän kehittäjien ja käyttäjien välille yhteisen kielen. Prosesseja tutkimalla ja tarkentamalla erotetaan kriittisimmät osat ja ne osat, jotka on järkevää toteuttaa erillisinä. Järjestelmästä voidaan rakentaa erittäin mukautuva, jos saatavilla on mekanismi jolla ulkoistetaan tai muokataan helposti järjestelmän toimintaa ohjaavia prosesseja. Ymmärrettävät, tarkat ja dokumentoidut toimintaprosessit ovat tärkeitä suunniteltaessa toiminnallisia muutoksia järjestelmään esim. toimintaympäristön muuttuessa, mutta myös muutosten dokumentoinnista on huolehdittava. Luonnollisesti komponenttipohjaisen sovellustuotannon kaikki menetelmät eivät paranna kaikkien tarpeiden täyttymistä. Seuraavaksi on lueteltu jäljelle jääviä ongelmia, joihin komponenttipohjainen sovellustuotanto ei tarjoa riittäviä mahdollisuuksia pureutua: Järjestelmien hajautus lisää niiden monimutkaisuutta ja osallistuvien ohjelmistojen määrää, jolloin vikojen paikallistaminen voi vaikeutua. Yhdenmukaisten hallinta- ja jakelumekanismien puuttuessa joudutaan usein tukeutumaan tuotekohtaisiin mekanismeihin, ja järjestelmäympäristön heterogeenisyys vaikeuttaa varsinkin suurikokoisten komponenttien markkinoiden syntymistä. Ei riitä, että komponenttien riippuvuudet muista komponenteista on määritelty: on oltava myös keino varmistaa komponentin sopivuus tai vaadittavat toimenpiteet sen sopeuttamiseksi asiakasorganisaation olemassa olevaan järjestelmäympäristöön. Komponenttipohjaisen järjestelmän pitkäaikaisessa hallinnassa ja kehityksessä syntyy uusia vaatimuksia myös laadunvarmistukseen, konfiguroinnin hallintaan, toimittajien tietämyksen säilyttämiseen ja päivitysten vaikutusten arviointiin. Suuret toiminnalliset tai tekniset muutokset asettavat arkkitehtuurin ja jakeluvälineiden joustavuuden koetukselle, mikä tosin vastaa tilannetta myös ei-hajautetuissa tai perinteisemmissä sovelluksissa, mutta järjestelmän laajuus, kerroksellisuus ja monimutkaisuus aiheuttavat näihin ongelmiin helposti kerrannaisvaikutuksen. Perinnejärjestelmät sisältävät usein suuren määrän organisaatiolle arvokasta tietoa ja toiminnallisuutta, jonka kuvaamiseen toimintaprosessilähtöinen suunnittelu ei suoraan sovi. Suunnittelumenetelmät ovat uuden järjestelmän rakentamiseen orientoituneita, ja on vaikea erottaa vanhojen järjestelmien aiheuttamat häiriöt prosessien uudelleensuunnittelussa niistä piirteistä, jotka ovat vanhoissa järjestelmissä säilyttämisen arvoisia. Komponenttien saatavuus itsenäisinä tuotteina ei varmista sitä, että ne ovat laajasti testattuja ja riittävästi dokumentoituja. Komponenttien evaluoinnin ja testauksen on oltava kiinteä osa Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

22 22 OSA I: Perusteet komponenttipohjaisten sovellusten rakentamista. Komponentit rakennetaan yleensä juuri tiettyä kompositiota varten, jolloin on huolehdittava integrointitestauksesta hankinnan yhteydessä, kun komponentti otetaan uudenlaiseen käyttöyhteyteen. Komponenttien integroitavuuteen vaikuttavat komponenttien määriteltyjen riippuvuuksien lisäksi sekä myyjän että ostajan dokumentointi- ja evaluointitavat ja näiden välillä toisistaan poikkeavat arkkitehtuurilliset vaatimukset. Komponenttiteknologioiden nopea kehitys pakottaa väline- ja infrastruktuurikehittäjät keskittymään vain muutamiin tuettuihin ympäristöihin ja standardien versioihin. Tuotekeskeiset ratkaisut ja standardoinnin puute joillakin alueilla, kuten laadunvarmistuksessa ja järjestelmien hallinnassa vaikeuttavat organisaation laajuista keskitettyä sovellusten hallintaa. Komponenttien soveltuvuuden arviointi on ensisijaisen tärkeää. Soveltuvuus käyttöön saavutetaan, jos hankittava tai valmistettava komponentti vastaa riittävästi lopullisessa toimintaympäristössä tarvittavaa kokonaisuutta. Tietyssä ympäristössä toimivan komponentin soveltuvuus toiseen ympäristöön on aina varmistettava. On myös huomattava, että kuvassa 1 numeroilla esitetyt menetelmät ja lupaukset eivät toteudu automaattisesti komponenttitekniikoita käytettäessä, vaan arkkitehtuuri ja sovellustuotanto on suunniteltava siten, että komponenttien lupauksilla on toteutumisen edellytykset. Organisaation toimintamalli on määrätynlainen juuri tietyllä hetkellä, mutta monet toiminnalliset vaatimukset tietojärjestelmille ovat geneerisiä ja toimialariippumattomia (Devos, Tilman 1999). Näitä toiminnallisia vaatimuksia ovat mm. tietojen syöttö, haku ja käyttö, raportointi ja dokumenttienhallinta. Organisaatiossa tarvittavien järjestelmien rakentamiseksi on välttämätöntä mallintaa organisaation toimintaa ja toimialan käsitteistöä ja toimintaprosesseja, mutta sovellusten tehokkaan toteuttamisen saavuttamiseksi geneerisiin osiin voidaan kehittää tuottavuusvälineitä. 2.3 Ohjelmistoteollisuuden kehitysnäkymät Suomen ohjelmistoteollisuuden kehityssuunnista tehdyssä selvityksessä Nukari ja Forsell (1999) kartoittivat todennäköisesti toteutuvia trendejä. Alan trendit luokiteltiin markkinoinnin, myynnin ja jakelun, teknologian, rahoituksen, henkilöstön ja muiden tekijöiden näkökulmista. Trendit noudattavat hyvinkin tarkasti maailmanlaajuisia kehitysnäkymiä 1 (Booch 2000). Seuraavassa esitellään lyhyesti keskeisimmät trendit koostettuina näistä lähteistä. Ohjelmistotuotemarkkinat ovat globalisoitumassa, ja uusia markkinoita avautuu myös kansainvälisesti. Kuluttajamarkkinoiden merkitys kasvaa, ohjelmistojen tuotteistaminen lisääntyy ja tuotteiden valmistuminen nopeutuu. Kansainvälisten yhteistyöliittymien ja Internetin merkitys kasvavat; samalla kuitenkin myös sovellusten paikallistamisen merkitys kasvaa. Teknologian trendejä ovat laitteistojen kapasiteetin ja määrän jatkuva kasvu, tietoverkkojen merkityksen huima lisääntyminen, ohjelmistokomponenttien ja langattomien sovellusten merkityksen lisääntyminen ja tietojenkäsittelyn hajautuminen. Kehittämisalueita ovat tiedon haku ja hallinta, käyttäjäkeskeisyys ja helppokäyttöisyys sekä uudet verkko-orientoituneet toimintamallit ja arkki- 1 Grady Boochin tekemään kyselyyn ohjelmistotuotannon tulevaisuuden näkymistä vastasi n. 100 kansainvälisten suunnittelu-, väitöskirja- ja ohjelmistopalkintojen saajaa, yritysten johtavaa tutkijaa ja teknistä johtajaa. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

23 KOMPONENTTIPOHJAINEN JÄRJESTELMÄTUOTANTO 23 tehtuurit. Ohjelmistojen elinkaari lyhenee, ja kehitystyöstä tulee jatkuvaluonteista. Samalla ohjelmistot monimutkaistuvat entisestään toiminnallisuuden ja koon kasvaessa. Ohjelmistotuotannossa pyritään löytämään tasapaino nopean toteuttamisen ja huolellisen suunnittelun välillä, mutta yleisesti ottaen kevyet ja hyvin omaksuttavat metodologiat voittavat raskaat ja kaikenkattavat. Henkilöstöpula on maailmanlaajuinen ilmiö ohjelmistoalalla, ja tuotekehitysosastot kasvavat maissa, joissa koulutettua työvoimaa on saatavilla. Hajautettu sovellustuotanto ja virtuaaliset tiimit, joissa on toimialan osaajia, tulevat mukaan tuotteiden kehittämiseen. Ohjelmistotuotannon osaamisen tehtäväkentät hajautuvat, ja ohjelmistoinsinöörien tehtävänä on yksinkertaistaa ja helpottaa ohjelmistojen koostajien työtä. Rahoituksellisia kehitysnäkymiä ovat ohjelmistoyritysten omistuksen kansainvälistyminen ja pääomarahoituksen, yhteissijoitusten, alkuvaiheen rahoituksen ja tuotekehitysrahoituksen lisääntyminen. Ohjelmistovalinta tapahtuu ennen laitteiden valintaa tietojenkäsittelykonseptia uusittaessa, ja ohjelmistoteollisuus organisoituu uudelleen nopeaan tahtiin tapahtuvien yritysostojen kautta. 2.4 Miksi komponentteja terveydenhuoltoon? Edellisessä luvussa esitetyistä sovellustuotannon keskeisistä tarpeista terveydenhuollon sovelluksissa korostuvat olemassa olevien järjestelmien hyödyntäminen, heterogeeniset ympäristöt, järjestelmien suuresta koosta ja määrästä johtuvat hallintaongelmat sekä toiminnallisiin ja teknisiin muutoksiin varautuminen. Terveydenhuollon perinnejärjestelmät, mukaan lukien Musti-tekniikkaan pohjautuvat järjestelmät, sisältävät suuret määrät toimialan tietoa ja tietämystä, jonka uudelleen rakentaminen ja koodaaminen alusta lähtien on riskialtista ja epätaloudellista. Kehittäjä- ja käyttäjäorganisaatioissa on myös olemassa olevaa vanhojen tekniikoiden ja käytäntöjen osaamista, jonka hyödyntäminen järjestelmien kehittyessä on hyödyllistä. Terveydenhuollon järjestelmiä on hankittu jopa samoihin yksiköihin siten, että eri järjestelmät vaativat erilaista infrastruktuuria, eli erilaisia käyttöjärjestelmä-, ohjelmisto- ja laitealustoja. Tuloksena on syntynyt heterogeeninen järjestelmäympäristö, jossa eri tekniikoilla toteutettujen järjestelmien yhteistoiminnan parantaminen on kallista ja vaikeaa, koska järjestelmät joko eivät tarjoa yhteistoiminnallisuuden rajapintoja, tai rajapinnat ovat eri tasoilla (ks. integrointitasot, luku 12.1). Terveydenhuollossa on alettu kehittää entistä enemmän huomiota toimintaprosessien määrittelemiseen siten, että asiakkaan näkökulmasta palveluketjut saadaan mahdollisimman saumattomiksi (ks. myös luku 16.1). Toimintaprosessien uudelleenmäärittely ja systematisointi johtaa toiminnallisiin muutoksiin, joihin mukautuminen monoliittisissa sovelluksissa on vaikeaa ja hidasta sovelluksiin kiinteästi koodattujen toimintaprosessien ja mukauttamismekanismien puutteen vuoksi. Myös uudet teknologiat tarjoavat houkuttelevia mahdollisuuksia järjestelmien integrointiin ja asiakkaan osallistumisen parantamiseen. Terveydenhuollon toimiala on varsin monimutkainen eikä kaiken kattavaa, yleisesti käytettyä toimialan mallia ole saatavilla 2. Eri järjestelmät kattavat usein tarkasti jonkin pienen osa-alueen toteu- 2 USA:n HL7-yhdistyksen kehittämä HL7 RIM (Reference Information Model) pyrkii kuvaamaan terveydenhuollon toimialan käsitteet sekä niiden väliset suhteet. Mallia käytetään HL7-standardin version 3 sanomien muodostamiseen karsimalla kuhunkin sanomaan vain mukaan tarvittavat osat. Malli on kuitenkin suunniteltu lähinnä Yhdysvaltain terveydenhuoltojärjestelmää silmällä pitäen, eikä sen paikallistamiseen Suomen oloihin olla toistaiseksi ryhtymässä. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

24 24 OSA I: Perusteet tuksen, mutta kokonaisjärjestelmän hallinta ja hahmottaminen on vaativa tehtävä. Kun järjestelmiltä vaaditaan yhä suurempaa avoimuutta ja yhteentoimivuutta, myös järjestelmien kuormituksenkestoja skaalautuvuusvaatimukset nousevat tärkeään asemaan. Myös järjestelmien koko kasvaa, ja eri järjestelmissä käsitellään usein samoja tieto- ja toimintokokonaisuuksia. Hajautettuja komponentteja on menestyksekkäästi käytetty teollisuuden ohjelmistoissa. Teollisuudessa ohjelmistot on kuitenkin yleensä rajattu hyvin selvästi, eikä niillä ole yleensä ollut yhtä laajoja integroituvuusvaatimuksia kuin terveydenhuollon sovelluksilla. Viime aikoina komponenttipohjaiset järjestelmät ovat saaneet yhä suuremman jalansijan suurten hajautettujen organisaatioiden hallinnollisten ja toiminnallisten järjestelmien toteutuksissa. Eräänä syynä tähän kehitykseen on se, että ne mahdollistavat olemassa olevien järjestelmien hyödyntämisen kokonaisuutta edelleen kehitettäessä. Terveydenhuollon organisaatioille komponenttien käytön puolesta puhuvat mm. seuraavat seikat: Terveydenhuollon tietojärjestelmien integrointitarpeet: potilashallinnon, hoidon, yleis- ja taloushallinnon sekä päätöksenteon tuen ja diagnosoinnin järjestelmät vaativat yhä enemmän ja yhä toiminnallisempaa yhteistoimintaa paitsi keskenään, myös ulkoisten yhteistyökumppanien järjestelmien kanssa. Erillisten, suurten ja monoliittisten sovellustuotteiden sovittaminen ja mukauttaminen uudelleen suunniteltaviin toimintaprosesseihin on vaikeaa. Organisaation sisäiset eri sovellusten yhteiset tarpeet, kuten osasto- ja sovellusrajat ylittävien toimintoprosessien hallinta, yhdessä paikassa määritellyt käyttöoikeudet, kerralla tapahtuva kirjautuminen eri järjestelmiin ja yhteisten termistöjen ja koodistojen käyttö on erittäin vaikeaa integroida erillisiin monoliittisiin sovelluksiin. Olemassa oleviin ja perinnejärjestelmiin sitoutunutta osaamista, tietoa ja toiminnallisuutta voidaan käyttää edelleen järjestelmiä uusittaessa. Vanhojen järjestelmien kertakaikkisen korvaamisen sijaan voidaan niiden pohjalle rakentaa uutta järjestelmää siten, että järjestelmän uusiminen tapahtuu osa kerrallaan. Terveydenhuollon tietojärjestelmien vaatimusten yhteiset piirteet organisaation, alueen, valtakunnan ja eri maiden tasolla mahdollistavat ainakin samojen kehysratkaisuiden ja standardien käytön. Sovellusten rakentajille komponenttitekniikoiden etuja ovat: Sovellusten jakaminen erillisiin, itsenäisiin moduuleihin helpottaa yksittäisten osien toteuttamista, muutoksiin varautumista, hajautettua kehitystyötä ja nopeaa koostamista. Tuotteet ovat paremmin kohdistettavissa ja muunnettavissa eri asiakkaiden tarpeita vastaaviksi. Olemassa olevien tuotteiden käyttökelpoiset piirteet voidaan säilyttää uusissa tuotteissa kapseloimalla vanhoja toteutuksia uudelleenkäytettäviksi komponenteiksi. Vanhan tekniikan osaaminen säilyy osana uudenkin järjestelmän toteutusta. Järjestelmän eri osiin voidaan tarjota vaihtoehtoisilla tekniikoilla tehtyjä toteutuksia. Arkkitehtuurilähtöinen sovelluskehitys helpottaa tuoteperheiden kehittämistä. On tietenkin selvää, että komponenttipohjaiset menetelmät eivät ole ainoa mahdollisuus järjestelmien väliseen integrointiin tai hajautettujen sovellusten rakentamiseen, vaan olemassa olevat sanomapohjaiset integraatioratkaisut ja kaksitasoiseen asiakas-palvelin-arkkitehtuuriin perustuvat järjestelmät tulevat säilymään ja ovat edelleen käyttökelpoisia monissa sovelluskohteissa. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

25 OHJELMISTOTUOTANTOPROSESSI 25 3 OHJELMISTOTUOTANTOPROSESSI 3.1 Prosessin vaiheet ja vaihtoehdot Tietojärjestelmien tuotantoprosessissa käydään läpi seuraavia vaiheita, jotka eivät ole pelkästään peräkkäisiä: Vaatimusmäärittely vaatimusmäärittelyt (requirements engineering), analyysi (systems analysis), suunnittelu (systems design), Analyysi Suunnittelu toteutus (systems implementation), Toteutus koodin ja moduulien testaus, Koodi- ja moduulitestaus integrointi- ja hyväksymistestaus sekä käyttöönotto ja ylläpito. On esitetty runsaasti erilaisia ohjelmistojen elinkaarimalleja Integrointitestaus Hyväksymistestaus (OMG 1998, Shroff 1999), joissa kuitenkin esiintyvät yleensä edellä luetellut vaiheet. Vesiputousmallissa (kuva 2) eri vaiheet käydään läpi peräkkäisessä Ylläpito Kuva 2. Vesiputousmalli järjestyksessä, ja vaiheesta Toimiala toiseen siirrytään tietyn hyväksymiskriteeristön Laadunvarmistus Ylläpito täyttyessä. V-malli (kuva 3) muistuttaa vesiputousmallia, Vaatimusmäärittely Hyväksymistestaus mutta korostaa testauk- sen merkitystä: kunkin toteutus- ja integrointivaiheen tuotoksia verrataan suunnittelu- ja vaatimusdokumentteihin. Analyysi Suunnittelu Integrointitestaus Koodi- ja moduulitestaus V-mallissa voidaan Tekninen toteutus Toteutus myös helposti esittää raja sovelluksen Kuva 3. V-malli toimialan analyysin ja tek- nisen toteuttamisen välillä. Protoilumalli on kuin vesiputousmalli, jossa käydään vesiputous nopeasti läpi tuottaen prototyyppejä, joita arvioimalla luodaan vaatimukset Vaatimusmäärittely Analyysi Suunnittelu Suunnittelu Toteutus Toteutus Testaus Testaus Käyttöönotto Käyttöönotto Versio 1 Versio 2 seuraavalle Suunnittelu Toteutus Testaus Käyttöönotto Versio 3 prototyypin versiolle tai pyritään todistamaan Kuva 4. Inkrementaalinen kehittäminen teknologian käy- Laadunvarmistus Integrointi Toteuttaminen Ylläpito Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

26 26 OSA I: Perusteet tettävyys. Prototyyppejä toistuvasti kehittämällä toteutetaan lopulta vaatimusten mukainen järjestelmä. Inkrementaalinen kehittäminen (kuva 4) perustuu siihen, että ohjelmistoa kehitetään vaiheissa, joissa kukin vaihe lisää järjestelmään uutta toiminnallisuutta. Jokaisen vaiheen osina ovat kehitys (suunnittelu ja toteutus), koodi- ja moduulitestaus, integrointitestaus ja jakelu. Mallin etuina ovat (osa)ohjelmiston nopea toteutus asiakkaalle ja edistymisen helppo seuraaminen. Inkrementaalinen kehittäminen vaatii kuitenkin huolellista suunnittelua ja projektinhallintaa. Inkrementaalinen kehittäminen sopii hyvin komponenttipohjaiseen lähestymistapaan, jossa komponentit toteuttavat osia lopullisen järjestelmän toiminnallisuudesta. Spiraalimalli (kuva 5) on riskilähtöinen elinkaarimalli: kukin spiraalin kierros pyrkii vastaamaan tunnistettuihin riskeihin tai ongelmiin. Kun kaikkiin riskeihin on löydetty ratkaisu, spiraalimalli yleensä päätetään vesiputousmallin mukaisena toteutusvaiheena. Spiraalimalli on myös hyvin iteratiivinen prosessi. Se noudattaa aloita pienestä -periaatetta, kunkin ongelman ratkaisun ja arvioinnin jälkeen tarkennetaan seuraavan kierroksen vaatimukset. Tavoitteet Alkuperäiset vaatimukset Arvioinnin tuloksiin perustuvat tarkennetut vaatimukset Arviointi asiakkaan kanssa Arviointi Riskianalyysi Alkuperäisten vaatimusten riskianalyysi Arviointiin ja tarkennettuihin vaatimuksiin perustuva riskianalyysi Toteutus Kuva 5. Spiraalimalli Jatkam is- tai keskeyttämispäätös Alustava prototyyppi Seuraavan tason prototyyppi Suunniteltu järjestelmä Eri elinkaarimalleja voidaan soveltaa järjestelmän eri osien tai yksittäisten komponenttien toteutuksiin. Valitusta elinkaarimallista riippumatta kussakin vaiheessa tuotetaan dokumentteja, mm. suunnittelun tueksi. Lisäksi varsinkin testaus- ja arviointivaiheessa peilataan tuotoksia edellisissä vaiheissa tuotettuihin dokumentteihin. Yksinkertaistaen vaiheiden voidaan ajatella etenevän iteratiivisesti siten, että kullakin ohjelmiston osalla, komponentilla tai sen osalla käydään läpi kaikkia vaiheita, kunnes osa täyttää vaatimusmäärittelynsä, jonka jälkeen voidaan siirtyä suurempiin, toteutetun osan sisältäviin osiin. RUP (Rational Unified Process) (Kruchten 2000) on runsaasti huomiota saanut tarkka ja yksityiskohtainen prosessi, joka perustuu inkrementaaliseen ja iteroivaan elinkaarimalliin muistuttaen spiraalimallia. Prosessi käyttää UML:n (ks. sanasto) käyttötapauksia, keskittyy ohjelmistoarkkitehtuuriin ja jakaa sovellustuotannon useisiin pieniin projekteihin (iterations), joiden tulokset ovat uusia piirteitä (increments). Kukin iteraatio keskittyy tärkeimpiin riskeihin ja tuottaa valittujen käyttötapausten toteutukset. Alussa luodaan tärkeimmistä toiminnoista pintapuolinen toteutus. Prosessin alkuvaiheessa iteraatiot tuottavat yleensä uusia versioita sovelluksen toteutettuihin osiin, loppuvaiheessa tuloksina on uusia piirteitä sovelluksiin. Elinkaarimalleja on arvosteltu siitä, että ne vaativat paljon dokumentaatiota ja runsaasti arviointia. Arvostelijat näkevät mallien formaalisuuden haittaavan kommunikointia asiakkaiden kanssa. Eräs vaihtoehtoinen lähestymistapa on RAD (Rapid Application Development), jossa kehitetään prototypoinnin tapaisesti uusia versioita prototyypeistä, jotka arvioidaan yhdessä asiakkaan kanssa. Prosessia ohjataan rajoittamalla kunkin ominaisuuden toteuttamiseen käytettävä aika time box:in eli tiukan aikarajan avulla (DSDM 2000). Toinen elinkaarimallien vaihtoehto on Microsoftin käyttämä synch-and-stabilize -prosessi (Cusumano, Selby 1997), joka perustuu useiden yhtäaikaisesti toimivien tiimien käyttöön. Komponenttien toimivuus yhdessä pyritään varmistamaan synkronoimalla muutokset samanaikaisesti eri tiimeissä. Uusia piirteitä kehitetään inkrementaalisesti tarkan tavoit- Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

27 OHJELMISTOTUOTANTOPROSESSI 27 teen (vision) ja piirteiden tärkeysjärjestyksen ohjaamina. Testauksella on suuri merkitys. Strategiana on rakentaa nopeasti riittävän hyviä tuotteita markkinoille pääsemiseksi, ja parantaa tuotetta vähitellen myyden useita versioita ja päivityksiä. Elinkaarimallit eivät myöskään ota riittävästi huomioon kasvanutta valinnanvaraa niissä tavoissa, joilla uusia ohjelmistoja voidaan ottaa käyttöön asiakasorganisaatioissa. Tarvittavan toiminnallisuuden hankkimiseksi organisaation järjestelmään ainoita vaihtoehtoja eivät ole enää perinteiset ostaminen tai itse rakentaminen. Sovellus tai sen osa voidaan (Allen 2000): ostaa kokonaisuudessaan ulkopuoliselta toimittajalta, ostaa ulkopuolisen toimittajan komponenttina, suunnitteluttaa ulkopuolisella taholla, vuokrata ulkopuoliselta taholta (ASP - Application Service Provider -toiminta), toteuttaa vanhan järjestelmän sovittimena (ks. sanasto) tai integroida yhteiseen edustajärjestelmään (ks. luku 12.3 ja sanasto: EAI - Enterprise Application Integration), kehittää laajennettavasta sovelluskehyksestä (ks. luvut 13 ja 14), kirjautua käyttämään sovellusta verkon kautta (ks. sanasto:.net), tai rakentaa itse. Toiminnallisuuden hankinnan vaihtoehtojen ja valinnanvaran lisääntyessä osaavan asiakkuuden merkitys korostuu. Organisaation on ymmärrettävä erilaisten vaihtoehtojen merkitykset ja pyrittävä kehittämään ja hankkimaan tietojärjestelmäkokonaisuuksia kokonaisvaltaisesti välttäen lukkiutumista umpikujatekniikoihin. 3.2 Komponenttipohjainen ohjelmistotuotantoprosessi ja sen tehtäväkentät Sovelluskehitys on viimeisiä teollisuudenaloja, joissa käsityö on edelleen hallitseva menetelmä. Muilla aloilla käytetään huomattavasti enemmän valmiita komponentteja. Komponenttipohjainen ohjelmistotuotanto edellyttää, että ollaan valmiita käyttämään valmiita, kenties toisessa organisaatiossa tehtyjä ja erikseen ostettuja korkean tason komponentteja. Komponenttipohjainen sovellustuotanto vaatii ohjelmistotuotantoprosessin muuttamista (Kähkipuro 2000) (ks. kuva 6). Keskeiset komponenttiteknologiat ovat riittävän kypsiä mittavien tietojärjestelmien toteuttamiseen, ja komponenttiprojektien ongelmat johtuvat usein vanhanlaisesta ohjelmistotuotantoprosessista. Taulukko 2. Perinteisen ja komponenttiprojektin vertailua (Kähkipuro 2000) Perinteinen projekti Komponenttiprojekti Järjestelmäajattelu tavoitteena järjestelmä tai Komponenttijärjestelmän raja häilyvä sama osajärjestelmä komponentti yleensä osana useassa järjestelmässä Tehdään itse Tietokeskeinen arkkitehtuuri järjestelmän ytimenä tietokanta, toiminta tiedon käsittelyä Hankitaan muualta jos mahdollista Palveluarkkitehtuuri kukin komponentti hallitsee omaa tieto- ja toimintasisältöään, ja sisältö muodostuu komponenttien yhteistoiminnan perusteella, esim. rajapintakuvausten avulla Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

28 28 OSA I: Perusteet Uusia vaatimuksia: 1. Liiketoimintaprosessit sovellusprojektien lähtökohdaksi projektin rajat ja tavoitteet määritellään liiketoimintaprosessin avulla, keinona komponenttipohjainen jäsennystapa: järjestelmä hahmotetaan joukkona komponentteja ja tavoitteet määritellään niiden liiketoimintaprosessien perusteella, jotka komponenttijoukolla on mahdollista toteuttaa. Komponenttijoukko on tietenkin laajennettavissa. Jos usea prosessi tarvitsee tiettyä toiminnallisuutta, siitä tehdään palvelu, jonka jokin komponentti toteuttaa. 2. Palveluarkkitehtuuri jo suunnitteluvaiheessa järjestelmä jäsennellään joukkona palveluita joita komponentit tarjoavat toisilleen, ja vain komponenttiliittymä on käyttäjien tiedossa. Komponentin sisäinen toteutus on toteuttajan päätettävissä, joskin infrastruktuurissa voi olla välineet esim. tallennukseen, eheyden valvomiseen ja tiedonhakuun. 3. Komponenttivarasto sisältää itse komponentin lisäksi teknistä kuvaustietoa, versionhallintatietoa, komponentin käyttörajoitukset, sidokset nykyisiin käyttäjiin jne. Suunnittelijoilla ja sovelluskehittäjillä on suora pääsy varastoon tutkimaan käytettävissä olevan komponenttijoukon käyttömahdollisuuksia. 4. Komponenttien hallinta ja hankinta Hankintaprosessi: onko jostain saatavilla sopiva komponentti (löydettävyys), kartutetaan organisaation komponenttiomaisuutta niin, että kulloinenkin sovellustarve tulee toteutettua tarkoituksenmukaisesti jos ei löydy, tehdään itse. Käyttöönotto: uusi komponentti julkistetaan komponenttivaraston kautta, tehdään tarvittavat muutokset, määritellään käyttöön liittyvät rajoitukset ja ohjeet. Hallintaprosessi: mitä versioita tuetaan, millä aikajänteellä komponentteja päivitetään, visio tulevasta arkkitehtuurista ohjaa hankintaprosessia. Keskeinen tae hankinnan ja hallinnan onnistumiselle on omistajuus: komponentin omistaja (yleensä liiketoimintaprosessin haltija) maksaa komponenttihankinnan ja varmistaa investoinnin hyödyllisyyden. Hankintaprosessin ohjaus Valmiit komponentit, pakatut sovellukset, ERP-ohjelmistot, itse tehdyt ja ostetut komponentit, komponenttiinfrastruktuurit jne. Komponenttivarasto Hankintaprosessi Hallintaprosessi Organisaation tarpeet Hankintaprosessin käynnistys Komponenttien kerääminen Järjestelmäintegraatio Sisäinen markkinointi Sovelluksen tarpeet Ohjelmistokehitys Toimivat sovellukset Kuva 6. Komponenttipohjainen ohjelmistonkehitysprosessi, Kähkipuroa (2000) mukaillen. Uuden ohjelmistotuotantoprosessin hyötyjä: 1. Hankinta- ja hallintaprosessin ansiosta uudelleenkäytettävyys paranee, komponenteista tulee koko organisaation omaisuutta eivätkä ne ole enää yhden projektin välineitä. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

29 OHJELMISTOTUOTANTOPROSESSI Eriytetyn hankintaprosessin ansiosta voidaan varmistua, että yhteiskäyttöön liittyvät kysymykset otetaan huomioon (heterogeenisyysvaatimus). 3. Hankintaprosessi erillään projektityöstä auttaa hallitsemaan laajoja järjestelmiä. 4. Komponenttimarkkinat (ainakin organisaation sisällä). 5. Liiketoimintaprosessin ohjaamat projektit sopeutuvat muutoksiin paremmin kuin perinteiset projektit, sovellusprojektit tehdään toimivilla ja valmiiksi testatuilla komponenteilla. Uuden ohjelmistotuotantoprosessin haittapuolet: 1. Hankinta- ja hallintaprosessien vaatiman lisätyön hyödyt näkyvät vasta komponenttiomaisuuden karttuessa. 2. Olemassa olevien järjestelmien istuttaminen mukaan ja palveluarkkitehtuurin rakentaminen pala kerrallaan on vaikeaa. 3. Liiketoimintaprosessien valinta sovellustyön lähtökohdaksi voi aiheuttaa vaikeuksia: esim. tulosten arviointi sen perusteella, saako toimintaprosessi tarvitsemansa tuen sen sijaan, että arvioitaisiin tietoteknisillä kriteereillä annettuja vaatimuksia. 4. Sovellukset eivät valmistuessaan käytä viimeisintä teknologiaa, koska teknologian uusia versioita tulee markkinoille myös projektin kuluessa vastapainoksi nopeampi tuki toiminnan vaatimuksille ja parempi käyttö teknologiainvestoinneille. Sovellusten komponenttipohjaisessa rakentamisessa on kaksi toisistaan poikkeavaa tehtäväkenttää: komponenttien rakentaminen ja sovellusten koostaminen komponenteista. Komponenttien rakentamisessa lähtökohtana voi olla esim. komponentille suunniteltu rajapinta, tai joissakin tapauksissa esim. vanha sovellus. Rajapinnasta on kuitenkin pyrittävä tekemään yleiskäyttöinen ja tarkoituksenmukainen, vaikka komponentin sisäinen toteutus perustuisikin vanhaan sovellukseen tai tietokantaan. Sovelluksen koostamisessa tarvitaan erilaisia välineitä ja taitoja kuin komponentin rakentamisessa. Varsinkin toimialan ja toimintaprosessien tuntemus korostuu koostettaessa sovelluksia korkean tason komponenteista. Herzum ja Sims (2000) esittävät kymmenen kultaista piirrettä komponenttipohjaiselle sovelluskehitykselle. 1. Komponenttikeskeisyys: Koko kehitysprosessin ajan keskitytään eri karkeajakoisuutta oleviin komponentteihin. Esimerkiksi yksittäisten hajautettujen komponenttien testauksessa komponenttien toimintaa verrataan toteutusdokumentteihin, hajautetuista komponenteista muodostuvan toimialakomponentin toimintaa suunnitteludokumentteihin, komponenttijärjestelmän toimintaa analyysidokumentteihin ja lopulta hyväksymistestauksessa järjestelmän vaatimuksiin. 2. Arkkitehtuurikeskeisyys: Erityisesti toiminnallisen arkkitehtuurin erottaminen muista arkkitehtuureista, kuten teknisestä ja sovellusarkkitehtuurista sekä projektinhallinnasta. 3. Autonomia: Komponenttijärjestelmän ja kunkin sen muodostavan osan itsenäisyyteen on kiinnitettävä huomiota kaikissa kehitysprosessin vaiheissa ja pyrittävä vähentämään riippuvuuksia osien välillä. 4. Lähestymistapa yhteistoimintaan: Vaikka pyritään itsenäisiin komponentteihin, on sallittava korkea yhteistoiminnan taso eri osien välillä. Haasteena on säilyttää kokonaisjärjestelmän eheys osien itsenäistä kehittämistä ja autonomiaa tukien. Tämä vaatii huomion kiinnittämistä tarpeellisiin riippuvuuksiin ja järjestelmän niihin osiin, joiden kanssa vaaditaan yhteistyötä. 5. Iteratiivisuus: Järjestelmän kehittäminen komponenteista ja komponenttien kehittäminen pienemmistä komponenteista jne. on inkrementaalinen ja iteratiivinen prosessi. Jotta prosessi on tehokas, on kehitysmenetelmien ja -prosessin tuettava nopeaa iterointia vaiheesta toiseen. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

30 30 OSA I: Perusteet 6. Kehityksen yhtäaikaisuus: Edelliset piirteet tukevat erillisten tiimien käyttöä järjestelmän osien toteuttamisessa. Tämä on nopean sovellustuotannon perusedellytys. 7. Jatkuva integraatio: Kehityksen iteratiivista luonnetta on tuettava kehitysprosessin läpi jatkuvalla integroinnilla. Järjestelmän toiminnallisuuden kehittäjän pitäisi voida keskittyä toiminnallisuuteen teknisten yksityiskohtien sijaan, ja saada nopeasti palautetta koko järjestelmän toiminnasta ja käyttäytymisestä jo ennen järjestelmän käyttöönottoa. 8. Riskinhallintalähtöisyys: Tietojärjestelmän kehittäminen on monimutkainen tehtävä, ja hajautus lisää monimutkaisuutta entisestään. Riskien hallittavuuteen voidaan pyrkiä yhteisillä kehityshankkeilla ja välittömällä palautteella projektien tilanteesta, joilla saadaan jatkuvaa tietoa suunnittelu- ja toteutuspäätöksistä. Käytettäviä keinoja ovat myös pienet ja nopeat iteraatiot kehitysprosessissa, jotka on otettu käytettävissä välineissä ja tuotantoprosessissa huomioon. 9. Uudelleenkäyttökeskeisyys: Uudelleenkäytettävyyteen pyritään kaikissa projektin vaiheissa, vaatimusmäärittelyistä lähtien. Komponenttien toteuttaminen vähillä ja määritellyillä riippuvuuksilla mahdollistaa niiden uudelleenkäytön useissa eri tilanteissa. 10. Komponentin kehittäminen tuotteena: Hyvän tuotteen erottaa laadusta, dokumentaatiosta, taloudellisuudesta ja saatavasta tuesta. Varsinkin toimialakomponentit ovat tuotteita, joita tullaan käyttämään niin monessa yhteydessä kuin mahdollista, jolloin niiden jatkuva kehittäminen johtaa laadun paranemiseen. Suunnitteludokumenttien ajantasaisuus tai mieluummin niistä suoraan lähtevä edelleen kehittäminen esim. generoimalla uusia toteutuksia johtavat optimoituun kehitysprosessiin. Hajautettujen komponenttipohjaisten sovellusten tuottamiseksi on ensin rakennettava edellytykset sovellusten rakentamiselle siten, että toimialalle sovellusta rakentavan sovelluskehittäjän tai suunnittelijan ei tarvitse liiaksi huolehtia infrastruktuurista ja teknisestä pohjasta, vaan hän pääsee keskittymään varsinaisen sovelluksen toiminnallisuuden ja ominaispiirteiden rakentamiseen. Selvityksen myöhemmissä luvuissa käsitellään näiden edellytysten rakentamista komponenttimallien, teknisen infrastruktuurin ja sovelluskehysten avulla. Välineiden valinnassa ei nykyisellään riitä, että valitaan väline, jolla on parhaat ominaisuudet. Koska ei ole yksittäisiä välineitä, jotka kattaisivat koko ohjelmistotuotantoprosessin, on valittava välineiden sijaan välinepaketteja, jotka voivat koostua eri toimittajilta saaduista välineistä eri tarkoituksiin. Valittavien välineiden on sovittava kehitys- ja käyttöympäristön alustoille sekä toimittava yhdessä, jotta niitä voidaan käyttää tehokkaasti. Välinepaketin valinnassa huomioon otettavia seikkoja ovat(va 2000): 1. Välinepaketin on tarjottava kehitysprosessin läpi ulottuvaa integraatiota vaatimustenhallinnasta toteutuksen kautta jakeluun. 2. Tuotteiden välisten liittymien, etenkin prosessin eri vaiheiden välillä, tulisi olla standardeihin perustuvia, jotta vältytään liialta sitoutumiselta yksittäiseen toimittajaan. 3. On tunnistettava pieni joukko kriittisiä ominaisuuksia kullekin valittavalle tuotteelle. Kriittinen ominaisuus on sellainen, että projekti epäonnistuu, ellei tuote kykene riittävän hyvin tarjoamaan ominaisuutta. Ominaisuudet riippuvat kustakin projektista ja harkittavien tuotteiden välisistä suurimmista eroista. 4. Kriittisten ominaisuuksien avulla valitaan lista tuotepaketteja, joita käyttämällä projekti todennäköisesti onnistuu. 5. Valitaan parhaiten sopivat tuotteet lisäkriteerien avulla. Nämä kriteerit voivat perustua eri lähteisiin, henkilökohtaisiin kokemuksiin ja preferensseihin jne. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

31 OHJELMISTOTUOTANTOPROSESSI 31 Jos välineet valitaan tämän prosessin mukaisesti, vähenee vaara, että valinta tehdään pelkästään henkilökohtaisten kokemusten perusteella. Kriittisten ominaisuuksien tunnistaminen ja tuotteiden vertailu näiden ominaisuuksien perusteella tuottaa objektiivisemman listan, josta lopulliset tuotteet valitaan. Seuraavassa on arvioitu erilaisia, osin limittäisiä, tehtäväkenttiä hajautetun komponenttipohjaisen sovellustuotannon alueelta. Suluissa on viittaukset kuvaan 7, jossa on esitetty hajautettujen sovellusten rakentamisen tehtäväkenttiä ja niissä tarvittavaa toimialan ja tekniikan osaamista. Sovellusalueen tuntemus Tietokantaasiantuntijat Käyttöliittymäsovelluskehittäjät Hajautettujen sovellusten kehittäjät Sovellusalueosaajat Palvelinsovelluskehittäjät Järjestelmäintegraattorit Menetelmäkehittäjät Infrastruktuurin toimittajat Tekninen osaaminen Kuva 7. Hajautettujen sovellusten kehittämisen tehtäväkentät Sovellusalueosaajat ovat toimialan asiantuntijoita, jotka määrittelevät toimialakohtaisia komponentteja. He voivat myös koostaa kokonaisia sovelluksia valmiista komponenteista. He määrittelevät sen, mitä uusilta järjestelmiltä vaaditaan. Sovellusalueosaajat tuntevat sovellusalueen sekä laajasti että tarkasti ja yksityiskohtaisesti. Ohjelmistoinsinöörit suunnittelevat, kehittävät ja rakentavat komponentteja. Tässä ryhmässä tarvitaan toimialan tuntemusta komponenttien toteuttamiseksi ja sidosryhmien vaatimusten ymmärtämiseksi ja toteuttamiseksi (käyttöliittymä- ja palvelinsovelluskehittäjät), mutta myös teknistä osaamista, kuten hajautettujen järjestelmien tuntemusta (hajautettujen sovellusten kehittäjät), tietokanta-asiantuntemusta (database analysts), ohjelmointitaitoja jne. Menetelmäkehittäjät kehittävät sovellusosaajille ja ohjelmistoinsinööreille välineitä, eli yleisiä sovellusarkkitehtuureita ja kehyksiä sekä suunnittelumalleja. Menetelmäkehittäjien on tunnettava tekniset edellytykset ja mahdollisuudet tehokkaiden arkkitehtuurien ja välineiden kehittämiseen, mutta heillä on oltava myös yleiskuva sovellusalueesta, mikäli menetelmiä kehitetään tietyn sovellusalueen tarpeisiin. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

32 32 OSA I: Perusteet Lisäksi infrastruktuurin toimittajat tarjoavat välineitä ja teknistä pohjaa, jolle sovellusten arkkitehtuuri voidaan suunnitella ja toteuttaa, ja järjestelmien integroijat kehittävät ratkaisuja ja välineitä järjestelmien yhteistoiminnallisuuden parantamiseksi ja järjestelmien liittämiseksi toisiinsa. Infrastruktuurin toimittajat ovat järjestelmissä käytettävien tekniikoiden ja tuotteiden asiantuntijoita, joilla ei yleensä ole erityisen laajaa tuntemusta sovellusalueesta. Järjestelmien integroijilla on oltava hyvä integrointitekniikoiden tuntemus sekä hyvä yleiskuva sovellusalueesta ja sen olemassa olevista järjestelmistä. Suurten sovellusten tuottaminen on siis usein tiimityötä, jossa yhä enemmän tarvitaan erilaisten toimialan ja teknisten osa-alueiden lisäksi monialaista yhteistyötä ja keinoja mahdollistaa eri kielillä puhuvien osallistujien tehokas yhteistyö. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

33 KOMPONENTTIMALLIT JA -VÄLIOHJELMISTOT 33 OSA II: TAUSTASELVITYKSET 4 KOMPONENTTIMALLIT JA -VÄLIOHJELMISTOT Tässä luvussa esitellään ja vertaillaan komponenttipohjaisen sovelluskehityksen mahdollistavia tekniikoita: komponenttimalleja ja väliohjelmistoja (middleware). Nämä osat muodostavat tärkeän teknisen pohjan, jonka avulla komponenttipohjaisten sovellusten hajauttaminen ja kommunikointi sekä komponenttien toteuttaminen mahdollistuvat. Näiden osien pohjautuminen standardeihin on välttämätöntä, jotta komponenttien siirrettävyys ja vaihdettavuus eri ympäristöjen tai sovellusten välillä voidaan toteuttaa. Ensin määritellään luvussa käytettävät käsitteet ja vaatimukset, joita näiden osien tulisi toteuttaa. Seuraavaksi esitellään kolme markkinoilla olevaa komponenttimallia ja vertaillaan niiden ominaisuuksia ja lisäpalveluita. 4.1 Komponenttimallien vaatimukset Komponenttimalli (Kuusi 1999) on standardi, joka määrittelee komponenttien rajapintojen rakenteen ja tavan, jolla komponentti kommunikoi muiden komponenttien kanssa tai tällaisen standardin toteutuksen. Lisäksi komponenttimalli voi tarjota komponenteille erilaisia palveluita. Vaihdettavien komponenttien toteuttamiseksi komponenttimallin on tuettava modulaarisuutta. Modulaarisuuden toteuttamiseksi tulisi olla mahdollista kapseloida komponentin käyttäytymistä monilla tasoilla (mukaillen Assmann 1999): toteutuksen ja suunnittelupäätösten kapselointi vain komponenttiliittymän kautta käytettäviksi, ohjelmointikieliriippumattomuus ja suoritusympäristöstä toiseen siirrettävyys: ohjelmointikieliä tai käyttöjärjestelmiä ei voi yhtenäistää, joten on tarjottava mahdollisuus yhdistää eri kielillä toteutettuja komponentteja, sijaintiriippumattomuus: komponentin tarkan sijainnin tietäminen ei ole tarpeen sen käyttämiseksi, elinkaaren kapselointi: joidenkin komponenttien on oltava (ainakin näennäisesti) käytössä aina, toisten ei; elinkaaren hallinta ei ole komponentin käyttäjän asia, sitomisen kapselointi: dynaamisissa tapauksissa komponentteja ei liitetä toisiinsa staattisesti, vaan etsitään suorituksen aikana hakemistosta; sitomisen on oltava käyttäjälle näkymätöntä. Mukauttamista käsiteltiin jo peruskäsitteiden (luku 2.1) yhteydessä. Komponenttimallin on tarjottava mahdollisuuksia sopeuttaa komponenttia, jos se ei sovi täysin käyttäjän vaatimuksiin. Sopeuttaminen voi tapahtua esim. sovittimen (adapter) avulla. Staattisessa sopeuttamisessa sopeuttava koodi käännetään järjestelmään. Dynaamisessa sopeuttamisessa hakemistosta löydettäviä komponentteja on sopeutettava suorituksen aikana. Tätä varten on toteutettava introspektio, jos komponentti tutkii toista komponenttia, tai reflektio, jos komponentti tarjoaa tietoja itsestään. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

34 34 OSA II: Taustaselvitykset Komponenttimalli voi tukea mukauttamista seuraavilla tavoilla: Mukauttaminen koodia generoimalla: - hajautuksen toteuttavan koodin generointi, - eri ohjelmointikielten välisten tietotyyppien mukauttaminen, - kommunikaation mukauttaminen, eri tavalla kommunikoivien komponenttien välisen liikenteen mukauttaminen. Dynaamisen mukautumisen tukeminen: - dynaaminen tyyppi- ja liittymätiedon tarkistaminen (introspektio) - meta-olioprotokolla; täydellisen tyyppijärjestelmän tarjoaminen sekä komponentista että tiedosta (reflektio). Komponenttien mukauttamisen lisäksi tärkeä vaatimus on laajennettavuus (Assmann 1999). Mustana laatikkona toimivia komponentteja käytettäessä ei päästä tutkimaan niiden sisäistä toteutusta. Kuitenkin komponenttien toiminnallisuutta olisi pystyttävä laajentamaan siten, että myös vanha toiminnallisuus on edelleen käytettävissä. Tyypillisiä laajennettavuustilanteita ovat lisäykset tietosisältömäärittelyihin. Laajennettavuus voidaan toteuttaa näkymien avulla, joita varten komponenttimallin on tuettava: abstract factory -mallia: komponenttien luonnin tulisi tapahtua yleisten luomisen hoitavien komponenttien avulla, jotka tukevat yhtenäisten komponenttiperheiden rakentamista, abstrakteja kerroksia: komponenttien käytön tulisi kulkea sellaisten kerrosten läpi, joissa toteutusta voidaan muuttaa tai laajentaa. Komponentit koostuvat monista eri tyyppisiin asioihin liittyvistä piirteistä. Samaan komponenttiin liittyviä eri piirteitä ovat mm. pysyvyys ja virheidenjäljitys. Komponenttimallit voivat tukea eri piirteiden erottamista toisistaan, mikä mahdollistaa myös tietyn piirteen toteutuksen korvaamisen seuraavilla tavoilla: useiden komponenttiliittymien tukeminen (kutakin piirrettä varten omansa), piirteiden erillinen määrittely ja yhdistäminen lopulliseksi komponentiksi erillisen työkalun avulla. Avoimien markkinoiden ja hankittavien vaihtoehtoisten tuotteiden toteutumiseksi tarvitaan myös standardointia. Standardit ovat joko virallisia (kuten ISO:n määrittelemät), avoimia (kuten teollisuuskonsortioiden, OMG:n tai W3C:n standardit) tai de-facto -standardeja, jotka voivat syntyä markkinajohtajien dokumentoitujen ja julkistettujen käytäntöjen perusteella. Standardit ovat merkittäviä lähtien erikielisten ja hajautettujen komponenttien kommunikoinnin määrittelyistä aina eri tyyppisten kapselointien, mukauttamisen, laajennettavuuden ja piirteiden toteuttamiseen asti. Standardoitu komponentti on usein lisärajoituksia sisältävä komponenttimalli tai joukko erityyppisiä mallikomponentteja, joiden avulla toteutetaan tyypillisiä sovellustarpeita. Standardoitujen komponenttien ansiosta voidaan kehittää korkeamman tasoisia apuvälineitä, koska komponentit toimivat samalla tavoin. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

35 KOMPONENTTIMALLIT JA -VÄLIOHJELMISTOT Komponenttimallien vertailua: COM+, CORBA, ja EJB Tässä luvussa vertaillaan kolmea markkinoilla olevaa vahvaa komponenttimallia: OMG:n CORBA:a, Microsoftin DCOM/COM+:aa ja Sunin Enterprise JavaBeansia. Tässä esitellään lyhyesti komponenttimallit ja niiden olennaisimmat erot. Luvun 4.1 perusteella komponenttimallien tulisi tukea standardeja käyttävien, mukautettavien, laajennettavien ja eri piirteiden erilliseen toteuttamiseen perustuvien komponenttien toteuttamista. Microsoftin COM (Component Object Model) on sekä spesifikaatio että toteutus. COM-malli ei määrittele, mikä komponentti on, vaan komponentti ja olio tarkoittavat usein samaa asiaa. Käytännössä komponentti toteuttaa yhden tai useamman COM-luokan, jotka kukin toteuttavat useita COM-rajapintoja. COM-komponenttien toteutus perustuu tiettyjen nimettyjen komponenttiliittymien käyttöön 3. Komponentti voi sisältää tukemiensa rajapintojen toteutuksen itse tai se voi sisältää osoittimen toiseen komponenttiin, joka tukee rajapintaa. Komponenttimallin sekä etu että rajoite on tiukka integraatio Windows-käyttöjärjestelmään. DCOM (Distributed Component Object Model) on COM:n laajennus, joka mahdollistaa eri prosessoreilla sijaitsevien komponenttien kutsut. COM:n ja DCOM:n avulla voidaan saavuttaa sijaintiriippumattomuus ja ohjelmointikieliriippumattomuus. Microsoft on esitellyt uuden.netstrategian ja tuoteperheen (ks. sanasto), jossa ei korosteta komponenttimallin käyttöä yhtä paljon kuin nykyisissä Windows-ohjelmistoissa, vaan lähestymistapa on web-lähtöinen ja suuntautunut XML:n käyttöön sovellusten integroinnissa. Sovellusoliot (Application Objects) Oliosanomavälitin (ORB) Yleiset toiminnot (CORBA Facilities) Yleiset oliopalvelut (CORBA Services) Kuva 8. OMA (Object Management Architecture) CORBA (Common Object Request Broker Architecture) on OMG:n kehittämä standardi hajautettujen oliopohjaisten järjestelmien rakentamiseen. Oliolla (tai komponentilla) tarkoitetaan COR- BA:ssa IDL-kielisen rajapinnan toteuttavaa koodia, joka voi olla olioluokka, koostua useista luokista tai voi olla toteutettu ei-oliopohjaisella kielellä. CORBA on standardi, ei toteutus, ja eri ohjelmistotaloilla on standardin mukaisia tuotteita. CORBA:an kiinteästi liittyvässä OMA (Object Management Architecture) -arkkitehtuurissa (Siegel 2000) on neljä pääosaa (ks. kuva 8): oliosanomavälitin, yleiset oliopalvelut, yleiset toiminnot ja sovellusoliot. Sovellusoliot (Application Objects) ovat yksittäisiin sovelluksiin toteutettuja standardoimattomia olioita, jotka käyttävät yleisiä toimintoja ja palveluita oliosanomavälittimen kautta. Oliosanomavälitin, yleiset oliopalvelut ja yleiset toiminnot ovat osia, joissa OMG tekee standardointityötä. Oliosanomavälitin (ORB, Object Request Broker) mahdollistaa eri osoiteavaruudessa sijaitsevien olioiden metodien kutsumisen. Se mahdollistaa myös eri kielillä tehtyjen olioiden kommunikaation. CORBA tarjoaa komponenteille ohjelmointikieliriippumattomuuden IDL:n kautta ja käyttöjärjestelmäriippumattomuuden (eri käyttöjärjestelmissä toimivat oliosanomavälittimet). 3 COM-komponenttimallissa kaikkien komponenttien on tuettava IUnknown-rajapintaa, joka sisältää kolme metodia: QueryInterface, Addref ja Release. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

36 36 OSA II: Taustaselvitykset Yleiset oliopalvelut (CORBA services) ovat joko olioita suoraan palvelevia oliopalveluita (nimi-, elinkaari-, pysyvyys-, serialisaatio-, ominaisuus-, suhde- ja astiapalvelut), yhteistyöpalveluita (tapahtuma-, callback-, yhtäaikaisuus- ja transaktiopalvelut) tai sovelluspalveluita (turvallisuus-, kysely-, lisensointi- ja vaihtopalvelut). Näitä palveluita voidaan käyttää kaikilla kunkin sanomavälittimen tukemilla ohjelmointikielillä. Yleiset toiminnot (CORBA facilities) ovat kaikkien CORBA-palvelimien ja asiakkaiden käytettävissä olevia toimintoja ja palveluita. Yleiset toiminnot ovat joko horisontaalisia tai vertikaalisia. Horisontaalisia yleisiä toimintoja ovat mm. MOF (Meta Object Facility) (ks. sanasto) sekä kansainvälistämis- ja tulostuspalvelut. Vertikaaliset yleiset toiminnot ovat toimialariippuvia palveluita. Mm. CORBAmed-työryhmän määrittelemät terveydenhuollon yleiset palvelut (ks. luku 13.1) ovat vertikaalisia yleisiä toimintoja. Kuvassa 9 on esitetty CORBA:n oliosanomavälittimen toimintaperiaate. Muut komponenttimallit perustuvat samaan ideaan: sanomavälitin on sovelluksesta riippumaton ohjelmisto, joka tarjoaa komponenttimallin peruspalvelut, kuten hajautuksen ja viestien välityksen. Sanomavälitin muodostaa olioväylän (object bus), joka välittää kutsut kutsuvalta sovellukselta palvelevalle sovellukselle. CORBA Component Model (CCM) (Siegel 2000) on CORBA:n versiossa 3 julkaistava komponenttimalli, joka tarjoaa standardoidun komponentin toteuttamiseen vaadittavat palvelut. Komponenttimallin ytimessä on astia (container), joka on palvelimella toimiva ohjelmisto. Astia sisältää oliosanomavälittimen, ja komponentit asennetaan astiaan, joka voi hoitaa Asiakas Dynaam inen kutsu IDL tynkä Olios anom a- välittimen liittym ä Olioväylä (Oliosanomavälittimen ydin) Sam a kaikilla oliosanom avälittim illä Komponenttiliittymästä riippuva tynkä tai kehikko Dynaam inen välitys Kohdeolion toteutus IDL kehikko Oliom uokkaim ia voi olla useita Kuva 9. Oliosanomavälittimen toiminta Oliomuokkain niiden transaktio-, turvallisuus- ja pysyvyyspalveluita. CCM:n uusia piirteitä ovat lisäksi tapahtumaväylät (event channels) ja se, että komponenttien on ilmoitettava tarjoamansa ja tarvitsemansa komponenttiliittymät. JavaBeans on Sunin komponenttimalli, joka perustuu Java-kieleen ja Java-ympäristöön 4. Komponenttimalli on tiukasti sidoksissa Sunin luokkakirjastojen muodostamaan sovelluskehykseen ja Java-kielen käyttöön. Enterprise JavaBeans on tarkoitettu palvelimella transaktioympäristössä toimivien komponenttien rakentamiseen. JavaBeans-mallin komponentti koostuu yhdestä tai useammasta luokasta sekä niiden tarvitsemista resursseista. Komponentti paljastaa käyttäjilleen joukon ominaisuuksia, tapahtumia ja metodeita. Malli erottaa toisistaan komponenttien ajonaikaisen ja suunnittelunaikaisen käytön. Hajautettujen komponenttien käsittely hoidetaan RMI (Remote Method Invocation) -palvelun (ks. sanasto) ja olioiden serialisoinnin avulla. Rajapintojen, joihin voidaan viitata verkon yli, tulee periytyä java.rmi.remote rajapinnasta. Enterprise JavaBeans on malli 4 JDK (Java Development Kit) 1.1 tai sitä uudempi Java-ympäristö sisältää JavaBeans-komponenttimallin. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

37 KOMPONENTTIMALLIT JA -VÄLIOHJELMISTOT 37 palvelimella ajettavia komponentteja varten. Se tarjoaa erilaisia palveluja näille komponenteille. Javan avulla voidaan saavuttaa käyttöjärjestelmäriippumattomuus Java-virtuaalikoneen avulla. Heikkona puolena on pidetty rajoittumista Java-kieleen ja -suoritusympäristöön. CORBA:n version 3 määrittelyissä on käytetty runsaasti EJB:n ajatuksia, ja komponenttimallit ovatkin lähentymässä toisiaan huomattavasti, mm. standardoidun komponentin käsitteen osalta. OMG sekä Sun ovat sopineet säännöistä, joilla CORBA- ja EJB-komponenttien vaihdettavuus toteutetaan astioiden (containers) tasolla. Komponenttimallit tarjoavat vaihtelevan määrän erilaisia lisäpalveluita. Esimerkiksi COM-malliin liittyvät kiinteästi Windows-palvelimen palvelut, jotka ovat yleensä käytettävissä. Myös CORBAoliosanomavälittimien toimittajien tuotteissa on yleensä mukana joukko yleispalveluita. Taulukossa 3 on esitetty komponenttimallien eroja. Taulukon käsitteet, joiden suhteen komponenttimalleja arvioidaan, on selitetty luvussa 4.1. Taulukko 3. Keskeisten komponenttimallien vertailua (Kuusi 1999, Räsänen 1999, Assmann 1999) COM / COM+ CORBA EJB Komponenttimallin luonne Mikä on komponentti? Binääritason de facto -standardi hajautettuun kommunikaatioon, tuote ja joukko eri tuotteiden palveluja Useiden rajapintojen toteutus Komponenttien rajapintoja ja komponenttipalveluja koskeva avoin standardi IDL-rajapinnan toteutus, tai hajautettu olio. Komponenttien rajapintoja koskeva de facto -standardi ja kirjasto, joka toteuttaa palveluita Yksi tai useampi Javaluokka ja niiden tarvitsemat resurssitiedostot Standardoitu komponentti Sijaintiriippumattomuus Käyttöjärjestelmäriippumattomuus Ei ole toistaiseksi. Liittymät tehdään helppokäyttöisiksi IDEtuotteiden, kuten Visual Basic, avulla. DCOM-laajennuksen avulla, etäoliot luodaan abstract factory -mallin mukaisesti, samaan aikaan kuin niitä asiakkailla edustavat proxyoliot Sidottu Windowskäyttöjärjestelmään CORBA 3:ssa ilmestyvät määritellyt CORBA Beantyyppiset komponentit Eri valmistajien sanomavälittimien avulla Käyttöjärjestelmälle on oltava ORB-toteutus Java Bean -komponenttimalli: vain tapahtumien avulla kommunikoivat komponentit, joiden tila voidaan serialisoida, siirtää verkon yli ja palauttaa automaattisesti. Näin komponentit siirtyvät eri ympäristöjen välillä helposti. RMI-pakkauksen avulla Java-kielisten komponenttien välillä Käyttöjärjestelmälle on oltava Java-virtuaalikone Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

38 38 OSA II: Taustaselvitykset Ohjelmointi kieliriippumattomuus Elinkaaren hallinta Sitomisen kapselointi Komponenttien staattiseen sitomiseen IDL-liittymistä käännetyt luokat, dynaamiseen sitomiseen Dynamic Invocation Interface (DII) ja vaihtopalvelut (trading services). Mukauttaminen koodia generoimalla Dynaamisen mukauttami sen tuki COM / COM+ CORBA EJB Toteutuu, komponenttien rajapinnat toteuttavat COM-standardin binääritasolla (binäärinen Microsoftin C++-kääntäjän liittymärakenne) Normaalisti DCOMoliot ovat väistyviä. Moniker-olioiden avulla olioiden elinkaari saadaan säilyväksi. Moniker-oliot vastaavat CORBA:n olio-muokkaimia ja niihin pääsee käsiksi webin kautta. Ei vaihtopalvelua, mutta moniker-oliot voivat sijaita missä tahansa verkon osoitteessa. DCOM sitoo toteutuksen Monikerien avulla Läpinäkyvä hajautus hajautuksen toteuttavan koodin (marshalling) avulla. Tietotyyppien mukauttaminen tapahtuu samalla. Ei tukea eri kommunikointitapojen väliselle ohjaukselle. Kullakin oliolla on standardin mukainen komponenttiliittymä (Iunknown), jossa on yksinkertainen metodi (QueryInterface), jolla tyyppi-informatiota voidaan kysellä. Lisäksi DCOM-varasto sisältää olioiden ja luokkien kuvaukset. Toteutuu, jos ohjelmointikielen ja IDL:n välille on määritelty kuvaus Palvelimen oliosanomavälitin ja oliomuokkain (Portable Object Adapter, POA), piilottavat sen, onko palveleva komponentti jatkuvasti alustettu, pysyvässä varastossa, eri osoiteavaruudessa tai kopioitu muualta. Läpinäkyvä hajautus hajautuksen toteuttavan koodin (marshalling) avulla. Tietotyyppien mukauttaminen tapahtuu samalla. Eri kommunikointitapojen (normaali oliokutsu, dynaaminen kutsu, tapahtumakommunikaatio tai callback-kutsu) välinen ohjaus ei ole automaattisesti tuettua. Liittymä- ja toteutusvarastot sisältävät tyyppien ja komponenttien kuvaukset. Olio sisältää toisen olion liittymän tutkimiseen tarvittavat metodit. Meta Object Facility (MOF) tarjoaa metaolioprotokollan. Lisäksi ominaisuuspalvelua voidaan käyttää komponenttien vakioitujen ominaisuuksien tarkistuksiin. Sidottu Java-kieleen ja useisiin Sunin pakkauksiin. Java Native Code Interface (JNI) voi toimia Javan ja C:n välisenä siltana. Javassa palveluiden elinikä on sen asiakkaiden hallinnassa, olioiden varaama muisti vapautetaan jossakin vaiheessa, kun niihin ei ole enää viittauksia. EJB-komponentit ovat pysyviä. Ei tukea. RMI:ssä läpinäkyvä hajautus Java-pohjaisille komponenteille. Tietotyyppien välistä mukauttamista ei ole, koska vain Java-kielen tyyppejä käytetään. Eri kommunikointitapojen välistä ohjausta ei ole tuettu. Javan sisäänrakennettu operaatio (instanceof) tyyppitietoa varten. Yksinkertainen komponenttivarasto toteutettu classpath-ympäristömuuttujan avulla. Metaolioprotokollana on Javan sisäänrakennettu reflektio, jonka avulla voi tutkia, mukauttaa tai vaihtaa komponentteja. Beankomponenteissa on lisäksi nimeämiskäytännöt. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

39 KOMPONENTTIMALLIT JA -VÄLIOHJELMISTOT 39 Rajapintojen mukauttaminen Laajennettavuus näkymien avulla Eri piirteiden erottaminen komponentin sisällä Komponenttien periyttäminen 5 COM / COM+ CORBA EJB Muuttumattomat rajapinnat, uusi toiminnallisuus uuden rajapinnan avulla DCOM:ssa komponentit luodaan abstract factorymallin mukaisesti (class factory). Ei automaattista tukea abstrakteille kerroksille. DCOM tukee yhdistettyjen komponenttien toteuttamista. Ei tukea erillisille työkaluille piirteiden itsenäiseen määrittelyyn. Vain luokilla komponenttien sisällä, jos komponentit on toteutettu jollain oliokielellä Oliopalvelut Nimipalvelu perustuu Microsoftin hakemistopalveluun tai monikerien (url) käyttöön; ei automaattista roskien keruuta, vaan viittauslaskenta, olio poistetaan muistista kun viittauksia ei enää ole. RMI tarjoaa URL-pohjaisen nimipalvelun; Javaympäristö kerää käyttämättömät oliot muistista, mutta keruujärjestelmää on arvosteltu tehottomuudesta. Containermalli. Yhteistyöja kommunikaatiopalvelut DCOM:ssa tapahtumapalvelu, MTS-transaktiopalvelu (Microsoft Transaction Servertuote), ei standardoitua turvallisuuspalvelua, binääriset komponentit on sertifioitava. Rajapintojen versiointi mahdollista Ei automaattista tukea abstract factory-mallille eikä abstrakteille kerroksille. CORBA:n olioilla voi olla vain yksi komponenttiliittymä. Vasta CORBA 3 tukee yhdistettyjä komponentteja, joilla on useita komponenttiliittymiä. Ei työkalutukea erillisille piirteiden itsenäiseen määrittelyyn. Mahdollistaa komponenttiliittymien välisen periyttämisen, myös moniperinnän Nimipalvelu strukturoiduille komponenttien nimille; elinkaaripalvelu poistoa varten, ei roskien keruuta; suhdepalvelu, astiat (containers) versiossa 3. Tapahtuma- ja callbackpalvelut; transaktio-, yhtäaikaisuus-, kysely- ja turvallisuuspalvelu. Versiointi mahdollista? Ei automaattista tukea abstract factory-mallille. Beanmallissa ominaisuuksia on käsiteltävä get/set-metodien avulla, joiden sisältö voidaan generoida, mutta ne eivät tue näkymiä eivätkä näkymien edelleen ohjausta. EJB:t ovat yhdistettyjä komponentteja, jolla voi olla useita liittymiä. Ei työkalutukea erillisten piirteiden määrittelyyn. JavaBeans-malli mahdollistaa komponenttien välisen toteutuksen perinnän Javakielen tasolla Javan säikeet, tapahtumat ja callback-mekanismi. EJB:ssä lisäksi transaktiot, pysyvyys ja yksinkertaiset liiketoimintaoliot. 5 Komponenttien välillä ei voi yleensä olla samanlaista perintäsuhdetta kuin olioluokkien välillä. Perintää voidaan kuitenkin matkia komponenttien välillä mm. suunnittelumallien avulla (ks. luku 7.2). Tässä selvityksessä luokkien välillä käytetään perintä-käsitettä, ja komponenttien välillä periyttäminen-käsitettä. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

40 40 OSA II: Taustaselvitykset Komponent timallin tarjoamat muut keskeiset palvelut COM / COM+ CORBA EJB Useat Windows-käyttöjärjestelmäpalvelut, sekä työasema- että palvelintasolla OMG:n määrittelemät yleiset oliopalvelut, hierarkkiset ja vertikaaliset sovellusoliopalvelut (Versio 3: määritellyt peruskomponenttimallit, astiat jne.) Introspektio, reflektio, Sunin Java-kirjastojen muodostama sovelluskehys, Session- ja Entitykomponenttikehykset, astia (container) -malli Räsänen (1999) totesi, että siirtyminen hajautustekniikoita käyttävään arkkitehtuuriin on toteutettavissa Musti-sovelluksissa. Komponenttimalleista tavoitteita parhaiten tukevia ovat COM-tekniikat ja CORBA, joista CORBA soveltuu kohdeympäristöön paremmin avoimuutensa, laajojen palvelumäärittelyjen ja heterogeenisten ympäristöjen tukensa vuoksi. Yhteenvetoja komponenttimalleista ja niihin liittyvistä palveluista löytyy www:stä mm. seuraavista osoitteista: CORBA: EJB: ja COM-tekniikat: Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

41 SELVITYS KOMPONENTTIARKKITEHTUURIMALLEISTA 41 5 SELVITYS KOMPONENTTIARKKITEHTUURIMALLEISTA Tässä luvussa esitellään kaksi tyypillistä viitearkkitehtuuria hajautetuille komponenttisovelluksille: kolmi- ja nelitasoiset viitearkkitehtuurit. Tämän jälkeen esitellään neljä esimerkkiarkkitehtuuria, joiden avulla on toteutettu komponenttisovelluksia. Lopuksi arvioidaan kunkin esimerkin lähestymistavan vahvuuksia ja heikkouksia. Hajautetut komponenttiarkkitehtuurit tarjoavat mahdollisuuden kapseloida sovellusten toiminnallisuutta monella tasolla. Niin käyttöliittymän, toimintalogiikan, kuin tietokantojenkin kapselointi on mahdollista näiden arkkitehtuurien avulla. Tässä luvussa on kuvattu lyhyesti pääpiirteittäin muutamia arkkitehtuurimalleja ja toteutusesimerkkejä, joita käyttäen on toteutettu komponenttipohjaisia järjestelmiä. Esimerkeistä tulee selkeästi ilmi, miten erilaisia lähestymistapoja komponenttiarkkitehtuureihin on käytetty. Arkkitehtuurien vertailu ja yhteismitallistaminen on juuri erilaisten lähestymistapojen vuoksi vaikeaa. Käytettävät komponenttitekniikat eivät juuri ota kantaa sovellusarkkitehtuuriin. Sovellusarkkitehtuurit ovat yleensä olleet joko valmistaja- tai tuotekohtaisia. On olemassa yksittäisiä sovelluskehitystuotteita, jotka sisältävät välineitä eri tasojen toteuttamiseen yhtenäistä sovelluksen arkkitehtuurikehystä käyttäen. Esitetyt arkkitehtuurit ovat vähintään kolmitasoisia arkkitehtuureja, joiden arkkitehtuurillinen jako perustuu pitkälti siihen, että sovelluksen kolme tasoa: käyttöliittymä, toimintalogiikka ja tietovarasto on erotettu toisistaan. Tyypillisiä muita arkkitehtuureita ovat yksi- ja kaksitasoarkkitehtuurit, joissa eri tasot sijaitsevat samoilla tietokoneilla. Esimerkiksi kaksitasoarkkitehtuurissa toimintalogiikka on yleensä sijoitettu joko käyttöliittymän (fat client) tai tietovaraston yhteyteen (thin client). Lisäesimerkkejä tässä esitettyjen arkkitehtuuriesimerkkien lisäksi: Turunen, Jarkko: Komponenttien suunnittelu case: MAVA. Systeemityö 1/2000, Sytyke ry. TeleMed architecture: gov/telemed/architecture.html 5.1 Yleinen viitearkkitehtuuri Yleisesti käytetty komponenttiarkkitehtuuri (Tanuan 2000) on kolmikerroksinen, ja arkkitehtuurissa järjestelmä on jaettu käyttöliittymäkerrokseen, komponenttikerrokseen ja tietokantakerrokseen. Kuvassa 10 tällainen arkkitehtuuri on esitetty UML-pakkausten ja niiden välisten riippuvuuksien avulla. Kuvassa 10 on peruskerroksina 1. Käyttöliittymäluokat. 2. Komponenttikerros, joka sisältää sekä muita komponentteja ohjaavat (Control) komponentit, pysyvää tietoa edustavat entiteettikomponentit että ulkoiset toimialakomponentit, jotka voivat kapseloida perinnejärjestelmän. 3. Tiedon säilytyskerros. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

42 42 OSA II: Taustaselvitykset Kuva 10. Yleinen kolmitasoinen komponenttisovelluksen arkkitehtuuri UML-pakkauksilla esitettynä [Tan00] Kuvassa 11 kolmitasomallia on laajennettu nelitasoiseksi siten, että on lisätty erillinen kerros sovelluksen omaa paikallista toimintalogiikkaa varten. Kuvassa on seuraavat kerrokset: 1. User Interface Layer: Käyttöliittymäkerros sisältää lomakkeita, valikoita ja dialogeja, joilla käyttäjä kommunikoi järjestelmän kanssa. Se on riippuvainen käyttöliittymän ajoalustasta sekä olioiden toteutuksia sisältävistä ja palvelukerroksista. 2. Local Business Objects Layer: Paikallisten toimialaolioiden kerroksessa sijaitsevat oliot hoitavat tarkemmin tietyn sovelluksen toimintatarpeita. Ne käyttävät hyväkseen yleisiä toimialaolioita yksinkertaistaen näin toimialamallia. 3. Corporate Business Objects Layer: Yleisten toimialaolioiden kerros sisältää toiminnallisuuden ja tiedot, jotka ovat tärkeitä koko organisaation toiminnalle. Tämän kerroksen komponentit tarjoavat palveluita, jotka ovat hyödyllisiä koko toimialalle. Liiketoimintasovelluksissa mm. Asiakas, Tuote ja Organisaatiorakenne ovat tyypillisiä yleisiä komponentteja liiketoiminta- Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

43 SELVITYS KOMPONENTTIARKKITEHTUURIMALLEISTA 43 toteutuksissa (Entity). Myös peruspalvelut (liiketoiminnassa esim. Tilaustenkäsittely, hinnoittelu, varastonhallinta ym.) kuuluvat tähän kerrokseen (Control). 4. Utilities and Services Layer: Yleisten palvelujen kerroksen eräänä päätehtävänä on kapseloida tietovarastot. Lisäksi matalan tason palvelut, kuten sovelluskehykset tai tarvittavat kirjastot kuuluvat tähän kerrokseen. Valtaosan tämän kerroksen palveluista tulisi kuulua palvelinten perusinfrastruktuuriin. Palveluita voi myös hankkia lisää uusilta osapuolilta. Kuva 11. Nelitasoinen viitearkkitehtuuri [Tan00] Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

44 44 OSA II: Taustaselvitykset 5.2 CCS-SIS CCS-SIS (Mykkänen 1999; CCS-SIS 1999) on brasilialainen terveydenhuollon ohjelmistokomponenttikonsortio (Consórcio de Componentes de Software para Sistemas de Informação em Saúde). Konsortion perusidea on kapseloida yleisesti käytettävä sovelluslogiikka komponentteihin, joiden rajapinnat on sovittu kansallisessa konsortiossa. Määrittelyjen mukaiset komponentit ovat käytettävissä sellaisinaan sovellusten rakentamisessa ja saatavilla komponenttivarastosta. CCS-SIS:n arkkitehtuurin tutkittu toteutus (kuva 12) perustuu ODBC:n käyttöön sovelluspalvelimen komponentin ja tietokantapalvelimen välissä, mutta pääpaino on komponenttirajapintojen määrittelyssä. Komponentin rajapinta on DCOM / CORBA rajapinta, joka kapseloi komponentin toiminnallisuuden. Työasemalle näkyvissä on palvelimen komponentin tynkä (työasemavälineistön, esim. Delphin komponentti), johon voidaan liittää erikoistuneita näyttökomponentteja (tietyn komponentin esittämiseen tai käsittelyyn tarkoitettuja komponentteja) tai yleiskäyttöisiä näyttökomponentteja Connector-komponentin avulla. CORBA- tai DCOM -yhteys on piilossa sovelluksen kehittäjältä, ja toimintatason komponentin ominaisuudet ja metodit ovat käytettävissä tyngän ominaisuuksien ja metodien kautta. Workstation Developer builds applications using business components Application server Standardized interfaces of business components Database server display component business stub Delphi application CORBA / DCOM Server application (Delphi/NT) business object display component (ODBC) connector business object business object Kuva 12. CCS-SIS-arkkitehtuurin eräs toteutus [Myk99] CCS-SIS-projekti on toteuttanut tätä arkkitehtuuria käyttäen n. 40 komponenttia, joista 15 on toimialakomponentteja. Toteutuksissa on käytetty sekä DCOM- että CORBA-kommunikaatiota palvelimen komponentin toteutuksen ja työaseman välillä. Toiminnallisuuden lähtökohtina ovat olleet kansalliset ja CORBAmedin määrittelemät standardit. Komponentteja on käytetty menestyksellisesti mm. kansallisen terveyskortin tiedonkeruusovelluksessa (komponentit tietorakenne-orientoituneita) ja ravitsemusarvojen laskentasovelluksessa (komponentit palveluorientoituneita). 5.3 RC Business Object Architecture Sveitsiläiselle Rösch Consultingille suunnitteltiin puitearkkitehtuuri toimialakomponenteille (Merkert 1996). Arkkitehtuurin pohjalta toteutettiin kokonaisuudessaan oliopohjainen pilotti, joka toteutettiin Smalltalk-kielellä käyttäen GemStone -oliotietokantaa ja VisualWorks -sovelluskehitintä (Smalltalk-spesifisiä työkaluja). Arkkitehtuuria kuvaavat seuraavat piirteet, joissa näkyy suunnittelun pohjana käytetty CORBA: Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

45 SELVITYS KOMPONENTTIARKKITEHTUURIMALLEISTA 45 - Arkkitehtuurissa käsitellään vain Business Objects-tasoa, ja jokainen kapseloitu toimialakomponentti sisältää käyttöliittymäkomponentit teknisinä olioina. Tämä poikkeaa esim. OMG:n BOMSIG-työryhmän CORBA-arkkitehtuurista, jossa on erikseen Business Objects, Presentation Objects ja Process Objects -tyyppisiä olioita. - Jokaiselle toimialakomponentille on määritelty yksi IDL-rajapintaa. Myös sen osakomponenttien rajapinnat on määritelty IDL:n avulla. Näin toimialakomponenttikokonaisuuden kehittäjä käyttää samoja mekanismeja kuin kokonaisuuden käyttäjä. Kuva 13. RC Business Object Architecture komponentti [Mer96] - Toimialakomponenttien jakelu ja hajautus hoidetaan sanomavälitinten yhteistoiminnalla ja sanomavälittimestä riippumattomien olioviittausten avulla. - Järjestelmän toteutusvälineitä käytetään myös pitkäikäisten toimialakomponenttien toteuttamiseen. Tavoitteena oli näiden piirteiden ja myöhempien ideoiden avulla saavuttaa yksinkertaisuus, ymmärrettävyys ja arkkitehtuurin selkeys suunniteltaviin järjestelmiin. Kukin toimialakomponentti koostuu käsittelyosasta (processing) ja esitysosasta (presentation). Kuvassa 13 uloin raja kuvaa toimialakomponentin käyttäjän käytettävissä olevia rajapintoja, ja toimialakomponenttikapselin sisäinen osa on kapselin käyttäjälle näkymättömissä. Sisäisen näkymän tarkastelu: 1. Käyttöliittymä (Presentation) Kapseli voi sisältää useita käyttöliittymäluokkia erilaisia käyttötarkoituksia varten. Lisäksi kullakin käyttöliittymäluokalla voi olla useita yhtäaikaisia esiintymiä, esim. kutakin yhtäaikaista käyttäjää varten. 2. Käsittely (Processing) Käsittelykomponentti sisältää toimintasäännöt, joilla komponentin käyttäytyminen määritellään, ja myös komponentin yhteistoiminnallisuuden toteutuksen. Yksinkertaisuuden saavuttamiseksi kullakin toimialakomponenttikapselilla on vain yksi käsittelykomponentti. Toteutuksessa suositeltiin pysyvän ohjelmointiympäristön käyttöä (oliotietokanta), jolloin erillistä tietovarastonkäsittelyä ei tarvinnut ottaa huomioon. Passiivinen tietovarasto vaatii lisäselvityksiä tällaisessa mallissa. Komponenttikapselin kehittäjän on päätettävä sisältääkö käyttöliittymäkomponentti kaikki kapselin esitysmetodit vai tarjoaako käsittelykomponentti ainoan näkyvän liittymän. Valinnan voi tehdä, koska CORBA:n tyyppimäärittelyn voi toteuttaa useampi kuin yksi luokka ja näin komponenttikapselin tietyn liittymän toteutus voi olla tarjolla sekä käyttöliittymä- että käsittelykomponentissa. Toteutukseen (Kuva 14) valittiin Smalltalk-pohjainen oliotietokanta GemStone ja Smalltalk-sovelluskehitin VisualWorks. Kukin komponenttikapseli rakennettiin kokonaisuudessaan GemStone- Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

46 46 OSA II: Taustaselvitykset Kuva 14. RC-arkkitehtuurin toteutus [Mer96] oliotietokantaan. Yhden komponenttikapselin toteutus sisälsi käsittelykomponentin ja vähintään yhden käyttöliittymäkomponentin. Käsittelykomponentti kommunikoi sekä käyttöliittymän että muiden toimialakomponenttien kanssa IDL-liittymien avulla. Käsittelykomponentti sisälsi toimintalogiikan ja käytti hyväkseen GemStonen pysyvyyden hoitavaa ohjelmointiympäristöä, jolloin tietovarastojen tarkempi suunnittelu ei ollut tarpeen. Muihin ympäristöihin liittymiseksi GemStone tarjosi yleisen socket-pohjaisen kommunikaation. VisualWorks-kehitintä käytettiin käyttöliittymien tekoon, koska GemStonen ja VisualWorksin välinen yhteys on läpinäkyvä. Tällöin GemStonen olioihin pääsee VisualWorks-sovelluskehittimestä käsiksi kuin ne olisivat paikallisia Smalltalk-olioita. Socket-pohjainen kommunikaatio ulkopuolisten olioiden kanssa vaatii kuitenkin monimutkaista järjestelmänhallintaa. Toteutuksessa projekti joutui kuitenkin huomattaviin vaikeuksiin: luodut oliot olivat riippuvaisia käyttäjien istunnoista, mitä ei oltu otettu huomioon suunnittelussa, olioiden ja ulkomaailman väliin ei saatu rakennettua tehokasta kommunikaatiota yleisen socket-kommunikaation avulla, käyttöliittymän rakentamisessa käytetty sovelluskehitin ei saanut yhteyttä palvelinolioihin paitsi dokumentoimattoman mekanismin kautta, GemStone ei voinut luoda VisualWorks-oliota ja saada takaisin viittausta luotuun olioon, tuotteen saaminen myyjältä oli erittäin vaikeaa jne. GemStone / VisualWorks ei tarjonnut riittäviä työkaluja sille, että myös esityskomponentit olisivat osa säilytettävää olion kokonaistoteutusta ja suunnittelussa ei oltu otettu kaikkia tarvittavia toiminnallisuusnäkökohtia huomioon. Osaltaan vaikutti, ettei suunnittelun ja toteutuksen aikana ollut vielä vakiintuneita malleja ja koko toimialakomponenttiajatus sai suhteellisen vähän tukea teknologiasta, mm. alan standardointi ei ollut nykyisellä tasollaan. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

47 SELVITYS KOMPONENTTIARKKITEHTUURIMALLEISTA NAC Business Services Architecture NAC (Network Applications Consortium) on loppukäyttäjäorganisaatio, joka koostuu etupäässä suurista USA:laisista yrityksistä ja oppilaitoksista (mm. Exxon, Bell, Compaq, University of Michigan). NAC:n Business Services Architecture (BSA) (NAC 1998) (ks. kuva 15) on käsitteellinen kehysmalli, jolla pyritään tuomaan esiin tärkeitä seikkoja komponenttipohjaisten sovellusten kehittämisessä. Siinä on yhdistetty peruspiirteitä palveluorientoituneista monitasoarkkitehtuureista, komponenttipohjaisista sovelluskehitysmalleista ja Burton Groupin Network Services Model-mallista, ja sen tavoitteena on tarjota joustava malli hajautettujen komponenttipohjaisten laajojen sovellusten suunnitteluun, jakeluun, ylläpitoon ja laajentamiseen. Palvelupohjainen arkkitehtuuri laajentaa modulaarisuutta eristämällä tiedon ja toimintalogiikan täysin. Gartner Groupin määritelmän mukaan palvelupohjainen arkkitehtuuri on Monikerrosmalli, joka auttaa organisaatioita jakamaan toimintalogiikkaa ja tietoa. Siinä on useita ohjelmistokerroksia ja se noudattaa periaatetta, jonka mukaan monet toimintasäännöt ovat yhteisiä monille jonkin tietojoukon käsittelijöille pikemminkin kuin tietylle sovellukselle. Palvelu on musta laatikko, joka piilottaa koodin ja tiedon käyttäjäsovelluksen suunnittelijalta. Tavoitteena on maksimoida koodin uudelleenkäyttö ja minimoida toimintalogiikan ja tiedon toistuvuus organisoimalla toiminnot yhteiskäyttöisiin, kapseloituihin moduuleihin. Kuva 15. NAC:n palveluarkkitehtuurin perusosat [NAC98] Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

48 48 OSA II: Taustaselvitykset Esimerkiksi eristämällä tiedon tallennus- ja hakutoiminnot omaksi loogiseksi kerroksekseen (data services) erilleen toimintalogiikkakerroksesta, voidaan tehdä uusi toimintapalvelu (business service) uudelle mukaan tulleelle yritykselle. Uusi toimintapalvelu sisältää yrityksen omat toimintatavat ja säännöt, mutta vanhojen tietokantojen tiedot ovat sellaisenaan käytettävissä data servicen kautta. Business service-kerros voi kutsua data services kerrosta (B-1), joka taas voi kutsua tiettyä tietokantaa, tai legacy serviceä (B-2), joka kapseloi esim. perinnejärjestelmän (ks. kuva 15). Arkkitehtuuri jakaa sovellukset viiteen osaan. Jaon tavoitteena on varmistaa että kukin toimintapalvelu on uudelleenkäytettävissä. Uudelleenkäyttäjä voi olla myös toinen toimintapalvelu, joko organisaation sisältä tai ulkopuolelta. Käyttäjäpalvelut (user services) mahdollistavat käyttäjän vuorovaikutuksen toimintapalvelujen kanssa. Vuorovaikutus perustuu johonkin toimintapalvelun näkymään. Esimerkiksi ylläpitäjällä, organisaation sisäisellä käyttäjällä, ulkoisella kumppanilla tai asiakkaalla on kullakin erilainen näkymä toimintapalveluun, erilaisilla esitysmuodolla ja toiminnallisuudella. Käyttäjäpalvelut ovat usein thin client -periaatteen mukaisia, lomakepohjaisia näkymiä, jotka on suunniteltu tietyn tyyppiselle käyttäjälle. NAC toteuttaa käyttäjäpalveluita HTML:n, Javan tai ActiveX:n avulla. NAC:n loogisen arkkitehtuurin mukaisesti käyttäjäpalvelut voivat sijaita joko käyttäjän työasemalla tai toimintapalvelimella, jolloin vain esityskomponentti on työasemalla. Toimintapalvelut (business services) toteuttavat toimintasäännöt ja prosessit, joista toimintamalli muodostuu. Toimintapalvelut voidaan hajauttaa useille toimintapalvelimille (kolmitasoarkkitehtuurin keskimmäinen kerros) mikäli niiden saavutettavuus, skaalattavuus tai saatavuus niin vaativat. Toimintapalvelujen suunnittelu on erotettu täysin muista palveluista. Arkkitehtuuri abstrahoi toiminnot, joista sovellus muodostuu ja eristää ne toisistaan niin, että kutakin niistä voidaan käyttää tehokkaasti pitkällä aikavälillä. Toimintapalveluiden on oltava uusien käyttöliittymien käytettävissä ja niiden on eristettävä käyttäjät toteutuksen yksityiskohdista kuten erilaisista tietokannoista, perinnejärjestelmistä, hakemisto- ja turvallisuuspalveluista jne. Kukin toimintapalvelu edustaa jotain toimintaa, joka on saavutettavissa vain tämän palvelun kautta, vaikka se voikin olla toteutettu usealla komponentilla. Esimerkiksi tilaus voi johtaa sarjaan operaatioita joissa on mukana useita eri komponentteja, kuten asiakkaan varmistus, tilauksen varmistus, inventaarion päivitys, toimitus ja laskutus. Tietopalvelut (data services) ovat kerros, joka muuntaa toimialakomponentit tiettyyn tietokantaan tallennusta varten. Edistyneet tietopalvelut voivat tukea komponentin tallennusta useisiin tietokantoihin, esim. osa komponentista voi olla Oracle-tietokannassa, toinen perinnejärjestelmässä. Perinnepalvelut (legacy services) tarjoavat komponenttirajapinnat perinnejärjestelmiin, joihin on päästävä käsiksi sellaisenaan. Ne voidaan toteuttaa joko komponenttipohjaisena sovittimena (ks. sanasto), vanhan järjestelmän päälle, tai omana kerroksenaan, joka on yhteydessä vanhaan järjestelmään yhdyskäytävän kautta. Nämä palvelut tarjoavat abstraktit toimialakomponenttirajapinnat sekä vanhan järjestelmän palveluihin että tietoihin, ja niitä käyttävät joko toimintapalvelut tai tietopalvelut tilanteesta riippuen. Lisäksi BSA-arkkitehtuuri painottaa sitä, että suuret organisaatiot ovat pitkälti riippuvaisia yleisesti käytettävistä palveluista, jotka ovat yhteisiä. Näistä palveluista käytetään nimeä Common Services Infrastructure. Yleisten palvelujen on siis toimittava keskenään yhteen, ja komponenttipohjaisten hajautettujen sovellusten on integroiduttava olemassa oleviin tai uusiin yleisiin palveluihin NAC:n yleisiä palveluja on lueteltu taulukossa 4. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

49 SELVITYS KOMPONENTTIARKKITEHTUURIMALLEISTA 49 Hakemistopalvelut / directory services Turvallisuuspalvelut / security services Transaktiopalvelut / transaction services Viestipalvelut / messaging services Taulukko 4. NAC:in yleisiä palveluja Palvelut, joilla verkkotoimijat (käyttäjät, tulostimet, työasemat, palvelimet, yleispalvelut, komponentit) saavat selville mitä muita toimijoita verkossa on saatavilla, minkä nimisiä ne ovat ja kuinka niiden palveluja käytetään Palvelut, joiden avulla toteutetaan kaikkien verkon tietojen ja resurssien yhtenäisyys, tarkkuus ja yksityisyys. Näiden palvelujen avulla vahvistetaan käyttäjien, prosessien, komponenttien ja muiden verkkotoimijoiden identiteetti ja varmistetaan, että verkkotoimijoilla on pääsy vain niihin tietoihin ja palveluihin, joihin niille on annettu käyttöoikeudet. Varmistavat että toisiinsa liittyvät aktiviteetit voidaan suorittaa siten, että häiriöistä huolimatta tiedot ja muut resurssit säilyttävät eheytensä. (ks. myös luku 14.2, transaktiopalvelu). Keinot kommunikoida verkkotoimijoiden välillä, vaikka kaikki osallistujat eivät olisi aktiivisesti yhteydessä verkkoon. Esimerkiksi store-and-forward sähköpostijärjestelmä tallentaa viestit siihen asti, kun vastaanottaja käyttää sähköpostilaatikkoaan. Muiden palvelujen (käyttäjä-, toiminta-, tieto- ja perinnepalvelujen) on voitava: tunnistuttaa itsensä turvallisuuspalvelulla saadakseen tunnisteen, joka validoi palvelun oman identiteetin, saada turvallisuuspalvelulta tietyn käyttäjän tai roolin/käyttäjäryhmän tunnisteet, joka pyytää käyttöoikeuksia ja käyttää hakemistopalvelua paikallistamaan palvelu, jota tarvitaan tehtävän suorittamiseen. Kuva 16. NAC:n Common Services Infrastructure (NAC 1998) Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

50 50 OSA II: Taustaselvitykset Esimerkki yleispalveluista (ks. kuva 16): myyntiedustaja kirjautuu järjestelmään antamalla käyttäjätunnuksen ja salasanan (1). Hakemistopalvelu paikallistaa turvallisuuspalvelun (2) ja auktorisoi käyttäjän sisäänkirjoittautumisen. Järjestelmä käyttää myös viestipalvelua (3) vahvistamaan tietyn määrän ylittävät tilaukset, esim. lähettämällä sähköpostiviestin esimiehelle. Tietovarastot säilyvät eheinä riippumatta virhetilanteista jotka sattuvat ennen prosessin hyväksyntää ja loppuunsaattamista, koska koko prosessia suojaa transaktiopalvelu (4). Käytännön tasolla NAC määrittelee komponenttinsa joko MicroSoftin ActiveX- tai JavaSoftin JavaBeans -tekniikkaa käyttäen. ActiveX-komponentit perustuvat binääristandardiin, ja ovat pitkälti käyttöjärjestelmäriippuvia, kun taas JavaBeans-komponentit ovat kieliriippuvaisia, mutta käyttöjärjestelmäriippumattomia. Jotta komponentit ovat käytettäviä, niiden on tarjottava mekanismit, joilla kehitinympäristöt saavat selville niiden ominaisuudet ja niiden aiheuttamat tapahtumat. Komponenttien on tuettava ominaisuuksiensa graafista editointia, ja niiden on oltava muokattavissa suoraan ohjelmointikielen avulla. Lisäksi on oltava keinot liittää komponentteja yhteen siten, että semanttiset erot voidaan ottaa huomioon. Itse sovelluskehitysprosessi voidaan jakaa kahteen perusalueeseen: sovelluksen kokoaminen, johon tarvitaan sovellusalueen erityisosaamista ja komponenttien rakentaminen, joka vaatii teknisempää osaamista. Tämän mallin tukemiseksi hajautetun ympäristön on tuettava kommunikaatioinfrastruktuuria. Sekä COM/DCOM ja CORBA sisältävät samat peruskäsitteet ja samankaltaisen toiminnallisuuden, joita tarvitaan palvelupohjaisen arkkitehtuurin toteuttamisessa. Kuvassa 17 esitetyssä NAC:n teknisessä sovellusarkkitehtuurissa (kuva 17) näkyy selvästi olioväylän käyttö (vrt. kuva 8, luku 4.2). Kuva 17. NAC:n väyläpohjainen tekninen sovellusarkkitehtuuri (NAC 1998) Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

51 SELVITYS KOMPONENTTIARKKITEHTUURIMALLEISTA IBM SanFrancisco IBM SanFrancisco (IBM 2000) on Java / RMI pohjainen sovelluskehys ja arkkitehtuuri, joka piilottaa järjestelmän hajautuksen ja transaktioiden hallinnan teknisen toteutuksen sovelluskehittäjiltä. Se on monikerroksinen, yhteiskäyttöinen kehys, jonka avulla kehitetään alustariippumattomia, hajautettuja oliosovelluksia. San Francisco-järjestelmät koostuvat kolmesta kerroksesta: Foundation, Common Business Objects ja Core Business Processes. Foundation-kerros on hajautetun tietojenkäsittelyn peruskerros, joka peittää toteutustekniikat sovelluksilta tarjoamalla yleisiä toimintoja sovellusten kehittämiseen ja levittämiseen. Se sisältää sovellusrajapintoja hajautetuille palveluille kuten turvallisuus- ja transaktiopalveluille sekä yhdenmukaiset keinot sovellusten hallintaan. Näin se muodostaa pohjan SanFranciscon hajautetuille olioille. Hajautetuissa olioissa: käyttöliittymä on eristetty toimintalogiikasta, tiedonsäilytyspalvelu on eristetty, komento- ja valintalogiikka on eristetty toimintalogiikasta ja käyttöliittymästä ja toimintalogiikka voi olla hajautettua. Foundation-kerros on yhteydessä tietovarastoihin, luo oliot, tarjoaa toimialakomponenteille peruspalvelut (luonti, yhteys toimialakomponenttiin, päivitys, poisto), hallitsee hajautettujen olioiden toimintaympäristöä ja toimii nimipalvelimen kanssa olioiden sijoittamiseksi ja löytämiseksi. Common Business Objects (CBO)-kerros sisältää yleistettyjä mekanismeja, joita käytetään yleisesti liiketoimintajärjestelmien ongelmien ratkaisuissa. Kerros sisältää yleisesti liiketoiminnassa tarvittavia toimialakomponentteja, ja luokkia, jotka voivat poiketa monimutkaisuudessaan toisistaan paljonkin. Lisäksi tässä kerroksessa on liittymät liiketoiminnan sovellusalueen perusprosesseihin. Kuvassa 18 näkyy SanFranciscon kerroksellinen sovellusarkkitehtuuri. Kuva 18. IBM SanFrancisco sovelluksen kerrokset (IBM 2000) Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

52 52 OSA II: Taustaselvitykset 5.6 Johtopäätökset CCS-SIS -projektissa on saatu aikaan kansallisella yhteistyöllä ja standardoinnilla käyttökelpoisia tuloksia ja malleja jatkokehitykselle. Tähän on päästy keskittymällä nimenomaan komponenttiliittymien määrittelyjen yhtenäistämiseen. Brasilialaiset ovat aktiivisesti mukana kansainvälisessä yleisten palvelujen määrittelytyössä mm. OMG:n CORBAmed-työryhmässä. Komponenttivaraston keskeinen asema on ollut tärkeä onnistumisen edellytys CCS-SIS -projektissa. Mielenkiintoinen on myös käyttöliittymien rakentamisessa käytetty Connector-komponentin idea: komponentin avulla voidaan käyttöliittymä rakentaa käyttäen normaaleita käyttöliittymäkontrolleja, joilla ei ole erikoisominaisuuksia. Projektilla on yksinkertainen perusidea: kevyiden toimialakomponenttien tekeminen ilman raskasta komponentti-infrastruktuuria ja suuria yleispalveluita. Idea on käyttökelpoinen varsinkin silloin, kun siirtymistä komponenttipohjaiseen ohjelmistotuotantoon ollaan aloittamassa. CCS-SIS:n arkkitehtuurillinen lähestymistapa ei ole kuitenkaan koko arkkitehtuuria kattava. Mm. tiedon tallennuskerros on jätetty huomioimatta, ja toteutuksissa on käytetty tietokantapohjaisia ODBC-väliohjelmistoja avoimena tietokantarajapintana. Projektilla on myös ollut ulkoisista syistä johtuvia taloudellisia vaikeuksia, ja jatkokehityksen tilanne on epäselvä. RC Business Object Architecture pyrki puhdasveriseen toimialakomponentin toteutukseen: yksi ja ainoa komponenttikapseli sisältää sekä tietovaraston, käsittelysäännöt että käyttöliittymän. Tähän tavoitteeseen pyrittiin valitsemalla toisiaan mahdollisimman hyvin tukevat tuotteet. Toteutus ei kuitenkaan onnistunut edes erityisesti Smalltalk-lähtökohtaan sopivilla työkaluilla. Arkkitehtuurissa toimialakomponentin kommunikointiin ulkopuolisten komponenttien kanssa oli jätetty yhden varsin rajoittuneen ja riittämättömän mekanismin varaan, ja tietovarastoratkaisu nojautui pelkästään oliotietokannan käyttöön ottamatta muita mahdollisuuksia huomioon. Eräs tehty valinta oli määritellä myös esitystapaluokalle oma IDL-liittymä, kun toinen vaihtoehto olisi sijoittaa käyttöliittymän saataville palvelinkomponentin edustaja. Jos jokaisella toimialakomponentilla on käytössä vain oma käyttöliittymärajapintansa, voi käyttöliittymän rakentamisessa monen komponentin yhdistetyn näkymän rakentaminen ja käyttöliittymän kokonaisintegrointi vaikeutua. Käytännön toteutuksissa heterogeenisissä ympäristöissä ei liene mahdollista tehdä vain yhtä kapselia, joka sisältää kaikki toimialakomponenttiin kuuluvat kerrokset. Hajautuksen etuihin kuuluu mm. uusien hajautettujen osien itsenäinen jakelu. NAC:n Business Services Architecturen suuri ansio on yleisten palvelujen tarpeen tunnistaminen ja näiden palvelujen nimeäminen. Lisäksi arkkitehtuurissa on selkeästi erotettu eri kerrokset toisistaan, ja toimintalogiikka eriytetty selvästi muista kerroksista. Palvelupohjainen arkkitehtuuri vaatii kuitenkin raskaan infrastruktuurin ja suuren joukon palveluja, joiden pitäisi olla olemassa täysipainoisten sovellusten toteuttamiseksi. Infrastruktuurin vähittäinen rakentaminen on välttämätöntä, eikä palvelujen rakentamisjärjestykseen oteta kantaa. Käytännössä ennen sovellusten rakentamista onkin hankittava infrastruktuurin toteuttava tuote tai tuoteperhe valmiiksi. Lähestymistapa poikkeaa mm. CCS-SIS:stä siten, että myös tietopalvelut (Data Service) ovat saman komponenttitekniikan kautta käytettävissä kuin esim. toimintalogiikan toteuttavat palvelut. IBM:n SanFrancisco- kehyksessä on kypsä ja muunnettava arkkitehtuuri, joka tarjoaa runsaasti eri vapausasteita komponenttien toteuttamiselle. Mallia voidaan käyttää halutuilla tasoilla. Toimintaprosessien valmiiden kehysten tunnistaminen liiketoiminnan sovellusalalta sekä prosessikehyksiin sopivien komponenttien toteuttaminen on tuottavuutta lisäävä idea. Selkeät ohjeet mallin käyttämiseksi ja laajentamiseksi ovat välttämättömiä ja hyvin toteutettuja SanFrancisco-kehyksessä. SanFrancisco-sovelluskehys perustuu kuitenkin pelkän Javan käyttöön, eikä olemassa olevien sovellusten integrointia ole otettu riittävästi huomioon. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

53 SELVITYS KOMPONENTTIARKKITEHTUURIMALLEISTA 53 Tutkittujen arkkitehtuurimallien perusteella yleisiä periaatteita komponenttipohjaisten järjestelmien suunnittelussa ovat: olemassa olevien komponenttimallien ja viestistandardien käyttö, suunnittelun aikana keskittyminen vain komponenttiliittymiin, rajapintojen palvelupohjaisuus ja arkkitehtuurin monitasoisuus, joka mahdollistaa komponenttien hajautuksen sekä eri kerrosten selkeät vastuut. Tämän luvun esimerkeistä käy ilmi, että onnistuneissa komponenttitoteutuksissa on keskitytty komponenttien palvelujen määrittelyihin, olemassa olevien ja yleisten menetelmien käyttöön tai yleiskäyttöisten kehysten kehittämiseen ja tarvelähtöiseen suunnitteluun. Projekteissa, joissa toteutus ei ole onnistunut toivotulla tavalla, on sitouduttu liiaksi tiettyihin yksittäisiin tuotteisiin, jätetty huomioimatta tärkeitä toiminnallisuuden osa-alueita ja käytettävien välineiden mahdollisuuksia niiden toteuttamisessa sekä jätetty varautumatta järjestelmäympäristön heterogeenisuuteen. Toimialakomponenttien rakentaminen voidaan aloittaa yksinkertaisista komponenteista, jotka eivät vaadi kovin monimutkaista infrastruktuuria tuekseen, kuten on tehty CCS-SIS projektissa. Jotain tiettyä erityistehtävää hoitamaan rakennettavat komponentit ovat hyvä lähtökohta arkkitehtuurin rakentamiselle ja vähittäiselle toiminnallisuuden laajentamiselle. Yleisten palvelujen infrastruktuurin mukaisia palveluita ei ole yleensä valmiina sovellusten toimintaympäristöissä. Näin ollen ei voida nojautua vahvasti olemassa olevien palvelujen hyväksikäyttöön. Komponentti-FixIT -projektissa on syytä rajata yleiset palvelut tehtävien ratkaisujen ulkopuolelle. Kehitettävien toimialakomponenttien on kuitenkin kyettävä käyttämään yleisiä palveluja, joita infrastruktuuri tarjoaa. Jatkossa yleiset palvelut ovat osa hankittavaa sovellusinfraa, ja markkinoilla on jo infrastruktuurituotteita, jotka toteuttavat suuren määrän yleisiä palveluita komponenttimallien peruspalvelujen lisäksi. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

54 54 OSA II: Taustaselvitykset 6 KOMPONENTTIARKKITEHTUURI Tässä luvussa käsitellään karkeajakoisia komponentteja, eli hajautettuja ja toimialakomponentteja. Nämä suuret komponenttityypit yhdistetään hajautusarkkitehtuuriin sekä toiminnalliseen arkkitehtuuriin, jotka ovat kaksi näkemystä toimialakomponenttijärjestelmän arkkitehtuuriin. Tässä esitetty viitearkkitehtuuri ja komponenttityypit muodostavat myös luvussa 17 esitetyn tavoitearkkitehtuurin perusosat. Kompositiorajapinnan merkitys korostuu komponenttitekniikassa. Komponenttiliittymä muodostaa ainoan keinon muille ohjelmistoille käyttää komponentin palveluja johtaen selkeään arkkitehtuuriin. Rakenne noudattaa facade-suunnittelumallia (ks. luku 7.2) piilottaen komponentin muodostavien lukuisten luokkien palvelut yhden ja ainoan komponenttiliittymäluokan palveluiksi. Tämä on selvä etu verrattuna monien oliopohjaisten järjestelmien vaikeaan hallittavuuteen ja vaikeaselkoisuuteen, joka johtuu olioiden välisten riippuvuuksien suuresta määrästä. Hajautetut komponenttiarkkitehtuurit mahdollistavat hyvin eritasoisten ja eri tehtäviä hoitavien komponenttien kapseloinnin ja integroinnin. Komponentti-FixIT -projektissa pääpaino on toimialakomponenttien (business components) tekemiseen tarkoitettujen välineiden luomisessa, mutta arkkitehtuurissa on usein myös muunlaisia komponentteja, jotka tukevat toimialakomponenttien toteutusta, ja nämä komponentit voivat mm. olla osa välineistöä, jolla toimialakomponentteja rakennetaan. On välttämätöntä esittää myös arkkitehtuurillinen kehys, jos hajautetuille komponenteille aiotaan tehdä tuottavuusvälineitä, joilla eri osat toiminnallisen kokonaisuuden toteuttavasta komponentista saadaan tehokkaasti toimimaan keskenään. Arkkitehtuurin ja pitkälti myös komponenttisovelluksen rakentamisen perusperiaatteita ovat (Herzum, Sims 2000): kehämäisten riippuvuuksien välttäminen sekä toimialakomponenttien välillä että (varsinkin) toimialakomponentin hajautettujen osien välillä arkkitehtuurin normalisointi: kunkin ohjelmiston osan ja toiminnon tulisi kuulua yhteen ja vain yhteen komponenttiin kerroksellisuus: joko suljettujen tai avointen kerrosten 6 avulla yhdenmukaisuus: samanlaiset osat toimivat samalla tavalla ajallinen koheesio, ei suunnittelukoheesio: samaan aikaan käytettävien osien on oltava yhdessä vs. suunnittelun aikana toisiinsa liittyvien osien olisi oltava yhdessä. (Ks. myös koheesioperiaatteet, luku 7). 6.1 Hajautettu komponentti Toimialakomponentin osana oleva hajautettu komponentti (distributed component, DC) (Herzum, Sims 2000) on osa toimialan jonkin käsitteen toteutusta tietojärjestelmässä. Se on toteutettu esimer- 6 Suljetut kerrokset ovat arkkitehtuurin kerroksia, joiden läpi ei näy, eli ylin kerros ei voi ottaa yhteyttä kolmanneksi ylimmässä kerroksessa toimivaan palveluun, vaan pelkästään toiseksi ylimpään kerrokseen. Avoimissa kerroksissa yhteydet välikerrosten ohi sallitaan. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

55 KOMPONENTTIARKKITEHTUURI 55 Interface -operation c Services Implementation Interface -operation a -operation b Dependencies of other components (proxies) Kuva 19. Hajautettu komponentti Socket (dependencies of component execution environment) kiksi EJB-, CORBA- tai DCOM-komponenttina, eli sen komponenttiliittymä noudattaa jotain komponenttimallia. Hajautettu komponentti on yleensä toteutettu olio-ohjelmointikielellä, ja se on karkeajakoisuudeltaan palvelutason komponentti (ks. luku 2.1). Hajautetulla komponentilla on oma sisäinen rakenteensa, johon sen toteuttavat ohjelmointikielen luokat sopivat. Vaihtoehtoisesti hajautettu komponentti voi kapseloida komponenttiliittymänsä taa myös perinnejärjestelmän toteutuksen, jolloin komponenttiliittymän operaatiot ovat perinnejärjestelmässä toteutettavia toimintoja. Tällöin hajautetun komponentin sisäinen toteutus on sovitin (ks. sanasto), joka ohjaa komponenttiliittymän palvelupyynnöt vanhaan järjestelmään ja vanhan järjestelmän toimintojen tulokset palvelukutsujen vastauksiksi tai palvelupyynnöiksi toisille komponenteille. Hajautetulla komponentilla (ks. kuva 19) voi olla useita komponenttiliittymiä (interface), ja kullakin komponenttiliittymällä voi olla useita operaatioita. Hajautettu komponentti voi käyttää muiden komponenttien palveluita, jolloin se on näiden palvelujen saatavuudesta riippuvainen. Muiden komponenttien palvelujen käyttö voi tapahtua komponentin proxy-rajapinnan avulla. Muiden komponenttien tarjoamien palveluiden lisäksi hajautettu komponentti voi olla riippuvainen komponenttien suoritusympäristöstä, joka tarjoaa mm. käytettävän käyttöjärjestelmä- ja laitteistoalustan, komponenttimallin sekä mahdollisesti yleiskäyttöisiä palveluita (socket). Hajautettu komponentti voi olla joko tyyppiperusteinen tai esiintymäperusteinen. Arkkitehtuurityylit-luvussa (luku 8) on käsitelty eri arkkitehtuurityylien eroja ja käyttökohteita. Hajautettu komponentti toteuttaa tyypin, eli suoritettavana oleva hajautettu komponentti (komponentti-esiintymä) tekee yhden tai useamman tyyppi-esiintymän (olion) riippuen arkkitehtuurityylistä. Hajautettu komponentti vastaa itse omasta toiminnastaan, ja sen luomaa oliota ei kopioida paikasta toiseen (pass by value) vaan siihen viitataan olioviittauksella (pass by reference). Hajautetulla oliolla (esim. CORBA-olio, jona hajautettu komponentti näkyy verkossa), on tietty toteutuksesta riippumaton verkkoliittymä. Hajautetun olion tyypillinen elinkaari on seuraava (Arseniev 1997): Hajautettu olio rekisteröi itsensä verkon hakemistoon nimellään ja liittymäpalveluillaan. Jos verkossa oleva toimija tarvitsee olion palveluja tai tietoja, se voi suorittaa hakemistokyselyn löytääkseen tietyn hajautetun olion nimen tai liittymän perusteella. Verkon toimija voi kutsua hajautetun olion palveluja esimerkiksi sen tietojen lukemista tai asettamista varten. Asetusmetodit voivat esim. muuttaa hajautetun olion tilaa (ks. luku 8.1, esiintymäperusteinen tyyli). Business Object -nimeä käytetään usein hajautetusta toimintalogiikkatason (enterprise) komponentista Näin ollen Business Object -nimellä kutsuttavat toimialakomponentit ovat erikoistapaus hajautetuista komponenteista. Jos hajautettu komponentti on tehty oliokielten luokista, sisäisessä toteutuksessa käytettävät luokat voidaan luokitella esim. seuraavasti (Bralick 1999): Rajaluokka (boundary) on järjestelmän luokka, joka on yhteydessä ulkopuoliseen toimijaan. Tällä luokalla mallinnetaan järjestelmän ja toimijan välinen vuorovaikutus, mutta siinä ei tarvitse kuvata, Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

56 56 OSA II: Taustaselvitykset miten vuorovaikutus todellisuudessa tapahtuu. Kunkin boundary-luokan pitäisi olla suhteessa ainakin yhteen ulkopuoliseen toimijaan (ja päinvastoin). Entiteettiluokalla (entity) mallinnetaan pitkäikäistä, pysyvää tietoa ja siihen liittyvää toimintoa ja käyttäytymistä tai käsitettä. Tämä luokka näyttää usein loogisen tietorakenteen ja kertoo mistä tiedosta järjestelmä on riippuvainen. Kontrolliluokka (control) esittää koordinaatiota, sekvenssiä, transaktiota ja muiden olioiden hallintaa. Kapseloi esim. mallinnuksessa löydettyyn käyttötapaukseen liittyvän kontrollin. Esittää usein monimutkaista laskentaa tai johdannaisuutta. Muutokset koordinaatioon, sekvenssiin, transaktioon jne. voidaan tehdä kontrollikomponenttia tai -luokkaa muuttamalla. Luokkatyyppien tarkempi jaottelu kuvataan hajautetun komponentin rakentamista käsittelevässä luvussa (luku 15). 6.2 Hajautusarkkitehtuuri Hajautettuja komponentteja käytetään komponenttijärjestelmässä loogisen hajautuksen periaatteella: kukin hajautuskerros vastaa joistakin tähän kerrokseen soveltuvista toiminnoista, ja kerroksia voidaan fyysisessä hajautuksessa yhdistellä tarvittaessa. Saman kerroksen hajautetut komponentit voivat kommunikoida keskenään. Lisäksi ylemmän kerroksen hajautetulle komponentille on sallittua kommunikoida edellisen alemman kerroksen komponenttien kanssa. Tässä esitetty hajautusarkkitehtuuri noudattaa luvussa 5.1 esitettyä nelikerroksista viitearkkitehtuuria. Hajautettujen komponenttien kategoriat hajautuskerrosten mukaisesti (Herzum, Sims 2000): Käyttöliittymä (user): rakennetaan käyttöliittymän esitystä varten. Vain tämän kerroksen komponenteilla on käyttäjärajapinta (ks. luku 2.1). Käyttöliittymäkomponentti voi olla suunniteltu säilyttämään oman pysyvän tietonsa (esim. ikkunan koko tai sijainti, mitä tietoja näytetään). Käyttöliittymäkomponentti on aina loppukäyttäjän työasemalla, koska sen on reagoitava käyttäjän syötteisiin. Käyttöliittymäkomponentti saa tarvitsemansa datan edustajakomponentilta. Fyysisesti käyttöliittymäkerros sijoitetaan niin lähelle käyttöliittymän toteuttavaa näyttötekniikkaa kuin mahdollista. Työtilakerroksen (workspace) Edustaja: rakennetaan yhden käyttäjän tarpeita silmällä pitäen, eikä tarvitse ottaa huomioon useita yhtäaikaisia käyttäjiä. Tähän komponenttiin voidaan rakentaa esim. toimintalogiikkaa silloin, kun se on järkevintä sijoittaa käyttäjän työasemalle, mutta edustaja voi olla myös eri koneella kuin käyttäjä (esim. www-palvelin). Edustaja on yhteydessä toimintalogiikkakomponenttiin ja sisältää mm. tyngän toimintakerroksen komponentin käyttämiseksi. Toimintataso (enterprise): yleistä toimintalogiikkaa sisältävän komponentin on oltava yhtäaikaisesti useiden käyttäjien käytettävissä palvelimella. Se tarvitsee tiedon pysyvyys- ja transaktiopalveluja. Toimintatason komponentti toteuttaa pääasiallisesti toimialakomponentin toimintalogiikan. Resurssi (resource): hajautettu komponentti jaettujen resurssien hallintaan. Resurssikomponentti ei sisällä lainkaan toimintalogiikkaa. Tyypillinen resurssikomponentti tarjoaa tietokantayhteyden, eli sillä on datarajapinta. Resurssikomponentti hakee ja tallentaa tietoa toimintatason komponentin pyyntöjen mukaisesti. Edellä mainittujen neljän kategorian mukaisten komponenttien avulla toteutetaan komponenttiarkkitehtuurin kerroksellisuus. Lisäksi voidaan käyttää vielä kahden tyyppisiä hajautettuja komponentteja: Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

57 KOMPONENTTIARKKITEHTUURI 57 Yhdyskäytävä (gateway): komponentti joka on tarkoitettu välikappaleeksi muihin palveluihin tai komponentteihin. Esimerkiksi ulkopuolinen järjestelmä voi käyttää yhdyskäytävän avulla toimialakomponentin palveluita. Testaus (testing): testauskomponentin avulla voi testata toistuvasti hajautettua tai toimialakomponenttia tai sen osaa. Testauskomponentti voi olla tarkoitukseen erityisesti suunniteltu tai toimia skriptipohjaisesti. Kuvassa 20 näkyy hajautettujen komponenttien avulla toteutettu toimialakomponentti viitearkkitehtuurissa. 6.3 Toimialakomponentti Toimialakomponentin (Business Component / Business Object) määritelmiä: Virallinen versio: "Business Objects are representations of the nature and behaviour of real world things or concepts in terms that are meaningful to the enterprise. Customers, products, orders, employees, trades, financial instruments, shipping containers and vehicles are all examples of real-world concepts or things that could be represented by Business Objects." (OMG 1995) Komponenttimarkkinaversio: A component that supports a specific piece of business logic or expertise, for example, credit card authorization or address deduplication. Most do not have a user interface or presentation layer so you can customize the front end to your own design. (Componentsource 2000) What is a Business Object (Ingenia 1998)? A representation of a thing in the business domain A unit of delivery which cooperates with other Business Objects by passing messages A software component that is part of a framework of cooperating business objects designed to achieve a particular business or technical purpose. High level business components which appear as icons on a graphical user interface and can be assembled to implement some particular business process. Allows ad-hoc integration by end-users Näiden määritelmien perusteella toimialakomponentti kapseloi siis tosimaailman olion käyttäytymisen ja ominaisuudet kokonaisuudessaan uudelleenkäytettäväksi komponentiksi. Toimialan olioiden suhteet voidaan mallintaa toimialakomponenttien välisinä suhteina, ja toimialakomponentin ominaisuuksien määrittelyn sekä sovelluksen koostamisen toimialakomponenteista voi suorittaa toimialan asiantuntija. Komponenttien standardit kiinnittävät huomiota komponenttien verkkoon julkistamiin liittymiin eivätkä niiden sisäiseen toteutukseen. Standardeissa tuetaan toimialakomponenttien rakentamista käärimällä perinnejärjestelmän toteutus verkkoliittymän sisään (sovitin), ja määritellään metodeja, joilla toimialakomponentteja kutsutaan ja joilla ne kommunikoivat keskenään. Useat (näistäkin) määritelmistä kuvaavat myös toimintatason hajautettuja komponentteja. Selvyyden vuoksi tässä dokumentissa toimialakomponentista käytetään seuraavanlaista määritelmää: Toimialakomponentti koostuu hajautetun järjestelmän osana olevan toimialan käsitteen tai prosessin esittämiseen, toteuttamiseen ja jakeluun tarvittavista ohjelmistoista. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

58 58 OSA II: Taustaselvitykset Toimialakomponentti on hajautettujen komponenttien yhdistelmä (ks. kuva 20), ja se voi sisältää useita edellä kuvattuja hajautettuja komponentteja (Herzum, Sims 2000). Karkeajakoisuudeltaan (ks. luku 2.1) se on liiketoimintapalvelutason komponentti. Toimialakomponentti kuuluu yhdistävänä käsitteenä toiminnalliseen arkkitehtuuriin, kun taas sen hajautetut komponentit ovat teknisen arkkitehtuurin toiminnallisia osia. Dependency Toimialakomponentin rakenne (ks. kuva 20) koostuu enimmillään neljästä hajautetuilla (teknisillä) komponenteilla toteutetusta loogisesta kerroksesta: käyttöliittymä- (user), työtila- (workspace), toiminta- (enterprise) ja resurssi- (resource) kerrokset. Kerrosten väliset suhteet on määritelty komponentin sisällä tarkasti. Viestit kulkevat toimialakomponentin sisällä ylhäältä alaspäin, päinvastaiseen suuntaan tapahtuvaan kommunikointiin voidaan käyttää esim. tapahtumia (events). Jakelua varten kerrokset voidaan organisoida esim. siten, että käyttäjä- ja työtilakerros muodostavat oman jakeluyksikkönsä (esim. käyttäjän työasemalla), ja toiminta- ja resurssikerrokset oman yksikkönsä (esim. sovellus- ja tietokantapalvelimella). Kokonainen toimialakomponentti on hajautuskerrosten välinen yhdistävä tekijä ja summa. Se sisältää sekä tietovaraston, käsittelylogiikan, työtilan (esim. työpöytäintegraatio, luku 11.3) että tiedon esityksen käyttäjälle. Sen muodostavien hajautettujen komponenttien suoritusympäristö hoitaa hajautuksen vaatimat seikat. Näin ollen toimialakomponentti voi olla fyysisesti sijoitettu kahdelle tai useammalle koneelle, ja sen hajautetut osat voivat myös sijaita eri paikoissa. Tärkeä osa toimialakomponentin määrittelyä ja toteutusta ovat sen riippuvuudet. Riippuvuudet ovat paitsi toiminnallisia (riippuvuuksia muista toimialakomponenteista), myös riippuvuuksia komponenttien suoritusympäristöstä. Toimialakomponentti esittää suhteellisen itsenäistä käsitettä (esim. ei osoite, mutta potilas) tai prosessia (esim. lähetteen kirjaaminen, ei potilaan osoitteen muuttaminen). Sitä käsitellään itsessään komponenttina suunnittelun, toteutuksen, suorituksen ja jakelun aikana. Vaikka toimialakomponentti on itsenäinen, se ei ole eristetty; se tarjoaa yhteistoiminnallisuuden toteuttavia rajapintoja muiden toimialakomponenttien käyttöön ja voi olla riippuvainen muiden komponenttien tarjoamista palveluista. Toimialakomponentilla on tarkasti määritellyt rakentamisen aikaiset ja ajonaikaiset liittymät, se voidaan liittää itsenäisesti ajonaikaiseen ympäristöön, ja siihen voidaan viitata ajon aikana verkossa. Tätä varten tarvitaan tekninen infrastruktuuri, joka tarjoaa komponentille elinympäristön. Business component User Workspace Enterprise Resource Socket Plug user interface framework local CEE (Java, COM) enterprise CEE persistence framework Kuva 20. Toimialakomponentti ja komponentin suoritusympäristö Infrastructure CEE = component execution environment Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

59 KOMPONENTTIARKKITEHTUURI 59 Taulukko 5. Toimialakomponenttien toiminnalliset kategoriat (Herzum, Sims 2000) Kategoria Komponenttien kuvaus Varuskomponentti (Utility) Entiteetti (Entity) Prosessi (Process) Ulkoinen (Auxiliary) Yleiskäyttöisiä komponentteja, jotka voivat olla esim. perustoimintoja tukevia, mahdollisesti useissa toimialakomponenttijärjestelmissä tarvittavia käsitteitä. Voivat olla yleiskäyttöisiä, komponenttimarkkinoilta tai yleisestä varastosta saatavia komponentteja. Esim. osoitekirja, valuuttakonvertteri, laboratoriotutkimusnimikkeistö. Edustavat sovelluksen ja toimialan peruskäsitteitä, joilla toimintaprosessit toteutetaan. Entiteettikomponenttien tarjoamat palvelut tukevat entiteettien hallintaa, ylläpitoa, ryhmittelyä, linkityksiä, esitystä, konvertointia jne. Esim. Potilas, Tilaus Edustava toimialan prosessia tai aktiviteettia. Monissa tapauksissa prosessikomponentit avustavat käyttäjää jonkin toimialan tehtävän suorittamisessa toteuttaen kyseisen tehtävän esim. entiteettikomponentteja käyttämällä. Komponentti, joka ei ole toiminnallisessa yhteydessä välttämättä mihinkään sovellukseen, vaan jota tarvitaan tukemaan järjestelmän kehitystä tai suoritusta. Tällaisia komponentteja voivat olla esim. tietokannan yhtenäisyyttä valvova komponentti, tai järjestelmän suorituskykyä tarkkaileva ja siitä raportoiva komponentti. Toimialakomponentit voidaan luokitella erilaisia tehtäviä hoitaviin komponentteihin (ks. taulukko 5). Nämä toiminnalliset kategoriat ovat lähes ristikkäisiä hajautettujen komponenttien kerrosten mukaisten kategorioiden kanssa: kuhunkin kategoriaan kuuluva toimialakomponentti voi sisältää yhdessä tai useammassa kerroksessa olevia hajautettuja komponentteja. Onkin huomattava, että samanlaisia toiminnallisia rooleja voi olla varsinkin myös palvelimilla toimivilla toimintatason hajautetuilla komponenteilla. Toimialakomponentin esittäminen voi olla toisen toimialakomponentin tarjoaman käyttöliittymän vastuulla. Käyttöliittymän ei myöskään tarvitse olla täydellinen tai itsellinen, esimerkiksi voi olla, että toimialakomponentti tarjoaa vain perus liittymän esim. yksinkertaisen paneelin ja hakukäyttöliittymän, ja sille voidaan tehdä tarpeen mukaan uusi käyttöliittymä tai juuri tiettyyn tilanteeseen soveltuva käyttöliittymä voi olla toisen toimialakomponentin vastuulla (esim. kyseisen toimintaprosessin toteuttava komponentti). 6.4 Komponenttijärjestelmä Toimialakomponenteista koostettu järjestelmä sisältää sekä toiminnalliset kerrokset (prosessikerros, entiteettikerros, varus- (utility) komponenttikerros) että hajautuskerrokset, jotka muodostuvat toimialakomponenttien kerroksista. Tämän toiminnallisen arkkitehtuurin kerrokset muodostuvat prosesseja ohjaavista toimialakomponenteista ja yleiskäyttöisistä sekä tietyn sovelluksen toimintoja edustavista komponenteista. Kerrosten tarkoituksena onkin jaotella toiminnallisuutta, ei teknistä toteutusta. Toiminnallinen arkkitehtuuri poikkeaa näin esim. hajautusarkkitehtuurista siten, että sen kerrokset eivät ole suljettuja vaan avoimia kerroksia: ylimmän toiminnallisen kerroksen komponentti voi ottaa yhteyttä esim. kolmanneksi ylimmän kerroksen komponentteihin. Kuitenkin myös toiminnallisessa arkkitehtuurissa pyritään ylhäältä alas kulkeviin kutsuihin ja kehämäisten riippuvuuksien välttämiseen. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

60 60 OSA II: Taustaselvitykset Lab Test application Process Lab Test Manager Performance Monitor Entity Lab Test Department Patient Databas e Integrity Manager Utility Lab Test CodeBook Test Result Calculator AddressBook Auxiliary Kuva 21. Komponenttijärjestelmä toimialakomponenttien toiminnallisina suhteina Tietojärjestelmä kootaan toimialakomponenteista, jotka koostuvat hajautetuista komponenteista. Hajautetut komponentit koostuvat esim. ohjelmointikielten luokista. Myös koko tietojärjestelmälle voidaan tehdä komponenttiliittymä, jolloin kyseessä on sovellustason komponentti. Komponenttijärjestelmän tasolla kehämäisten riippuvuuksien välttämisestä voidaan tinkiä tietyissä tapauksissa, jos pidetään huolta siitä, että eri toimialakomponenttien hajautettujen komponenttien välillä ei ole kehämäisiä riippuvuuksia (esim. komponentin työtilaosa voi kutsua toisen komponentin toimintapalveluita, jotka käyttävät ensimmäisen komponentin omia toimintapalveluita). Komponenttijärjestelmällä voi olla omia ulkoisia liittymiä, jotka eivät kuulu mihinkään sen toimialakomponenteista. Myös sen osana olevat komponentit voivat tarjota omia liittymiään järjestelmän ulkopuolelle. Järjestelmän ulkopuolisten liittymien tarjoamisessa ei yleensä voida tehdä oletuksia liittymiä käyttävien muiden järjestelmien toiminnasta tai luotettavuudesta, joten liittymissä on otettava enemmän mm. turvallisuusnäkökohtia huomioon kuin järjestelmän sisäisten liittymien suunnittelussa. Komponenttijärjestelmän liittymien käyttöä järjestelmien integroinnissa käsitellään luvussa Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

61 KOMPONENTTEN MALLINTAMINEN JA SUUNNITTELU 61 7 KOMPONENTTIEN MALLINTAMINEN JA SUUNNITTELU Toimialakomponenttien toteutuksen lähtökohtana voi olla: 1. UML- tai muun suunnittelun tuottamat spesifikaatiot (business engineering), 2. olemassa oleva sovellus tai 3. standardi tai sovittu käytäntö. Kirjallisuudessa korostetaan, että toimialakomponenttien tulisi syntyä toimintaprosessien uudelleensuunnittelun tuloksena. Toimialakomponenttien mallien pitäisi olla toimialan asiantuntijoiden suunnittelemia. Suunnittelumenetelmät ovat orientoituneita uusien järjestelmien tuottamiseen, eikä vanhojen järjestelmien toiminnallisuutta ja uudelleenkäyttömahdollisuuksia tai niiden vaikutuksia toimialan tai prosessien mallintamisessa ole otettu riittävästi huomioon. Komponentti-FixIT projektissa pyritäänkin rakentamaan välineet, joilla voidaan rakentaa toimialakomponentteja nykyiseltä tekniseltä pohjalta ottaen huomioon kaikki edellä mainitut lähtökohdat. Komponentti-FixIT -projektissa ainakin osa toiminnallisuudesta ja varsinkin suuri osa järjestelmän tietosisällöstä on ennestään olemassa FileMan-tietokannassa ja M-palvelimella sekä työaseman sovellusohjelmassa. Komponenttipohjaisessa suunnittelussa korostuvia seikkoja (Isokallio, Skwarek 2000): hienojakoinen tai karkeajakoinen lähestymistapa 7, luokan ja komponentin ero, tietotyyppimuunnokset, hajautus, tapahtumankäsittely, tilallisuus ja tilattomuus (ks. myös luku 8) ja pysyvyys (ks. myös luku 10). Toimialakomponenttiin sisällytettävien toimintojen tulisi muodostaa itsenäinen kokonaisuus, joka on sopivan karkeajakoinen. Sopivan karkeajakoisuuden määrittely riippuu asiayhteydestä, eikä yhtä oikeaa tapaa sen määrittelyyn ole. Heuristisia sääntöjä sopivan kokoisten komponenttien löytämiseen ovat (Herzum, Sims 2000): reaalisuus: käsitettä käyttävät ja sen ymmärtävät toimialan ihmiset, itsenäisyys: käsitettä käytetään ilman, että herää kysymys siitä, minkä toisen käsitteen osa se on, tarve: toimialakomponentin tulee täyttää markkinoilla 8 vallitseva tarve, olla helposti markkinoitavissa tai on oltava helposti perusteltavissa, miksi käsite kannattaa toteuttaa komponenttina, 7 Hienojakoisten ja karkeajakoisten operaatioiden avulla voidaan hoitaa osin samoja tehtäviä. Hienojakoiset operaatiot hoitavat pientä toiminnallisuutta (esim. Potilas.SetNimi), ja niillä on suhteellisen yksinkertaiset parametrit. Karkeajakoiset operaatiot hoitavat suurempaa toimintakokonaisuutta (esim. Potilas.SetPotilaanTiedot) ja parametreja voi olla runsaasti tai ne voivat olla monimutkaisia tietorakenteita. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

62 62 OSA II: Taustaselvitykset itsenäinen kehittäminen: toimialakomponenttien tulee olla sen kokoisia, että niiden itsenäinen kehittäminen on mahdollista esimerkiksi 2-3 henkilön työpanoksella, yhteenkuuvuus (koheesio): ainakin jonkin yhteenkuuluvuusperiaatteen on toteuduttava toimialakomponentin sisällä: - ajallinen: kehitystyön ja jakelun jälkeisen jatkokehityksen aikana komponenttiin kuuluvat käsitteet muuttuvat luultavimmin yhdessä ja yhtä aikaa, - toiminnallinen: komponenttiin kuuluvat toiminnot muodostavat loogisesti toisiinsa liittyvän kokonaisuuden, - suorituksen aikainen: on teknisesti järkevää sijoittaa suoritettavia moduuleita samaan osoiteavaruuteen, etenkin jos moduulien välillä tarvitaan laskentatehoa vaativaa vuorovaikutusta, - toimija: tietyn komponentin käyttäjien tulisi olla suhteellisen samanlaisissa rooleissa; jos komponenttia kutsutaan hyvin erilaisilla operaatioilla hyvin erilaisten käyttäjien toimesta, kannattaa harkita komponentin jakamista pienempiin osiin; myös saman omistajan komponentit voivat kuulua yhteen. stabiilius: tunnistettujen komponenttien tulisi olla järjestelmässä aina tai yleensä läsnä olevia käsitteitä, vaikka niiden sisältö tai tarkka toiminnallisuus muuttuisikin; jakaminen tai yhdistäminen jälkikäteen on kallista ja aikaa vievää, ja keskeinen kysymys on niiden piirteiden löytäminen, jotka tekevät käsitejoukosta itsenäisen kokonaisuuden, yleiskäyttöisyys: useat yleiskäyttöiset (varuskomponentti (utility) -tyyppiset) komponentit eivät välttämättä löydy mallintamalla ongelma-aluetta, vaan esim. toistuvien toiminnallisten piirteiden ja käyttökelpoisuuden perusteella; esimerkiksi muistiinpanot-komponentti, joka voi liittyä moniin sinällään itsenäisiin käsitteisiin voi tulla käyttäjien toivomuslistalle vasta kauan järjestelmän käyttöönoton jälkeen. 7.1 Sovellusalueen ja komponenttien mallintaminen Komponenttipohjaisessa ohjelmistotuotannossa on asetettu entistä suurempia vaatimuksia sovellusalueiden ja sovellusten mallintamiselle. Mallinnuksessa korostetaan nykyisin toimintaprosesseista ja niiden uusimisesta lähtevää oliopohjaista suunnittelua. UML (Fowler 1999) on yleisesti käytetty notaatio komponenttisuunnittelussa. UML ei ota kantaa siihen, millaisella prosessilla (ks. luku 3.1) sovelluksia mallista kehitetään, vaan sillä tehtyjä malleja voi käyttää erilaisissa kehitysprosesseissa. UML:n etuna on se, että sillä voidaan mallintaa viittä suunnittelussa tarvittavaa näkymää (Tanuan 2000): skenaariot: esittää käyttäjän vuorovaikutuksen järjestelmän kanssa (käyttötapauskaavio, yhteistoimintakaavio), prosessinäkymä: esittää aktiivisten olioiden yhtäaikaisuuden tai tietyn olion tilan (tilakaavio, sekvenssikaavio, yhteistoimintakaavio, aktiviteettikaavio), 8 Markkinat voivat olla myös organisaation sisäisiä. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

63 KOMPONENTTEN MALLINTAMINEN JA SUUNNITTELU 63 looginen näkymä: esittää toiminnalliset komponentit ja niiden rakenteelliset suhteet (luokkakaavio 9, komponenttikaavio), kehitysnäkymä: esittää koodikomponenttien organisoinnin (tarkka luokkakaavio) ja fyysinen näkymä: näyttää komponentin sijoittelun eri verkkosolmuihin (sijoittelukaavio). Käyttötapauslähtöisessä suunnittelussa suunnittelun pohjaksi otetaan käyttötapaukset. Myös vanhojen sovellusten toiminnallisuuden havainnollistamisessa käyttötapausten laatimisesta voi olla hyötyä. Käyttötapauksia tulisi laatia järjestelmän tärkeimmistä ja monimutkaisimmista toiminnoista. Käyttötapauksista kirjoitettavien kuvausten pohjalta syntyvät yleensä ehdokkaat tärkeimmiksi entiteettikomponenteiksi (substantiivit kuvauksissa). Olemassa olevissa esim. FileMan-järjestelmissä ehdokkaat voivat olla tietosisällöltään esim. FileMan-tiedostoja. Valittujen ehdokkaiden perusteella voidaan piirtää luokkakaavio komponenttien luokista. Myös luokkien väliset suhteet kuvataan luokkakaaviossa. Luokkakaavion tekemisen jälkeen voidaan jatkaa esim. tarkentamalla käyttötapauksia tai piirtämällä vuorovaikutuskaavio, jossa luokkien välistä toimintaa mallinnetaan. Nämä tarkennetut kaaviot johtavat jälleen luokkakaavion tarkentamiseen. Tarkennetusta luokkakaaviosta voidaan pyritään erottamaan samaan toimialakomponenttiin kuuluvat luokat. Suunnittelussa on erotettava selkeästi, mitkä ovat luokkapiirteitä tai ominaisuuksia (esim. olion haku hakuavaimella), mitkä taas tietyn luokan esiintymään (olioon) liittyviä piirteitä tai ominaisuuksia (esim. olion tietojen tallennus). Luokkien ja olioiden välisiä suhteita on kolmen tyyppisiä (Callista 1999): yleistäminen (generalization) ja perintä (inheritance) luokkien välillä, kooste (aggregation) tai kompositio 10 (composition, vahva kooste) olioiden välillä ja assosiaatio (association) olioiden välillä. Joissakin suunnitteluvälineissä ei ole luvallista käyttää perintää pysyvien luokkien välillä. Luokkien välistä polymorfismia tai perintähierarkian olioiden pysyvyyttä ei tueta kaikissa välineissä. Perintää tuleekin käyttää harkiten ja on varmistettava, että sitä käytettäessä suunnitelmat pystytään siirtämään myös käytäntöön. Luokkien välisiä suhteita määriteltäessä on määriteltävä, onko kyseessä kooste vai assosiaatio, ja lisäksi on määriteltävä suhteen molempiin päihin kardinaliteetti, eli montako osanottajaa suhteessa voi olla kumpaankin suuntaan luettuna. Peruskardinaliteetit ovat yhdestä yhteen (1:1), yhdestä moneen (1:n) ja monesta moneen (n:n) suhteet. Jokaiselle suhteelle voidaan määritellä rooli molempiin suuntiin, eli mitä suhde tarkoittaa kumpaankin suuntaan luettuna. Mallinnusvälineiden ja toteutustekniikoiden välistä kuilua kaventamaan on kehitteillä useita ratkaisuja, mm. OMG:n määrittelemä MOF (Meta Object Facility) (OMG 1999a) (ks. sanasto). Tyypillinen MOF:n ja mallivaraston käyttötapa voisi olla seuraavanlainen: 9 Luokkakaaviota käytetään usein monilla eri tasoilla projektissa: toimialan mallintamisessa (analyysivaihe), järjestelmän pääluokkien mallintamisessa (suunnitteluvaihe) ja toteutuksen yksityiskohtaisessa suunnittelussa (toteutusvaihe). 10 Kompositio oliomallinnuksen yhteydessä poikkeaa käsitteenä hieman kompositiona tapahtuvasta sovelluksen rakentamisesta (koostaminen), jossa sovellukset kootaan komponenteista. Oliomallinnuksen kompositio-käsite tarkoittaa, että koostamiseen käytetty osa poistetaan samalla kun kokonaisuus poistetaan, ja on näin tiukempi kuin määritelmä kuin sovellusten koostaminen komponenteista, joita voidaan käyttää useissa sovelluksissa. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

64 64 OSA II: Taustaselvitykset 1. Järjestelmän suunnittelija määrittelee sopivilla (MOF:ia tukevilla) välineillä oliopohjaisen tietomallin, joka tallennetaan mallivarastoon. 2. Tallennetusta mallista voidaan generoida suoraan esim. CORBA IDL-liittymämäärittelyt (MOF:n ja CORBA:n IDL:n välinen kuvaus on määritelty) 3. Suunnittelija tai ohjelmoija tutkii ja tarkentaa IDL-määrittelyjä toistaen kohtia 1 ja Ohjelmoija toteuttaa IDL-määrittelyjen mukaisen palvelimen ja rakentaa normaalisti sitä käyttävät asiakasohjelmistot. Lisävälineet voivat esim. tuottaa osan palvelimen toteutuksesta valmiiksi tai laajentaa mallivarastopalvelua tallentamaan myös tehdyt spesifikaatiot tai toteutukset. MOF:a käytettäessä mallinnusvälineillä tehdyt mallit tallennettaisiin varastoon, ja varastossa olevia malleja käyttävällä välineellä voitaisiin tuottaa alustava toteutus sovellukselle, esim. valmiit komponenttirajapinnat. MOF kuuluu OMG:n arkkitehtuurissa (ks. luku 4) yleisten toimintojen (Common Facilities) joukkoon. 7.2 Suunnittelumallit ja sovelluskehykset Oliopohjaisen uudelleenkäytön pohjana voidaan käyttää joko perintää tai koostetta (Gamma ym. 1995). Perinnän avulla luokista voidaan johtaa uusia alityyppejä, jotka perivät ylätyyppinsä liittymän, jonka operaatiot pystytään määrittelemään uudelleen. Luokan alityyppiä voidaan käyttää itse ylätyypin asemasta suorituksen aikana (polymorfismi). Polymorfismin käyttö vähentää ohjelmiston riippuvuuksia, koska luokkia pystytään lisäämään hierarkiaan tekemättä muutoksia niitä käsitteleviin algoritmeihin. Perinnän käyttö johtaa suuriin luokkahierarkioihin ja siihen, että uudelleen määriteltävien operaatioiden tarkka toteutus on tunnettava, jotta perittävä luokka ei muodostu semanttisesti yhteensopimattomaksi yläluokan kanssa. Lisäksi yläluokan toteutuksen muuttuessa saatetaan joutua tekemään vastaavat korjaukset alaluokkiin. Näin ollen perintä on valkea laatikko -uudelleenkäyttöä. Koostetta käytettäessä olioiden liittäminen tapahtuu väljemmin kuin perinnässä, välittämällä olioviittauksia toisille olioille. Olion tarvitsee tietää vain toisen olion olioliittymä voidakseen käyttää tämän palveluja. Kooste säilyttää tiedon ja toteutuksen kapseloinnin, ja on siten musta laatikko -uudelleenkäyttöä. Koostetta käytettäessä suorituksen aikana luodaan useampia olio-esiintymiä kuin perintää käytettäessä. Toisaalta luokkahierarkiat ovat pienempiä ja luokkia on vähemmän. Järjestelmän toiminta perustuu olioiden suhteisiin ja yhteistyöhön yksittäisten laajoja osia toteuttavien olioiden sijaan. Koostetta käyttämällä saavutetaan myös perintää parempi ajonaikainen joustavuus, koska vaadittavan olion tilalle voidaan sijoittaa halutun tyypin alityypin mukainen olio. Suunnittelumalleja (design patterns) (Gamma ym. 1995) käytetään suunnittelukokemuksen ja tietouden tallentamiseen ja levittämiseen. Suunnittelumallit edistävät uudelleenkäyttöä kahdella tasolla: ohjelmista tulee helpommin uudelleenkäytettäviä ja suunnittelumallien käyttö itsessään on ohjelmistojen suunnitteluideoiden uudelleenkäyttöä. Suunnittelumallit koostuvat: 1. Yksikäsitteisestä nimestä, jonka tulisi kuvata ideaa hyvin. 2. Ongelman kuvauksesta, johon sisältyvät ehdot, jotka on oltava voimassa mallin käyttämiseksi. 3. Mallin tuoman ratkaisun kuvauksesta, joka koostuu mukana olevista elementeistä (esim. olioluokista), niiden rooleista, vastuista ja niiden välisistä suhteista; Ratkaisuna ei anneta konkreettista suunnittelua tai toteutusta. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

65 KOMPONENTTEN MALLINTAMINEN JA SUUNNITTELU Ratkaisun tuomista seurauksista mahdollisine kompromisseineen. Tässä käsitellään ratkaisun tehokkuus, kielikohtaiset seikat ja vaikutukset järjestelmän joustavuuteen, laajennettavuuteen ja siirrettävyyteen. Suunnittelumallit sisältävät usein lisäksi kuvaukseen liitetyt käyttö- ja ohjelmakoodiesimerkit, mainintoja muista aiheeseen liittyvistä suunnittelumalleista, kuvaus idean syntymotiiveista, käyttökokemuksista jne. Valmiita suunnittelumalleja käytetään yleisesti komponenttipohjaisen sovellusarkkitehtuurin ja komponenttien toteutuksen suunnittelussa. Tässä dokumentissa viitataan myöhemmissä kohdissa eri suunnittelumalleihin, joita voidaan käyttää eri tasoilla sovelluksen tai toimialakomponentin eri osien toteuttamiseen. Oliosuuntautuneet suunnittelumallit voidaan jakaa käyttötarkoituksen mukaan luomista käsitteleviin (creational), rakenteellisiin (structural) ja käyttäytymistä (behavioral) käsitteleviin. Samaan jaotteluun voidaan liittää se, käsitteleekö malli luokkia vai olioita. Luokkia tarkastelevat suunnittelumallit selvittävät luokkien ja aliluokkien välisiä suhteita, jotka muodostetaan perinnän avulla. Olioita hyödyntävät suunnittelumallit käyttävät olioiden dynaamisia suhteita hyväkseen. Taulukossa 6 esitellään lyhyesti muutamia suunnittelumalleja. Taulukko 6. Esimerkkejä suunnittelumalleista (Luova 1997; Gamma ym. 1995) Nimi Tyyppi Käyttökohde esim. Ratkaisu factory method luominen olioiden luominen ajon aikana (luokka) käyttää hyväkseen perintää abstract factory luominen olioiden luominen ajon aikana (olio) prototype luominen olioiden luominen ajon aikana (olio) käyttää hyväkseen koostetta ja delegaatiota, olion luominen delegoidaan erilliselle oliolle käyttää delegaatiota adapter facade composite rakenteellinen rakenteellinen yhteensopimattomien luokkien yhdistäminen, yritetään yhdistää ohjelmaan luokka, joka ei vastaa liittymältään ohjelman tarjoamaa luokan liittymää selkeyttää alijärjestelmien välisiä riippuvuuksia, tekee alijärjestelmän paremmin erotettavaksi muusta järjestelmästä olioiden plug and play yhdistäminen rakenteellinen rakennetaan yhdistettävien liittymien välille luokka, jonka ansiosta luokkien liittymät vastaavat toisiaan alijärjestelmän kutsut ja alijärjestelmästä ulospäin tehtävät kutsut ohjataan erillisen objektin kautta primitiivisiä olioita yhdistelemällä saadaan aikaan yhdistelmäolioita decorator rakenteellinen olioiden yhdistäminen, uuden toiminnallisuuden liittäminen olioihin käyttämättä perintää tai uusia aliluokkia olioiden ketjuttaminen siten, että uusi (uuden toiminnallisuuden toteuttava) olio sisältää osoittimen laajennettavaan olioon Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

66 66 OSA II: Taustaselvitykset Nimi Tyyppi Käyttökohde esim. Ratkaisu strategy käyttäytyminen state mediator observer template method käyttäytyminen käyttäytyminen oliojoukon keskinäinen kommunikointi keskitetään kulkemaan erillisen olion kautta oliot eivät ole keskenään riippuvaisia, vaan pelkästään mediatoroliosta käyttäytyminen käyttäytyminen algoritmin kapselointi olion sisään, järjestelmän käyttäytymisen muuntelu suorituksen aikana tilakuvauksen ja operaatioiden kapselointi olion sisään, järjestelmän käyttäytymisen muuntelu suorituksen aikana olioiden välisten riippuvuuksien vähentäminen olioiden välisten riippuvuuksien vähentäminen, MVC-sovelluskehyksen toteuttaminen, yhdestämoneen suhteen muodostaminen olioiden välille ja toisistaan riippumattomien olioiden pitäminen ajan tasalla malliolion muutoksissa algoritmien uudelleenkäyttö, yleisten prosessien toteuttaminen algoritmin sisältävä olio liitetään toisen olion osaksi, joka käyttää algoritmia delegaation avulla asiakasolio käyttää delegaatiota stateolion operaatioiden hyödyntämiseen Koostuu subject- ja observer- osasta; subject sisältää tietoabstraktion ja viittaukset siihen liitetyistä observerolioista. Subject sisältää liittymän jonka avulla sitä muutetaan (SetState) tai tutkitaan (GetState) ja liittymät, joilla observereita lisätään tai poistetaan (Attach ja Detach). Observer voi tehdä muutoksia subject:iin ja ilmoittaa siitä subject:in Update-liittymän avulla. Subject ilmoittaa muutoksista kaikille tarkkailijoille (Notify). Template-algoritmi on algoritmin abstrakti kuvaus, joka kuvaa algoritmin askel askeleelta. Osa askelista on samassa luokassa määriteltyjä abstrakteja metodeja, joiden toteutusta voidaan vaihdella aliluokissa. Sovelluskehys (framework) tarjoaa tietyn ongelma-alueen sovelluksille yhteisen kehyksen, johon on tallennettu eri sovelluksille yhteiset ominaisuudet (Luova 1997). Toiminnot ja oliot, jotka ovat eri sovelluksissa erilaisia, parametrisoidaan. Esimerkiksi vaihtelevat osat suunnitellaan vaihdettaviksi komponenteiksi, jotka voidaan liittää sovelluskehyksen runkoon sovelluskohtaisesti. Sovelluskehyksen runko määrää ohjelman suorituksen kulun eli kutsuu tarvittaessa komponentteja, joilla suunnittelija on määritellyt sovelluksen ominaispiirteet. Tämä ominaisuus erottaa sovelluskehykset luokkakirjastoista, joita käytettäessä kirjaston luokkia kutsuva koodi on ohjelmoitava erikseen. Sovelluskehys on joukko keskenään yhteistoiminnassa toimivia luokkia, joista osa voi olla abstrakteja. Sovelluskehys on usein sovellusaluekohtainen. Osa luokista on abstrakteja, jotta käyttäjä voisi korvata ne perimällä, dynaamisella sidonnalla tai koosteella (Kuusi 1999). Sovelluskehys toteuttaa yhden tai useampia suunnittelumalleja. Sovelluskehykset ovat konkreettisempia ja erikoistuneempia elementtejä kuin suunnittelumallit. Sovelluskehykset sisältävät osittaisen toteutuksen toisin kuin suunnittelumallit. Suunnittelumallit ovat myös arkkitehtuurillisesti pienempiä elementtejä kuin sovelluskehykset. Koska sovelluskehyksiä käytetään rakennuspalikkoina uusien ohjelmistojen kehittämisessä ja niillä on tarkoin määritellyt rajapinnat, ne täyttävät osan komponentilta vaadituista ominaisuuksista. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

67 KOMPONENTTEN MALLINTAMINEN JA SUUNNITTELU 67 Kehykset eivät kuitenkaan ole itseriittoisia kuten komponentit, vaan niiden käyttäjän on aina lisättävä toiminnallisuutta sovelluskehykseen. Komponenttipohjaiset sovelluskehykset voivat sisältää mm. sovittuja rajapintoja ja operaatioita, joita kehyksen mukaiset komponentit toteuttavat. Tyypillisiä sovelluskehyksiä ovat käyttöliittymäkehykset, koska käyttöliittymien luominen vaatii runsaasti koodia, joka on samantapaista eri sovellusten välillä. Käyttöliittymän eristäminen itse ongelman mallista esitettiin ensimmäisen kerran Model-View-Controller (MVC) -suunnittelumallissa, joka luotiin Smalltalk-ohjelmointikielellä jo 80-luvun alussa. Sovelluskehykset voidaan luokitella esim. seuraavasti (Luova 1997): 1. Ohjelmistosovelluskehys (application framework) ei ratkaise mitään reaalimaailman ongelmaa, vaan tarjoaa välineen helpottamaan sovellusten rakentamista. Esim. käyttöliittymäkehykset ovat tällaisia sovelluskehyksiä. 2. Alakohtainen sovelluskehys (domain framework) kattaa jonkin reaalimaailman ongelma-alueen sovellustarpeen. Otollisia alueita ovat alueet, joilla tarvitaan useita samantyyppisiä sovelluksia. Esimerkiksi CORBAmedin palvelumääritykset ovat terveydenhuollon alakohtaisia sovelluskehyksiä. 3. Tukisovelluskehys (support framework) tarjoaa systeemitason palveluita, kuten hajautetun tietojenkäsittelyn tuen tai laiteajurituen. Alakohtaisten terveydenhuollon yleisten palvelujen sovelluskehysten määrittelyjä on tässä selvityksessä esitelty luvussa 13, ja toimialasta riippumattomia ohjelmistosovelluskehyksiä lueteltu luvussa 14. Toinen tapa luokitella sovelluskehyksiä on niiden tapa tuottaa sovelluksia. Tapa voi olla joko koostamista (rakennetaan järjestelmä yhdistelemällä komponentteja) tai generointia (järjestelmä tuotetaan johtamalla aikaisemmasta järjestelmästä tai määrittelemällä järjestelmän ominaispiirteet valmiiseen ongelmakohtaiseen kehykseen). Koostamiseen perustuvia kehyksiä voidaan käyttää rakennettaessa uusia erityyppisiä sovelluksia, mutta generointiin perustuvista kehyksistä voidaan luoda vain tietyn ongelma-alueen sovelluksia. Tämän jaottelun mukaan alakohtaiset sovelluskehykset kuuluvat generoituihin kehyksiin ja ohjelmisto- ja tukisovelluskehykset koostettuihin kehyksiin. Sovelluskehysten suunnitteluun ei ole yhtä erityisen sopivaa menetelmää, vaan eri analyysi- ja suunnittelumenetelmiä on sovitettava toimimaan toistensa kanssa yhdessä. Lähteessä (Luova 1997) on esitetty seuraava karkea menetelmä, jonka vaiheet eivät ole pelkästään peräkkäisiä vaan osittain päällekkäisiä ja kehämäisiä: 1. Analyysivaiheessa jaetaan ongelma-alue intuitiivisesti erillisiin itsenäisiin osa-alueisiin. Näistä osa-alueista etsitään roolianalyysiä ja käyttötapausanalyysiä käyttäen potentiaalisia arkkitehtuurin perusolioita ja alisysteemejä 2. Analyysissä löydettyihin osa-alueisiin suoritetaan samanlaisuus- ja eroavuusanalyysi. Tämän analyysin tulosten ja osa-alueiden pohjalta aletaan muotoilla järjestelmän jakoa alijärjestelmiin ja alisovelluskehyksiin. Muotoilussa käytetään vastuulähtöistä suunnittelua ja yhteistyökaavioita, joiden avulla yritetään yksinkertaistaa olioiden ja alijärjestelmien välistä kommunikointia. 3. Uudelleenkäyttöön, joustavuuteen ja parametrisointiin pyritään etsimällä abstrakteja luokkia ja tapoja kuvata vaihtelua. Vaihtelun kuvaamiseen yritetään löytää sopiva toteutustapa esim. käyttäen ohjelmointikielten analyysiä, jonka avulla etsitään samanlaista ja erilaista käyttäytymistä, tietorakenteita, metodien tai muuttujien nimiä ja koodin rakennetta. 4. Järjestelmän sisäinen rakenne kuvataan toteutusta varten sopivalla järjestelmän luokkarakenteen kuvausmenetelmällä, kuten luokkakaaviolla. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

68 68 OSA II: Taustaselvitykset 5. Vastuulähtöinen sekä samanlaisuus ja eroavaisuus -analyysit eivät tuo esiin laajojen arkkitehtuurillisten kokonaisuuksien hyödyntämistä suoraan. Näitä mekanismeja päästään hyödyntämään systemaattisesti käyttämällä suunnittelumalleja järjestelmän arkkitehtuurin luonnostelussa ja parantamisessa. Komponentti-FixIT:in analyysivaiheessa tätä menetelmää ei ole noudatettu orjallisesti, vaan on pyritty käyttämään olemassa olevia yleisiä arkkitehtuureita, sovelluskehyksiä ja toiminnallisuusjoukkoja hyväksi. Arkkitehtuurin perusoliot on määritelty yleisten komponenttijärjestelmissä esiintyvien olioiden mukaisesti, ja alijärjestelmät jaetaan osajärjestelmiin ja olioihin vastuulähtöisen ajattelutavan mukaisesti. Osajärjestelmien ja olioiden välisiin suhteisiin sovelletaan suunnittelumalleja, joita löytyy kirjallisuuden lisäksi jo toteutetuista välineistä, jolloin myös osittainen toteutus on valmiiksi saatavilla. Yksittäisten osajärjestelmien tarkat kuvaukset ja sisäinen rakenne kuvataan, kun siirrytään osajärjestelmän tarkempaan suunnitteluun. Sovelluskehysten kehittäminen on luonteeltaan iteratiivista. Ohjelmia on testattava ja suunnittelua tarkistettava työn edetessä. Muutokset voivat koskea vain ohjelmallista toteutusta tai myös abstraktiota, jolloin ne vaikuttavat arkkitehtuuriin. Jatkuvien muutosten takia sovelluskehystä ei kannata julkaista käyttäjille ennen kuin abstraktien luokkien liittymät ja muut arkkitehtuurin keskeiset osat ovat suhteellisen stabiilissa tilassa. Tosin osakehysten julkaiseminen voi tapahtua myös vähitellen, sitä mukaa kun ratkaisut vakiintuvat ja todetaan sopiviksi. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

69 ARKKITEHTUURITYYLIT 69 8 ARKKITEHTUURITYYLIT Tässä luvussa esitellään arkkitehtuurityylejä sekä komponenttien yhteistoimintamalleja. Näitä tyylejä ja malleja käytetään sovellusarkkitehtuurissa määrittelemään komponenttien palvelujen rakennetta sekä kutsusuhteita. Arkkitehtuurityylit ovat sovellusarkkitehtuurissa (ks. luku 6) tehtäviä päätöksiä, jotka vaikuttavat varsinkin hajautettujen komponenttien suunnitteluun ja toteutuksiin. Arkkitehtuurityyli ratkaisee pohjimmiltaan, ovatko hajautetut palvelut olioita vai yleiskäyttöisiä palveluita. Eri arkkitehtuurityylejä voidaan yhdistellä samassakin järjestelmässä, mutta järjestelmien integroinnissa, jossa samojen asioiden toteuttamiseen on käytetty eri arkkitehtuurityylejä eri järjestelmissä, joudutaan yleensä rakentamaan sovitusmekanismeja eri tyylisten komponenttien välille. Komponenttiarkkitehtuurissa (ks. luku 6) voidaan yhdistellä erilaisia arkkitehtuurityylejä. 8.1 Tyyppi-, esiintymä- ja tapahtumaperusteiset tyylit On olemassa kolme erilaista arkkitehtuurityyliä ja ajattelutapaa, joilla komponenttipohjaisia sovelluksia rakennetaan (Herzum, Sims 2000): 1. tyyppiperusteinen, 2. esiintymäperusteinen ja 3. tapahtumaperusteinen. Tässä luvussa esitellään nämä arkkitehtuurityylit ja vertaillaan niiden vaikutuksia järjestelmän suunnitteluun ja toteutukseen. Esiintymä-käsitettä käytetään kolmessa merkityksessä: 1. erottamaan suunnittelun ja ajon aikainen komponentin käsite toisistaan (ajon aikainen on esiintymä); pyritään käyttämään nimitystä komponentin ajon aikainen esiintymä, 2. komponentti tarjoaa toimialan käsitteen toteutuksen, esim. Potilas Juha Mykkänen ; tässä luvussa käytetään tätä merkitystä: komponentti-esiintymä, hajautettu olio (distributed object) tai 3. samalle komponentille voidaan luoda useita esiintymiä muistiin esim. suorituskyky-, kuormantasaus- tai muista syistä. esiintymäklooni. Tyyppiperusteisessa (type-based) tyylissä komponentti-esiintymä edustaa tyyppiä, esim. Invoicekomponentti itse asiassa ohjaa laskujen joukkoa sen sijaan että olisi lasku. Tässä tyylissä kukin komponenteista nähdään palvelun tarjoajana, jonka liittymien kautta tunnistetaan ja käsitellään haluttua tyypin esiintymää. Tätä tyyliä käytettäessä ei tietylle esiintymälle ole olemassa verkkoosoitetta, vaan esim. kaikki laskut käsitellään yhden verkossa olevan Invoice-komponentin kautta. Esiintymäperusteisessa (instance-based) tyylissä komponentti-esiintymä edustaa käsite-esiintymää, esim. voi viitata verkossa suoraan Invoice-tyyppiseen laskuun Kuopion yliopisto, atk-keskus. Tällöin esiintymän tunniste on osa itse komponenttia ja voidaan puhua komponentista oliona. Puhtaassa tapahtumaperusteisessa (event-based) tyylissä toimialakomponentit eivät keskustele suoraan keskenään, vaan lähettävät ja vastaanottavat tapahtumia. Tämä mahdollistaa vahvan komponenttien eristämisen toisistaan, mutta johtaa tapahtumien kulun vaikeaan jäljitettävyyteen. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

70 70 OSA II: Taustaselvitykset Käytännössä tapahtumapohjaista kommunikaatiota kannattaa käyttää tietyissä erikoistilanteissa, varsinkin sovellustason komponenttien välisessä kommunikoinnissa. Toimialakomponenteista tehdyn järjestelmän sisällä tapahtumia käytetään yleensä: 1. päivitysmekanismina: jos jostain tiedosta esim. suorituskykysyistä tehdään kopio, voi kopio ottaa vastaan tapahtuman, kun alkuperäinen tieto muuttuu, ja paikallinen kopio voidaan päivittää, 2. ilmoitusmekanismina käyttöliittymäkerrokselle: esim. käyttäjä voi saada tiedon jonkin häntä koskevan tehtävän syntymisestä tai valmistumisesta, 3. toimialakomponenttien viittausten ajan tasalla pitämiseen ja 4. tosimaailman tapahtuman esittämiseen varsinkin komponenttien välisessä viestinnässä. Tyyppi- ja esiintymäperusteiset arkkitehtuurityylit ovat synkronoituja tyylejä, eli perustuvat kutsuvastaus -periaatteeseen. Tapahtumaperusteinen tyyli ei ole synkronoitu. Seuraavassa taulukossa on vertailtu tyyppiperusteisen ja esiintymäperusteisen ajattelutavan ja arkkitehtuurin eroja: Komponentin elinkaari Taulukko 7. Tyyppi- ja esiintymäperusteisen arkkitehtuurityylin vertailua Tyyppiperusteinen Esiintymäperusteinen Komponentin aktivointi ja deaktivointi tapahtuu harvoin; voi jopa olla, että komponentti aktivoidaan järjestelmän käynnistyksen yhteydessä ja deaktivointia ei tehdä lainkaan järjestelmän eliniän aikana. Manager-komponentti: sama kuin edellinen. Manager-komponentti luo uuden komponentin tapahtuman tai jopa osatapahtuman ajaksi. Esiintymäkomponentin elinkaaren hallinta on tärkeä osa teknistä arkkitehtuuria, ongelmakohdaksi voi muodostua roskien keruu. Tunnistus Komponentilla on staattinen tunniste. Yksinkertainen järjestelmä voi esim. konfiguraatiotiedoston perusteella löytää komponentin. Komponentin tunnisteella ei ole mitään tekemistä esim. tietokantaan tallennetun tiedon kanssa. Selvä vastuun jako: palvelun tarjoaja on erillään säilytettävästä tiedosta. Yhdenmukainen vuorovaikutusmalli sekä päätason että alemman tason käsitteille. Esiintymäkomponentin tunniste muodostuu yleensä kahdesta osasta: tyyppi- ja esiintymäosasta, esim. potilas/ acd3. Usein suuri kiusaus linkittää esiintymätunniste suoraan dataan johon käsittely liittyy, yksinkertaisissa järjestelmissä esim. pääluokan olion avainkenttään (vrt. tietuenumero). Tämä rikkoo arkkitehtonisen kerroksellisuuden, ja johtaa myös erilaisen kutsuperiaatteen käyttämiseen riippuen siitä, onko kyseessä päätason vai alemman tason käsite komponentin sisällä 11. Jos esiintymätunniste on pääavain, ratkaisu sitoo komponentin identiteetin resurssikerrokseen, ja aiheuttaa sen, että jos tietokantamalli muuttuu jossain komponentissa, voivat vaikutukset ulottua toiseen komponenttiin. 11 Jos esiintymä edustaa tietokannan pääavainta (tai tietuenumeroa), tunnistetta käytetään esim. id_inst.operation (out Result). Jos tieto liittyy alemman tason käsitteeseen on komponentin tarjottava myös tämä tunniste esim. id_inst.operation (in id_sub_inst, out Result). Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

71 ARKKITEHTUURITYYLIT 71 Nimi- ja suhdepalvelu Roolit Transaktionhallinta Kokoelmahallinta Toimintatason tai toimialakomponentin luokka Testaus Tyyppiperusteinen Vähän käyttöä. Nimiavaruus suhteellisen staattinen. Rooleja voidaan välttää komponenttitasolla. Tässä mallissa on helpompaa rakentaa geneerinen, kaikenkattava toimialakomponentti joka hoitaa eri tyyppisiä tehtäviä kuin rakentaa perustoiminnallisuus yhteen komponenttiin ja laajentaa toiminnallisuutta esim. käyttäytymisen periyttämisen avulla. Roolien käyttö kuitenkin jopa sisäisessä komponenttisuunnittelussa silti suotavaa. Suhteellisen suoraviivaista. Yleensä tyyppiperusteinen tyyli on toteutettu tilattomilla komponenteilla, jolloin transaktioita käsitellään vain tietokantaoperaatioiden yhteydessä. Tällöin transaktiokäyttäytyminen voidaan hoitaa komponenttialustaan kuuluvien transaktioiden avulla. Samalla tyyppiperusteisella komponentilla hoidetaan sekä käsite-esiintymän että kokoelmien hallinta. Suurten esiintymämäärien käsittelyyn voi olla tarpeen tehdä erillinen collection komponentti. varuskomponentit (utility), prosessi, entiteetti Tapahtumaan osallistuvat komponentit helposti löydettävissä testien suunnittelemiseksi. Testin tulokset liitettäessä tilattomia komponentteja ovat näkyvissä joko paluuparametreissa tai esim. tietokannan tilassa. Esiintymäperusteinen Nimi- ja suhdepalvelu voivat muodostua hyvin tärkeiksi. Esiintymäpohjainen ajattelu voi johtaa hienojakoisempaan komponenttien mallintamiseen. Sama kuin nimi- ja suhdepalvelussa. Oliomallinnuksessa käytettävät roolit houkuttelevat tekemään (perimään) toiminnallisuutta perusluokista, joita erikoistamalla muodostetaan erikoistoiminnallisuus. Transaktion voidaan ajatella sisältävän itse komponentin tilan, ei pelkkää dataa. Tällöin komponentti-esiintymän tilan käsittelyssä on otettava huomioon transaktiokäsittelyn haasteet: lukitukset, deadlock, commit, rollback. Yleensä erillinen manager-komponentti, joka ei yleensä suorituskykysyistä ole yhteydessä itse esiintymäkomponentteihin, vaan käyttää suoraan resurssikerroksen komponenttia keräämään tarvittavan tiedon. Manager-komponentti hoitaa tämän lisäksi factory-tehtävät, metadata-käsittelyä jne. Lisäksi suuria esiintymämääriä käsittelemään voi olla tarve (tyyppiperusteiselle) collection komponentille. entiteetti Teoreettisesti vähän eroa tyyppiperusteiseen. Pragmaattisia monimutkaisuuksia testaukseen, esim. tilallisia komponentteja liitettäessä testin tulokseen sisältyy myös se, missä tilassa eri komponentti-esiintymät ovat testin tuloksena. Vaikeuttaa testausta ja voi johtaa ennakoimattomaan toimintaan. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

72 72 OSA II: Taustaselvitykset Komponenttityyppien määrä Tiedon pysyvyys Kapselointi Suorituskyky Vaatimukset välineille ja komponenttimallille Filosofinen lähtökohta Esimerkki liittymän määrittelyistä Tyyppiperusteinen Soveltuu selkeytensä ansiosta hyvin suuriin (rakenteellisesti ja kuormituksellisesti) projekteihin. Usein optimaalinen karkeajakoisuus komponenteissa, datasaarekkeiden (ks. luku 10.1) käyttö. Komponentti hoitaa usein itse tiedon tallennuksen. Tyyppiperusteinen kapselointi: toisen komponentin käytettävästä palvelusta tiedettävä enemmän. Tyyppitason yhtäaikaisuus vaatii palvelun toteuttavalta komponentilta runsaasti yhtäaikaisuuden ja yhtäaikaisten kutsujen käsittelyä. Käyttää vähemmän komponenttimallien ominaisuuksia. Yleisen abstraktiomallin rakentaminen suhteellisen helppoa. Perinteisen järjestelmän modularisoinnin laajennus. iepotilas potilas_manager; potilas_manager.create( in potilas_id, in potilas_data); potilas_manager.read(in potilas_id, out potilas_data); potilas_manager.list(in haku_avain, out potilas_lista); Esiintymäperusteinen Periyttäminen ja perustyyppien ja roolien käyttö johtavat komponenttityyppien suureen määrään. Tämä voi aiheuttaa suurissa (rakenteellisesti ja kuormituksellisesti) järjestelmissä vaikeuksia ylläpidettävyyteen ja uudelleenkäytön, suunnittelun ja jakelun hallittavuuteen. Hienojakoisia komponentteja, ei ajatella tietoa saarekkeina vaan käytetään pysyvyyskehystä. Luonnollista ajatella että tiedon pysyvyyden tulisi näkyä komponentin liittymissä. Usein yksinkertaiset Tallenna ja Hae operaatiot eivät ole riittäviä. Voi johtaa tilanteeseen, jossa toiminnallinen hajautettu komponentti vastaa toisen toiminnallisen hajautetun komponentin tiedon säilytyksestä. Koodin ja suunnittelun täydellisempi kapselointi: toimintalogiikka yleensä aidosti paikallista. Riittävän kypsällä arkkitehtuurilla saavutetaan parempi suorituskyky kuin tyyppiperusteisella tyylillä. Yhtäaikaisuus esiintymätasolla tyyppitason sijaan johtaa esiintymäkomponentin yhtäaikaisten kutsujen mahdollisuuden pienenemiseen. Käyttää paljon komponenttimallien edistyneitä ominaisuuksia. Olioperusteisen lähestymistavan laajennus: käsitteellisesti mahdollista rakentaa järjestelmä aidoista olioista, elegantti hajautettujen olioiden lähestymistapa, oliokäsitteet, roolit, perintä jne. iepotilas yks_potilas (potilas_id); yks_potilas.create (in potilas_data); yks_potilas.read (out potilas_data); lisäksi iepotilastypemanager potilas_manager; potilas_manager.list (in haku_avain, out potilas_lista); Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

73 ARKKITEHTUURITYYLIT 73 Tyyppi-, esiintymä- ja tapahtumaperusteisia tyylejä voidaan myös yhdistää jossain määrin, mutta on tärkeää tunnistaa, missä käytetään mitäkin tyyliä. Tyylin valintaan huomion kiinnittäminen on järkevintä, kun kyseessä ovat nimen omaan toimintakerroksen komponentit. Yleensä sekä käyttäjäettä työtilakerrosten komponenteissa on kyse esiintymäperusteisista komponenteista, ja resurssikerroksessa palveluista (tyyppiperusteinen). Järjestelmän rakentamisessa voidaan tietoisesti valita esiintymäperusteinen tyyli niihin osiin, joissa esiintymäkomponenteilla on oltava verkko-osoite ja käyttää muissa osissa tyyppiperusteisia (palvelu-) komponentteja. Komponenttien toteutusteknologiat tuntuvat luontaisesti suosivan esiintymäperusteista tyyliä. Kuitenkin komponenttimalli, joka tukee esiintymäperusteista tyyliä, tukee automaattisesti myös tyyppiperusteista. Eri piireissä käydään kiivastakin väittelyä komponenttien luonteesta. Toiset tutkijat korostavat komponenttien merkitystä oliomenetelmien tien jatkajana, toiset korostavat tietystä verkon pisteestä saatavien palvelujen merkitystä. Komponenttien tilattomuus (palvelu) tai tilallisuus (olio) sekä monet muut suunnitteluun ja toteutukseen vaikuttavat seikat kiteytyvät hyvin pitkälti juuri käytettyyn arkkitehtuurityyliin. Järjestelmien toteuttajien kannalta on tärkeintä saavuttaa toimiva ratkaisu komponenttien toteuttamisessa ja integroinnissa. 8.2 Koordinaattorit ja yhdenvertaiset komponentit Toimialakomponenttijärjestelmässä kukin komponentti voidaan nähdä koordinaattorina (coordinator), eli komponentti ohjaa kaikkia komponentteja, joista se on riippuvainen. Koordinaattorirooli on yhdistelmä facade- ja mediator- suunnittelumalleista (ks. luku 7.2). Facade-malli tarjoaa yhdistetyn liittymän alijärjestelmän liittymiin, eli komponentin liittymä on yhdistelmä komponentin käyttämien alempien komponenttien liittymistä. Mediator-malli määrittelee olion, joka kapseloi sen, kuinka olioiden joukko kommunikoi. Se edistää komponenttien välisen kommunikaation väljää yhdistämistä hoitamalla komponenttien välisen kommunikaation niin, ettei komponenttien tarvitse suoraan käyttää toistensa palveluja. Koordinaattori-komponentin liittymä tarjoaa facade-mallin mukaisen näkymän koordinaattorin käyttämille komponenteille ja sen toteutus toimii näiden komponenttien mediaattorina. Järjestelmä voidaan nähdä muodostuvan koordinaattoreista, joista jokainen tarjoaa omille koordinaattoreilleen itsensä alapuolella hierarkiassa olevien osien toiminnallisuuden. On löydettävä tasapaino, mille tasolle komponenttien autonomia ja toimintalogiikan sijoittaminen tehdään: 1. Jos toimintasäännöt ja suuri osa koordinaatiosta viedään alemman tason komponenteilta ylemmän tason komponenteille, saadaan aikaan helposti muokattava järjestelmä: toimintalogiikan muuttaminen vaikuttaa vain korkean tason komponentteihin, ja on selvä ero tieto- ja prosessikomponenttien välillä. Toimintasääntöjen ulkoistaminen on mahdollista. Prosessikomponentin rakentaminen voi olla vaikeaa, koska suuri osa logiikasta sijaitsee ja on toteutettava siellä. Entiteettikomponentit ovat yksinkertaisia ja uudelleenkäytettäviä, mutta eivät kovin käytännöllisiä. 2. Jos toimintasäännöt ja vastuu painetaan mahdollisimman matalalle tasolle siten, että kukin kerros vastaa alempien kerrosten koordinaatiosta, syntyy itseriittoisia komponentteja. Kukin komponentti omistaa ja toteuttaa sitä suoraan koskevan toimintalogiikan. Kaikilla komponenteilla on jonkin verran älykkäitä toimintoja. On helpompaa käyttää ja uudelleenkäyttää tällaisia Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

74 74 OSA II: Taustaselvitykset komponentteja, koska käyttäjän ei tarvitse huolehtia kovin monista asioista. On vaikeampaa muokata järjestelmän toiminnallisuutta, koska toimintasäännöt sijaitsevat eri komponenteissa. Esimerkkinä edellisestä voidaan tarkastella vaikkapa potilas-komponenttia. Ensimmäinen vaihtoehto toteutuu, jos luodaan erillinen Potilashallinta-komponentti, joka hoitaa järjestelmässä esim. potilaiden siirtoja yksiköstä toiseen ohjaamalla sekä Potilas- että Yksikkö -entiteettejä. Toinen vaihtoehto on kyseessä, jos Potilas-komponentti sisältää toiminnot, joilla esim. potilaan siirto yksiköstä toiseen tapahtuu. Koordinaattoreiden toteuttaminen sujuu luonnollisimmin tyyppiperusteisella tyylillä. Koordinaattori-mallin lisäksi on malli, jossa komponentit kommunikoivat yhdenvertaisina (peer-topeer). Tämä malli soveltuu yleensä tilanteisiin, jossa komponenteilla mallinnetaan todellista yhdenvertaisten käsitteiden vuorovaikutusta. Komponenttitasolla tämä on yleensä varsin korkean tason komponenttien kommunikaatiota, varsinkin prosessikomponenttien tai järjestelmien tasolla. Tällainen kommunikaatio toimii, kun sitä käyttävien komponenttien määrä on suhteellisen pieni. Tällöin komponentin rakentamisessa on otettava huomioon mahdolliset kutsut muilta nimetyiltä komponenteilta. Tätä mallia käytettäessä voidaan joutua myös tinkimään periaatteesta, jonka mukaan komponenttien välille ei saa syntyä kaksisuuntaisia riippuvuuksia. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

75 TEKNINEN ARKKITEHTUURI 75 9 TEKNINEN ARKKITEHTUURI 9.1 Teknisen arkkitehtuurin osat Tekninen arkkitehtuuri on toteutus komponenttijärjestelmän virtuaalikoneesta. Tämä virtuaalikone muodostuu sekä komponenttien suoritusympäristöstä että kehitysympäristöstä (ks. kuva 22). Komponentin suoritusympäristö eli tekninen infrastruktuuri puolestaan muodostuu teknisestä pohjasta sekä yleiskäyttöisistä palveluista. Sekä tekninen pohja että palvelut käyttävät komponenttien toteutusteknologioita (esim. CORBA, COM, EJB). Komponentin komponenttialusta-rajapinta (ks. luku 2.1) on tekniseen arkkitehtuuriin yhteydessä oleva komponentin osa. Tekninen arkkitehtuuri Komponenttien suoritusympäristö (CEE) Kehitysympäristö Tekninen pohja Yleiskäyttöiset palvelut }Tekninen infrastruktuuri Komponentin toteutusteknologiat Kuva 22. Tekninen arkkitehtuuri Toiminnallisuuden ohjelmoijat käyttävät koko teknistä arkkitehtuuria (mukaan lukien kehitysympäristö) toimialakomponenttien toteuttamiseen. Toiminnallisuuden ohjelmoijien asiakkaita ovat komponenttien käyttäjät, jotka käyttävät komponenttien toiminnallisuutta ja suoritusympäristöä tietojärjestelmissä. Teknistä arkkitehtuuria ei ole saatavilla yhtenä integroituna pakettina, vaan se on rakennettava tapauskohtaisesti. On tärkeää määritellä rakennettavalle järjestelmälle vaatimukset ja käytettävät tekniikat kaikkiin jäljempänä kuvattuihin kerroksiin ja varmistettava, että kokonaisuuden eri osat toimivat yhdessä ja soveltuvat valittuun sovellusarkkitehtuuriin. Komponentin siirrettävyys voi olla lähdekooditasoista (siirto vaatii komponentin uudelleenkääntämisen ja -linkittämisen), binääritasoista (siirto mahdollista ilman uudelleenkääntämistä ja Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

76 76 OSA II: Taustaselvitykset -linkitystä) tai kehityksen aikaista (komponentin siirto kehitysympäristöstä toiseen ajoympäristön sijaan). Komponenttien suoritusympäristö (CEE, Component Execution Environment) on ajonaikainen infrastruktuuri, johon hajautettujen komponenttien on sovittava. Myös itse hajautetussa komponentissa voi olla oma eristyskerroksensa, joka eristää toiminnan toteuttavan koodin komponentin toteutusteknologiasta. Tämä osa hajautetusta komponentista riippuu komponenttien suoritusympäristöstä. Tämän kerroksen avulla voidaan toteuttaa lähdekooditasoinen siirrettävyys komponenttiteknologioiden välillä (edellyttäen että komponentin suoritusympäristöt tukevat samoja ohjelmointikieliä tai ovat kielen suhteen neutraaleja). Näin ollen hajautetun komponentin siirtäminen voidaan nykyisellään toteuttaa generoimalla uudestaan eristyskerroksen toteuttavat luokat ja kääntämällä uudelleen toimintalogiikan toteuttavat luokat. Lähitulevaisuudessa on epätodennäköistä, että komponenttien suoritusympäristöjen välistä binääritason siirrettävyyttä tullaan saavuttamaan, joten siirrettävyyden turvaamiseksi on pyrittävä tekemään hajautettujen komponenttien lähdekoodista mahdollisimman siirrettävää. Merkattua tietoa (esim. XML) käyttävien liittymien ja eri kielille tehtyjen adapterien yhdistelmä voi tarjota jatkossa siirtymäpolun kohti binääritasoista siirrettävyyttä. Eristyskerroksen toteuttamisessa voidaan joko valita tietyn ajon- ja kehityksen aikaisen ympäristön tukeminen, tai liikkumavara eri ajo- ja kehitysympäristöjen välillä. Myös ensimmäisessä tapauksessa (esim. Microsoft-ympäristö) vaaditaan huomattavasti työtä, jotta saavutetaan yksinkertaisuus ja vastuiden erillisyys. Jos eristyskerros joudutaan toteuttamaan joka kerta uudelleen, vaikkakin suunnittelumalleja ja selkeitä ohjeita käyttäen, tulee suuri osa tarvittavasta työstä jatkuvasti kuulumaan eristyskerroksen toteuttamiseen. Toivottavampi on tilanne, jossa koko eristyskerros generoidaan automaattisesti toiminnan ohjelmoijan tekemän määrittelyn perusteella. Tämä malli vaatii yleensä mallinnusvälineiden kehittämistä sekä kehitysprosessin ja ajonaikaisten käsitteiden sopimista, mikä ei voi olla yksittäisen sovellusprojektin tehtävä. Teknisen pohjan vastuulle kuuluvia asioita ovat (Herzum, Sims 2000): komponentin yksinkertainen kutsuminen, komponentin elinkaari: aktivointi, deaktivointi, yhtäaikaisuus: saman prosessin on voitava käsitellä useita yhtäaikaisia säikeitä ja asynkroninen viestien välitys (viestijonot ja palvelut). Lisäksi tekninen pohja voi tarjota keinot dynaamisen perinnän toteuttamiseen. Dynaaminen perintä (Herzum, Sims 2000) tarkoittaa, että hajautettua komponenttia voidaan laajentaa jakelun jälkeen lisättävällä toiminnallisuudella siten, että laajennuksen toteuttava (erillinen) komponentti joko toteuttaa palvelun itse, delegoi pyynnön alkuperäiselle komponentille tai toiselle palvelun toteuttavalle komponentille. Komponenttien suoritusympäristö huolehtii siitä, että komponenttiryhmä näkyy komponentin kutsujalle vain yhtenä komponenttina, jota kutsutaan kuten alkuperäistä (laajentamatonta) komponenttia. Dynaamisen perinnän käyttö mahdollistaa delegaatioon perustuvien komponenttikehysten luomisen. Yleiskäyttöisiä palveluita ovat (ks. myös luku 14.2): transaktiot, virheidenkäsittely, tapahtumat ja pysyvyys. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

77 TEKNINEN ARKKITEHTUURI Teknisen arkkitehtuurin toteutus Arkkitehtuurin kerrosten yhdistämiseksi on määriteltävä infrastruktuuri, joka sisältää tarvittavat ohjelmisto-osat. Infrastruktuuri sisältää turvallisuus-, transaktio-, tietokantaliittymä- ja sovellusten välisen kommunikaation ratkaisut. Seuraavassa taulukossa on esitelty sekä komponenttien suoritusympäristössä että kehitysympäristössä tarvittavia ohjelmistoja. Kehitysympäristön välineitä ei yleensä tarvita komponenttien suoritusympäristössä, mutta kehitysympäristön välineiden on luonnollisesti tuettava valittuja suoritusympäristön tekniikoita. Infrastruktuurin osa Taulukko 8. Teknisen infrastruktuurin osat Käyttökohde Standardit / spesifikaatiot Käytettävissä olevia tuotteita ja välineitä KOMPONENTTIEN SUORITUSYMPÄRISTÖ (TEKNINEN INFRASTRUKTUURI) Väliohjelmistot (Middleware) Sovellusten välinen ja verkkokommunikaatio Tietokantakommunikaatio Turvallisuus Muut yleiset palvelut Sovellusten välinen tai yksittäisen sovelluksen kerrosten välinen tiedonsiirto Tiedonsiirto tietokantojen ja sovelluslogiikan välillä Ulkoistetut turvallisuuspalvelut Hakemistopalvelut jne. CORBA, DCOM, EJB, Java/RMI, HL7, XML, CCOW ODBC, JDBC, JDO, ADO, CORBA Persistent State Service GSSAPI Generic Security Services API, digitaalivarmenteet, Makropilotti / alueellinen turvallisuuspalvelinliittymä? LDAP Tietokannat Pysyvän tiedon tallennus sql, ks. tietokantakommunikaatio Sovelluspalvelimet Monitasoarkkitehtuurin hallinta, transaktioiden hallinta, komponenttien asennus ja hallinta Visibroker, IBM Component Broker (CORBA), Windows 2000 Server (DCOM), J2EE (EJB) RPC Broker, ks. myös tietokannat Kerberos, PKI FileMan, Cache Objects, Jasmine, Oracle, MS SQL Server XA (transaktiot) Jasmine ii / UniCenter, Bea M3, Microsoft MTS, Inprise Application Server Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

78 78 OSA II: Taustaselvitykset Infrastruktuurin osa Www-palvelimet Käyttöliittymät Selaimet Windows Java Käyttökohde Standardit / spesifikaatiot Www-sivujen ja tiedostojen saanti, web-portaalit Kevyen, joka käyttökerralla käyttäjän työasemalla ladattavan käyttöliittymän toteutus Toiminnallisesti rikkaan, suorakäyttöisen käyttäjän työasemalle asennettavan käyttöliittymän toteutus Alustariippumattoman, mahd. dynaamisesti ladattavan työasemakäyttöliittymän toteutus HTML, Java, XML HTML, DHTML, Java, JavaScript, JSP, ASP, XML, WAP ActiveX JavaBeans, Servlets Käytettävissä olevia tuotteita ja välineitä Sun Java Web Server, Apache, Microsoft IIS Netscape Navigator / Communicator, Microsoft Internet Explorer Windows, JVM Sun Java plug-in Suoritusympäristön varastot KEHITYSYMPÄRISTÖ Suunnittelumallinnus- ym. CASE-välineet Sovelluskehittim et ja ohjelmointikielet Kehitysympäristön varastot Komponenttien varastointiväline, Lääketieteelliset sanastot ja määritelmät, sovellusnavigaatio (prosessikehykset), toimintasäännöt Sovelluksen suunnittelussa käytettävät välineet Sovelluksen toteutuksessa ja ohjelmoinnissa käytettävät välineet Suoritusympäristön varastot, metadata repository, julkinen lista standardoiduista DCOM- CORBA- ja RMI-liittymistä MOF, XMI, UML Java, Object Pascal, Visual Basic Voivat sisältyä sovellus-palvelimiin tai komponenttimallit toteuttaviin tuotteisiin Paradigm +, Rational Rose, CoolSpex, MetaEdit Delphi, JBuilder, Jasmine Studio, M, Cache Object Architect, Visual Studio voivat sisältyä sovelluskehittimiin tai komponenttimallit toteuttaviin tuotteisiin Kuten edellisestä taulukosta näkyy, hajautettujen komponenttisovellusten vaatima tekninen infrastruktuuri on raskas ja monitahoinen. Se muodostuu helposti myös kalliiksi sekä hankkia että ylläpitää, ja on yleensä mahdotonta hankkia kokonaisympäristöä vain testausta ja kokeilua varten. Asiakasorganisaation olemassa olevan infrastruktuurin hyväksikäyttö on perusedellytys suoritusympäristön vähittäiselle rakentamiselle. Tällöin olemassa olevien ja jo hankittujen infrastruktuurin Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

79 TEKNINEN ARKKITEHTUURI 79 tuotteiden avoimet rajapinnat ovat erittäin arvokkaita kokonaisjärjestelmän kehittämistä ajatellen, mutta samoihin standardeihin perustuminenkaan ei välttämättä takaa eri tuotteiden yhteentoimivuutta. Sovelluspalvelinkerroksen merkitys korostuu komponenttipohjaisten hajautettujen sovellusten teknisessä infrastruktuurissa. Väliohjelmistot, sovelluspalvelinohjelmistot ja useimmat varastot sekä suoritus- että kehitysympäristössä ovat tekemisissä sovelluspalvelimen kanssa. Myös komponenttimallien monet ominaisuudet on tarkoitettu suoraan sovelluspalvelimille. Tietokannat, käyttöliittymät ja www-palvelimet voidaan yleensä toteuttaa vaihtoehtoisia tuotteita tai tekniikoita käyttäen myös samaa sovelluspalvelinta käyttäen. Jotta komponenttipohjaisessa ohjelmistotuotannossa olisi järkeä, komponenttien hankinnan, sopeuttamisen ja yhdistämisen tulisi olla helpompaa kuin uusien komponenttien rakentamisen. Komponenttivarastot sisältävät uudelleenkäytettäviä komponentteja ja metadataa, jonka avulla komponenttien hakeminen varastosta on helppoa. Komponenttivarasto on linkki komponenttituotannon ja sovellustuotannon välillä. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

80 80 OSA II: Taustaselvitykset 10 KOMPONENTTIEN PYSYVIEN TIETOJEN HALLINTA Tässä luvussa luodaan katsaus siihen, millaisia tiedonsäilytystarpeita organisaation sovelluksilla tyypillisesti on sekä pohditaan kuinka komponentit voivat hoitaa pysyvien tietojensa tallennuksen vaarantamatta itsenäisyyttään. Luvussa myös selvitetään komponenttien itse hoitamaa tiedon tallennusta ja yleiskäyttöisiä pysyvyyspalveluita. Lisäksi esitellään oliopohjaisessa suunnittelussa ja toteutuksessa käytettävä pysyvä oliomalli. Lopuksi pohditaan sitä, kuinka tietokannanhallintajärjestelmien tarjoamia palveluja voidaan lähestyä komponenttien alustariippumattomuuden näkökulmasta. Suurissa organisaatioissa on hyvin monenlaisia tiedon pysyvyysratkaisuja ja tarpeita. Tyypillisiä suuren (terveydenhuolto-)organisaation eri tasoisia pysyvyyteen ja tietovarastoihin liittyviä tarpeita ovat (VA 2000): On-line Transaction Processing (OLTP) järjestelmät vastaavat sovellus- ja osastokohtaisesta tiedon tallennuksesta ja vastaavat välittömästi käyttäjän pyyntöihin. Monet valmiit tuotteet nojaavat tiettyjen OLTP-tietokantojen käyttöön. OLTP-tietokannat soveltuvat yleensä nopeisiin ja tietomääriltään suuriin tapahtumiin. Toiminnalliset tietovarastot (Operational Data Stores, ODS) yhdistävät useiden OLTPjärjestelmien tietoja ja tarjoavat lähes reaaliaikaisen ja osittain integroidun näkymän muuttuvaan ja ajantasaiseen dataan. Yleensä toiminnallinen tietovarasto on organisoitu jonkin perusalueen (potilas, palveluntarjoaja) ympärille, ja sitä käytetään toiminnallisten päätösten tekoon. Kliiniset tietovarastot (Clinical Data Repository), jotka yhdistävät eri järjestelmistä saatavaa tietoa yhdenmukaiseksi näkymäksi kuuluvat toiminnallisten tietovarastojen luokkaan. Viitetietokanta (ks. luku 17.5) kuuluu tähän luokkaan. Data warehouse-ratkaisuja käytetään organisaation pitkäaikaisten trendien ja suuntausten määrittelyyn ja ymmärtämiseen. Tietovarasto tarjoaa integroidun ja historiallisen näkymän tietoon, joka voi olla kerätty ulkoisista lähteistä tai toiminnallisista tietovarastoista, ja jota käytetään strategisen päätöksenteon apuna. Tieto yleensä noudetaan ja suodatetaan sekä puhdistetaan ennen tallennusta Data warehouse-varastoon. Raportointi, analyysi ja tiedon louhinta (data mining) ovat tyypillisiä käyttötarpeita. Data warehouse-ratkaisu voi olla monitasoinen esim. siten, että yksittäisellä osastolla on oma varastonsa (data mart), joka voi saada tietonsa organisaation yhteisestä varastosta. Arkistointia varten tiedon on oltava saatavilla yleiskäyttöisessä muodossa yhdessä saantioikeuksien kanssa. Siirryttäessä kohti läpi elämän kestävää terveyskertomusta tarvitaan tiedon varastointia, jossa tärkeimmät tiedot ovat välittömästi saatavilla, mutta myös harvemmin tarvittavien tietojen tulisi olla niihin oikeutettujen käytettävissä tarvittaessa. Tiedon tallennus tuoteriippuvassa tai binäärisessä muodossa vaarantaa tiedon pitkäaikaisen säilyvyyden, jos samalla ei tallenneta täysiä saantioikeuksia tai tarvittavia ohjelmia tiedon lukemiseen. XML:n käyttö tiedon tallennukseen voi helpottaa huomattavasti myös pitkäaikaisen varastoinnin ongelmia. Metadata-varastot (Metadata registries) sisältävät tietoa datasta, jonka avulla on mahdollista nimetä, tunnistaa, määritellä, luokitella ja rekisteröidä dataelementtejä. Näiden varastojen avulla voidaan helpottaa tietojen vaihtoa ja käyttöä eri järjestelmien tai käyttäjien välillä. Oliotietokannat ovat olio-ohjelmointikielten yleistyttyä luontainen ratkaisu tiedon tallennukseen. Oliotietokantojen avulla ei tallenneta pelkkää tietosisältöä, vaan sekä tieto että toiminnallisuus yhtenä oliona. Oliotietokannat tarjoavat relaatiotietokantoja parempia mahdollisuuksia rikkaiden ja monimutkaisten tietotyyppien (ääni, kuva, video jne.) tallentamiseen ja hallintaan. Myös johtavat Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

81 KOMPONENTTIEN PYSYVIEN TIETOJEN HALLINTA 81 relaatiotietokantojen toimittajat ovat alkaneet lisätä oliomaisia ominaisuuksia tuotteisiinsa. Toistaiseksi oliotietokantojen olematon markkinaosuus on selkeästi rajoittava tekijä tämän tyyppisten tietovarastojen hankinnassa. Komponentit voivat joutua säilyttämään tietoa eri tasoilla (Herzum, Sims 2000): toimialakomponentin varsinainen tietosisältö (OLTP tai toiminnalliset tietovarastot), data warehousing: historiallinen perspektiivi toimialakomponenttien tietosisältöön, virhetilanteista toipumista varten, konfiguraatiot tai käyttöpreferenssit, esim. käyttöliittymän esitystapa ja metadata: tieto sovelluksesta, komponenteista, toimintasäännöistä tai itse datasta Toimialakomponentin tiedon säilytys Integroidun tietokannan käsite on sekä FileMan- että relaatiomallisissa tietokannoissa hyvin syvään juurtunut suunnittelu- ja toteutuskäytäntö. Yleensä tietokannalla on oma tietoarkkitehtuurinsa, ja tietokanta on modularisoitu jollakin tasolla. Tämä tiedon modularisointi ei läheskään aina noudata toimintalogiikan modularisointia, ja tietoarkkitehtuuri nähdään usein erillisenä komponenttiarkkitehtuurista. Tämä malli rajoittaa huomattavasti komponenttien autonomiaa. Tietokannasta tulee integraatiopiste, ja se muodostaa suuren määrän komponenttien välisiä riippuvuuksia. Jotta täydellinen komponenttien autonomia saavutettaisiin, kaiken suoraan komponenttiin liittyvän olisi oltava osa komponenttia. Hajautetun komponentin tasolla tämä ei ole yleensä mahdollista, esimerkiksi toiminta (enterprise) tason hajautettuun komponenttiin ei ole järkevää sijoittaa käyttöliittymäasioita, eikä jokaisen hajautetun komponentin pitäisi sisältää tiedon tallennukseen liittyvää toiminnallisuutta. Näiden asioiden sisällyttäminen toimialakomponentteihin tai systeemitason komponentteihin on sen sijaan hyväksyttävää. Näin myös tietokannan on oltava komponentoitu, ja pysyvän tiedon täytyy kuulua johonkin toimialakomponenttiin. Tällöin kukin toimialakomponentti sisältää oman datasaarekkeensa (island of data) (Herzum, Sims 2000), joka on suunnittelun aikana joukko tietokantamäärittelyitä, ja suorituksen aikana komponentin pysyvä tieto. Datasaarekkeella ei ole suoraa linkkiä mihinkään pysyvään tietoon, joka sijaitsee toimialakomponentin ulkopuolella. Saarekkeen tietovarastot ovat komponentin kannalta paikallisia. Kerroksellisessa arkkitehtuurissa kullakin saarekkeella on oma resurssikerroksensa, joka on toteutettu esimerkiksi resurssikerroksen hajautettuna komponenttina, johon voi olla yhteydessä vain samaan toimialakomponenttiin kuuluva toiminta (enterprise)-kerroksen hajautettu komponentti. Datasaarekemallissa tietokanta jaetaan saarekkeisiin, joista jokaisen omistaa jokin toimialakomponentti. Toimialakomponentin sisällä pätevät normaalit tietokantasuunnittelun periaatteet. Ainoa ero on se, kuinka tietoa käsitellään saarekkeen ulkopuolelta toimialakomponentin toimintakerroksen hajautettujen komponenttien liittymien kautta. Kukin toimialakomponentti hoitaa oman pysyvän tietonsa tallennuksen. Toimialakomponentin käyttäjän ei tarvitse tietää liittymän takana sijaitsevan tietovaraston tyyppiä tai toimintaperiaatetta. Datasaarekemalli sopii järjestelmän transaktio-osan tiedon tallennukseen, eli toiminta (enterprise)- ja resurssikerroksiin. Toimialakomponentin pääasiallinen datarajapinta (ks. luku 2.1) toteutetaan yleensä resurssikerroksessa. Tietojen, joita käytetään tyypillisesti yhdessä tulisi sijaita samassa datasaarekkeessa ja samassa toimialakomponentissa. Näin datasaarekkeen ja toimialakomponentin karkeajakoisuus on hyvin pitkäl- Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

82 82 OSA II: Taustaselvitykset le samaa luokkaa. Karkeajakoisuus mahdollistaa sen, että tiukasti toisiinsa liittyvät taulut tai tiedostot ovat samassa saarekkeessa, mikä parantaa järjestelmän suorituskykyä ja skaalautuvuutta. Joidenkin kokemusten mukaan tyypillinen toimintatason komponentin luokkien tarvitsema datasaareke sisältää 5-20 relaatiotaulua. Tämän välin ulkopuolinen määrä voi olla merkki mallinnusongelmista. Datasaarekemallin mukaan ainoa tapa päästä käsiksi toisen komponentin pysyvään tietoon on toimintatason hajautettujen komponenttien liittymien kautta. Perinteisiä tietokantatekniikoita ei pitäisi käyttää komponenttien välillä. Toisten komponenttien sisältämään tietoon viittaaminen voi tapahtua loogisten vierasavainten avulla. Looginen vierasavain on tietokannan kenttä, joka tunnistaa loogisesti toisessa datasaarekkeessa sijaitsevan tiedon. Relaatiomallisessa tietokannassa loogista vierasavainta ei saisi määritellä taulussa vierasavaimeksi. FileMan-mallissa loogisena vierasavaimena voitaneen käyttää tietuenumeroa hyvin paljolti osoitinkentän tapaan. Esimerkiksi tilausrivi (order line) -tietovarasto voi sisältää item_id-kentän, jonka avulla tunnistetaan tilattava tuote. Integroidussa relaatiokannassa item_id määriteltäisiin luultavimmin vierasavaimena, FileMan-tietokannassa osoitinkenttänä. Komponenttimallissa kenttää ei ole määritelty tietokantaan vierasavaimena, vaan toimintatason komponentti Order voi käyttää tätä kenttää käsitellessään tilausrivejä ja kutsuessaan Item komponentin liittymää, jolla Item-komponentti palauttaa tietoa omasta tietovarastostaan. Loogisen vierasavaimen käyttö relaatiokannassa vaatii tietokantamäärittelyn muuttamista, mutta jos FileMan-tietokannassa käytetään loogisena vierasavaimena tietuenumeroa (joka mahdollisen tietokannan vaihdon yhteydessä ohjataan uuden tietokannan avainkentäksi), ei tietokantaan tarvitse tehdä muutosta. Loogista vierasavainta käyttämällä saavutetaan tarvittaessa parempi joustavuus: esimerkiksi tilausrivin toteuttavien luokkien suunnittelija on voinut päättää, että tilausrivin item_id-kenttä on merkkijonotyyppinen, kun taas item-tietovaraston suunnittelija on voinut tehdä item_id-kentästä numeerisen. Kannattaa kuitenkin pitää kiinni yhdenmukaisesta käytännöstä ellei ole hyvää syytä tehdä toisin. Loogisen vierasavaimen tuoma joustavuus mahdollistaa joustavan siirtymisen järjestelmän päivityksissä tai muutoksissa jotka vaikuttaisivat moniin tiedostoihin tai tauluihin. Jos toimintatason hajautetun komponentin liittymissä käytetään merkattua dataa, kuten XML:ää, voidaan tietotyyppiä vaihtaa liittymien tasolla. Yleensä datasaarekkeet pyritään normalisoimaan sekä sisäisesti että myös ulkoisesti, eli sama taulu tai tiedosto ei saisi olla kahdessa datasaarekkeessa. Duplikaatio voi kuitenkin joskus olla monimutkaisissa tapauksissa tarpeen. Yhdestä moneen -suhteen tietovaraston (1:n taulut, normaali looginen ja hierarkkinen toistuma) pitäisi kuulua vain yhteen toimialakomponenttiin, ja siihen pitäisi navigoida vain yhdestä suunnasta. Yleensä tällainen tietovarasto sijoitetaan komponenttiin, joka on korkeammalla toiminnallisessa hierarkiassa 12. Monesta moneen suhteen tietovaraston (n:n taulut, suhdetiedostot) pitäisi kuulua koordinaattorikomponenttiin, joka on molempien suhteeseen osallistuvien komponenttien yläpuolella toiminnallisessa hierarkiassa. Tällöin koordinaattori hoitaa tiedonkulun suhteeseen kuuluvien komponenttien välillä. Tämä mahdollistaa myös navigoinnin molemmista suunnista. 12 Toiminnallisessa hierarkiassa komponentti voi käyttää vain alemman tai saman tason komponenttien palveluita. Tähän ratkaisuun syynä on kehämäisten riippuvuuksien välttäminen, eräs komponenttisuunnittelun perusperiaatteista. Kehämäisten riippuvuuksien poissaolo on toteutunut, jos komponenttien välille voidaan piirtää DAG (directed asyclic graph) kaavio. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

83 KOMPONENTTIEN PYSYVIEN TIETOJEN HALLINTA 83 Molemmat edellä esitetyt ohjeet pätevät, kun toisiinsa liitetyt toimialan entiteetit ovat yhteydessä eri komponentteihin kuuluvien tietovarastojen kautta. Jos ne kuuluvat samaan komponenttiin, myös suhteen tietovarasto kuuluu yleensä samaan komponenttiin Tiedon tallennus komponentin vastuulla Toiminta- ja resurssikerroksen hajautetut komponentit eivät yleensä hae kaikkea sitä dataa, minkä ne voisivat. Esimerkiksi jokin potilaaseen liittyvä operaatio saattaa tarvita vain potilaan tunnistetiedot. Tiedon tallennus komponentin vastuulla (Component persistence) (Herzum, Sims 2000) tarkoittaa lähestymistapaa, jossa tiedon säilytystä ohjataan suoraan toimintatason hajautetun komponentin sisältä. Oman toimintansa hoitavien komponenttien filosofian mukaisesti tiedon pysyvyysliittymiä ei paljasteta toimintatason komponenttia käyttäville muille komponenteille liittymien kautta. Pikemminkin operaatiot kuvaavat toiminnallista ominaisuutta, esim. update_order( ), ja operaation toteutuksen vastuulla on hoitaa tiedon tallennus. Komponentin hoitamaan tiedon tallennukseen on useita vaihtoehtoja: Suora tietokantayhteys. Toimintatason hajautettu komponentti käyttää suoraan tietokantapalvelimen kanssa kommunikoivaa väliohjelmistoa, kuten SQL-kieltä ja ODBC:tä tai RPC Brokeria. Toisin sanoen toimintakerroksen logiikka on yhdessä resurssikerroksen logiikan kanssa. Vaikka tämä on nopea tapa kirjoittaa sovelluksia, se ei tue hyvin uudelleenkäyttöstrategiaa, sitoo toimintalogiikan suoraan tietokantaan, sekoittaa eri kerrosten vastuita ja aiheuttaa tietokantamuutosten heijastumisen kalliina muutoksina muualle järjestelmään. Kerroksellinen yhteys. Tässä tapauksessa tietokantayhteys on upotettu ohjelmalliseen kerrokseen toimialakomponentin loogiseen resurssikerrokseen. Kerros voidaan toteuttaa omana hajautettuna resurssikomponenttinaan. Kerroksellisella yhteydellä pyritään siihen, että toimintalogiikan ohjelmoijalta piilotetaan resurssikerroksen tiedonsäilytysmekanismit. Hajautetun komponentin rakentaja ei ole suoraan yhteydessä tietokantaan vaan käyttää esimerkiksi pysyvyysluokkien (PLC persistence language class) joukkoa (ks. luku 15.5). Suora tietokantayhteys on nopea toteuttaa, vaatii yleensä vain vähän käynnistystyötä, tarjoaa hyvän suorituskyvyn, mutta on ajan mittaan kalliimpi kehittää ja ylläpitää. Kerroksellinen yhteys vaatii alkutyönä sopivan kehyksen tekemisen tai hankkimisen, voi olla hieman tehottomampi kerroksellisuuden vuoksi, mutta skaalautuu tarvittaessa suuriin projekteihin ja on muutosten suhteen sallivampi. Kerroksellisessa yhteydessä toimialakomponentin pysyvä oliomalli (ks. luku 10.4) on näkyvissä toimintakerroksessa toteutettuina pysyvyysluokkina. Kukin pysyvyysluokka sijaitsee vain yhdessä toimialakomponentissa ja sen omistaa kyseisen toimialakomponentin toimintakerros, mutta se voi olla käytettävissä saman toimintakerroksen muissa hajautetuissa komponenteissa. Pysyvän oliomallin ohjaus tietokantaan on toteutettu resurssikerroksen komponentissa, jonka on tietenkin tunnettava käytettävä tietokantamalli. Toiminta- ja resurssikerroksen välinen kommunikaatio voidaan kerroksellisessa yhteydessä toteuttaa pysyvyysluokan sisäisesti tai ulkoisesti: sisäinen toteutus: kukin pysyvyysluokka sisältää pysyvyysmekanismin toteutuksen ja yhteyden resurssikerrokseen ulkoinen toteutus: kunkin pysyvyysluokan pysyvyysmekanismi on luokan ulkopuolinen. Tällöin pysyvyysluokka on pelkkä tietoluokka, ja erillinen luokka (PLC handler, PLC pointer, PLC Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

84 84 OSA II: Taustaselvitykset reference) toteuttaa tiedon tallennuksen. Tällöin vastuu tiedon tallennuksesta on erillään resurssikerroksen tietokantayhteydestä. Varsinainen pysyvyysluokka ei sisällä juuri lainkaan toimintalogiikkaa ja sen liittymä koostuu lähinnä get - ja set -operaatioista. PLC handler tarjoaa pysyvyysliittymät ja on yhteydessä resurssikerrokseen. Tämä helpottaa mm. pysyvyysluokkien uudelleenkäyttöä esim. parametreina välitettävinä toimialan tietotyyppeinä (ks. luku 15.3). PLC handler on ainoa toimintatason hajautetun komponentin luokka, joka tietää, kuinka kommunikoida resurssikerroksen kanssa, tai onko resurssikerros toteutettu hajautettuna komponenttina. Jos tiedon pysyvyys hoidetaan kerroksellisen yhteyden avulla, jolloin toimintalogiikka kommunikoi vain pysyvyysluokan kanssa, ja yhteys resurssikerrokseen on piilotettu PLC handler -luokkaan, ratkaisu on suorituksen aikana hyvin skaalautuva. Lisäksi sopivien määrittelyiden sekä muutamien projektiin liittyvien sääntöjen avulla koko resurssikerros, kaikki resurssiluokat sekä PLC handler - luokat on mahdollista generoida automaattisesti. Resurssikerroksen suunnittelussa huomioon otettavia seikkoja: Resurssikerros voi olla toteutettu eri teknologioilla, eikä sen tarvitse välttämättä olla hajautettu komponentti. Riippuen resurssi- ja toimintatason hajautettujen komponenttien välisestä kutsumekanismista kerroksen toteuttaminen voi vaikuttaa suoritustehoon. Toisaalta hajautetuilla komponenteilla toteutettu kerrosten erotus on hyödyllinen esim. tietokantatekniikkaa vaihdettaessa, jopa tietokannan vaihtaminen ilman vaikutuksia toimintakerroksen hajautettuihin komponentteihin voidaan saavuttaa. Resurssikerros ei voi koskaan kutsua suoraan toista resurssikerrosta tai mitään muuta toisen komponentin kerrosta kehämäisten riippuvuuksien välttämiseksi. Ainoa poikkeus on, jos resurssikerros piilottaa sen, että toinen järjestelmä hoitaa tiedon tallennuksen, jolloin resurssikerroksen koodi käyttää tätä toista järjestelmää. Kerroksellisessa arkkitehtuurissa pyritään välttämään tietokannan liipasinten (trigger) käyttöä. Liipasinten välttäminen helpottaa siirtymistä eri tietokantojen välillä, ja estää toimintalogiikan pirstoutumisen osittain resurssikerrokseen. Jos jostain syystä liipasimia halutaan käyttää, ne välitetään vastaaviin toimialakomponentteihin esimerkiksi ottamalla ne kiinni resurssikerroksessa ja palauttamalla ne toimintakerrokseen tapahtumina (mikäli toimintakerroksen komponentti on kirjautunut tapahtuman kuuntelijaksi). Toimintakerros voi edelleen lähettää nämä tapahtumat, jos se on tarpeen Pysyvyyspalvelut Pysyvyyspalvelut ovat komponenttien suoritusympäristön tarjoamia palveluja. Komponentti voi käyttää näitä palveluja oman tilansa tallentamiseen tai noutamiseen. Pysyvyyspalveluita voidaan käyttää komponenteissa, joiden on voitava ulkoistaa tilansa, esimerkiksi virhetilanteista toipumisen, konfiguroinnin tai käyttäjän henkilökohtaisten käyttöasetusten tallennuksessa. Se soveltuu ennen kaikkea käyttäjä- ja työtilatason komponenteille. On myös mahdollista käyttää sekä komponentin vastuulla hoidettavaa tiedon tallennusta että pysyvyyspalveluratkaisuja samassa komponentissa sopivissa kohdin. Komponenttien suoritusympäristö (CEE) voi tarjota pysyvyyskehysratkaisuja. Mikäli suoritusympäristö tarjoaa tämän palvelun, toiminnallisuuden ohjelmoijan tarvitsee yleensä toteuttaa vain kaksi operaatiota: internalize ja externalize. On mahdollista käyttää merkattua dataa komponenttiesiintymän tiedon tallennuksessa näiden operaatioiden avulla siten, että eristyskerros voi hoitaa nämä operaatiot automaattisesti, jolloin tiedon tallennus on täysin läpinäkyvää toiminnallisuuden ohjelmoijan kannalta (Herzum, Sims 2000). Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

85 KOMPONENTTIEN PYSYVIEN TIETOJEN HALLINTA 85 Esimerkiksi komponentin esiintymän aktivoinnin yhteydessä se noutaa tilansa internalize - metodilla. Deaktivoinnissa sille taas lähetetään externalize viesti, jolla se palauttaa tilansa tietovarastoon. Mikäli komponentti käyttää dynaamista perintää, voidaan tilan tallennuksesta tehdä yliluokan tehtävä. Pysyvyyspalvelumallin etuina ovat: yksinkertaisuus ohjelmoijan kannalta: toteutetaan vain internalize- ja externalize- operaatiot, mahdollisesti niidenkin toteutus automatisoitavissa yksinkertainen yleiskäyttöinen mekanismi varsinkin käyttöliittymä- ja työtilakerroksiin Pysyvyyspalveluiden heikkoutena on se, että kehys vaatii runsaasti kommunikaatiota tiedon tallennuksessa, ja toiminta voi olla hitaampaa kuin hajautetun komponentin itse hoitama tiedon tallennus. Yleensä se kuitenkin on riittävän tehokasta ainakin käyttäjä- ja työtilakerroksissa Myös palvelimen komponentin suoritusympäristöön on määritelty pysyvyyspalveluiden spesifikaatioita. Sun on määritellyt Java Data Objects (JDO) -spesifikaation (Sun 2000), joka tarjoaa yleisiä pysyvyyspalveluita. OMG on määritellyt Persistent State Service (PSS) -palvelun (Siegel 2000), jonka kapseloi pysyvyyspalvelut yleiskäyttöisen rajapinnan taakse. Toistaiseksi näitä spesifikaatioita tukevia tiedonhallintatuotteita on niukasti, mutta ne tarjoavat houkuttelevan mahdollisuuden tiedon varastointikerroksen erottamiseen toimintakerroksesta Pysyvä oliomalli Pysyvä oliomalli (Persistent Object Model, POM) (Herzum, Sims 2000) on tarpeen toteutettaessa hajautettuja komponentteja oliotekniikalla. Pysyvä oliomalli kuvaa pysyvien olioiden väliset suhteet yleensä monitasoarkkitehtuurin toimintakerroksessa. Pysyvän oliomallin ohjaus varsinaiseen tietokantaan tapahtuu resurssikerroksessa. Käytetty lähestymistapa (oliosuuntautunut toimintatason hajautettujen komponenttien ja datasaarekkeiden käyttö) asettaa haasteen oliomallin ja ei-oliomallisen tietokannan yhteensovittamiselle. Kunkin toimialakomponentin tiedon pysyvyyden ongelman ratkaiseminen tarkoittaa tässä tapauksessa juuri tätä yhteensovittamista. Suhteet ja tunnistus ovat ongelmallisia asioita oliomallin sovittamisessa. Seuraavat ongelmat esiintyvät ei-olioparadigmaan perustuvissa tietokannanhallintajärjestelmissä. Oliotietokannat ja relaatiotietokantoihin tehdyt oliolaajennukset helpottavat oliomallien tallentamista eikä sovitusta tarvita. Suhteet: On melko yksinkertaista sovittaa assosiaatio- tai koostesuhde oliomallin ja ei-oliomallin välillä esim. käyttämällä vierasavainta tai osoitinkenttää. Relaatiotietokannoissa koostetyyppisen suhteen sovitus on kuitenkin aina hoidettava jollakin tavalla, kun taas oliotietokannoissa kooste voidaan yleensä tallentaa sellaisenaan. Perintä- tai yleistyssuhteen hierarkkinen kokonaisuus on purettava normalisoituihin osiin relaatiotietokantaan tallennusta varten ja koottava uudelleen käyttöä varten. Luokkien välinen perintäsuhde voidaan sovittaa kolmella eri tavalla. Oletetaan, että yliluokka sisältää esiintymän tunnisteen, ja siitä peritään aliluokkia, joissa on keskenään eri ominaisuuksia: 1. Jokaista konkreettista aliluokkaa varten on oma taulu tai tiedosto. Kunkin konkreettisen luokan tapauksessa sovelluskehittäjän on ohjattava kysely ja kuhunkin aliluokkaan liittyvät ominaisuudet oikeaan tiedostoon tai tauluun. Tiedon hakemista varten on otettava tällöin selville käytettävä luokka. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

86 86 OSA II: Taustaselvitykset 2. Kaikki konkreettiset luokat ovat samassa tiedostossa tai taulussa. Jokainen tietue sisältää yhden ylimääräisen kentän (esim. class:string), joka kertoo, mistä luokasta on kyse. Samoin kukin tietue sisältää vain kyseiseen luokkaan kuuluvat tiedot. Tiedon haku tietokannasta edellyttää tällöin luokkarajoitteen lisäämistä hakuun. 3. Relaatiotietokannassa perintä voidaan esittää koosteen avulla: on oma taulu yliluokkaa varten, ja omat taulut kutakin aliluokkaa varten. Yliluokan taulu sisältää yliluokkaan kuuluvat ominaisuudet, ja aliluokkaan kuuluvat taulut aliluokkien omat ominaisuudet. Sekä yli- että aliluokkien tauluissa on tunniste, jonka avulla sama esiintymä tunnistetaan. Relaatiokannan Join-operaatiolla muodostetaan kooste yli- ja aliluokan tauluista, jolloin koosteesta saadaan sekä yli- että aliluokan esiintymän ominaisuuksien arvot. FileMan-tietokanta tuntee koosteen toistuvan kentän (alitiedoston) muodossa. Sen lisäksi yleinen rakenne on nimikenttäosoitin, jolloin esimerkiksi Henkilön perustiedot ovat omassa tiedostossaan ja Potilas-tiedostossa on osoitin Henkilöön. Osoitinkentän kautta pääsee nopeasti Potilaasta Henkilön tietoihin. Kullakin ratkaisulla on puolensa. Toivottava tilanne on, että suunnittelijalle annetaan mahdollisuus käyttää kuhunkin tilanteeseen parhaiten sopivaa mallia. Tunnistus: Oliomaailman tunniste-käsite poikkeaa sekä relaatio- että FileMan-tietokantojen tunnisteesta. Oliopohjaisen kielen luokan esiintymä tunnistetaan yleensä osoittimen avulla, joka osoittaa siihen tilaan muistissa, jossa olio sijaitsee, eikä sen sisältämien tietojen perusteella. Oliomaailmassa on täysin hyväksyttävää olla kaksi eri oliota, joilla on täysin samat ominaisuuksien arvot. Relaatiotietokannassa tietue tunnistetaan pääavaimen avulla, FileMan-tietokannassa tietuenumero on yksikäsitteinen, ja muistuttaa oliotietokannan tunnistetta. Pysyvän oliomallin ohjauksessa tietokantamalliin on kolme vaihtoehtoa: 1. Suunnitellaan ensin tietokantamalli, ja johdetaan oliomalli siitä. Tällöin tietokantamalli voi olla suhteellisen hyvin optimoitu, mutta tämä voi johtaa kompromisseihin oliomallinnuksessa, koska siellä on käytettävä käsitteitä, jotka eivät ole oliopohjaisia. Syntyvä oliomalli voi olla kömpelö vaikuttaen kehitystyön tehokkuuteen. Toisaalta syntyvät järjestelmät voivat olla hyvin skaalautuvia, koska tietojen tallennuksessa käytetään tietokantajärjestelmää tehokkaasti. Tämä malli soveltuu hyvin automaattiseen ohjaukseen (mapping) tietokantamallista oliomalliin. 2. Suunnitellaan ensin pysyvä oliomalli, ja johdetaan tietokantamalli siitä. Tämä johtaa yleensä vähempiin kompromisseihin oliomallinnuksessa, ja soveltuu hyvin automaattiseen tai sääntöjen mukaiseen ohjaukseen oliomallista tietokantamäärittelyihin. Näin tarvitaan vähemmän työtä, infrastruktuuria ja välineistötukea, mutta malli ei ole kovin tehokas eikä joustava eikä yleensä skaalaudu kovin hyvin (Herzum, Sims 2000). 3. Suunnitellaan pysyvä oliomalli ja tietokantamalli erikseen, ja suunnitellaan yhdyskäytävä mallien välille. Tämä tapa saa aikaan hyvin joustavan toteutuksen, jossa ei tarvitse tehdä juuri kompromisseja tietokannan suunnittelussa eikä oliomallin suunnittelussa. Molemmat mallit voidaan optimoida itsenäisesti ilman että niiden yhdenmukaisuus juuri kärsii. Tämä tapa johtaa skaalautuviin ja suorituskykyisiin järjestelmiin. Ratkaisu vaatii runsaasti kehitystyötä, koska mallien välisen sillan rakentaminen on vaikeaa automatisoida ja vaatii taitoa kaikilla tasoilla. Muita tiedon pysyvyyskehykseen liittyviä kysymyksiä ovat: Miten luokka ohjautuu useaan tauluun tai tiedostoon? Miten usea taulu tai tiedosto muodostavat yhden luokan? Voidaanko esim. kyselyihin tarkoitetuille komponenteille antaa tietokantahauissa käytettyjä korvausmerkkejä (esim. hakuavaimena?omponent* )? Mikä on tarkka strategia koskien tyhjiä tulosjoukkoja ja arvoja? Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

87 KOMPONENTTIEN PYSYVIEN TIETOJEN HALLINTA Tiedon yhdenmukaisuus ja muut tietokantojen tarjoamat palvelut Datasaarekemallissa tiedon yhdenmukaisuuden varmistaminen on selvä ongelma, koska tietokannan mahdollisuuksia ei käytetä tiedon ja esim. viittausten ajan tasalla pitämiseen. Tiedon yhdenmukaisuuden varmistamiseksi komponentin on hoidettava tiedon yhdenmukaisuus etenkin omien tietojensa osalta, ja myös muiden komponenttien osalta epäsuorasti niiden liittymien kautta. Jos komponenttien välisen tiedon integrointiin käytetään korkeamman tason komponentteja, voidaan saavuttaa itsenäiset alemman tason komponentit. Tällöin ylemmän tason komponentin kuuluu suorittaa jotkin operaatiot, jos sen käyttämillä alemman tason komponenteilla ei ole suoraa riippuvuutta. Esimerkiksi jos yhden alemman tason entiteetin poistamisen pitäisi johtaa toisen alemman tason entiteetin poistamiseen, on näitä molempia kontrolloivan komponentin tehtävä koordinoida molempien komponenttien operaatioita. Tästä lähestymistavasta seuraa se, että (hajautetut) komponentit jaellaan yhteentoimivina kokoelmina. Toimialakomponentti voi nojautua ennalta määritellyn yhteistoimintamallin mukaiseen toimintatapaan sen sisältämien hajautettujen komponenttien välillä. Tietokannanhallintajärjestelmissä lukitus tapahtuu tietojen muuttamisen yhteydessä. Lukitusten hoitaminen ja yhtäaikainen käyttö voidaan toteuttaa eri tavoin. Optimistisessa lukituksessa kaikki käyttäjät voivat lukea tietokannan tietoa. Myös tietueen ollessa lukittuna muut käyttäjät voivat lukea tietoja, ja tiedon oikeellisuus tarkistetaan ennen tietojen muuttamista tai tallennusta. Pessimistisessä lukituksessa muut käyttäjät eivät voi lukea lukittuna olevan tietueen tietoja. Myös turvallisuustarkistukset, toiminta virhetilanteissa ja virhetilanteista toipuminen on toteutettu eri tietokannoissa eri tavoin. Yhtäaikaiseen käyttöön, virhetilanteista toipumiseen jne. eri tietokannat tarjoavat yleensä omia ratkaisujaan. Yleensä toimialakomponentin sisällä voidaan hoitaa nämä ongelmat yhtenäisellä tavalla, mutta toimialakomponenttien välisessä toiminnassa vastuu on yleensä hoidettava ulkoisesti, esim. transaktio- ym. yleisten palvelujen avulla tai yhteisen koordinaattori-komponentin avulla. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

88 88 OSA II: Taustaselvitykset 11 KÄYTTÖLIITTYMÄT Käyttöliittymät ovat tärkeä ja loppukäyttäjälle ainoa näkyvä osa tietojärjestelmää. Monet suunnittelumenetelmät, esim. OMT++ (Aalto, Jaaksi 1994), ottavat käyttöliittymät myös koko järjestelmän suunnittelun tärkeäksi lähtökohdaksi. Myös käyttötapauspohjaisessa mallinnuksessa käyttötapauksista on usein suora linkki sovelluksen käyttöliittymiin. Hajautetuissa järjestelmissäkään käyttöliittymien merkitys ei ole pelkästään palvelimella sijaitsevan datan esittämisessä käyttäjälle, vaan käyttöliittymiin voi kuulua useiden ikkunoiden monimutkainen järjestelmä, joka sisältää monimutkaisia käyttöliittymäkomponentteja ja -rakenteita, vedä-pudotatekniikkaa, prosessien välistä kommunikaatiota, useiden alempien kerrosten toiminnan integrointia, toimintaprosessien ja työnkulkujen ohjausta sekä kielivalintoja. Kaiken tämän toteuttaminen käyttäjäystävällisellä tavalla ei suinkaan ole helppo tehtävä. Hajautetuissa ja komponenttisovelluksissa mielenkiinto kohdistuu yleensä etupäässä palvelimilla sijaitsevien komponenttien komponenttirajapintoihin, mutta komponentin suoritus- ja kehitysympäristön tulisi tukea tehokkaasti myös arkkitehtuurin ylimpien kerrosten tehokasta ja rikasta toteuttamista Käyttöliittymien suunnittelu Käyttöliittymien suunnittelussa noudatettavia perusperiaatteita ovat (Simonen 2000): Yksinkertaistaminen: riittävän yksinkertaiset toiminnot, ei liikaa tietoa näytössä kerrallaan, käyttäjän lyhytkestoisen muistikuorman minimointi, perustoiminnot helposti huomattavissa ja edistyneemmät ja harvinaiset toiminnot voidaan sijoittaa taustalle. Käyttäjän tukeminen: ei tiukkoja sääntöjä toimintojen suoritusjärjestykselle, erilaisia reittejä ja oikopolkuja käyttäjille, ohjeistuksen tarjoaminen varsinkin käyttäjän harvemmin suorittamiin tehtäviin, palautteen antaminen käyttäjän toiminnoista, selkeä poistumistapa eri tiloista ja toiminnoista, käyttäjäkohtaisten asetusten ja preferenssien sekä työn tilanteen tallennus sovelluksesta poistuttaessa, käyttäjän tehtävien tunnistaminen ja ennakointi ja sopivan opasteen tarjoaminen, yksinkertaisen ja luonnollisen dialogin käyttö ja kauttaaltaan yhdenmukainen käyttöliittymä. Käyttäjän tottumusten tunteminen: käyttäjän tuntemien termien ja kuvakkeiden käyttö. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

89 KÄYTTÖLIITTYMÄT 89 Suorakäyttöiset käyttöliittymät ovat käyttöliittymiä, joissa käyttäjä saa välittömän palautteen tekemistään toiminnoista. Suorakäyttöisessä käyttöliittymässä tilanne kuvaruudulla vastaa sovelluksen tilaa jatkuvasti, ja operaatiot, joita käyttäjä ei voi suorittaa, ovat poissa käytöstä. Välitön palaute auttaa käyttäjää korjaamaan virheet heti niiden sattuessa. Eräkäyttöisissä järjestelmissä käyttäjä saa palautteen vasta suoritettuaan toiminnon loppuun. Myös eräkäyttöisissä käyttöliittymissä pyritään huolehtimaan siitä, että käyttäjä ei joudu esim. syöttämään tietoa uudelleen virhetilanteen jälkeen. Tyypilliset Windows- ja Java-sovellukset ovat suorakäyttöisiä: käyttäjä saa välittömästi palautteen, järjestelmä käyttää dialogeja ja ilmoituksia käyttäjälle, ja toiminta on hyvin vuorovaikutteista. Eräkäyttöisiä käyttöliittymiä ovat mm. perinteiset HTML-lomakkeet, käyttäjä täyttää ensin kaikki lomakkeen tiedot, minkä jälkeen hän painaa lähetä-nappia, ja vasta palautuvalla sivulla järjestelmä antaa palautteen esim. virheellisistä syötteistä. HTML-lomakekäyttöliittymien vuorovaikutteisuutta on pyritty parantamaan mm. käyttämällä dynaamista HTML:ää Komponenttijärjestelmien käyttöliittymät Komponenttitekniikoita käyttäen on kaksi päävaihtoehtoa käyttöliittymän toteuttamiseen: 1. Staattinen käyttöliittymä, jonka sovelluksen tai käyttöliittymän rakentaja rakentaa sovellusta varten 2. Dynaaminen käyttöliittymä, joka muodostuu automaattisesti sovelluksen suorituksen aikana palvelimelta saatavan metadatan perusteella. Edellisten yhdistelmä on kyseessä kun toimintatason komponentin määrittelyjen perusteella luodaan peruskäyttöliittymä, jota käyttöliittymän rakentaja muokkaa pidemmälle. Metadatan saanti on tarpeen myös staattisten käyttöliittymien rakentamisessa. Sekä staattiset että dynaamiset käyttöliittymät voivat olla joko suorakäyttöisiä tai eräkäyttöisiä. On huomattava, että käyttöliittymä on komponentin hajautusarkkitehtuurissa eristettynä toimintalogiikan toteuttavista palveluista. Tämä mahdollistaa entistä suuremman vapauden ja useita erilaisia vaihtoehtoja käyttöliittymien toteuttamisessa. Palvelimella sijaitsevien komponenttien palvelut voidaan esittää eri tyyppisille käyttäjille ja eri tyyppisissä sovelluksissa eri tavoin. Samoja palveluita voidaan käyttää hyvinkin erilaisilla käyttöliittymillä. Tiedon esitystapaan liittyviä seikkoja määritellään varsinkin perinnejärjestelmissä myös tietokannassa, esim. kenttien pituudet. On kyseenalaista sijoittaa runsaasti tiedon esitystapaan liittyviä seikkoja esim. toimintatason komponentin määrittelyn yhteyteen. Toisaalta dynaamista käyttöliittymää varten toteutettava esitystapakerros nojautuu täysin alemmilta kerroksilta saatavaan metadataan, jolloin on välttämätöntä määritellä esitystapaseikkoja käyttöliittymäkerrosta alemmalla tasolla. Esityksessä käytettävän tekniikan ja käyttäjärajapinnan (ks. luku 2.1) toteuttamisen tulisi kuitenkin kuulua pelkästään käyttäjää lähinnä olevan arkkitehtuurikerroksen vastuulle. FixIT-välineistön kaksitasoarkkitehtuurin toteutuksissa käyttöliittymä on staattinen lomakesovellus: kukin versio on asennettava tai ladattava käyttäjän työasemalle sekä tehtävä tarvittavat yhteysmäärittelyt ennen sovelluksen käyttöä. Käyttäjällä on käytössään pelkästään sovellukseen ohjelmoidut toiminnot ja eri sovellusten integrointi käyttäjän kannalta tapahtuu yleensä rakentamalla tarvittava osa käytettävää sovellusta mukaan toiseen sovellukseen (esim. perustietojen syöttö henkilörekisteristä, joka toimii tutkimusrekisterin kannalta apurekisterinä). Tämä aiheuttaa tietenkin ylimääräistä ohjelmointityötä ja usein myös toimintalogiikan duplikoitumista, koska sovelluksen apurekisterillä on myös oma sovelluksensa, joka on ensisijaisesti tarkoitettu kyseisten tietojen käsittelyyn. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

90 90 OSA II: Taustaselvitykset Kehitysympäristö sisältää dynaamisia piirteitä, koska se sisältää apurin (wizard), joka luo automaattisesti tietokannan määrittelyjen ja sovelluskehittäjän valintojen perusteella käyttöliittymäpohjan, josta sovelluskehittäjä voi jatkaa lomakkeen rakentamista. Eräässä dynaamisen käyttöliittymän toteuttavassa kehyksessä (Devos, Tilman 1999) ratkaisu perustuu keskitetyn varaston käyttöön. Sovellusten rakentamisessa käydään läpi useita vaiheita (halutussa järjestyksessä): oliomallin laajentaminen tai muuttaminen, sovellusympäristön määrittely ja käyttöliittymäikkunoiden ulkoasujen määrittely, oikeuksien myöntämiseen käytettyjen sääntöjen laajentaminen tai tarkentaminen, toimintasääntöjen määrittely ja työnkulkuprosessien määrittely. Keskitettyyn varastoon luodaan sovelluksissa tarvittavat olioluokat, ja luokille määritellään kaikille sovelluksille yhteiset ominaisuudet, käyttäytyminen ja rajoitukset. Oliomallin määrittelyn jälkeen luodaan tarvittavat tietokantamääritykset ja ohjaukset (mappings). Sovellusympäristö määritellään yhteisestä oliomallista valitsemalla sovellukseen mukaan otettavat, luotavat ja kyseltävät oliot ja ominaisuudet. Kun sovellusympäristö on tallennettu varastoon ja käyttöoikeudet on asetettu, perussovellus on käyttövalmis: käyttäjät voivat valita ko. ympäristön, syöttää tietoa, tehdä kyselyitä, ottaa tulosteita jne. Ympäristöä voi edelleen muokata joko yksittäisen käyttäjän tai useiden käyttäjien tarpeiden mukaan määrittelemällä näkymiä, kyselyitä tai alemman tason sovellusympäristöjä. Varastopohjaista sovelluskehystä käyttämällä (Devos, Tilman 1999) on toteutettu dynaaminen käyttöliittymä. Ympäristössä käyttöliittymän määrittelyvälineet antavat mahdollisuuksia luoda uusia lomakkeita ja listoja sekä muuttaa olemassa olevia. Olioiden ominaisuuksien esittämiseksi valitaan jokin tarjolla olevista näyttökontrolleista, esim. olioiden suhteiden oletuseditori voidaan korvata haluttaessa toisenlaisella lomakkeella tai kontrollilla. Suhdepolkuja voidaan seurata editorissa, mikä mahdollistaa eri luokista koostettujen olionäkymien muodostamisen (denormalisoinnin). On huomioitu, että käyttäjillä on tapana kertoa vaatimuksiaan sen toimintatavan perusteella, joka heillä on juuri sillä hetkellä. Heidän on vaikeaa kuvitella kuinka uusi teknologia vaikuttaa heidän tuleviin työtapoihinsa. Tämän takia uusien ohjelmistojen kokeilu ja prototypointi on tarpeen. Liian usein kuitenkin prototyyppejä käytetään suunnittelun validointiin, eikä varsinaisten vaatimusten löytämiseen. Toiminnallisuuteen tehdyt parannukset varsinkin niiltä toiminnallisuuden osilta, jotka ovat suhteellisen riippumattomia toimialasta, kannattaa tehdä uudelleenkäytettäviksi lisäämällä ne käytettävien toteutusten varastoon. Dynaamisen käyttöliittymän käyttöä puoltavia seikkoja ovat ylläpitotyön väheneminen käyttäjien työasemilla, koska käyttöliittymä muodostuu palvelimen määrittelyjen perusteella sekä se, että käyttöliittymä voi mukautua automaattisesti palvelujen muutoksiin. Staattisen käyttöliittymän avulla voidaan helpommin toteuttaa monimutkaisia ja erikoistapauksiin sopivia käyttöliittymiä ja käyttää edistyneitä näyttökomponentteja. Onkin tavoiteltavaa, että komponenttipohjaista sovelluskehystä, kuten komponentti-fixit:iä käyttämällä tehdyt sovellukset sisältävät sekä riittävästi palvelimilla sijaitsevaa metadataa dynaamisen käyttöliittymän muodostamista varten että keinot rakentaa staattisia ja toiminnallisesti rikkaita ja erikoistuneita käyttöliittymiä samoihin palveluihin. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

91 KÄYTTÖLIITTYMÄT Työpöytäintegraatio ja portaalit Viime aikoina erityistä huomiota on saanut yhdenmukaisen ja integroidun näkymän tarjoaminen käyttäjälle. Suorakäyttöisissä käyttöliittymissä tämä suuntaus näkyy sovellusten välisen työpöytäintegraation kehittämisenä. Eräkäyttöisissä ja web-käyttöliittymissä samaan suuntaan on pyritty kehittämällä portaaleja. Työpöytäintegraation standardit, kuten CCOW (CCOW 1998), määrittelevät yleisen mallin työasemalla toimivien sovellusten työpöytälähtöisen visuaalisen integroinnin toteuttamiseen. CCOW on nimen omaisesti potilaan hoitotietoa käsittelevien sovellusten integrointiin tarkoitettu standardi. Työasemalla yhtäaikaisesti toimivat sovellukset voivat synkronoida toimintansa standardin avulla esim. siten, että kun yhdessä sovelluksessa valitaan tietty potilas, muut sovellukset siirtyvät samaan potilaaseen. Potilaan käsittelyn lisäksi mm. sovellusten yhteisen sisäänkirjoittautumisen synkronointi on mahdollista CCOW:n avulla. Nykyisellään CCOW-standardiin on olemassa ActiveX-tekniikkaan perustuvia toteutuksia Windows-ympäristöön. Sovelluksiin on rakennettava tuki CCOW:n synkronoinnin hoitavalle osalle (Context Manager), jotta integrointi saavutetaan. Portaali-käsitettä käytetään eri merkityksissä, useimmiten tarkoittaen www-palvelua, joka tarjoaa laajan valikoiman eri resursseja tai palveluita. Enterprise portal -nimitystä käytetään portaalista, joka tarjoaa tietylle käyttäjäryhmälle, esimerkiksi organisaation työntekijöille, integroidun lähtöpisteen tarjottaviin verkkopalveluihin. Tyypillisiä ja tavoiteltavia portaalin piirteitä ovat (alkeellisimmista lähtien): 1. palveluihin (esim. intranet) pääsy yhdestä paikasta, käyttäjän sijainnista riippumatta, yleiset tietopalvelut, haut ja yleisesti tarvittavat linkit; 2. sisällön integrointi, pääsy yhteisiin hakemistoihin, henkilökohtaistaminen, käyttäjäkohtainen muokattavuus, käyttäjän roolista riippuvat palvelut, käyttäjään liittyvän ajankohtaisen tiedon automaattinen tarjoaminen; 3. sovellusten integrointi portaalin kautta käytettäviksi, portaaliin sisäänkirjoittautuminen riittää sovellusten käyttämiseen, mahd. toiminnalliset linkit www-informaation ja tietojärjestelmien välillä. Portaalin toteuttamisessa pyritään yleensä mm. vastaamaan eri käyttäjäryhmien erilaisiin tietotarpeisiin (kustomointi), tukemaan eri ihmisten erilaisia työtapoja (personointi), tarjoamaan suoraan yhdestä pisteestä linkkejä tarvittavaan tietoon tai palveluihin (työprosessien kehittäminen) ja varmistamaan portaalijärjestelmässä automaattisesti tietojen ajantasaisuus. Tietojärjestelmän integroimiseksi portaalin tai työpöytäintegraation avulla järjestelmän on tarjottava sopiva integrointirajapinta. Työpöytäintegraatiossa järjestelmän käyttöliittymään rakennetaan osa, jonka avulla kommunikointi synkronoinnin hoitavan palvelun kanssa hoidetaan. Työpöytäintegraation lisääminen järjestelmään jälkikäteen on hyvin vaikeaa, ellei järjestelmien suunnittelussa ole otettu ulkopuolisen ohjauksen mahdollisuutta huomioon. Portaaliratkaisuissa järjestelmät, jotka tarjoavat selainpohjaisen käyttöliittymän, voidaan yleensä liittää portaalista käytettäviksi. Yleisiä turvallisuusrajapintoja kerralla tapahtuvan sisäänkirjoittautumisen toteuttamiseksi ei kuitenkaan ole yleensä tarjolla, ja valmiit www-käyttöiset käyttöliittymät eivät ole yleensä kustomoitavissa tai personoitavissa kovinkaan laajasti. Käyttöliittymälähtöinen ja käyttäjäläheinen integrointi on vain yksi lähestymistapa tietojärjestelmien yhteistoiminnallisuuteen. Seuraavassa luvussa tarkastellaan järjestelmien integrointia laajemmassa mittakaavassa. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

92 92 OSA II: Taustaselvitykset 12 JÄRJESTELMÄINTEGRAATIO Edellisessä luvussa kuvattiin järjestelmien integrointia tarjoamalla käyttäjälle yhtenäisiä näkymiä eri järjestelmiin ja yhteisiä palveluita työpöytäintegraation toteuttamiseen. Sovellusten välistä integrointia on kuitenkin lähestytty yleisesti alemmalla tasolla. Enterprise Application Integration (EAI, ks. sanasto), on yleisnimitys organisaation järjestelmien yhteentoimivuuden parantamiseen pyrkimisestä modernisoinnin yhteydessä. Terveydenhuollon tietojärjestelmien toiminnan kehittäminen vaatii sovellusten yhteistoimintaa. Sairaaloissa on käytössä useita erillisjärjestelmiä erilaisia käyttötilanteita palvelemaan. Järjestelmien sulava yhteistoiminta vaatii joko sovellusten välistä kommunikointia tai sovellusten kehittämistä mahdollisimman pitkälle yhteisistä osista rakentuviksi. Toisaalta sovelluskehittäjät ja ylläpitäjät haluaisivat yhtenäisen ja eri osiltaan hyvin yhteensopivan ympäristön helpottamaan sovellusten ylläpitoa, rakentamista ja yhteensovittamista. Tässä luvussa tarkastellaan eri tasoja ja tapoja, joilla sovellusten yhteistoiminnallisuutta voidaan toteuttaa. Yhteentoimivuusprotokolla (interaction protocol) on joukko sääntöjä, jotka määrittelevät kahden tietojärjestelmän välisen vuorovaikutuksen. Yhteentoimivuusprotokollat voivat sisältää järjestelmien välisten viestien muodon määrittelyjä ja myös näiden viestien vaihtamiseen käytettäviä tekniikoita. Järjestelmien yhteentoimivuus ei ole pelkkä tekninen ongelma, vaan siihen sisältyvät myös sisällölliset, toiminnalliset ja arkkitehtuurilliset seikat. Järjestelmät voivat olla vuorovaikutuksessa hyvin eri tavoin, alkaen hyvin löyhästi määritellyistä protokollista, jotka vaativat tulkkaamisen molemmissa päissä, tiukasti integroituun yhteistoimintaan, jossa järjestelmät kommunikoivat natiivisti, eli käyttäen identtisiä protokollia kaikilla tasoilla. Eri toimittajien tekemien järjestelmien yhteentoimivuuden perusta ovat standardit tai yhteiset sopimukset. Järjestelmien rakentaminen on standardien mukaisiksi voi lisätä järjestelmän toteuttamistyötä ja toteutuskustannuksia. Onkin järjestelmien hankkijoiden vastuulla suosia standardien mukaisia järjestelmiä, jotta organisaation järjestelmäkokonaisuudesta voidaan rakentaa järjestelmien yhteentoimivuutta tukeva. Standardeja kehitetään hyvinkin eritasoisiin vaatimuksiin. Kuvassa 23 luetellaan eri tasoisia terveydenhuollon sovelluksissa käytettyjä standardeja. Practice Practice guidelines, protocols Cochrane (EBM), (EBM), Best Best practice (Doctor s CD/ CD/ Finland), care care guidelines (Prodigy) Classifications, nomenclatures and and terminology ICD-10, Snomed, ICPC, ICPC, terminology servers (UMLS, Galen-in-Use) Best practices De De facto facto and and de de jure jure standards HL7, HL7, Edifact, DICOM 3, 3, CEN CEN 251, 251, ISO ISO Health Health care care specific specific objects objects HANSA HANSA // HISA, HISA, CORBAmed, MS MS HUG HUG Generic Generic standards standards and and tools tools UML, UML, XML, XML, SGML, SGML, HTML, HTML, DCOM, DCOM, CORBA, Java Java Infrastructure Kuva 23. Terveydenhuollon sovellusten standardien hierarkia (Saranummi 2000) Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

93 JÄRJESTELMÄINTEGRAATIO Integrointitasot Kuten edellisessä kappaleessa todettiin, järjestelmiä voidaan sovittaa yhteen hyvin monilla eri tasoilla. Eri tasojen tunnistaminen on hyödyllistä yhteensovittamista suunniteltaessa ja käytettäviä tekniikoita ja standardeja valitessa. Tasot (alimmasta korkeimpaan) (Herzum, Sims 2000): 1. Tekniset liittymät ovat ohjelmistomekanismeja, joilla kohdejärjestelmään ollaan yhteydessä. Tämän tason sopiminen tarkoittaa käytettävän tekniikan sopimista, esim. CORBA:n, RPC:n, DCE:n tai suoran SQL-kielen käyttöä jaettuun tietoon pääsemiseksi. Teknisen liittymän protokolla voi olla myös usean tekniikan yhdistelmä, esim. XML:n käyttö CORBA-liittymän päällä. Tekninen liittymä voi olla tietokantaperusteinen, tiedostopohjainen yhdyskäytävä tai ohjelmointirajapinta (API) tai näiden yhdistelmä. Tietokantaperusteinen liittymä on yleinen integrointitapa esim. Musti-järjestelmissä ja muissa vanhoissa järjestelmissä, joissa yleensä ainoa tapa päästä käsiksi toisen sovelluksen tietoon toista sovellusta muuttamatta on käyttää suoraan sen tietokantaa, tai rakentaa yhteentoimivuuden toteuttava sovitin (interoperability adapter adapter-suunnittelumalli). Tietokantaan suoraan kirjoittaminen on riskialtista, koska on voitava pitää huolta myös tietoalkioiden välisistä suhteista. Sovitinta käyttämällä voidaan paremmin varmistaa, että tieto kirjoitetaan kantaan siten, että yhtenäisyys säilyy. Sovittimen kirjoittaminen voi tosin johtaa siihen, että on tunnettava kohdejärjestelmän sisäinen toteutus, ja osa kohdejärjestelmän toimintalogiikasta kopioidaan sovittimeen. Tietokantaperusteinen liittymä vaatii siis paljon tietoa molempien järjestelmien sisäisestä toteutuksesta. Tiedostopohjainen yhdyskäytävä (gateway) tarjoaa formalisoidun, joskus standardoidun kahdenvälisen liittymän, jota molempien järjestelmien on tuettava. Näissä järjestelmissä toinen järjestelmä kirjoittaa sovitun formaatin mukaisen tiedoston tai viestin, ja toinen lukee saman viestin samassa formaatissa. Tämä malli tarjoaa yksinkertaisen integraatioprosessin, jossa on sovittava pelkästään tiedoston rakenteesta. Sopiminen voi johtaa myös siihen, että jos on kommunikoitava usean järjestelmän kanssa, kukin liittymä vaatii oman kahdenvälisen toteutuksensa, ja jos jokainen liittymä on suunniteltu erikseen, on liittymät kallista toteuttaa. Ohjelmointirajapinta (API-) pohjaiset liittymät ovat liittymiä, joissa kutsuva järjestelmä voi kutsua toisen järjestelmän rajapintaa, jolloin kutsuttava järjestelmä toteuttaa liittymässä määritellyn palvelun. Sen sijaan, että konvertoitaisiin dataa taulusta toiseen, käyttäjälle annetaan joukko liittymiä. Nykyisin monet ohjelmointirajapintaliittymät ovat tiedon ylläpidollisesti orientoituneita, eli tarjoavat turvallisen tavan käyttää tietokantaa olemassa olevan sovelluksen osia käyttämällä. Ne eivät yleensä tee juuri tiedon käsittelyä, mutta tarjoavat yleensä helpon ja melko hyvin tiedon yhdenmukaisuuden säilyttävän tavan päästä tietoon käsiksi. Teknisiä esimerkkejä käytetyistä protokollista ovat CORBA, DCOM, MQ ja RMI. 2. Tekninen infrastruktuuri. Mahdollisuus kutsua teknisesti toisen järjestelmän liittymää ei poista kahden järjestelmän välisen vuorovaikutuksen teknisiä ongelmia. Esim. kohdejärjestelmän on joko oltava käynnissä, jotta sitä voi kutsua, tai kohdeympäristön on tiedettävä, kuinka käynnistää kohdejärjestelmä kutsun tullessa. Se kuinka aktivointi tapahtuu, kuuluu teknisen infrastruktuurin vastuulle. Tekninen infrastruktuuri kattaa kahden järjestelmän välisen kommunikoinnin teknisen tuen, ja sisältää mm. virheidenkäsittelyn, nimeämisen, transaktiot jne. Se Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

94 94 OSA II: Taustaselvitykset sisältää myös työnkulun tekniset näkökohdat, tai mahdolliset skriptaukset 13, joilla voidaan helpottaa ja koordinoida vuorovaikutusta. Teknisen infrastruktuurin ja teknisen liittymän erottaminen on tärkeää komponenttipohjaisessa järjestelmien yhteistoiminnassa, koska jotta liittymiä voitaisiin kutsua, on oltava olemassa tekninen infrastruktuuri, joka tukee kutsumista, ja tämä infrastruktuuri voi olla tarpeen rakentaa hyvinkin edistyneeksi, jopa täysiveriseksi komponenttien suoritusympäristöksi. On tarpeen saavuttaa yleinen tekninen infrastruktuuri tai kehys, jotta yhteentoimivuuden yksityiskohtainen taso saavutettaisiin. Jokainen protokolla, jota ei käytetä molemmissa järjestelmissä, vaatii tulkkaamisen, ja jollei tällaista tulkkaamista ole saatavilla, eivät kaikki yhteistoiminnan muodot ole mahdollisia. Esim. elleivät kohdejärjestelmä ja tekninen infrastruktuuri paljasta transaktiomallia, ei kutsuva järjestelmä voi kutsua kohdejärjestelmää transaktionaalisella tavalla. Teknisen infrastruktuurin eri protokollia voidaan lähestyä kahdella vastakkaisella arkkitehtuurimallilla: Mallituntemus: kutsuva järjestelmä tuntee kohdejärjestelmän teknisen infrastruktuurin protokollan, ja protokolla on suunniteltu siten, että kutsuva järjestelmä voi mukautua kohdejärjestelmän protokollaan. Esim. kutsuva järjestelmä voi tuntea kohdejärjestelmän liittymän, jota voi kutsua transaktion aloittamiseksi ennen toiminnallisen liittymän kutsua. Kontekstituntemus: Kutsuvalla ja kohdejärjestelmällä on yhteisiä protokollia, ideaalitilanteessa myös kunkin protokollan konteksti. Esim. molemmat voivat olla osa teknistä transaktiokehystä, jossa molemmat järjestelmät pääsevät kunkin transaktion kontekstiin koska tahansa, tai konteksti voidaan siirtää helposti järjestelmästä toiseen. Transaktioon osallistuminen ei ole pelkästään aloituksen ja suorituksen ulkoistamista, vaan voi olla hyvin yhteistoiminnallista mahdollistaen molempien järjestelmien mukana olemisen yhdessä ja samassa transaktiossa. 3. Sovellusinfrastruktuuri. Toiminnallisen yhteensopivuuden saavuttamiseksi tarvitaan sovellusinfrastruktuuria, joka sisältää arkkitehtuuriset päätökset, käytännöt, liittymäkäytännöt ja suunnittelumallit. Kukin teknisen infrastruktuurin protokolla kääntyy joksikin sovellusinfrastruktuurin protokollaksi. Tällä alueella ei ole juuri standardeja, joten yleensä kehitetään projektin tarpeisiin oma ratkaisu, joka vaatii tulkkausta tai sovitinta yhteentoimivuuden tukemiseksi. Esimerkiksi teknisen turvallisuusinfrastruktuurin olemassaolo ei takaa yhteistoiminnallisuutta: järjestelmien on silti sovittava näennäisesti triviaaleista asioista kuten tavasta, jolla tunnistetaan osallistuvat yksilöt tai ryhmät, tai toimintasäännöistä, joilla joillekin ryhmille sallitaan operaatioita ja toisilta ne kielletään. Toinen esimerkki sovellusinfrastruktuurin merkityksestä on virheidenkäsittely: vastaanottavan järjestelmän on tiedettävä mitä tehdä virheen sattuessa. Virheet voivat olla joko teknisiä ( verkkoyhteyttä ei saatu ) tai toiminnallisia ( tuote on loppunut varastosta ). Virheen merkitys on määriteltävä molemmissa järjestelmissä, esim. jos on sovittu, että virhekoodi 1001 tarkoittaa että tietyn potilaan tutkimustulosta ei löytynyt, on kyse sovellusinfrastruktuuritason protokollasta Skriptit (scripts) ovat yksinkertaisia välineitä, joita luodaan tarpeen mukaan esim. kehitysympäristössä tapahtuvaa toistuvaa toimintaa varten. Esimerkiksi tietyn sovelluksen mukaan tulevien tiedostojen kääntäminen ja kopiointi jakelupakettiin, komponenttien liittymien kehämäisten riippuvuuksien poissaolon varmistaminen, saman komponentin verkossa olevien versioiden tarkastaminen ja tarvittavan hakemistorakenteen luominen ovat tehtäviä, joita varten voidaan toteuttaa yksinkertaisia skriptejä. 14 Jos alemmat tasot eivät tue virheiden käsittelyä, on kiinnitettävä erityistä huomiota virhetilanteiden käsittelyyn sovellusinfrastruktuurin tasolla. Esimerkiksi CORBA-sovelluksia rakennettaessa palvelimella Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

95 JÄRJESTELMÄINTEGRAATIO Toiminnalliset liittymät. Mikäli projekti on päättänyt, että liittymien määrittelyyn käytetään jotain tiettyä tekniikkaa, esim. CORBA IDL:ää, tiedetään, millainen tekninen infrastruktuuri tarvitaan ja miten liittymää kutsutaan teknisesti. Tällöin ei kuitenkaan tiedetä mitään toiminnallisesta liittymästä. Esim. se, onko operaatio hae_potilas vai lisaa_tutkimus, ei ole osa teknisiä päätöksiä. Esim. CORBA:ssa määritellään osana teknistä protokollaa, että operaatiolla on nimi ja voi olla joukko parametreja. Toiminnallisessa liittymässä määritellään operaatioiden toiminnalliset nimet ja parametrit. Teknisten ja toiminnallisten liittymien muodot ovat suorassa yhteydessä toisiinsa: toiminnallisten liittymien määrittelyssä käytetään teknisen infrastruktuurin tarjoamia käytäntöjä. Nykyisillä tekniikoilla on mahdollista määritellä toiminnalliset liittymät ilman sitoutumista tiettyihin teknisiin liittymiin. Toiminnallisen liittymän määrittely voidaan tehdä prosessoinnin tyypin tai tiedon tyypin avulla. Esim. OMG:n määrittelemät toiminnalliset liittymät keskittyvät prosessointiin ja toiminnallisuuteen, kun esim. HL7 ja EDIFACT keskittyvät tiedon siirtämisen standardointiin. Ohjelmointirajapintaa käyttävissä liittymissä nämä päätökset näkyvät operaatioiden nimien ja parametrien määrittelyissä sekä operaatioiden välisissä yhteyksissä. Perinteisessä yhteentoimivuudessa kutsuva järjestelmä tarvitsee yleensä entiteettidataa, eli jonkin toimialan käsitteen sisältämää dataa. Tällöin kutsuva järjestelmä yleensä luo, lukee, poistaa tai tarkistaa tietoa kohdejärjestelmän perusentiteeteistä, ja tarvitaan lähinnä vuoropuhelua ylläpitotyyppisten ohjelmien välillä. Viime aikoina järjestelmien välinen vuorovaikutus on keskittynyt korkeammalle tasolle, esim. kohdejärjestelmä toteuttaa toimialan transaktion, jota yksi järjestelmä ei voi suorittaa itsenäisesti. Tässä tapauksessa yhteistoiminta tapahtuu enimmäkseen toimintaprosessitasolla, jolloin yhteistoiminnallisuuden tarve voi olla lähtöisin jopa käyttöliittymätasolta. 5. Semantiikka. Kun toiminnallisista liittymistä on sovittu, on tarpeen sopia kunkin interaktion tarkasta merkityksestä. Esim. komponentin operaatiolla luo_tilaus (in tilaus, out tulos) voi olla useita merkityksiä: 1. Kohdejärjestelmä luo uuden tilaus-tietueen tietokantaan, ja tietue pitää sisällään tietoa tilauksesta. Operaation ja tavaroiden asiakkaalle lähettämisen välillä ei ole yhteyttä. Kohdejärjestelmän muut osat eivät saa tietoa uuden tilaustietueen saapumisesta; tilaukselle ei tehdä aikataulua eikä tilaukseen liitetä tuotteita. Kutsuja ei saa tietoa siitä, hyväksyttiinkö tilaus ja onko se käsiteltävänä, vaan siitä, olivatko tiedot hyväksyttäviä. Jos kutsuja haluaisi tietoa esim. toimitusaikataulusta, pitäisi kutsujan kutsua toista liittymää, tai kohdejärjestelmä voisi käyttää tapahtumamekanismia jota kutsuja kuuntelisi. 2. Kohdejärjestelmä luo uuden tilauksen toiminnallisesti: tilaus aikataulutetaan ja siihen määritellään tavarat tilauksen luonnin suorana seurauksena. Kutsuja saa operaation suorana tuloksena tietoa operaation toiminnan tuloksesta. Pelkästään liittymiä tarkastelemalla ei operaation merkityksestä saa kuvaa. Toiminnan kannalta liittymän operaation merkitys on kuitenkin äärimmäisen tärkeä. Sama liittymä voi johtaa eri tapauksissa hyvin erilaiseen lopputilaan järjestelmässä, ja kutsujalle palautuvan tiedon merkitys voi poiketa paljonkin eri tapauksissa. Näin ollen alemmilla tasoilla tarkasti sovitulla liittymällä voi olla hyvin erilaisia merkityksiä. tapahtunut virhe voi palauttaa asiakassovellukseen pelkän Odottamaton virhe ilmoituksen, eli ohjelmisto ei anna mitään vihjettä virheen paikasta tai vaiheesta jossa se tapahtui. Tässä tilanteessa palvelinkomponentin olisi pitänyt napata virhe ja palauttaa esim. merkityksellinen virhekoodi asiakassovellukselle. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

96 96 OSA II: Taustaselvitykset Kun tietyn järjestelmän semantiikan määrittely on riittävän korkealla tasolla, voidaan toteuttaa semantiikan toteuttavia yhdyskäytäviä tai semanttisia siltoja. Lähitulevaisuudessa järjestelmien tulisi voida esittää kyselyitä käytettyjen liittymien tasoista, ja on myös esitetty visioita joissa voitaisiin kysellä semantiikan toteutuksia. Tämä vaatii kuitenkin huomattavasti nykyistä laajempaa standardointia, ja nykyisellään semantiikasta sopiminen on kallista järjestelmien toteuttajien välistä sopimista. 6. Toiminnallinen viitemalli. Esimerkki: kutsuva järjestelmä lukee potilastietoa kohdejärjestelmästä. Potilaan tunniste on 10 merkkiä pitkä kutsuvassa järjestelmässä, ja 36 merkkiä pitkä kohdejärjestelmässä. Riippumatta siitä miten hyvin järjestelmien väliset sovittimet on toteutettu, kutsuva järjestelmä ei kykene käyttämään saamaansa tietoa oikein. Esimerkki kuvaa kuinka liittymillä voi olla hyvin suora suhde järjestelmän sisäiseen toteutukseen. Mikäli järjestelmillä ei ole yhteistä toiminnallista viitemallia, niiden toiminnallisuus rajoittuu toiminnallisuuden pienimpään yhteiseen osajoukkoon. Mikäli jatkossa on tarkoitus integroida helposti tai koota sovelluksia eri toimittajien tekemistä osista, on tarpeen saavuttaa yhteisten teknisten liittymien, teknisen infrastruktuurin, sovellusinfrastruktuurin, toiminnallisten liittymien ja semantiikan lisäksi myös sama toiminnallinen viitemalli kaikista pisteistä, joiden on oltava vuorovaikutuksessa tai joihin on vaikutuksia, kun järjestelmät toimivat yhdessä. Täyden yhteentoimivuuden saavuttamiseksi tarvitaan siis toiminnallinen viitemalli, mutta järjestelmässä se on yleensä täysin sisäinen: esim. ainoa tapa kohdejärjestelmän tietokannan lukemiseen tarkoitetun sql-lauseen kirjoittamiseen on tietää kohdejärjestelmän tietokantakuvaus. Tämä on kohdejärjestelmän sisäisen toiminnallisen viitemallin tietoa. 7. Kehitysprosessin liittymät. On tilanteita, joissa järjestelmässä tiedetään jo aikaisessa kehitysvaiheessa, minkä järjestelmien kanssa yhteistoiminnallisuutta tarvitaan. Tällöin mukana olevien järjestelmien rajoitukset ja mahdollisuudet voidaan ottaa huomioon jo varhain kehitysprosessissa. Esimerkiksi jotta järjestelmien yhteistoiminta on mahdollista jo suunnittelun ja kehitystyön aikana, voi olla tarpeen saada käyttöön toisen järjestelmän spesifikaatio, jotta järjestelmien integrointi tai yhteistoiminnallisuus saavutetaan. Kehitysprosessin liittymien protokollat voivat ottaa kantaa myös jakeluun, kuten määritellä tarkasti sellaisten tiedostojen loogisen tai jopa fyysisen sijainnin, joita yhteistoiminnallisuuden toteuttamiseen tarvitaan. Järjestelmän teknisen arkkitehtuurin on otettava huomioon teknisten liittymien ja teknisen infrastruktuurin yhteistoiminnallisuuden protokollat. Sovellusarkkitehtuurissa on otettava huomioon sovellusinfrastruktuuri. Toiminnallisen arkkitehtuurin on otettava huomioon toiminnalliset liittymät, semantiikka ja toiminnallinen viitemalli, ja järjestelmän kehitysprosessin ja -välineiden kehitysprosessin liittymät Integrointitavat Kukin integrointitaso voi vaatia useita protokollia, esim. teknisessä infrastruktuurissa voi olla turvallisuusprotokolla, transaktioprotokolla jne. Kukin protokolla ja taso voidaan toteuttaa eri tavoin. 1. Integroitu yhteistoiminta saavutetaan, kun järjestelmillä on yhteinen protokolla. Esim. kaksi erillään kehitettyä järjestelmää voidaan saattaa toimimaan yhdessä tekemällä tarpeeseen yhteistoimintasovittimet. Sovitinten tehtävänä on toteuttaa jonkin yhteistoiminnallisuustarpeen toteutus. Integroitua yhteistoimintaa ovat myös mm. yhteistä tietokantaa käyttävät järjestelmät. 2. Siltayhteistoiminta (bridged interaction) on yhteistoimintaa, jossa molemmat järjestelmät sopivat käyttävänsä yhteistä formaattia joka voi poiketa molempien järjestelmien omasta Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

97 JÄRJESTELMÄINTEGRAATIO 97 formaatista. Silta ei yleensä sisällä älykkyyttä, ja se voidaan nähdä ulkoisena protokollamäärittelynä, johon molempien järjestelmien on mukauduttava. Yleensä mukana on ainakin viisi osaa eli kaksi järjestelmää, kaksi sovitinta ja itse silta. Nämä sovittimet poikkeavat integroidun yhteistoiminnan mukauttajista siten, että nämä sovittimet muuntavat tiedon sillan vaatimaan muotoon, johon molempien järjestelmien on erikseen mukauduttava. Jos saatavilla on yleinen standardi tai yleisesti käytettyjä siltoja, pitäisi siltaan sovitettujen järjestelmien voida toimia yhteen protokollan mukaisella tasolla. Ulkopuolelta hankittujen tai yleisten sanomamäärittelyjen, esim. HL7-viestien tai XML-dokumenttien käyttäminen ovat esimerkkejä siltayhteistoiminnasta. 3. Koordinoitu yhteistoiminta on tilanne, jossa kohde- ja kutsuva järjestelmä vaihtavat informaatiota niiden yläpuolella olevan koordinaattorin avulla. Usein koordinaattori voi olla erillinen sovellus, joka koordinoi järjestelmien yhteistoimintaa. Yksinkertaisissa järjestelmissä se voi olla esim. käyttöliittymän toteuttava koodi. Myös tätä koordinaattoria varten voi olla tarpeen tehdä sovittimet järjestelmiin. 4. Väyläyhteistoimintaan (bus-based interaction) perustuvassa yhteistoiminnassa protokolla ei kulje suoraan järjestelmien välillä, vaan yhteisen infrastruktuurin tason kautta. Tässä tapauksessa sovitin muuntaa järjestelmän sisäisen protokollan muotoon, joka on määritelty komponentin väylän liittymässä. Tämä tarjoaa korkeimman joustavuuden tason, mutta vaatii ohjelmistojen tekijöiden välisen arkkitehtuurisopimuksen. Väyläyhteistoiminta on yleensä rakennettu järjestelmään alusta alkaen, kun esimerkiksi siltayhteistoiminta toteutetaan usein jälkikäteen. Väyläyhteistoimintaa voidaan käyttää myös toteuttamaan muita integrointitapoja. Lisäksi useat järjestelmät voivat käyttää samaa väylää, kun esim. siltayhteistoiminnassa on kyseessä kahden välinen yhteys. Yhteisten verkossa sijaitsevien komponenttipalvelujen käyttö on väyläyhteistoimintaa. Taulukko 9. Liittymätasot, niiden yhteentoimivuusmallit, integrointitavat ja standardit Integrointitaso Yhteentoimivuusmalli Integrointitapa Standardit Tekniset liittymät API-pohjainen Väyläpohjainen CORBA, COM+, EJB, MQ-series, XML Tekninen infrastruktuuri Kontekstipohjainen Väyläpohjainen EJB Component Model, CORBA Components Sovellusinfrastruktuuri Yhteinen malli Väyläpohjainen Ei standardeja, yksittäisiä tuotteita kuten Forté Toiminnalliset liittymät API-pohjainen Silta tai integroitu HL7, CORBAmed, EDIFACT, X12 jne. Semantiikka Kontekstipohjainen Väyläpohjainen, erityisesti yleinen varasto Toiminnallinen viitemalli Kehitysprosessin liittymät Yhteinen malli Yhteinen malli Väyläpohjainen, erityisesti yleinen varasto Väyläpohjainen Standardeja / määrittelyitä ilmestymässä? HL7 RIM, ei kansallisia standardeja Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

98 98 OSA II: Taustaselvitykset Kussakin yhteistoimintatilanteessa eri protokollatasoilla voi olla eri integrointitapa. Jopa saman protokollatason sisällä voi olla eri tapaa käyttäviä protokollia. On yleistä että samassa järjestelmässä on sekä väylä- että siltayhteistoimintaa tai sekä koordinoitua että siltayhteistoimintaa. Eri protokollatasojen kesken on yleensä jokin vallitseva integrointitapa, jolloin järjestelmien yhteistoiminta yleistetään usein tätä tapaa käyttäväksi. Taulukossa 9 eritellään eri integrointitasojen ja tapojen yhteyksiä ja yhteentoimivuusmalleja. Kustakin tasosta on lisäksi lueteltu muutamia standardeja, joita tasolla on käytettävissä Komponenttipohjainen integrointi Komponentteja integroidaan toisiinsa järjestelmää komponenteista koottaessa. Eri järjestelmiä integroitaessa voidaan integroinnissa käyttää toisen järjestelmän palveluita, mikäli yhteentoimivuus on suunniteltu ja komponenttiliittymät tehty käytettäviksi. Komponenttien karkeajakoisuuden yhteydessä luvussa 2 määriteltiin sovellustason komponentti kokonaisena sovelluksena, jolle on rakennettu komponenttiliittymä. Sovellustason komponenttipohjainen yhteistoiminta (federation) on väljempi yhteys kuin sovelluksen kokoaminen komponenteista. Sovellustason komponentit ovat huomattavasti toimialakomponentteja suurempia yksiköitä, ja ne voivat sijaita tai olla rakennettuja eri organisaatioissa. Komponenttien yhteistoiminta voi olla joko suunniteltua tai tarpeen mukaan (ad hoc) rakennettua. Ad hoc -yhteistoiminnassa ei yleensä ole mallia, joka kuvaa yhteistoiminnan kokonaisuutena, vaan yhteistoiminnallisuus rakennetaan tiettyä tarvetta varten usein jälkikäteen. Yhteistoiminnan onnistuminen riippuu tällöin siitä, onko järjestelmät suunniteltu avoimiksi ja valmiiksi ennakoimattomaan yhteistoimintaan. Tällaisen yhteistoiminnan rakentaminen on usein hyvin kallista ja monimutkaista ja voi tuottaa luotettavuus-, suorituskyky- tai turvallisuusongelmia. Yleensä tällöin toteutetaan muunnokset molemmissa järjestelmissä useissa protokollakerroksissa. Suunniteltua (architected) yhteistoimintaa käyttämällä yhteistoiminnallisuutta lähestytään ulkopuolisena tehtävänä, joka on kuitenkin osa toiminnallisuuden ongelman ratkaisua. Se vaatii sopivien kehitysprosessien, välineiden ja toiminnan mallintamisen olemassaoloa sekä tiettyä arkkitehtuuria yhteistoimintaan osallistuvilta järjestelmiltä. Järjestelmien välisessä integroinnissa komponenttitekniikalla on neljä päävaihtoehtoa (Herzum, Sims 2000): 1. Yhteistoiminta mustana laatikkona toteutuu, kun järjestelmä näkee vain joukon liittymiä, jotka noudattavat sovittuja protokollia eri tasoilla. Järjestelmien sisäinen toteutus voi tällöin olla käytännössä mitä vain. Toimialakomponenteista koottuun järjestelmään on suhteellisen helppoa tehdä tarvittavat sovittimet tai yhdyskäytävät, jotta musta laatikko -yhteistoiminta toteutuu. Kuvassa 24 kuvataan yhteistoiminnan toteuttaminen järjestelmän yhdyskäytävän (system gateway) avulla. Tällainen ratkaisu piilottaa kohdejärjestelmän toteutuksen, mutta yhdyskäytävän on oltava mukana järjestelmän alkuperäisessä suunnittelussa ja toteutuksessa. Kuvassa 25 musta laatikko-yhteistoiminta toteutus perustuu järjestelmän sovittimen (interoperability adapter) käyttöön. Sovitin voidaan rakentaa järjestelmään järjestelmän jo ollessa käytössä. Sovitin toimii suurelta osin samoin kuin yhdyskäytävä: se kutsuu tarvittavien järjestelmän sisäisten komponenttien palveluita. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

99 JÄRJESTELMÄINTEGRAATIO 99 System Gateway Lab Test Manager Performance Monitor Lab Test Patient Department Databas e Integrity Manager Lab Test CodeBook Test Result Calculator AddressBook Kuva 24. Järjestelmän yhdyskäytävä (gateway). Interop. adapter Lab Test Manager Performance Monitor Lab Test Patient Department Database Integrity Manager Lab Test CodeBook Test Result Calculator AddressBook Kuva 25. Järjestelmän sovitin (interoperability adapter) 2. Jos molemmat järjestelmät on rakennettu toimialakomponenteista, voidaan halutessa käyttää järjestelmän sisäisen toimialakomponentin liittymiä. Tällöin on kyseessä valkea laatikko-yhteistoiminta: Tällaisessa yhteistoiminnassa on tunnettava toisen järjestelmän komponentin olemassaolo, käyttäytyminen ja identiteetti. Jos järjestelmillä on yhteisiä komponentteja, tässä mallissa ne monistetaan sekä rakentamisen että suorituksen aikana molempiin järjestelmiin. Kuvassa 26 näkyy valkea laatikko-yhteistoiminnan toteutus paljastamalla järjestelmän sisäisten toimialakomponenttien rajoitettuja komponenttiliittymiä järjestelmän ulkopuolelle. 3. Yhteisiä komponentteja käyttämällä järjestelmät jakavat komponentit, jotka löytyvät molemmista järjestelmistä. Nämä yhteiset komponentit voivat olla osa järjestelmää, joka on eri toimittajalta kuin yhteentoimivat järjestelmät. Yhteiset komponentit voivat muodostaa toiminnallisen väylän, joka luo pohjan väylään liittyvien komponenttien liittymille. Sitä varten teknisen ja sovelluksen arkkitehtuurin on oltava yhteensopiva ja myös toiminnallisen arkkitehtuurin tärkeimpien osien. Tällaiseen yhteistoimintaan pyritään mm. seuraavassa luvussa esiteltävien terveydenhuollon yleisten palvelujen standardeilla. 4. Täysi integraatio tarkoittaa, että mitään toimialakomponenttia ei kopioida järjestelmien välillä, ja järjestelmät eivät ole (ainakaan suorituksen aikana) erillisiä. Tämä taso vaatii kuuden alimman protokollakerroksen hyvän alustuksen, ja raja sovellustason komponenttien yhteistoiminnan ja toimialakomponenttien yhteistoiminnan välillä muuttuu häilyväksi. Käytännössä tällöin järjestelmät on rakennettu käyttäen samoja arkkitehtuuri- ja myös kehitysprotokollia, tai organisaatio on rakentanut kokonaisjärjestelmänsä samaan arkkitehtuuriin ja infrastruktuuriin sopivista toimialakomponenteista. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

100 100 OSA II: Taustaselvitykset C C Lab Test Manager Performance Monitor C Lab Test Patient Department Databas e Integrity Manager Lab Test CodeBook Test Result Calculator AddressBook Kuva 26. Komponenttien rajoitettujen liittymien tarjoaminen järjestelmän ulkopuolelle. Sovellusten integroinnissa komponenttitekniikalla on päätettävä järjestelmien vastuista ja siitä, mitä järjestelmä käynnistää yhteistoiminnan ja kuinka yhteistoimintaa hallitaan. Sovellustason komponentit voivat olla yhteistyössä seuraavilla tavoilla: 1. Komponenttien master-slave yhteistoiminta: yksi järjestelmä on selkeästi kommunikaation aloittaja ja ainoa aktiivinen toimija, kun toinen on palvelujen tarjoaja. Monet sähköisen kaupankäynnin järjestelmät ovat tällaisia, niissä on yksi sovellustason komponentti (slave), johon monet järjestelmät (master) kytkeytyvät. On usein tarpeen, että myös slave-järjestelmä voi käynnistää kommunikaation, mutta tämä toteutetaan yleensä tapahtumamekanismin avulla. 2. Komponenttien koordinoitu yhteistoiminta: sovellustason komponenttien välinen yhteistoiminta, jossa kommunikaatio tapahtuu koordinoivan tahon kautta. Tämä koordinoiva taho (Component Manager) voi olla itse sovellustason komponentti, toimialakomponentti tai hajautettu komponentti. Myös muilla tavoilla toteutettua koordinaatiota voidaan käyttää. Manager voi kommunikoida hallitsemiensa komponenttien kanssa viestejä lähettämällä, kun taas hallittujen komponenttien tulisi käyttää tapahtumia aloittaakseen koordinaattorille kommunikoimisen. 3. Komponenttien yhdenvertainen (peer-to-peer) -yhteistoiminta: yhteistoiminnan muoto, jossa osallistuvat sovellustason komponentit voivat vapaasti ja suoraan kutsua toistensa palveluita. Tämä tapa mahdollistaa suurimman joustavuuden, mutta on monimutkaisin ja kallein kaikissa järjestelmän elinkaaren vaiheissa. Se rikkoo kehämäisten riippuvuuksien välttämisen periaatteen, ellei yhteistoimintaa ole suunniteltu tarkoin. Tällainen yhteistoiminta on ihmismäistä ja älyllisesti houkuttelevaa. Kahden järjestelmän välinen kommunikaatio on usein ideaalitilanteessa kaksisuuntaista. Master-slave ja yhdenvertainen yhteistoiminta voidaan toteuttaa millä tahansa integrointitavoista. Komponenttien koordinoitu yhteistoiminta voidaan saavuttaa koordinoidun yhteistoiminnan lisäksi väyläyhteistoiminnalla Merkattu data ja XML XML:n (extensible Markup Language, ks. sanasto) ja merkatun datan (tagged data) käyttö järjestelmien integroinnissa on kasvattamassa suosiotaan voimakkaasti. Varsinkin Internetin www-pohjaisessa käytössä XML:n on yleistymässä, koska XML tukee useammanlaisia sovelluksia kuin kiinte- Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

101 JÄRJESTELMÄINTEGRAATIO 101 ään merkkaukseen perustuva HTML. XML tarjoaa mahdollisuuden määritellä rajoittamattoman määrän sovelluksesta riippuvia merkkauksia, joita voidaan käsitellä yhdellä jäsentäjällä tehokkaasti. Myös sekä ihmisen että koneen luettava muoto sekä sisällön erottaminen linkeistä ja ulkoisen esitysmuodon erottaminen merkkauksista ovat XML:n hyödyllisiä piirteitä. XML on erittäin vahva väline metadatan esittämiseen itse datan yhteydessä. Merkkaukset kertovat, mistä tietoelementistä kulloinkin on kyse. Vaikka XML on alun perin kehitetty dokumenttistandardiksi, sen monikäyttöisyys tekee siitä houkuttelevan valinnan myös järjestelmien integroinnissa ja komponenttitekniikoiden joustavuuden parantamisessa. XML:n dokumenttityyppimäärittelyihin on perinteisesti käytetty dokumentin tyyppimäärittelyä (Document Type Definition, DTD). Uusi vaihtoehto dokumenttien määrittelyyn on vielä standardoimaton XML Schema, joka on mm. Microsoftin.NET-arkkitehtuurin (ks. sanasto) perusta. Schema on dokumenttimäärittely, joka noudattaa itsekin XML:n mukaista dokumenttityyppiä, ja tukee mm. eri tietotyyppejä. XML:n käyttö www-dokumenteissa mahdollistaa tarkennetut haut, käyttäjän määrittelemät ulkoisen esityksen muodot sekä tietorakenteet, joita selaimessa oleva ohjelmisto voi käyttää esim. kerätyn tiedon jatkokäsittelyssä. Järjestelmien integroinnissa XML:n dokumenttimäärittelyitä voidaan käyttää siltana (ks. luku 12.2), jota sovitettavat järjestelmät ymmärtävät ja pystyvät käsittelemään, ja siirrettävät tiedot voivat olla rakenteisessa muodossa. Uutta tietojenvaihtoformaattia ei tarvitse määritellä aina uudelle osapuolelle, jonka kanssa tietoja halutaan vaihtaa. Rakenteisen esitysmuodon avulla eri tietokannoista tehdyt haut voidaan yhdistää yhdeksi dokumentiksi, jonka käyttäjä voi muotoilla itse. Rakenteisessa hakumäärittelyssä eri tietokantojen yksityiskohtaiset hakumäärittelyt voidaan piilottaa ja sallia tietyille henkilöille rajoitetut haut. Yksittäisistä järjestelmistä riippumaton esitysmuoto sallii myös eri henkilöiden ja eri paikoissa olevien tietovarastojen yhteiskäytön. Muita XML:ään liittyviä spesifikaatioita ovat mm. dokumentin esitysmuodon määrittelyyn tarkoitettu XSL (extensible Stylesheet Language), dokumenttien välisten muunnosten tekoon suunniteltu XSLT (extensible Style Language Transformation), metadatan siirtämiseen mallinnusvälineiden, sovellusten ja varastojen välillä määritelty XMI (XML Metadata Interchange) sekä komponenttien kutsumiseen merkkijonopohjaisen kommunikaation avulla käytettävä, toistaiseksi standardoimaton SOAP (Simple Object Access Protocol). Näiden spesifikaatioiden lyhyet kuvaukset ovat tämän selvityksen sanastossa. Suuri osa siirrettävästä toimialan tiedosta on yleensä tietorakennemuotoista. Vaikka muunkin laista tietoa siirretään, muodostuu yleensä valtaosa tiedoista alfanumeerisesta datasta, joka sisältää informaatiota, kuten lukumääriä, kuvauksia, päivämääriä jne. Tällaisen tiedon käsittelyssä korostuvat joustavuusseikat, ja merkattu data voi parantaa komponenttiliittymien joustavuutta seuraavilla tavoilla: Liittymiä voidaan kehittää ilman että pakotetaan kaikki liittymien käyttäjät kehittymään samalla aikaa. On mahdollisuus kuljettaa tietorakenteita useilla vastaanottajilla siten, että kukin vastaanottaja tietää, kuinka käsitellä jotain osaa tiedosta, mutta välttämättä millään vastaanottajalla ei ole etukäteen tietämystä koko rakenteesta. Useimmissa liittymäteknologioissa operaation nimi on käännetty osaksi tiettyyn paikkaan palvelun toteuttavaa koodia, ja kunkin parametrin paikka ja tyyppi on oltava jo kutsujalla oikein. Kun tietorakenne lähetetään, liittymäteknologia tarkistaa yleensä vain tiedon tyypin. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

102 102 OSA II: Taustaselvitykset Esim. komponenttiliittymän operaatio voisi olla muotoa: paivita_kumppanin_osoite (in string kumppani_id, in Osoite kumppanin_osoite); Liittymään lähetettävä kumppanin osoite-tietorakenne on seuraava: Katuosoite: string Neulaniementie 1 Postinumero: integer Postitoimipaikka: string Kuopio Liittymä osaa tarkistaa vain, että ensimmäinen ja kolmas tietoalkio ovat merkkijonoja, ja keskimmäinen kokonaisluku. Mikäli jostain syytä katuosoite ja postitoimipaikka vaihtavat paikkaa kutsussa, kutsu on liittymän mukainen, mutta semanttisesti väärä. Toinen ongelma on versiointi: mikäli osoite-rakenne muuttuu siten että se sisältäisi myös maan, ei vanhanlainen kutsu enää tuottaisi oikeaa tulosta. Näin uuden liittymän määrittely pitäisi lähettää kaikille liittymän käyttäjille. Tähän ongelmaan voidaan varautua esimerkiksi käyttämällä liittymien versiointia, mutta se voi johtaa ylläpitotyön lisääntymiseen, eikä versiointi ole kaikissa nykyisissä komponenttimalleissa toteutettavissa. Merkattu data tarjoaa ratkaisun lähettämällä datan mukana metadataa, eli tietoa tiedosta itsestään. XML on de-facto standardi merkatun datan esittämiseen. Yksi tapa XML:n käyttämiseen on merkata liittymässä käytetty data hyvin yksinkertaiseksi dokumentiksi. Tällöin esim. Osoite voisi olla seuraavan muotoinen: <Osoite> <Katuosoite>Neulaniementie 1</Katuosoite> <Postitoimipaikka>Kuopio</Postitoimipaikka> <Postinumero type= integer >70210</Postinumero> </Osoite> Tällöin komponenttiliittymän operaatio voisi olla muotoa: paivita_kumppanin_osoite (in string kumppani_id, in string kumppanin_osoite_xml); Tiedon käsittelyssä kohdekomponentti jäsentäisi XML-parametrin, ja saisi siitä nimen perusteella oikeat parametrit. Tämä mahdollistaa esim. parametrien järjestyksen riippumattomuuden, sen että vanhaan liittymään välittyisi vain tarvittavat tietoalkiot vaikka kutsussa olisi muitakin, ja jos kohdejärjestelmän postinumeron tyyppi muuttuisikin merkkijonoksi, voisi kutsuva järjestelmä edelleen käyttää omaa kokonaislukumuotoista postinumeroaan, koska kohde vain muuntaisi sen merkkijonoksi. Toisaalta kutsuva komponentti voisi sisällyttää itseensä (ja kutsuun) myös Maa-tiedon, vaikka kohdekomponentti ei sitä odotakaan. Tällöin kutsuttava komponentti yksinkertaisesti jättää vieraan tiedon jäsentämättä. Siitä huolimatta kohdekomponentti voi välittää saamansa kutsun sellaisenaan edelleen toiselle kohdekomponentille, joka saattaakin olla kiinnostunut myös Maa-tiedosta. Merkattu data ja merkatut liittymät eivät poista tietotyyppien yhteensopivuustarkistuksia eikä tarpeita versioida liittymiä, mutta ne voivat vähentää niitä. Osallistujien on tietenkin hyväksyttävä käytettävät merkkaukset ja tiedon yleinen rakenne. Merkkaukset tarkastetaan suorituksen, ei käännöksen aikana (kuten tyypitetyssä liittymässä). Kutsujan ja kohteen roolit myös kääntyvät toisinpäin: sen sijaan että kutsujan on aina mukauduttava käytettävään liittymään, kohde mukautuu Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

103 JÄRJESTELMÄINTEGRAATIO 103 kutsujan lähettämään dataan. Lisäksi kohde voi mukautua puuttuviin merkkauksiin tai tietoalkioihin, mikäli se itse sisältää esim. oletusarvoja. Sovellustason komponenttien tai ulkoisten järjestelmien kanssa tapahtuvassa kommunikaatiossa merkattu data voi huomattavasti parantaa liittymien joustavuutta. Merkatun datan muita käyttökohteita komponenttitekniikassa ovat esim. työtilakerroksen komponenttien yleisten liittymien teko käyttöliittymiä varten, luettavassa muodossa olevan ajonaikaisen datan säilytys, siirtyminen käännöksen aikaisesta liittymien tarkistuksesta suorituksen aikaiseen, komponentin skriptaus (koko komponentille yleinen execute -liittymä), viestijonojärjestelmä, jossa viestin teknistä muotoa ei ole ennalta määritelty jne. Merkatun datan ongelmana on mm. se, että ohjelmoijan on jäsennettävä ja rakennettava merkattuja tietorakenteita, ellei hajautetun komponentin eristyskerros hoida sitä automaattisesti. Kaksinkertaisten (sekä tyypitetyn että merkatun) liittymien tekeminen voi heikentää järjestelmän suorituskykyä. Lisäksi XML-viestit käyttävät huomattavasti enemmän kaistanleveyttä tiedonvälityksessä puheliaisuutensa ja pitkien merkkausten takia. Merkkausten sopimiseen järjestelmien välillä on yleensä käytettävä jonkinlaista varastotekniikkaa, ja merkkausten lisäksi semantiikasta on sovittava. Merkattu data ei myöskään poista yhteen sopimattomien eri järjestelmien tietotyyppien (36 vai 10-merkkinen tunniste?) ongelmia. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

104 104 OSA II: Taustaselvitykset 13 TERVEYDENHUOLLON YLEISTEN PALVELUJEN STANDARDIT Yleiset, eri sovelluksissa käytettävät palvelut kuuluvat komponenttiarkkitehtuurissa yleensä komponenttien suoritusympäristön infrastruktuuriin. Toimialan sovellusten yleiset ja yhteiset tarpeet ovat johtaneet kuitenkin myös vertikaalisten, tietyn toimialan sovellusten yhteisiä toimintoja toteuttavien palvelujen tunnistamiseen ja standardointiin. Terveydenhuollon toimialalla perinteisesti käytetyn sanomapohjaisen integraation standardoinnin lisäksi yleisiä oliopalveluita on standardoitu. Tässä luvussa esitellään OMG:n CORBAmed-työryhmän sekä CEN:n Medical Informatics-työryhmän tuottamat yleisten palvelujen standardit. Tässä luvussa esiteltävät yleiset palvelut noudattavat samanlaista palveluarkkitehtuuria kuin NAC:n palveluarkkitehtuuri (ks. luku 5.4). Integrointitasona (ks. luku 12.1) on toiminnallisten liittymien taso, ja integrointitapana (ks. luku 12.2) integroitu yhteistoiminta, koska palvelua käyttävillä järjestelmillä on standardissa määritelty yhteistoimintaprotokolla. Mikäli palvelut on toteutettu hajautettujen komponenttien avulla, on integrointitapana teknisten liittymien tasolla väyläyhteistoiminta (ks. luku 12.2). Sovelluskehysten luokittelun mukaan (ks. luku 7.2) kyseessä ovat alakohtaiset sovelluskehykset CORBAmed CORBAmed on OMG:n terveydenhuollon komponenttiliittymiä kehittävä ryhmä (Domain Task Force, DTF) (CORBAmed 2000). CORBAmed on julkaissut ja kehittää uusia terveydenhuollon yleiskäyttöisten komponenttipalvelujen spesifikaatioita. Pääpaino on yleiskäyttöisten toiminnallisten palvelujen kehittämisessä siten, että järjestelmien tietosisältöön ei oteta jyrkkää kantaa, vaan HL7 ja vastaavat sisältöön painottuvat standardit kattavat sisällöllisen alueen. Tavoitteena on vähentää esim. eri osastojen omissa järjestelmissä duplikoitunutta toiminnallisuutta (toimenpiteitä, henkilöresursseja ja ohjelmistoja) yleisiä palveluja käyttämällä. OMG:n OMA-arkkitehtuurissa (ks. luku 4.2) CORBAmed:in määrittelemät palvelut kuuluvat vertikaalisiin yleisiin toimintoihin (CORBA facilities). Seuraavassa taulukossa esitellään CORBAmedin julkaisemat tai kehitettävänä olevat spesifikaatiot ilmestymisjärjestyksessä (tilanne elokuussa 2000). Vaihe-sarakkeessa Adopted tarkoittaa hyväksyttyä, virallista spesifikaatiota, RFP (Request for proposal) tarkoittaa spesifikaatiota, joka on työstettävänä CORBAmedin työryhmässä ja josta on työversioita saatavilla. Näiden spesifikaatioiden lisäksi CORBAmed on julkaissut useita RFI (Request for Information) dokumentteja, mm. CORBA / M interoperability dokumentin, johon ei tosin ole tullut vastauksia. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

105 TERVEYDENHUOLLON YLEISTEN PALVELUJEN STANDARDIT 105 Taulukko 10. CORBAmedin palveluspesifikaatiot (CORBAmed 2000; VA 2000) Spesifikaatio Vaihe Lyhyt kuvaus Ydinpalvelut Erityistä PIDS (Person Identification Service) TQS (Terminology Query Service) RAD (Resource Access Decision) COAS (Clinical Observation Access Service) CIAS (Clinical Image Access Service) Adopted, kaupallisia tuotteita Adopted, kaupallisia tuotteita Adopted, kaupallisia tuotteita Adopted, kaupallisia tuotteita Adopted Palvelu henkilön tunnistamiseen yksikäsitteisesti tietyssä ympäristössä Palvelu terminologisen tiedon saantiin käytettäväksi välitystä, tietojen esittämistä tai dynaamista löytämistä varten Palvelu lääketieteellisen tiedon saantioikeuksien selvittämistä ja saantisäännöstöjen hallintaa varten. Palvelu henkilöön liittyvän kliinisen tiedon hakemiseen. Palvelu kuvien hakuun ja hallintaan. 1. Nimialueet, henkilölle annettava yksikäsitteinen tunniste nimialueen sisällä, nimialueiden välinen tunnisteiden korrelointi 2. Henkilöiden hakemista tukevat palvelut sekä interaktiivista että viestipohjaista toimintatapaa käyttäen, riippumatta hakualgoritmista 3. Eri PIDS-toteutusten yhteentoimivuus ydin profiilielementtien määrittelyiden avulla. Kontrolloidut termistöresurssit hajautetussa olioympäristössä. Yksittäisestä sovelluksesta erotettu oikeuksien tarkistus, turvallisuusperiaatteiden määrittely. Kliinisten havaintojen, mittausten ja tulosten oliomalli, hierarkiat jne. COAS:ista yksityiskohtaistettu hakupalvelu kuvia varten Peruspalvelu CORBAmedin spesifikaatioiden joukossa, johon useat muut spesifikaatiot perustuvat Yhteistoiminta PIDS:n kanssa edellyttää RAD:ssa esitettyjä muutoksia PIDS:iin. Voidaan toteuttaa joko perustuen CORBAsecurityyn tai ilman sitä COAS:n spesialisaatio Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto

106 106 OSA II: Taustaselvitykset Spesifikaatio Vaihe Lyhyt kuvaus Ydinpalvelut Erityistä HILS (Health Information Locator Service) SLiMS (Summary List Management Service) MTM (Medical Transcription Document Management) HDIF (Healthcare Data Interpretation Facility) OMS (Order Management Service) RFP RFP RFP RFP RFP suunnitteilla Lääketieteellisen tiedon paikallistamiseen käytettävä palvelu. Palvelu yhteenvetolistojen hallintaan Palvelu kliinisen tiedon siirtoon ja jäljentämiseen Kliinisen päätöksenteon tuen komponentti Palvelu tilausten hallintaan Tiedon sijainnin hajautetussa ympäristössä selvittäviä palveluita Nykyisellään USA:n lakien mukaisen sairaalan potilaan yhteenvetolistan tuottamiseen. Mekanismit lääketieteellisten dokumenttien ja niihin liittyvän metadatan käsittelyyn 1. yleiset liittymät kliinisen datan muunnoksiin 2. älykkäiden järjestelmien integrointi terveydenhuollon sovelluksiin Täydentää mm. PIDS:iä Käyttää hyväksi COAS:ia Käyttää hyväksi COAS:ia 13.2 HISA (Healthcare Information Systems Architecture) CEN:n 15 komitea TC251 (Medical Informatics) on määritellyt HISA (Healthcare Information Systems Architecture) arkkitehtuurin (CEN 1997), jonka tarkoituksena on tarjota standardoitu yleiskehys potilaan hoitoa ja organisaation johtamista tukevien tietojärjestelmien toteuttamiselle. Standardissa määritellään joukko terveydenhuollon järjestelmille yhteisiä tietoja ja palveluita yhteentoimivuuden pohjaksi. Yleisten palvelujen kerros (Common Services Layer) on määritelty sovellusten ja tiedonsiirtomekanismien väliin siten, että yleiset palvelut ovat riippumattomia tiedonsiirtoteknologiasta tai mistään yksittäisestä sovelluksesta. Yleiset palvelut siis noudattavat samoja periaatteita kuin NAC:n Common Services Infrastructure ja CORBAmed:in palvelumääritykset. 15 CEN (Comité Europeén de Normalisation) on eurooppalainen standardointijärjestö, jonka tekniset komiteat tuottavat standardeja sekä esistandardeja. TC251-komitean eri työryhmät tuottavat terveydenhuollon tietotekniikkaan liittyviä (esi-)standardeja, joukossa tässä esitellyn HISA-arkkitehtuurin (Working Group 1) lisäksi mm. sairauskertomus, koodistot, viestit ja kommunikaatio, lääketieteelliset kuvat ja multimedia, laitteiden välinen kommunikaatio ja turvallisuus ja yksityisyys. Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäristötieteet 7

107 TERVEYDENHUOLLON YLEISTEN PALVELUJEN STANDARDIT 107 Kuva 27. HISA-arkkitehtuuri (CEN 1997) Kukin yleisen palvelun määrittely sisältää käsitemallin (kuvattu ER-kaaviona) palveluun osallistuvien entiteettien suhteista sekä kunkin entiteetin tarvittavat ominaisuudet. Kukin palvelumäärittely on varsin lyhyt eikä sido esim. toteutuksissa käytettäviä koodistoja tai tietotyyppejä. Kaikille yleisille palveluille yhteisiä toimintoja ovat:! Hakukriteeriin sopivien entiteettien listan hakeminen; hakukriteerit voivat olla riippuvia entiteetin ominaisuuksista tai suhteista muihin entiteetteihin! Entiteetin yhden esiintymän ylläpito, joka sisältää:! Kaikkien esiintymään liittyvien tietojen haun! Uuden esiintymän lisäämisen! Olemassa olevan esiintymän ominaisuuksien muuttamisen! Yhden esiintymän poiston! Kussakin suhteessa esiintymään liittyvien muiden entiteettien listan hakeminen! Kunkin yksittäisen olemassa olevan suhteen ylläpito Taulukossa 11 esitellään lyhyesti HISA:ssa määritellyt kuusi terveydenhuollon yleispalvelua. Juha Mykkänen: Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto