Kuntasektorin SOA-teknologialinjaukset

Kuntasektorin SOA-teknologialinjaukset 16.12.2008 versio 1.0 Laatinut: Tampereen kaupungin kokonaisarkkitehtuurin projektiryhmä

2 (56) 1 JOHDANTO... 5 2 PALVELUKESKEISEN ARKKITEHTUURIN YLEISKUVAUS... 6 2.1 JOHDANTO... 6 2.2 PALVELUKESKEISEN ARKKITEHTUURIN MÄÄRITELMÄ... 6 3 VAATIMUKSET SOA-PALVELUILLE... 7 3.1 PALVELUIDEN PITÄÄ OLLA KARKEUSTASOLTAAN ERILAISIA JA TOISISTAAN KOOSTETTAVISSA... 7 3.2 PALVELULLA PITÄÄ OLLA HYVIN MÄÄRITELLYT JA STANDARDEIHIN NOJAUTUVAT RAJAPINNAT... 8 3.3 PALVELUIDEN TULEE OLLA LÖYHÄSTI KYTKETTYJÄ... 8 3.4 PALVELUIDEN TULEE OLLA HELPOSTI HAETTAVISSA... 8 3.5 PALVELUIDEN TULEE OLLA LIIKETOIMINTALÄHTÖISIÄ... 9 3.6 PALVELUIDEN TULEE OLLA UUDELLEENKÄYTETTÄVIÄ... 9 3.7 PALVELUIDEN TULEE OLLA YHTEENTOIMIVIA ERI JÄRJESTELMIEN JA YMPÄRISTÖJEN VÄLILLÄ... 10 4 TEKNOLOGIAT JA PALVELINOHJELMISTOT... 11 4.1 SOA-TEKNOLOGIAT JA OHJELMISTOTUOTTEET... 11 4.2 WEB-SOVELLUSPALVELUT... 14 4.2.1 Web-sovelluspalveluiden yleiskuvaus... 14 4.2.2 WS-I web-sovelluspalvelut... 16 4.3 PALVELUHAKEMISTOT JA NIIDEN SUHDE KOKONAISARKKITEHTUURIMALLINNUKSEEN... 18 4.4 LIIKETOIMINTAPROSESSIEN HALLINTA JA PROSESSIMOOTTORIT... 19 4.4.1 Yleistä prosessien hallinnasta ja prosessimoottoreista... 19 4.4.2 BPEL-prosessien hallintaohjelmistot... 20 4.4.3 Prosessimoottorin tuomat hyödyt prosessitoteutuksiin... 23 4.5 LIIKETOIMINTASÄÄNTÖJEN HALLINTA JA SÄÄNTÖMOOTTORIT... 25 4.6 PALVELUVÄYLÄT, ESB... 26

3 (56) 4.7 MASTER DATA JA SEN HALLINTA (MDM)... 27 4.8 KÄYTTÖLIITTYMÄT JA PORTAALIT... 28 4.8.1 SOA:n suhde käyttöliittymiin... 28 4.8.2 Portaalikäyttöliittymät... 29 4.8.3 Portaalikäyttöliittymien käyttökohteet kunnissa... 29 4.8.4 Portaalipalvelimet... 29 4.9 MDA... 31 5 SUOSITUKSET SOA-TEKNOLOGIOIDEN HYÖDYNTÄMISESTÄ... 34 5.1 YLEISIÄ TEKNOLOGIOIDEN KÄYTTÖSUOSITUKSIA... 34 5.2 OHJEISTUS WEB-SOVELLUSPALVELUIDEN TOTEUTUKSEEN... 35 5.3 VAIHTOEHTOISET TEKNOLOGIAT JA STANDARDIT... 36 5.4 HYVIÄ KÄYTÄNTÖJÄ JA ARKKITEHTUURIMALLEJA SOA:N HYÖDYNTÄMISESSÄ... 37 5.5 INTEGROINTI SOA-YMPÄRISTÖSSÄ... 38 5.6 TIETOSUOJA JA TIETOTURVA SOA-YMPÄRISTÖSSÄ... 39 6 STANDARDIT... 42 6.1 LIIKETOIMINTAPROSESSIT... 42 6.1.1 BPMN... 42 6.1.2 BPEL... 43 6.2 WS-I BASIC PROFILE STANDARDIT... 44 6.2.1 SOAP... 44 6.2.2 XML Schema... 45 6.2.3 WSDL... 47 6.3 WEB-SOVELLUSPALVELUHAKEMISTOT... 47 6.3.1 UDDI... 48 6.3.2 WSIL... 48 6.4 OBJECT MANAGEMENT GROUP (OMG) STANDARDIT... 48

4 (56) 6.4.1 UML... 48 6.4.2 MOF... 49 6.4.3 OCL... 50 6.4.4 QVT... 51 6.4.5 XMI... 51 6.5 PORTAALIPALVELIMET... 51 6.5.1 WSRP... 51 6.5.2 JSR-168... 52 6.5.3 WS-* standardit ja määrittelyt... 52 7 KIRJALLISUUSVIITTEET... 54 8 MUUTOSHISTORIA... 55

5 (56) 1 Johdanto KuntaIT on asettanut palvelukeskeisen arkkitehtuurin (SOA) edistämisen yhdeksi tärkeimmäksi tulevaisuuden tavoitteeksi. Tämä dokumentti vastaa mitä palvelukeskeinen arkkitehtuuri tarkoittaa teknologisessa mielessä KuntaIT:lle. Dokumentin päätehtävä on esitellä palvelukeskeiseen arkkitehtuuriin pohjautuvat standardit ja koestetut teknologiat, joiden käyttämistä kuntasektorin IT-hankkeissa suositellaan. Dokumentti sisältää lisäksi käyttöohjeita ja suosituksia näiden teknologioiden hyödyntämisestä palvelukeskeisessä ympäristössä. Tämä dokumentti on osa KuntaIT:n SOA-suosituksia. Tämän dokumentin pohjatietona toimii KuntaIT:n dokumentti SOA:n hyödyntäminen kuntasektorilla [12]. Tämän dokumentin kohderyhminä ovat: Tietojärjestelmähankinnoista ja -kilpailuttamisesta vastaavat tahot Prosessien ja ohjelmistojen toteuttamisesta vastaavat tahot, mm. projektipäälliköt Kokonaisarkkitehtuurin kehittäjät Teknologia-arkkitehtuurin kehittäjät Tietojärjestelmien toimittajat Ohjelmistoarkkitehdit ja kehittäjät Asioita käsitellään dokumentissa syy-seuraus järjestyksessä. Dokumentin alussa määritetään palvelukeskeisen arkkitehtuurin käsite. Tämän jälkeen määritellään vaatimukset palvelukeskeisen ympäristön palveluille, joiden perusteella myöhemmin esiteltävät teknologiat ja standardit on valittu. Tämä vaatimuksista teknologioihin suhde on yksisuuntainen. Valittujen teknologioiden ja standardien käyttäminen ei takaa palveluille asetettujen vaatimusten täyttymistä. Tämän vuoksi teknologialinjauksia tulee aina käsitellä kokonaisuutena, jossa painopiste on teknologiavalintojen perusteissa ja palvelukeskeisen arkkitehtuurin kehittämisessä. Arkkitehtuurin kehittäminen saa puolestaan syötteensä liiketoiminnalta. Lähtökohtana on, että liiketoiminta ohjaa arkkitehtuuria ja arkkitehtuuri teknologioita (ks. kuva 1.1). Liiketoiminta Arkkitehtuuri Teknologiat Kuva 1.1 Liiketoiminnan ohjaava vaikutus

6 (56) 2 Palvelukeskeisen arkkitehtuurin yleiskuvaus 2.1 Johdanto Tässä luvussa kuvataan suppeasti palvelukeskeisen arkkitehtuurin käsite. Määritys perustuu SOA:n hyödyntäminen kuntasektorilla [12] dokumenttiin, joka käsittelee asiaa laajemmin. 2.2 Palvelukeskeisen arkkitehtuurin määritelmä KuntaIT käyttää seuraavaa määritelmää palvelukeskeisestä arkkitehtuurista: Palvelukeskeinen arkkitehtuuri (SOA) on joukko suunnitteluperiaatteita, käytäntöjä, menetelmiä, kehyksiä ja tekniikoita, jotka mahdollistavat sovellustoiminnallisuuksien tarjoamisen ja pyytämisen joukkona jaettuja liiketoimintalähtöisiä sovelluspalveluita. SOA muodostaa ajattelutavan asioiden suunnittelemiseksi ja hahmottamiseksi palveluiden kautta. SOA-ympäristössä ohjelmistojen toiminnallisuus ja sovelluslogiikka toteutetaan jaettujen uudelleenkäytettävien palveluiden avulla. Palvelut toimivat toiminnallisuuden ja sovelluslogiikan rakennusosina. Palvelut sisältävät palvelurajapinnan ja niitä kutsutaan tietoverkossa välitettävien viestien välityksellä. SOA nojautuu avoimiin standardeihin ja hajautettujen löyhästi toisiinsa kytkettyjen palveluiden uudelleenkäytölle. SOA lisää liiketoimintalähtöisyyttä, uudelleenkäytettävyyttä, paikka-, alusta- ja toimittajariippumattomuutta sekä tietojärjestelmien yhteentoimivuutta. Palvelukeskeinen arkkitehtuuri nähdään yleensä keskeisenä tekijänä liiketoimintaprosessien kehittämisessä. SOA-palveluiden suhde liiketoimintaprosesseihin on kaksisuuntainen. SOA auttaa prosessien kehittämisessä mahdollistaen joustavat prosessitoteutukset ja prosessien mittaamisen (ks. prosessimoottorin hyödyntäminen prosessien mittaamisessa, alakohta 4.4.2). Prosessit toimivat puolestaan pohjana SOA-palveluiden määrittelyssä. KuntaIT ei SOA-palveluvaatimuksissa edellytä palveluiden etsimistä prosessimäärityksistä, vaan näkee tämän yhtenä keskeisenä toimintatapana SOA-palveluiden liiketoimintalähtöisyyden toteuttamisessa (ks. alakohta 3.5). Merkittävimpinä vaatimuksina liiketoimintalähtöisyyden lisäksi ovat palveluiden koostettavuus, uudelleenkäytettävyys ja toteutustavan näkymättömyys palvelun käyttäjille (ns. musta laatikko). SOA vaikuttaa kaikkiin kokonaisarkkitehtuurin näkökulmiin eikä sitä voida ottaa käyttöön pelkästään yhden näkökulman osalta. Tämä asia jää usein huomiotta esim. SOAteknologiaa toimittavien yritysten viestinnästä. Esim. prosessimoottorit ja palveluväylät kuuluvat usein tärkeänä osana SOA-perustaiseen teknologia-arkkitehtuuriin. Näiden ohjelmistojen hyöty on kuitenkin vähäinen, jollei esim. toiminta-arkkitehtuuri tue palvelukeskeistä ajattelua. SOA ei myöskään määrää yksittäisiä teknologioita tai käytettäviä standardeja, mutta sen asettamat vaatimukset aiheuttavat näihin runsaasti rajauksia. Merkittävimmät rajaukset liittyvät yleensä seuraavassa luvussa käsiteltäviin palveluvaatimuksiin.

7 (56) 3 Vaatimukset SOA-palveluille Palvelut toimivat SOA:n keskiössä ja ovat näin järjestelmien toiminnan edellytys. Palvelukeskeisen arkkitehtuurin käyttö ei kuitenkaan määrää käytettäviä standardeja teknologioita. Tämän sijaan SOA asettaa palveluille vaatimuksia, jotka määräävät mitä teknologioita ja standardeja voidaan SOA-ympäristössä käyttää. Seuraavissa alakohdissa on lueteltu vaatimukset SOA-palveluille. Nämä vaatimukset ovat hyvin keskeisiä myöhempien lukujen kannalta. Näitä vaatimuksia voidaan pitää palvelutoteutusten kulmakivinä, joihin myöhempien lukujen teknologiavalinnat ja johtopäätökset nojautuvat. 3.1 Palveluiden pitää olla karkeustasoltaan erilaisia ja toisistaan koostettavissa Palveluiden pitää olla karkeustasoltaan erilaisia eli palveluiden tulee koostua pienemmistä palveluista (ks. kuva 4.4 palvelukerrokset). Tällä mahdollistetaan, että palvelut toteuttavat vaadittavan toiminnallisuuden ja ovat uudelleenkäytettäviä. Ylätason karkeat SOA-palvelut ovat harvoin uudelleenkäytettäviä, koska ne on kehitetty yksittäisten prosessien tai käyttötapausten pohjalta. Yksittäisten käyttö- tai integraatiotarpeiden pohjalta toteutetut ylätason palvelut ovat ongelmallisia myös suorituskyvyn osalta. Palveluiden ei suorituskyvyllisesti pitäisi palauttaa suurta määrää kutsujan kannalta tarpeetonta tietoa, mihin karkean tason palvelujen uudelleenkäyttö helposti johtaa. Myös pelkästään hienojakoisten alatason palveluiden käyttö johtaa huonoon lopputulokseen. Suorituskyvyllisesti ja mahdollisen uudelleenkäytön kannalta ei ole hyvä, että palvelua käyttävä sovellus tekee runsaasti etäpyyntöjä hienorakenteisille palveluille. Lisäksi pelkästään hienojakoisten palveluiden käyttö ei aina takaa sovelluksilta vaadittavaa toiminnallisuutta esim. transaktioiden käsittelyn osalta. Tämän vuoksi palveluiden pitää olla karkeustasoiltaan erilaisia. Tämä vaatimus aiheuttaa monesti haasteita vanhoihin sovelluksiin tehtävien integrointikerroksien kanssa. Integrointipalvelut ovat monesti liian karkeita uudelleenkäytettäväksi, vaikka niitä teknisesti olisikin mahdollista käyttää uudelleen eri tietojärjestelmistä. Vanhoissa järjestelmissä ja niistä johdetuissa palveluissa prosessilogiikka on monesti sisäänrakennettu palveluun. Tämä estää uudelleenkäytön lisäksi esim. prosessimoottorin hyödyntämisen prosessilogiikan hallinnassa. SOA-palveluita tarjoavan integrointikerroksen lisääminen ei siis tee sovelluksesta SOA-ideologian mukaista, jollei integrointikerros itsessään ole toteutettu palvelupohjaisesti. Vaatimus palveluiden koostamisesta mahdollistaa myös helpon tavan uuden toiminnallisuuden lisäämiselle ja muuttamiselle vanhoja palveluita rikkomatta. Prosessimoottoreita hyödyntävät BPEL-prosessit ovat hyvä esimerkki karkeista koostepalvelusta, joiden käyttäminen edellyttää hienompien palveluiden olemassaoloa. Näitä koostepalveluita voidaan edelleen käyttää rakennusosina isommissa koostepalveluissa, esim. toisissa BPELprosesseissa. Palveluiden koostettavuusvaatimus seuraa myös standardointijärjestö W3C:n määrityksiä. W3C edellyttää, että web-sovelluspalveluiden (web service) pitää olla koostettavissa muista web-sovelluspalveluista. Tarkemmin web-sovelluspalveluita on käsitelty kohdassa 4.2.

8 (56) Koostettavuudelle on olemassa myös muita tulkintoja. Koostettavuudella voidaan viitata myös esim. palvelurajapintojen suunnittelutapaan, jossa uusia ominaisuuksia voidaan lisätä pienissä erissä olemassa olevaan palveluun muuttamatta nykyistä toiminnallisuutta. Tällöin esim. palvelurajapinnan viestirakenteisiin lisätään uusia osioita uutta toiminnallisuutta varten, samaan aikaan kuitenkin sallien vanhojen laajentamattomien viestirakenteiden ja toiminnallisuuksien käyttämisen samoissa palveluissa. Tämän kaltainen koostettavuus on tärkeä huomioida palveluita suunniteltaessa. Tässä dokumentissa termillä viitataan kuitenkin ensin annettuun määritykseen. 3.2 Palvelulla pitää olla hyvin määritellyt ja standardeihin nojautuvat rajapinnat Palvelurajapinnat kuvaavat palvelun toiminnallisuuden piilottaen kuitenkin toteutukseen liittyvät yksityiskohdat. Tämä abstrakti palvelurajapinta pitää kuvata standardilla ja alustariippumattomalla tavalla, esim. WSDL-standardia (Web Services Description Language) käyttäen. Tämä mahdollistaa avoimuuden ja uudelleenkäytön edistämisen sekä mm. palvelumallien ja tietojen automaattisen viennin kokonaisarkkitehtuuri- ja prosessimallinnusta tukeviin työkaluihin. 3.3 Palveluiden tulee olla löyhästi kytkettyjä Palveluiden tulee olla irrallaan toteutuksesta ja toteutusta pitää pystyä vaihtamaan ilman että palveluiden käyttäjät sitä huomaavat. Tämä mahdollistaa palveluiden joustavan hallinnan, kehityksen ja ylläpidon sekä tekee mahdolliseksi esim. liiketoimintaihmisille muuttaa ohjelmiston toiminnallisuutta (esim. liiketoimintasääntöjä) varsinaista ohjelmistoa muuttamatta ja sen toimintaa keskeyttämättä. Palveluiden tulisi mielellään olla myös asynkronisia ja dokumenttipohjaisia. Esim. WS-I web-sovelluspalveluita käytettäessä mieluummin document- kuin rpc-tyyppisiä. Vaikka synkroninen palvelu ei aina olekaan kytketympi kuin asynkroninen, ovat asynkroniset palvelut luonteeltaan löyhemmin kytkettyjä ja yleensä helpommin esim. palveluväylässä muunnettavia ja ohjattavia. Edelliset vaatimukset edellyttävät, että palvelut pitää voida yhdistää toisiinsa dynaamisesti eli suoriin skripti- tai metodikutsuihin perustuvat palvelurajapinnat eivät ole sallittuja. 3.4 Palveluiden tulee olla helposti haettavissa Palveluiden pitäisi olla potentiaalisten käyttäjien nähtävillä ja haettavissa. Web-service standardit antavat tähän hyvän mahdollisuuden. Yleisimmin käytettyjä tapoja ovat keskitettyyn palveluhakemistoon perustuva UDDI (Universal Description Discovery and Integration) ja dokumentteihin perustuva WSIL. Palveluiden helppo haettavuus edistää uudelleenkäyttöä, ympäristön hallintaa ja innovatiivisuutta mahdollistaen palveluiden käytön ja yhdistelyn etukäteen suunnittelemattomalla tavalla. Uusia innovaatioita voi syntyä esimerkiksi eri organisaatioiden välisiä palveluita tarkastellessa tukemaan organisaatioiden välistä yhteistoimintaa ja mahdollisesti tuomaan uusia lisäarvopalveluita yhteisille asiakkaille.

9 (56) 3.5 Palveluiden tulee olla liiketoimintalähtöisiä Palveluiden pitää perustua liiketoimintatavoitteille, ei teknisille yksityiskohdille. Liiketoimintatavoitteet tulisi puolestaan johtaa kunnan strategiasta ja tulevaisuuden visioista, jotka toteuttavat kunnan toiminta-ajatusta ja vaikuttavuustavoitteita. Tämä on palvelukeskeisen arkkitehtuurin ydintavoitteita, jotka toteutuessaan antavat merkittäviä toiminnallisia ja taloudellisia hyötyjä. Käytännössä tämä vaatimus määrittelee etenemisjärjestyksen palveluiden tunnistamiselle ja prosessimallinnukselle. Palveluiden ja prosessien mallinnus on hyvä aloittaa tavoitetilasta ja toiminta-arkkitehtuurista, ei nykytilasta tai teknologiaarkkitehtuurista. Tämä vaatimus on SOA-siirtymän kannalta monesti tärkein ja haasteellisin. Sen toteutumisesta riippuu pääosin kuinka hyvin SOA:n hyödyt ja arkkitehtuurille asetetut tavoitteet toteutuvat. Vaatimuksen sivuvaikutukset tulevat usein myös aliarvioiduiksi. Se edellyttää monesti merkittäviä muutoksia organisaatioiden toimintatapoihin ja vastuujakoihin. Prosessimallinnusta pidetään yleensä keskeisimpänä tekijänä tämän tavoitteen saavuttamisessa. Palvelut olisi hyvä etsiä liiketoimintaprosessien kautta, jolloin palveluiden suhteet liiketoimintaan ovat jäljitettävissä. On kuitenkin tärkeää huomata, ettei pelkkä jäljitettävyys riitä tämän vaatimuksen toteutumiseen, vaan koko palvelusuunnittelun tulee lähteä liiketoiminnasta. Ohjelmistoarkkitehdit pystyvät monesti jäljittämään yksittäisen SOA-palvelun liiketoimintaprosessiin ja voivat tietää tarkasti miten palvelua hyödynnetään liiketoiminnassa. On kuitenkin mahdollista, ettei palvelu ole liiketoimintalähtöinen ja se olisi merkittävästi erilainen, jos se olisi kehitetty liiketoiminnan ehdoilla, esimerkiksi prosessimallinnuksen johdannaisena. Tämä vaatimus toimii keskeisenä yhdistävänä tekijänä SOA:n ja prosessimallinnuksen välillä. 3.6 Palveluiden tulee olla uudelleenkäytettäviä Palveluiden tulee olla uudelleenkäytettäviä. SOA:ssa palvelutoteutusten uudelleenkäyttö tarkoittaa samalla tietopääomien uudelleenkäyttöä. Uudelleenkäytettävyys tuo kustannussäästöjen ohella lukuisia hyötyjä niin ylläpidolle kuin sovelluskehitykselle. Palveluiden uudelleenkäyttö lisää myös ohjelmistojen vakautta lisäämällä tuotannossa jo entuudestaan käytettyjen ja testattujen ohjelmaosien käyttöä. Havaittuja virheitä ei tarvitse myöskään korjata kuin yhteen jaettuun palveluun. SOA-ympäristössä korjaus on mahdollista tehdä dynaamisesti puuttumatta palvelua käyttäviin sovelluksiin. Tämä eroaa merkittävästi esim. jaettujen uudelleenkäytettävien ohjelmakirjastojen käytöstä, jossa virheen korjaus edellyttää jokaisen jaettua kirjastoa käyttävän sovelluksen uudelleenrakentamista ja asentamista. On tärkeää huomata, että tämä vaatimus vaikuttaa myös palveluiden tunnistamiseen ja prosessimallinnukseen. Palveluiden tulisi olla prosessirajat ylittäviä eikä palveluita tule suunnitella pelkästään yhden prosessin näkökulmasta. Vaatimus uudelleenkäytettävyydestä yhdistyy muihin SOA-palveluvaatimuksiin. Palveluiden koostettavuusvaatimus edistää uudelleenkäytettävyyttä. Uudelleenkäytettävyys puolestaan edistää palveluiden helpon haettavuuden kanssa innovatiivisuutta ja organisaatiorajat ylittävää toimintaa. Vaikka palveluiden käyttäminen etukäteen suunnittelemattomalla tavalla tuokin monesti merkittäviä hyötyjä, pitää palveluiden käyttäjistä muistaa pitää kirjaa, jotta esim. palvelinresurssit osataan mitoittaa käytön määrän ja kriittisyyden mukaan. Tähän voidaan hyödyntää mallinnusohjelmistoja, palveluhakemistotuotteita ja standardeja (ks. lisätietoja kohdasta 4.3).

10 (56) Vaikka uudelleenkäytettävyys pitää palvelujen tunnistamisessa ja muussa toiminnassa aina huomioida, ei todelliseen uudelleenkäytettävyyteen ole aina mahdollista päästä. Eri organisaatiot hoitavat erilaisia tehtäviä eikä yhteistä toiminnallisuutta tai integrointitarpeita välttämättä esiinny. Tämä on syytä kuitenkin todeta palvelukohtaisesti ja tarkistaa esim. uutta palvelua analysoitaessa löytyykö samaa tehtävää tai vastuuta hoitavia palveluja entuudestaan yhteisestä palveluhakemistosta. 3.7 Palveluiden tulee olla yhteentoimivia eri järjestelmien ja ympäristöjen välillä Palveluiden tulee olla yhteentoimivia eri ympäristössä suoritettavien palveluiden ja sovellusten kanssa. Palveluiden käyttö ei saa olla esim. sidoksissa käyttöjärjestelmään tai ohjelmointikieleen. Merkittävää on huomata, ettei tämä vaatimus toteudu pelkästään teknisiä yksityiskohtia tarkastelemalla, vaan yhteentoimivuus pitää huomioida myös esim. palveluita tunnistettaessa. Esimerkiksi yhteisten tietojen (master data) pitää olla samanrakenteisia yhteentoimivuuden varmistamiseksi. Teknistä yhteentoimivuutta edistetään tukeutumalla avoimiin standardeihin ja yleisesti hyvinä pidettyihin ratkaisuihin. Teknisten linjojen tarkkuus ja konkreettisuus ovat tärkeitä asioita yhteentoimivuuden varmistamiseksi. Standardit voivat olla liian väljiä ja mahdollistavat liialliset rönsyilyt ja vaihtoehtoiset toteutustavat. Esimerkiksi web-sovelluspalvelu (web service) standardeihin nojautuvat ratkaisut voivat olla hyvin hankalasti eri ympäristöistä kutsuttavissa. Tämän vuoksi WS-I -yhteisö tarjoaa profiili-dokumentteja rajaamaan ja tarkentamaan web-sovelluspalveluihin liittyviä perusmäärittelyjä ja niiden yhteiskäyttöä. KuntaIT edellyttää SOA-palveluiden toteutuksissa WS-I basic profile määrittelyyn nojautumista (ks. kohta 4.2.2).

11 (56) 4 Teknologiat ja palvelinohjelmistot 4.1 SOA-teknologiat ja ohjelmistotuotteet Liiketoiminta (tavoitteet, strategia) Arkkitehtuuri (SOA) Teknologiat (Websovelluspalvelut) Kuva 4.1 Liiketoiminnan ohjaava vaikutus teknologioihin Palvelukeskeistä arkkitehtuuria tukemaan on kehitetty runsaasti ohjelmistoja, standardeja ja teknologioita. Palvelukeskeinen arkkitehtuuri ei ole kuitenkaan teknologiasidonnainen vaan lähtökohtana on, että arkkitehtuuri ohjaa teknologiavalintoja (ks. kuva 4.1 liiketoiminnan ohjaava vaikutus teknologioihin). Käyttötarpeet ja vaatimukset tarvittaville ohjelmistotuotteille tulevat SOA-palveluvaatimuksista (ks. luku 3) sekä kunnan SOA:n hallinnointiin ja strategiaan liittyvistä määrittelyistä. On hyvä huomata, että monien tuotteiden menestyksekäs hyödyntäminen voi edellyttää merkittäviä muutoksia mm. toimintatapoihin, organisaatioiden rakenteisiin ja vastuujakoihin, mikä puolestaan korostaa SOA-strategian ja kokonaisarkkitehtuurityön tärkeyttä (kokonaisarkkitehtuuria ja sen suhdetta SOA:an on käsitelty tarkemmin dokumentissa SOA:n hyödyntäminen kuntasektorilla [12]). Luvun 3 SOA-palveluvaatimukset asettavat tiukat vaatimukset palveluiden toteutusteknologioille. Näihin vaatimuksiin tällä hetkellä parhaiten vastaa web-sovelluspalveluteknologia (Web Service). Web-sovelluspalveluiden käyttö toimii myös yhtenä tärkeänä valintakriteerinä tuotteiden ja teknologioiden valinnassa. KuntaIT on valinnut seuraavat tuoteryhmät tukemaan palvelukeskeistä arkkitehtuuria. Kokonaisarkkitehtuurin mallintamista tukevat työkalut (tuki Archimate-kielelle suositeltavaa, lisätietoja mallinnuksesta dokumentissa SOA:n hyödyntäminen kuntasektorilla) BPMN-pohjaista prosessimallinnusta tukevat työkalut (ks. BPMN kohta 6.1.1, prosessimallinnuksen ja siihen liittyvän kokonaisarkkitehtuurimallinnuksen välistä suhdetta ja hyötyjä on käsitelty dokumentissa SOA:n hyödyntäminen kuntasektorilla) BPEL-prosessimoottorit (ks. prosessimoottorit kohta 4.4 ja BPEL-standardi kohta 6.1.2) Palveluväyläarkkitehtuuriin (ESB) liittyvät palvelintuotteet (ks. ESB kohta 4.5) Web-sovelluspalveluhakemistot (ks. kohta 6.3) Ajoympäristö WS-I yhteensopiville web-sovelluspalveluille (ks. web-sovelluspalvelut kohta 4.2)

12 (56) JSR-168 standardia tukeva portaalipalvelin (ks. portaalikäyttöliittymät kohta 4.8 ja JSR-168 standardi kohta 6.5.2) Tietoturvaohjelmistot kertakirjautumista (SSO), palveluiden käyttöoikeuksien tarkistusta ja valtuuttamista varten Master datan hallinnointituotteet (ks. MDM kohta 4.7) Näiden ohjelmistotuotteiden suhde toisiinsa on esitetty kaaviossa (kuva 4.2). Kaaviossa ohjelmistot on järjestetty ohjelmistoryhmittäin tyypillisen abstraktiotason mukaan (ohjelmistoryhmät vasemmalla). Alaspäin mentäessä abstraktiotaso laskee. On hyvä huomata, että kaavio sisältää myös kaksisuuntaisia suhteita. Tämän vuoksi ohjelmistojen keskinäinen sijainti kaaviossa ei ole täysin yksiselitteinen. Esim. kaksi web-sovelluspalvelua voi viestiä keskenään palveluväylän välityksellä. Tällöin toinen web-sovelluspalveluista lähettää viestin palveluväylälle ja toinen vastaanottaa palveluväylän välittämän viestin. Riippuen siitä, kumman web-sovelluspalvelun näkökulmasta asiaa tarkastelee, voidaan palveluväylä sijoittaa kaaviossa web-sovelluspalvelun ylä- tai alapuolelle. Koska kaavio on järjestetty tyypillisen abstraktiotason mukaan, on kerrosten välisten kutsujen suunta yleensä ylhäältä alaspäin. Kuva 4.2 Teknologiapino Tuoteryhmien ja teknologioiden jäsentely perustuu seuraavan kaavion mukaiseen kerrosjakoon.

13 (56) Kuva 4.3 SOA-kerrokset Abstraktiotaso kasvaa ylöspäin noustessa eikä ideaalitapauksessa ylimmällä kerroksella enää edellytetä teknisten yksityiskohtien tietämistä tai ohjelmointia. Nämä kerrokset heijastuvat suoraan palvelukerroksiin ja näiden toteutusmekanismeihin. Palvelukerrokset on esitetty alapuolella (kuva 4.4). Palveluita muodostuu eri projektien ja hankkeiden seurauksena. Alatason palveluiden ei tulisi kuitenkaan olla sidoksissa pelkästään näihin projekteihin, vaan niiden tulisi olla uudelleenkäytettävissä mahdollisimman laajasti. Uudet hankkeet voivat edellyttää myös olemassa olevien palveluiden laajentamista tai uusien palveluiden luomista olemassa olevan tiedon hyödyntämiseksi. Yläkerroksen palvelut koostuvat alemman tason palveluista ja tarjoavat riittävän toiminnallisuuden yksittäisten prosessien ja sovelluskohtaisten käyttötapausten toteuttamiseksi. Näiden palveluiden ei tarvitse olla yhtä uudelleenkäytettäviä kuin alemman tason palveluiden. Ylimmän tason palveluiden olisi suotavaa perustua tehtyihin prosessimalleihin ja palveluiden kooston olla joustavaa. Tyypillisesti prosessipalveluiden elinkaari vastaa liiketoimintaprosessin elinkaarta ja ovat näin kestoltaan pitkäikäisempiä kuin alemman tason palvelut. Lisäksi prosessipalveluiden tulisi tarjota prosessien mittaamiseen ja tehostamiseen riittävät välineet (toteutus esim. näitä ominaisuuksia tarjoavan BPEL-prosessimoottorin avulla).

14 (56) Kuva 4.4 Palvelukerrokset 4.2 Web-sovelluspalvelut SOA-palveluvaatimukset (luku 3) asettavat tiukat vaatimukset toteutusteknologioille. Näihin vaatimuksiin parhaiten teknologiapuolella tällä hetkellä vastaavat web-sovelluspalvelut (Web Service). Teknologioilla on kuitenkin taipumus muuttua arkkitehtuureja nopeammin, joten muita toteutusteknologioita on mahdollisesti tarjolla enemmän tulevaisuudessa. 4.2.1 Web-sovelluspalveluiden yleiskuvaus Web-sovelluspalvelu (Web Service) on joukko sovellustoimintoja, joita voidaan ohjelmallisesti kutsua tietoverkon yli. KuntaIT nojautuu web-sovelluspalvelun määrittelyssä standardointijärjestö W3C:n määritelmään. W3C:n mukaan web-sovelluspalvelu käsite viittaa XMLpohjaisiin SOAP-standardia tiedonvälitykseen käyttäviin asiakas-palvelin palveluihin, joiden rajapinnat on kuvattu ohjelmallisesti tulkittavalla kielellä (esim. WSDL). W3C:n Web Services Architecture dokumentti määrittelee web-sovelluspalvelun seuraavasti: Web Service Definition: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

15 (56) Web-sovelluspalvelun tulee olla: Itsenäinen (self-contained). Asiakaspäässä ei tarvita muita ohjelmistoja. Itsensä kuvaava. Koodigeneraattoreita tai erillistä metadatapalvelua ei tarvita palvelun kutsumiseen. Modulaarinen. Monimutkaisemmat ja laajemmat web-sovelluspalvelut voidaan koostaa pienemmistä ja yksinkertaisemmista web-sovelluspalveluista Alustariippumaton. Perustuu avoimille XML-pohjaisille standardeille ja on riippumaton esim. ohjelmointikielestä ja käyttöjärjestelmästä. Nämä vaatimukset ovat pääsääntöisesti samoja kuin SOA-palveluilta yleisesti vaadittavat ominaisuudet, ks. luku 3. On hyvä kuitenkin huomata, että nämä vaatimukset ovat luonteeltaan teknisempiä kuin yleisemmät SOA-palveluvaatimukset ja että SOA-palvelut eivät rajaudu pelkästään web-sovelluspalveluihin. Web-sovelluspalvelun pitää kuitenkin täyttää yleiset SOA-palveluvaatimukset ollakseen SOA-yhteensopiva. Esimerkiksi Java EE ympäristössä käytettävät EJB-komponentit eivät täytä luvun 3 SOA-palveluvaatimuksia (esim. kohtia 3.7 ja 3.2). Mikäli olemassa olevalle EJB-komponentille tehdään websovelluspalvelupohjainen rajapinta täyttää tämä helposti web-sovelluspalvelulta vaadittavat ominaisuudet, mutta voi edelleen rikkoa SOA-palveluvaatimuksia (esim. kohtia 3.1, 3.5 ja 3.6). Web-sovelluspalveluissa käytetään tyypillisesti seuraavia standardeja: SOAP-standardi kuvaa XML-pohjaisen viestikehyksen, jonka avulla tiedot välitetään web-sovelluspalveluille. XML Schema kuvaa SOAP-viesteissä käytetyt tietorakenteet mahdollistaen siirrettävien tietojen tarkan tyypittämisen. WSDL-kieli kuvaa formaalisti web-sovelluspalvelun rajapinnan ja konkreettisen käytön. Konkreettinen osuus sisältää mm. tiedon käytetystä protokollasta ja palvelun sijainnista. WSDL-kielistä dokumenttia kutsutaan myös palvelusopimukseksi. UDDI-standardi määrittelee keskitetyn palveluhakemiston web-sovelluspalveluille. Kolme ensimmäistä standardia ovat W3C-järjestön määrityksiä, UDDI puolestaan OASISjärjestön määrittelemä standardi. Web-sovelluspalveluita voidaan tuottaa alhaalta ylös tai ylhäältä alas periaatteella. Alhaalta ylös periaatteessa web-sovelluspalvelurajapinnat muodostetaan olemassa olevista komponenteista, esim. EJB-komponenteista. Ylhäältä alas periaatteessa määritellään ensin rajapinnat eli muodostetaan palveluiden WSDL-kuvaukset. Nämä kuvaukset määritellään WSDL-dokumentin abstraktissa osiossa eli kuvaukset eivät ota kantaa sijaintiin tai toteutusympäristöön. Näille abstrakteille kuvauksille tehdään myöhemmin toteutukset halutuilla ohjelmointikielillä. Viimeistään asennusvaiheessa määritellään protokollat, sidontatavat ja sijaintitiedot WSDL-dokumentin konkreettiseen osioon. Tätä lähestymistä kutsutaan englanniksi myös contract-first tavaksi. Tämä nimi on varsin osuva, koska pääpaino ja ensimmäiset tehtävät liittyvät palvelusopimuksen määrittelyyn. Ylhäältä alas mallia pidetään yleisesti lopputuloksen kannalta parempana vaihtoehtona, koska tällä tavalla taataan rajapintojen riippumattomuus toteutustavasta. WSDL-

16 (56) dokumentissa XML Scheman avulla kuvatut viestirakenteet mahdollistavat yleensä eri ohjelmointikieliä yksityiskohtaisemman rajapintamäärittelyn, mutta eivät taivu kaikkiin ohjelmointikielten tarjoamiin rakenteisiin. Tämän vuoksi olemassa olevasta rajapinnasta voi olla joskus hankala muodostaa web-sovelluspalvelua. Monesti houkutteleva vaihtoehto on generoida web-sovelluspalvelut automaattisesti olemassa olevista rajapinnoista (esim. javarajapinnoista). Tähän tehtävään on runsaasti työkaluja eri valmistajilla, mutta lopputulos on harvoin hyvä. Esim. java-rajapinnat eivät tarjoa riittävästi tietoa hyvän websovelluspalvelurajapinnan muodostamiseksi. Näistä rajapinnoista jäävät puuttumaan esim. merkkijonojen maksimipituudet, numeroiden arvoalueet, elementtien minimi- ja maksimimäärät sekä valinnaisuudet ja korvattavuudet, elementtien tarkat nimet, tekstien tarkat muodot ja tarkemmat tyypitykset (esim. tietotyyppi kuukausi). Osan tiedoista pystyy liittämään web-sovelluspalvelurajapintoja muodostettaessa erillisiin metatietoihin (esim. Javan annotaatiot) mutta suuri osa tiedoista pitää yleensä lisätä WSDL-kuvaukseen. Tämän vuoksi web-sovelluspalvelurajapintoja generoidessa pitää tuotokset aina tarkastaa ja palvelukuvaukset lähes aina tarkentaa käsin. 4.2.2 WS-I web-sovelluspalvelut Web-sovelluspalveluiden merkittävät hyödyt liittyvät integroitavuuteen ja mahdollisuuteen rakentaa ohjelmistoja palvelukeskeisesti tukeutuen olemassa oleviin palveluihin. Tähän tavoitteeseen pääseminen edellyttää palveluiden yhteiskäyttöisyyttä. Yhteiskäyttöisyys monitoimittajaympäristössä edellyttää puolestaan standardeihin nojautumista. Ensimmäiset web-sovelluspalvelut osoittivat kuitenkin, ettei tämäkään aina riitä. Standardit voivat olla liian väljiä sallien liiat rönsyilyt ja käyttötavat. Standardien toteuttaminen voi olla monesti liian vaikeaa ja työlästä, jos standardit ovat laajoja ja niille löytyy runsaasti laajennuksia. Lopputuloksena on usein, ettei mikään toimittaja tue standardeja kokonaisuudessaan ja eri toimittajat pitävät eri asioita tärkeinä ja valitsevat eri osat tukensa piiriin. Näin kävi ensimmäisten web-sovelluspalveluiden yhteydessä eikä yhteiskäyttöisyyttä saavutettu kuin yksinkertaisimpien palveluiden osalta. Tätä ongelmaa ratkaisemaan perustettiin vuonna 2002 websovelluspalveluiden yhteentoimivuutta ajava järjestö WS-I (Web Services Interoperability Organization). Tähän järjestöön kuuluvat kaikki alan merkittävimmät toimijat, yhteensä n. 200 eri yritystä, mm. BEA, IBM, Oracle, SAP, Microsoft, Sun Microsystems, JBoss, Vignette, Fujitsu, Nokia, IONA, Autodesk, Hewlett-Packard, Cisco, EDS, Vesisign, BT Group, NEC, NTT ja Hitachi. WS-I järjestöllä ei ole omia standardeja, vaan järjestö tarjoaa profiili-dokumentteja, joissa tarkennetaan ja rajataan web-sovelluspalveluihin liittyviä perusmäärittelyjä ja niiden yhteiskäyttöä. Merkittävimmät dokumentit ovat Basic Profile ja tätä laajentavat Attachment Profile ja Simple SOAP Binding Profile, joka eriytettiin omaksi dokumentiksi Basic Profile versiossa 1.1. Basic Security Profile dokumentti on järjestöllä edelleen työn alla. Uusin hyväksytty (final) Basic Profile versio on 1.1. Versiot 1.2 ja 2.0 ovat tällä hetkellä (joulukuu 2008) työn alla. WS-I järjestö on menestyksekkäästi onnistunut lisäämään web-sovelluspalveluiden yhteiskäyttöä monitoimittajaympäristössä. Myös ohjelmistokehitysvälineiden tuki WS-I yhteensopivuudelle on tällä hetkellä hyvä. Suurin osa yleisimpien kehitysvälineiden valmistajista tukee uusimmissa tuotteissaan WS-I yhteensopivien web-sovelluspalveluiden kehitystä. Koska WS-I:n tuomat hyödyt yhteentoimivuudelle ovat todistetusti merkittävät ja kehitystuki hyvä, edellyttää KuntaIT WS-I Basic Profilen noudattamista kaikissa tulevissa web-

17 (56) sovelluspalvelutoteutuksissa. Tästä vaatimuksesta poikkeaminen edellyttää erityisen hyviä perusteita, jotka tarkastetaan aina tapauskohtaisesti. Tällä hetkellä suositeltavin versio WS-I Basic Profile yhteensopivuusvaatimukselle on 1.1 (ks. http://www.ws-i.org/profiles/basicprofile-1.1.html). Versio 1.1 suosittelee käyttämään seuraavia versioita web-sovelluspalvelustandardeista: Standardi Versio SOAP 1.1 WSDL 1.1 UDDI 2.0 XML 1.0 XML Schema 1.0 HTTP 1.0 tai 1.1 Näiden standardien versioinnin lisäksi WS-I Basic Profile määrittelee lukuisia rajauksia standardien käytölle. Ennen WS-I Basic Profile määrityksiä merkittäviä yhteensopivuusongelmia oli etenkin viestien sidonnassa. Sidonnalla viitataan tapaan, jolla palvelu liitetään viestiprotokollaan (WS-I palveluissa protokollana aina SOAP). Alla listattuna merkittävimpiä rajoituksia, jotka tulee web-sovelluspalveluiden kehityksessä huomioida. Palveluiden väliseen viestintään tulee käyttää SOAP-viestikehystä (ei esim. WSIFlaajennuksia) SOAP-viestit pitää lähettää käyttäen HTTP(S) protokollaa (ei esim. ftp-protokollaa tai sähköpostia). HTTP-pyynnön metodina pitää käyttää POSTia. SOAP-sidonnassa (binding) ainoat sallitut kombinaatiot ovat RPC/literal ja document/literal. Tästä seuraa myös, että tietotyypit pitää määritellä XML Schemaa käyttäen eikä esim. SOAP-standardin määrittelemien tyyppien käyttö ole sallittua. SOAP-viestit eivät saa sisältää DTD-määrityksiä. Ainoat sallitut merkistöt SOAP-viesteille ja WSDL-kuvauksille ovat UTF-8 ja UTF- 16. Esim. HTML:n oletus merkistön ISO-8859-1 käyttö ei ole sallittua. RPC/literal sidontaa käytettäessä viestiosan (part-elementin) pitää käyttää typeattribuuttia, document/literal sidonnassa puolestaan aina element-attribuuttia. WSDL-kuvauksen sisältämien viestimäärityksien part-osassa käytettävän elementattribuutin pitää viitata juuritasolla määriteltyyn XML Schema elementtiin.

18 (56) Document/literal sidontaa käytettäessä WSDL:n viestikuvaukset voivat sisältää enintään yhden part-elementin. SOAP-viestin sisältöosan elementtien pitää olla samassa järjestyksessä kuin vastaavat part-määritykset WSDL-dokumentissa. Tämä koskee siis pelkästään RPC/literal muotoisia kuvauksia, kun huomioidaan aikaisemmat WS-I rajoitukset. SOAP-viestin sisältöosa (body) saa sisältää enintään yhden juurielementin. Tämän vuoksi operaatio voi ottaa vain yhden parametrin, jos viestiosan elementtimääritys ei ole complex-tyyppinen. Tyypillisesti WS-I:n tuomat rajoitteet voidaan parhaiten kiertää käyttämällä document/literal sidontaa wrapped tavalla. Document/literal wrapped on Microsoftin alun perin lanseeraama sidontamalli, josta on muodostunut alalle yleinen käytäntö. Tämä malli on valittu myös oletukseksi JAX-WS määrittelyyn, joka on osana mm. EJB 3.0 ja Java EE määrittelyjä. On kuitenkin hyvä huomioida, että document/literal wrapped ei kuulu lainkaan WS-I Basic Profile määrittelyyn eikä tämä ota wrapped-sidontaan mitään kantaa. Sidontamalli voidaan pitää kuitenkin WS-I yhteensopivana, koska se täyttää WS-I Basic Profilen sisältämät rajoitukset. Document/literal wrapped sidontamalli on laajennus WS-I Basic Profilen document/literal sidonnalle. Se määrittelee, että kaikki operaation parametrit tulee sitoa XML Scheman juurielementtiin, jonka pitää olla samanniminen kuin operaatio, johon parametrit kuuluvat. Tämä mahdollistaa, että SOAP-viestin sisältöosa voidaan validoida WSDL-dokumentin käyttämää XML-schemaa vasten ja operaatio on tunnistettavissa juurielementin nimestä. Jälkimmäinen mahdollistaa sen, että web-sovelluspalvelu voi sisältää useita samantyyppisiä parametreja sisältäviä operaatioita. Huonona puolena tästä on, ettei web-sovelluspalvelu voi koskaan sisältää useita samannimisiä operaatioita. 4.3 Palveluhakemistot ja niiden suhde kokonaisarkkitehtuurimallinnukseen Palvelurekisteri (service registry) ja hakemisto (service repository) ovat ohjelmistotuotteita, joihin tallennetaan tietoja web-sovelluspalveluista. Palvelurekisteri termillä viitataan yleensä UDDI-standardin toteuttavaan hakemistorekisteriin (ks. lisätietoja UDDI:sta 6.3.1) ja palveluhakemistolla laajempia ominaisuuksia tarjoavaan hakemistoratkaisuun. Palvelurekisterin voidaan käsitteellisesti ajatella sisältävän viitteitä ja hakemiston varsinaista tietoa palvelusta. Palvelurekisteri sisältää viittaukset web-sovelluspalveluiden WSDL-muotoisiin rajapintakuvauksiin ja suppeaa metatietoa näiden viitteiden löytämiseen. Palveluhakemistoihin kerätään tietoja SOA-palveluista laajemmin. Koska useat tuotteet sisältävät yhä useammin sekä rekisterin että hakemiston, ei eroa näiden osittain epäselkeiden käsitteiden välillä aina tehdä. Palveluhakemistoon kerätään usein tarkempien palvelukuvausten lisäksi teknistä tietoa. Näitä tietoja voivat olla esim. palvelinalusta, suorituskyky, arvioidut käyttäjämäärät, palvelun kriittisyys jne. Palveluhakemisto auttaa etenkin SOA-infrastruktuurin suunnittelussa ja hallinnassa. Sen avulla voidaan arvioida esim. minkälaisia varmistuksia ja suorituskykyä parantavia ratkaisuja tarvitaan. Palveluiden liiketoimintaan liittyvää tietoa hallinnoidaan kuitenkin yleensä kokonaisarkkitehtuurin mallinnukseen kykenevän mallinnustyökalun avulla. Tämä mahdollistaa SOApalvelutoteutusten jäljittämisen mm. liiketoimintaprosesseihin, käsitteisiin, organisaatioihin

19 (56) ja rooleihin. Mallinnustyökalut tarjoavat monesti myös ominaisuuksia websovelluspalveluihin liittyvien mallien automaattiseen luontiin WSDL-kuvausten pohjalta. Vaikka nämä mallit ovat luonteeltaan monesti teknisiä, tarjoaa tämä helpon tavan palvelutoteutusten liittämiseen ylätason malleihin. Näitä liiketoimintaan liittyviä tietoja voidaan joskus tuoda myös palveluhakemistoon, mutta silloin on syytä huolehtia, ettei tietoja tarvitse ylläpitää kahdessa eri paikassa. Kokonaisarkkitehtuurin mallintamista on käsitelty tarkemmin KuntaIT:n dokumenteissa SOA:n hyödyntäminen kuntasektorilla ja Archimatemallinnus. 4.4 Liiketoimintaprosessien hallinta ja prosessimoottorit 4.4.1 Yleistä prosessien hallinnasta ja prosessimoottoreista Yksi merkittävimpiä tietotekniikalta odotettavia pitkän aikavälin tavoitteita ovat liiketoimintaprosessien tehostaminen ja laadun parantaminen. Käytännössä tämä tarkoittaa, että tietojärjestelmien tulee elää ja kehittyä liiketoiminnan ehdoilla. Tämä edellyttää tietojärjestelmiltä joustavaa ja nopeaa mukautumista liiketoimintaprosesseihin kohdistuviin muutoksiin ja tukea prosessien mittaamiselle. Tätä haastetta vastaamaan on kehitetty prosessimoottoreita. Prosessimoottori on vastuussa prosessien suorittamisesta prosessimäärittelyjen mukaisesti. SOA-ympäristössä prosessimoottorin tehtävänä on ohjata web-sovelluspalveluita ja tukea palvelukeskeiseen arkkitehtuuriin perustuvan ympäristön kehitystyötä ja prosessikeskeisen toiminnan kehittämistä. Prosessimoottori mahdollistaa graafiseen malliin pohjautuvan prosessitoteutuksen ja tämän toteutuksen joustavan muokkaamisen. Lisäksi se tarjoaa seurantatyökalut prosessin työnkulkujen tehostamiseen ja analysointiin. Prosessimoottorin käyttämä prosessimalli voidaan johtaa ylätason prosessikuvauksista, jotka voidaan puolestaan yhdistää kokonaisarkkitehtuurimalleihin. Tätä asiaa on käsitelty tarkemmin kohdassa 5.4 ja dokumentissa SOA:n hyödyntäminen kuntasektorilla. Prosessimoottorin käyttöä ei pidä nähdä pelkästään teknologia-arkkitehtuuriin kuuluvana asiana, vaan se tulee nähdä ennen kaikkea osana liiketoimintaprosessien kehittämistä ja hallintaa. Prosessimoottori tukee prosessien määrittelyä, laadun mittaamista ja nopeuttaa mittausten perusteella tehtäviä korjaustoimenpiteitä mahdollistaen näin johdetun iteratiivisen prosessikehityksen. Prosessien mallintaminen ja siitä johdettavat toteutukset auttavat myös keskittymään projektien alussa liiketoimintakysymyksiin teknisten kysymysten sijaan. Toiminnan laadun ja teknologisen joustavuuden kehittämisen lisäksi prosessimoottorilla on merkittävä ohjausvaikutus arkkitehtuuriin kehittämiseen. Prosessimoottorin käyttö muokkaa yleensä arkkitehtuuria palvelukeskeisemmäksi. Esim. BPEL-prosessimoottorin käyttö edellyttää SOA-palveluiden ja prosessien kehittämistä ja tukee vahvasti keskitettyä hallintaa ja pitkäikäisten prosessipalveluiden toteuttamista. On tärkeää huomata, että liiketoimintaprosesseihin liittyy monesti useita eri tietojärjestelmiä. Tämän vuoksi liiketoimintaprosessien suoritusta ei ole hyvä liittää osaksi uutta tai olemassa olevaa järjestelmää, vaan tehdä se keskitetysti projekteille ja järjestelmille yhteisen ratkaisun kuten prosessimoottorin kautta. Prosessimoottorin avulla arkkitehtuurista tulee läpinäkyvämpi ja prosessimääritykset ohjaavat hallitusti palveluiden koostoa. Vaikka palveluita voidaan helposti koostaa ilmankin prosessimoottoria, on pitkäikäisten ja työnkulkujen seurannan mahdollistavien prosessipalveluiden kehitystyö ja ylläpito versiopäivityksineen hankalaa ja harvinaista ilman prosessimoottoria. Käytännössä prosessimoottorin käyttö vaikuttaa lähes aina myös ohjelmistoarkkitehtuurin suunnitteluun.

20 (56) Prosesseja voidaan hallita ja suorittaa orkestroimalla tai koreografialla. Orkestrointi perustuu malliin, jossa koostamislogiikka ja hallinnointi suoritetaan keskitetysti (ks. kuva 4.5). Koreografia (choreography) perustuu hajautettuun malliin, jossa koostamislogiikalle ja liiketoimintaprosessille ei ole yksittäistä omistajaa eikä hallinnoitsijaa (ks. kuva 4.6). Orkestroinnissa keskitetty liiketoimintaprosessi koordinoi web-sovelluspalveluja, koreografiassa web-sovelluspalveluiden pitää olla itse tietoisia minkä web-sovelluspalveluiden kanssa ne kommunikoivat. Orkestroinnin etuna on, ettei yksittäisten web-sovelluspalveluiden tarvitse tietää muista palveluista eikä niiden tarvitse tietää olevansa osa isompaa kokonaisuutta eli osallistumisesta prosessiin. Koreografiassa web-sovelluspalveluiden pitää olla tietoisia prosessista, oikeista operaatioista, viestimuodoista sekä viestinnän ajoituksesta. Orkestrointia voidaankin verrata kapellimestarin työhön ja koreografiaa esim. tanssiryhmän tekemään yhteistyöhön. Websovelluspalvelu 4 Websovelluspalvelu 3 Orkestroinnin koordinaattori (esim. BPELprosessimoottori) Websovelluspalvelu 1 Websovelluspalvelu 2 Kuva 4.5 Orkestrointi Prosessimoottoreista suurimman käyttäjäkunnan ovat saaneet BPEL-kieltä tukevat ohjelmistot. BPEL-prosessimoottori perustuu orkestrointimalliin ja on parhaiten tuettu kieli eri valimistajien prosessimoottoreissa (ks. lisätietoja BPEL-standardista alakohdasta 6.1.2). Kirjoitushetkellä (joulukuu 2008) kaikki BPEL-kieltä tukevista prosessimoottoreista eivät tue standardoitua 2.0 versiota, mutta lähes kaikki 1.1 versiota tukevat valmistajat ovat luvan- Websovelluspalvelu 4 Websovelluspalvelu 1 Websovelluspalvelu 3 Websovelluspalvelu 2 Kuva 4.6 Koreografia 4.4.2 BPEL-prosessien hallintaohjelmistot

21 (56) neet tukensa uudelle versiolle (on hyvä huomata, ettei BPEL 2.0 versio ole täysin yhteensopiva vanhempien versioiden kanssa, ks. lisää kohdasta 6.1.2). Alla on listattu yleisimmät BPEL-kieltä tukevat prosessimoottorit valmistajittain ja tuoteperheittäin: Valmistaja Tuoteperhe Prosessimoottori Active Endpoints ActiveVOS ActiveVOS Server IBM IBM SOA Foundation WebSphere Process Server Intalio Intalio BPMS Intalio Server JBOSS JBoss Enterprise Middleware JBoss jbpm BPEL Microsoft - BizTalk Server Oracle Oracle BPM Suite BPM Process Execution Engine (entinen BEA AquaLogic BPM Process Execution Engine) Oracle Oracle SOA Suite ja Oracle BPM Suite - Oracle BPEL Process Manager (mukana molemmissa suitessa) BPEL Server SAP SAP NetWeaver Exhange Infrastructure Integration Server QPR - QPR WorkFlow Server BPEL-prosessimoottori toimii ajoalustana BPEL-kielellä kuvatulle prosessille. BPEL tarjoaa standardin ja toimittajariippumaton tavan kuvata liiketoimintaprosesseja ja niiden työnkulkuja. BPEL-prosessi voi olla joko abstrakti tai suoritettava. Suoritettava BPEL-prosessi on aina web-sovelluspalvelu (ks. kohta 4.2), joka koostuu muista web-sovelluspalveluista. Suoritettava BPEL-kielinen liiketoimintaprosessi on siis koostettu web-sovelluspalvelu, josta käytetään myös nimitystä komposiittipalvelu (ks. SOA vaatimus palveluiden koostamiselle, kohta 3.1). Koska BPEL-prosessi on web-sovelluspalvelu, edellyttää BPEL-prosessin suoritus web-sovelluspalvelukutsua. BPEL-kielellä toteutettu komposiittipalvelu sisältää liiketoi-

22 (56) mintalogiikan, jonka perusteella se kutsuu muita web-sovelluspalveluita. Liiketoimintalogiikka voidaan halutessa myös ulkoistaa erilliseen web-sovelluspalveluun, jota komposiittipalvelu kutsuu. BPEL-palvelun vastuulla on myös rinnakkaisuuden ja virhetilanteiden käsittely. Yleensä monimutkaisemmat päättelysäännöt ja laskukaavat ulkoistetaan erilliselle sääntökoneelle, jota BPEL-palvelu kutsuu päätöstä tai laskemista tehtäessä. Sääntökone voi tarjota esim. web-liittymän säännön hallintaan ja sitä voidaan yleensä muuttaa ilman ohjelmointityötä. Erilliset sääntökoneet mahdollistavat säännön helpon muuttamisen lisäksi esim. säännön graafisen mallintamisen tai muita kaavan syöttämistä, kuvaamista ja testaamista helpottavia ominaisuuksia (ks. sääntömoottoreita käsittelevä kohta 4.5). Prosessien hallintaohjelmistot sisältävät BPEL-prosessimoottorin lisäksi yleensä välineet prosessin valvontaan ja hallintaan. Lisäksi ne voivat sisältää apuvälineitä manuaalisten, ihmistyötä vaativien, työnkulkujen toteuttamiseksi. Monesti ohjelmistot sisältävät myös integrointi-adaptereja, joilla helpotetaan esim. tietokanta- ja sanomajonointegrointeja. Yhtenä toimintamallina on, että työkalu generoi palvelun, jota BPEL-prosessi kutsuu integrointitehtävän suorittamiseksi. BPEL-kielisen kuvauksen näkökulmasta generoitu palvelu ei eroa muista kutsuttavista web-sovelluspalveluista. Prosessien hallintaohjelmistoihin liittyvät keskeisesti prosessien graafiset mallinnustyövälineet. Prosessien mallinnus- ja suunnittelutyökalu on yleensä prosessimoottorista irrallinen ohjelma, jolla prosessimoottoriin asennettava BPEL-kielinen prosessi suunnitellaan ja toteutetaan. BPEL-malleista käytetään usein myös nimitystä tekninen malli, koska BPELmalli sisältää lähes aina teknisiä yksityiskohtia, jotka ovat liiketoiminnan näkökulmasta tarpeettomia. Mallinnustyökalu sisältää yleensä prosessimoottorikohtaisia avusteita ja lisäominaisuuksia, minkä vuoksi lähes jokaisella prosessimoottorivalmistajalla on tarjolla oma mallinnustyökalu. Näitä lisäominaisuuksia voivat olla esim. tuki prosessin asentamiselle prosessimoottoriin, virheiden jäljitystoiminnot, mallin validointi ja raportointi, tukitoiminnot valmistajan muihin tuotteisiin (esim. sääntömoottori ja BAM), prosessimallin simulointi ja mittarien asettaminen prosessin eri vaiheille. Prosessien seurantaan suunnatuista ohjelmistoista käytetään usein nimitystä BAM (Business Activity Monitoring). BAM on alun perin Gartnerin lanseeraama termi, jolla viitataan yleisesti, liiketoimintaprosesseja laajemmin, liiketoimintaan liittyvien aktiviteettien reaaliaikaiseen seurantaan. Prosessimoottorivalmistajat tarjoavat yleensä yksinkertaisia seurantaominaisuuksia ilmaiseksi prosessien hallinta- ja ylläpitotyökalujen yhteydessä ja paketoivat laajemmat seuranta- ja analysointityökalut erikseen asennettaviin ja hinnoiteltuihin BAMtuotteisiin. Joillakin valmistajilla laajemmat BAM-ominaisuudet kuuluvat suoraan prosessimoottorituotteeseen. BAM-työkalut perustuvat lähes aina tapahtumien käsittelyyn ja analysointiin. Prosessin suorittamille tehtäville asetetaan tyypillisesti erilaisia mittareita mallinnustyökalun avulla. Prosessimoottorin suorittamista toimenpiteistä ja asetetuista mittareista syntyy prosessin suorituksen aikana tapahtumatietoja, joita BAM-työkalujen avulla analysoidaan. Prosesseista voidaan analysoida esim. suoritusaikoja, pullonkauloja ja tyypillisiä työnkulkuja. Sillä voidaan tunnistaa ongelmakohtien lisäksi esim. mitä reittejä pitkin prosesseissa harvemmin kuljetaan ja mitkä resurssit ovat mahdollisesti yli- tai alikäytössä. BAMtyökalut tarjoavat tyypillisesti graafisia raportointi- ja mittarinäkymiä. Raportointiominaisuudet tukevat usein tapahtumatietoon pohjautuvia laskutoimituksia ja koosteoperaatioita (esim. keskiarvo). BAM-ohjelmat mahdollistavat usein myös hälytysrajojen ja -sääntöjen asettamisen ja niiden pohjalta tuotettavat hälytykset.

23 (56) BPEL-prosessit voivat olla joko synkronisia tai asynkronisia ja ne voivat kutsua joko synkronisia tai asynkronisia web-sovelluspalveluita. Merkittävänä erona BPEL-palvelulla on tyypilliseen web-sovelluspalveluun verrattuna niiden pitkäkestoisuus ja tilan säilyminen. BPELprosessi voi kutsua esim. sovelluksen X web-sovelluspalvelua asynkronisesti ja jäädä odottamaan, että sovellus X välittää prosessille tiedot kutsumalla BPEL-prosessin palvelurajapintaa. Sovellus X voi pyytää käyttäjältä tietoja esim. portaalin välityksellä ja kutsua BPELprosessia vasta useiden päivien kuluttua (ks. kuva 4.7, esimerkissä portletti ja websovelluspalvelu viestivät yhteisen tietokannan välityksellä). Prosessimoottori voi virhetilannetta varten tai palvelinresursseja säästääkseen tallentaa prosessin väliaikaisesti tietokantaan (dehydration). Esim. sovellus X:n kutsuttua prosessin palvelurajapintaa, palvelupyyntöä odottamaan jäänyt prosessimoottori hakee kannasta prosessi-instanssin ja jatkaa prosessin suoritusta tallennusta edeltävästä tilasta (hydration). BPEL-prosessimoottori Sovellus X BPEL-prosessi SOAP/HTTP Websovelluspalvelu Websovelluspalvelurajapinta SOAP/HTTP Sovelluskomponentti (esim. websovelluspalvelu) Tietokanta Portletti HTTP Kuva 4.7 Prosessimoottorin käyttöesimerkki 4.4.3 Prosessimoottorin tuomat hyödyt prosessitoteutuksiin Merkittävimpiä hyötyjä prosessimoottorin käytöstä verrattuna prosessien työnkulkujen toteuttamiseen ohjelmoimalla ovat: Prosessimoottori ohjaa ja osittain pakottaa arkkitehtuuria palvelukeskeiseksi. Toteutuneesta arkkitehtuurista tulee läpinäkyvämpi ja SOA-vaatimuksia on vaikeampi kiertää.