PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15 STUDIES AND REPORTS OF THE PLUGIT PROJECT 15. Harri Karhunen

Transkriptio

1 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15 STUDIES AND REPORTS OF THE PLUGIT PROJECT 15 Harri Karhunen D Y N A A M I N E N M A L L I L I I K E T O I M I N T A S O V E L L U S T E N I N T E G R O I M I S E K S I KUOPION YLIOPISTO SAVONIA-AMMATTIKORKEAKOULU KUOPIO 2004

2 Tekijä: Harri Karhunen Tietojenkäsittelytieteen laitos PlugIT-projekti Kuopion yliopisto Myynti: Tietotekniikkakeskus / kanslia Kuopion yliopisto puh tike@uku.fi ISBN (koko teos) ISBN (osa 15) ISBN (PDF) Kopijyvä Oy, Kuopio 2004

3 Harri Karhunen. Dynaaminen malli liiketoimintasovellusten integroimiseksi. Painos. PlugIT-hankkeen selvityksiä ja raportteja s ISBN (koko teos) ISBN (osa 15) ISBN (PDF) T I I V I S T E L M Ä Tässä selvityksessä esitetään keinoja liiketoimintasovellusten yhteistoiminnallisuuden parantamiseksi palvelupohjaisessa ohjelmistoarkkitehtuurissa. Yrityksen tai yhteisön tuotantoprosessi nähdään palveluiden muodostamana joukkona. Palvelu voi koostua useiden palveluiden yhteistyön tuloksesta. Tavoitteena on kehittää ohjelmistoarkkitehtuuria siten, että palveluparadigman avulla voidaan parantaa eri liiketoimintasovellusten integroitumista toistensa kanssa. Tavoitteena on osoittaa yrityksille polku, jota kohti kulkea, jotta yritykset saavuttaisivat liiketoimintatavoitteensa ja menestyisivät kilpailussa toisten yritysten kanssa. Ohjelmistot tarvitsevat keinoja dynaamiseen kommunikointiin toimijaverkossa (many-tomany). Palvelupyynnön esittämisen ja suorittamisen tulee tapahtua turvallisesti, luotettavasti ja siten, että tiedon yhtenäisyys taataan kaikissa olosuhteissa. Lisäksi toiminnassa tulee huomioida organisaation erilaiset vaatimukset: - Hanketta varten tarvitaan erillisiä tiimejä. - Sovellus tai käyttäjä voi olla useassa tiimissä. - Käyttöoikeuksien hallinnan tulee tapahtua joustavasti. - Sovellusten kesken on kyettävä ylläpitämään kontekstia liiketoimintaprosessin toteuttamiseksi. - Palvelun tuottamiseksi tarvitaan tuotantoprosessi. Tuotantoprosessi ja sen erityispiirteet on hallittava. Sovellusintegraatio tulee huomioida jo kehitysaikaisissa liittymissä ja on pyrittävä siihen, että integrointi tapahtuu prosessi-integraation muodossa. Prosessi-integraatio mahdollistaa aikaisen kehittämisen ja myöhäisen sidonnan, jolloin integroituvien järjestelmien kehittäminen on helpompaa, koska hyvin määritellyt integrointipisteet auttavat rajoittamaan sovellusten välisiä riippuvuuksia. Usein jo olemassa oleviin sovelluksiin joudutaan rakentamaan liittymiä toisiin ohjelmistoihin. Liittymien rakentaminen tulee toteuttaa hyödyntäen olemassa olevaa teknologiaa. Verkkopalveluiden ja komponenttipohjaisen sovelluskehityksen yhdistämisen avulla voidaan erilaiset järjestelmät yhdistää ja taata tietoturva, transaktioiden hallinta ja riittävän luotettava toiminta kriittisissä liiketoimintajärjestelmissä. Selvityksessä esitetään dynaaminen malli palvelupyyntöjen käsittelemiseksi. Malli perustuu hierarkiseen Broker-arkkitehtuurimalliin. Mallin avulla kuvataan organisaation toimintaa ja sääntöjen avulla luodaan organisaation eri ohjelmistojen (ja käyttäjien) välille yhteistoiminnallisuutta. Mallin avulla luodaan universaali virtuaalikone, jonka kautta eri komponenttialustoilla toimivat ohjelmistot voidaan yhdistää yhdeksi toimivaksi kokonaisuudeksi. Yleinen kymmenluokittelu UDK: Asiasanat (YSA): komponentit, ohjelmistot, atk-ohjelmat, integraatio, sovellukset, verkkopalvelut

4

5 E S I P U H E Tämä selvitys on tehty PlugIT-hankkeessa sen TEHO-osaprojektissa vuosina PlugIThankkeessa on tuotettu avoimia ohjelmistorajapintojen määrityksiä sekä niihin liittyviä menetelmiä ja osaamista terveydenhuollon ohjelmistoyrityksille ja niiden asiakkaille. TEHO-osaprojektin tavoitteena on kehittää yhteistyöyritysten toimintaperiaatteita ja yhteisiä pelisääntöjä ja ratkaisuja ohjelmistotuotantoon, laadunvarmistukseen ja testaukseen. Tämä lisää yritysten tuotteiden integroitavuutta ja mahdollistaa kokonaisuuden integraatiotestauksen. Tämän selvityksen lähtökohtana on ollut PlugIT-hankkeessa tehty kehitystyö. Tämä selvitys tutkii liiketoimintaprosessien integraatiota palvelukeskeisen ajattelutavan näkökulmasta. Selvitys esittelee mallin, jonka avulla liiketoimintasovellusten yhteistoiminnallisuutta voidaan lisätä. Malli on rakennettu mahdollisimman yleiseksi, jotta siitä voidaan rakentaa toimialakohtaisia toteutuksia. Lähtökohtana selvityksessä on ollut prosessikeskeisyys. Sen ansiosta malli soveltuu teollisuuden, kaupan ja palvelusektorin sekä myös terveydenhuollon sovellusten yhteistoiminnallisuuden parantamiseen. Hanke tukee terveydenhuollon palvelutoimintaa ohjelmistotuotannon palveluketjun kautta, paremmin integroituvien ohjelmistokokonaisuuksien avulla. Kohderyhmänä ovat yritysten ja organisaatioiden tietohallinnossa työskentelevät henkilöt. Selvitys pyrkii siihen, että yritysten ja organisaatioiden avainhenkilöt näkisivät informaatiotekniikan tuomat mahdollisuudet keinona lisätä yrityksen toimintakykyä vastata asiakkaiden muuttuviin vaatimuksiin. PlugIT-hanketta ovat rahoittaneet ja siihen ovat osallistuneet TEKES, Mawell konserni, Medimaker Oy Ltd, Medici Data Oy, Mediweb Oy, Mylab Oy, Tietoenator Oyj, WM-data Novo Oyj, Atkos Oy, BEA Systems Oy, Commit; Oy, Enfo Oy, Fujitsu Services Oy, General Electric Healthcare CIS EMEA, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Helsingin ja Uudenmaan sairaanhoitopiirin kuntayhtymä, Pirkanmaan sairaanhoitopiirin kuntayhtymä, Pohjois-Savon sairaanhoitopiirin kuntayhtymä, Pohjois-Pohjanmaan sairaanhoitopiirin kuntayhtymä, Satakunnan sairaanhoitopiirin kuntayhtymä, Varsinais-Suomen sairaanhoitopiirin kuntayhtymä, Kuopion kaupungin sosiaali- ja terveyskeskus sekä Siilinjärven ja Maaningan terveydenhuollon kuntayhtymä. Esitän kiitokseni jatko-opintojeni ohjaajalle Anne Eerolalle kriitikistä ja kannustuksesta. Kiitän myös PlugIT-projektiin osallistuvien yritysten ja sairaaloiden edustajia hyvistä ideoista ja näkökulmista. Kuopiossa 26. elokuuta 2004 Harri Karhunen

6

7 SISÄLLYSLUETTELO 1 JOHDANTO Tavoitteet Business to Business Taustaa, tavoitteita ja vaatimuksia Ongelmat ja voimat Ongelmat Monoliittisten arkkitehtuurien ongelmat Voimat Tutkimuksen sisältö Historiaa KONTEKSTI Yleistä Palvelukeskeinen arkkitehtuuri Verkkopalvelut (Web-services) Bottom-up ja top-down Etäproseduurikutsu (RPC Remote prosedure call) - ja viestipohjainen (Message-oriented middleware MOM) -tyyli Web Services (WS) -verkkopalvelumäärittely YRITYSPALVELUARKKITEHTUURI RATKAISUNA Yleistä Yritystason palveluarkkitehtuuri (Enterprise service architecture ESA) Yleistä Standardit ovat elintärkeitä Trendejä, jotka vaativat yritystason arkkitehtuuria Arkkitehtuurin transformaatio Tietojärjestelmien evoluutio Yritystason arkkitehtuurin (ESA) sisäinen rakenne Yritystason palveluarkkitehtuurin perusarvot ja merkitys Komponentit ja palvelut, yrityssovellusten kerrokset Yritystason arkkitehtuuri (ESA) ja liiketoiminnan lisäarvo (Business Value of ESA) Koostesovellukset eli komposiittisovellukset (Composite applications) Joustavuus ja yhdenmukaisuus (Compliance) Esimerkkejä Portaalien avulla käytettävyyttä erilaisiin tarpeisiin Liiketoiminta-ajattelu ja arkkitehtuuri Arkkitehtuurin edut/haitat Yrityspalveluarkkitehtuurin luonne ja tavoitteet Sovellusten luokittelua Toiminta-alusta (Platform) DYNAAMINEN MALLI SOVELLUSINTEGRAATIOON Yleistä Dynaaminen arkkitehtuurimalli integroinnin suorittamiseksi Hypoteesit... 40

8 4.4 Prosessin mallintaminen Prosessin mallintaminen Prosessin palveluketju Järjestelmän määrittely ja palveluarkkitehtuurin tarve ARKKITEHTUURIKUVAUS Yleistä Uudet roolit palveluintegraattori Arkkitehtuurimalli Komponentit ja komponenttikaavio Komponentit ja komponenttien tehtävät Yleistä Asiakassovellus ja adapteri (Client Application and Adapter) Palvelun edustajakomponentti asiakkaalla Palvelukomponentti (Service component) Palveluagentti (Service Agent) Palvelukomponentti koordinaation- ja transaktionhallinta Yleistä Koordinaationhallinta hajautetussa ympäristössä Komponentin tilat Transaktioiden hallinta Rajapinnat ja niiden operaatiot Yleistä IAdapter IService IMessage ITransaction IRules Palvelypyyntö yhteistyökaavion avulla kuvattuna Nimipalvelu DYNAAMINEN ARKKITEHTUURI TERVEYDENHUOLLOSSA Yleistä Terveydenhuollon yleinen palvelurakenne Skenaarioita Skenaario1: asiakkaan terveyskeskuskäynti Skenaario 2: asiakas kutsutaan lähetteen pohjalta sairaalaan YHTEENVETO JA TULEVAISUUDEN HAASTEET Implementaation ongelmia Tietojärjestelmät ja ohjelmistotoimittajat Tulevaisuus LÄHTEET LIITE1. SANASTO JA KÄSITTEET... 1 LIITE2. DOKUMENTTIPOHJAISET LIIKETOIMINTAPROTOKOLLAT (EBXML, ROSETTANET, XCBL)... 1

9 1 J O H D A N T O 1.1 Tavoitteet Business to Business Liiketoiminta vaatii yrityksiltä yhteistoimintaa ja verkostoitumista. Yritykset luovat yhteenliittymiä valmistaakseen palvelukokonaisuuksia asiakkaiden tarpeisiin. Yhdessä yritykset ja yritysten osaaminen ovat enemmän. Asiakas esittää palvelupyynnön ja palveluntarjoajat muodostavat renkaan ja toteuttavat palvelupyynnön. Teknologian kehittyminen tarjoaa keinot yhteistoiminnan tehostamiseksi ja automatisoimiseksi. Ohjelmistotekniikassa palvelukeskeinen arkkitehtuuri pyrkii toteuttamaan yritysten tarpeet. Palvelutuotanto on toteutettava tehokkaasti, dynaamisesti, luotettavasti ja turvallisesti. Verkkopalvelutekniikoiden ja komponenttitekniikoiden avulla voidaan luoda skaalautuva ympäristö yhteistoimintaa varten (Sessions, 2000). Tuotantoprosessien toteuttaminen vaatii ohjelmistojen integrointia yhteistoiminnallisuuden aikaansaamiseksi. Integroinnin tulee tapahtua Prosessikeskeisesti (process-oriented). Yhteistoiminnallisuuden rakentaminen on tehokkaampaa tuotantoprosessin pohjalta, koska yhteistoiminnallisuus voidaan huomioida koko tietojärjestelmän kehityskaaren ajan (lifecycle). Prosessikeskeisyys mahdollistaa myös sovelluksen joustavamman muuttamisen. Integroinnin ongelmana korostuu sekä yrityskulttuurien erilaisuus että yritysten tietotekniikkaratkaisujen heterogeenisuus. Verkottuminen muodostuu hankalaksi teknisten esteiden johdosta. Tehokkainta olisi, jos informaatiojärjestelmät voisivat kommunikoida standardilla tavalla ja niiden semantiikka (tiedon syntaksi ja merkitys) olisivat samat kaikilla yrityksillä. Valitettavasti näin ei ole ja siksi yritysten ja sovellusten välille joudutaan suorittamaan yhteensovittamista eli integrointia yhteistoiminnallisuuden aikaansaamiseksi. Ihanteena on integraatio, johon organisaatiot voivat liittyä yhteisen rajapinnan kautta. Rajapinnan tulee olla niin yleinen ja yksinkertainen, että hyvinkin erilaisilla sovelluksilla on kyky hyödyntää rajapintaa. Tässä dokumentissa pyritään esittämään yleinen arkkitehtoninen ratkaisu, joka on yleistettävissä yritysten väliseen integraatioon. Esitettävä dynaaminen malli on nähtävä abstraktina viitekehyksenä, johon voidaan peilata järjestelmän nykyistä tilaa ja jota kohti voidaan pyrkiä. Modernit ohjelmistotalojen sovelluspalvelimet sisältävät yleensä kaikki verkkopalvelujen rakentamiseen tarvittavat komponentit kuten web-palvelimen, kehitystyökaluja mm. dokumenttien automaattiseen generointiin, integrointiin muiden järjestelmien kanssa sekä sovelluspalvelimen. Malli on tarkoitettu määrittely-, analyysi- ja suunnitteluvaiheen tarpeisiin. Rakentamisvaiheessa luodusta mallista tehdään tekniikkariippuva toteutus. Dynaaminen malli perustuu hierarkisten Broker-komponenttien käyttöön ja tarjoaa ansaintamahdollisuuden yritysten välisten liiketoimintojen järjestelijälle ja soveltuu erinomaisesti esimerkiksi erilaisten hankintarenkaiden rakentamiseen tai esimerkiksi teollisen tuotannon järjestämisessä. Terveydenhuollossa mallin avulla voidaan rakentaa esimerkiksi asiantuntijapalveluita tai luoda erilaisia hoitoprosesseja, käyttää mallia potilashallinnossa sekä rakentaa käyttöliittymäportaaleja, joiden avulla eri sovellusten toiminnallisuutta voidaan yhdistellä kunkin käyttäjäryhmän vaatimusten mukaisesti. SELVITYS 15 9

10 1.1.2 Taustaa, tavoitteita ja vaatimuksia Tämä dokumentti on tarkoitettu johdatukseksi yritysten ja organisaatioiden tietohallinnossa työskenteleville henkilöille. Tavoitteena on antaa eväitä ohjelmistoarkkitehtuurin suunnitteluun. Dokumentin ymmärtäminen edellyttää jonkin verran ohjelmistotekniikan käsitteiden tuntemusta. Dokumentti on jatkoa PlugIT:n E2-projektissa kehitettyyn sovellusulokkeen avulla tapahtuvaan integraatioon, jossa määriteltiin ja suoritettiin kahdenvälistä integraatiota KYS:n Puijon Sairaalan gastroenterologisen tutkimusyksikön ja kliinisen patologian laboratorion välillä. Integraatiotarve oli seuraava: Gastroenterologinen tutkimusyksikkö pyytää patologin lausunnon näytteestä lähettämällä lähetteen patologille. Integraation avulla lähettävä järjestelmä käyttää vastaanottavan järjestelmän palveluja mm. muodostaen omasta lausunnostaan pyynnön, täydentäen pyyntöä ja lähettäen sen vastaanottavaan järjestelmään. E2-projektissa sovellettiin PlugIT-hankkeessa kehitettyä integrointimenettelyä. Integrointi suoritettiin kahdenvälisesti siten, että toisen sovelluksen sovellusuloke tarjosi toiselle sovellukselle rajapinnan, jota toinen hyödynsi. Siirrettävä tieto sovellusten välillä muodostettiin rakenteisena dokumenttina XML-merkkauskielen avulla, jotta järjestelmän muutoksen takia ei integrointia tarvitse suunnitella kokonaan uudelleen. Kahden välinen integrointi ei kuitenkaan riitä yleiseksi ratkaisuksi liiketoimintaprosessien hallintaan. Tarvitaan yleisempi ratkaisu, joka mahdollistaa liiketoimintaa osallistuvien kumppaneiden yhteistoiminnan joustavammin ja useiden toimijoiden kesken. Tämän dokumentin mallin tavoitteena on suorittaa integrointeja monesta-moneen-tyyppisesti (many-to-many) ja suoraan sovellusten kesken. Aluksi näkökulma oli bottom-up tarkastelu, jonka pohjalta tutkittiin integraatiota ja sen ongelmia. Tarkastelukulma tutki suunnittelumallien avulla E2-arkkitehtuurimallia. Tutkimuksen pohjalta syntyi Broker-arkkitehtuurimalliin pohjautuva arkkitehtuurikuvaus. Mallissa tutkittiin palvelupyyntöjen välitystä tavoitteena tehokas ja skaalautuva komponenttirakenne erilaisten sovellusten kesken. Mallin nimipalveluominaisuuksia suunnittelumallien avulla on tutkittu edelleen. Palvelupyyntö voi muodostaa monimutkaisen tuotantoketjun, jossa transaktiot on hallittava. Palvelupyynnön kulloinenkin käsittelytilanne ja sisältö on hallittava, kun palvelu toteutetaan eri toimijoiden kesken. Sanotaan, että on hallittava konteksti (context management). Tutkittiin myös kontekstinhallinnan ongelmankenttää hajautetussa verkkoympäristössä. Luotu arkkitehtuurikuvaus pyrkii yksinkertaisuuteen ja joustavuuteen. Liiketoimintaprosessit voivat olla monimutkaisia. Pyrittäessä automatisoituihin tuotantoprosesseihin on prosessiin kyettävä tuomaan mukaan joitakin tekoälyyn liittyviä piirteitä kuten yksinkertaista päättelyä (jos x niin y) ja toimintaskriptien toteutusta. Siksi avuksi tarvitaan ohjelmistoagentteja. Agentit ovat palveluohjelmistoja, joiden tarkoituksena on tutkia annettua tehtävää ja tehdä tarvittavia johtopäätöksiä. Agentilta vaaditaan jonkinlaista älykkyyttä, jotta se voisi suorittaa päättelyä (Autonomous Interface Agents, 1997). Selvitysten perusteella kävi ilmi, että bottom-up -lähestymistapa on liian rajoittunut. Jos näkökulma on pelkästään tekninen, on tuloksena integraatio, joka voi olla toiminnaltaan tehokas, mutta joustamaton, koska tarkastelutapa ei huomioi liiketoimintaympäristöä ja sen asettamia vaatimuksia liiketoiminnan kehittyessä. Lähtökohdaksi on otettava top-down -lähestymistapa, mikä mahdollistaa liiketoimintaprosessien huomioimisen integraatiovaatimuksia laadittaessa. Muita vaatimuksia ovat tekniikkariippumattomuus, skaalautuvuus, tehokkuus ja yksinkertaisuus. Top down lähestymistapa tarkoittaa sitä, että lähtökohtana on tuotantoprosessi, jonka kaikki osat (=toiminnot) nähdään palveluina. Palvelut koostuvat toisista palveluista muodostaen toimintaverkon, joka toteuttaa tuotantoprosessin. Tekniikkariippumattomuus merkitsee sitä, että tämän määrittelyn mukainen järjestelmä on toteutettavissa kaikilla olemassa olevilla väliohjelmistoalustoilla. Skaalautuvuutta (scalability) tarvitaan, jotta järjestelmä selviää nopeista palvelupyyntöjen määrän muutoksista. Järjestelmän tulee olla tehokas, joten teknologiaa on sovellettava siten, että välitysjärjestelmän aiheuttama tehokkuushäviö voidaan minimoida. Hajautettu tiedonvälitys lisää väistämättä monimutkaisuutta ja virheen syntymisen mahdollisuus kasvaa verrattuna monoliittiseen keskitettyyn järjestelmään. Järjestelmän on tarjottava virheenkäsittely. Järjestelmän osien tulee olla mahdollisimman 10 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15

11 standardeja ja yksinkertaisia, jotta järjestelmä toimii luotettavasti ja virheenjäljitys on mahdollisimman helppoa. Koska malli pohjautuu jo olemassa olevaan teknologiaan ja koettuihin käytäntöihin, on sen soveltaminen yritystasolla kohtuullinen tehtävä. Koska integroinnin lähtökohtana on prosessikeskeisyys, niin tehdyt integrointiratkaisut kestävät ja skaalautuvat paremmin yrityksen toimintojen kehittyessä ja muuttuessa. Sovellusten esittämä palvelupyyntö muutetaan rakenteiseksi dokumentiksi XML-koodattuna SOAP-sanomaan paketoituna, joka toimitetaan vastaanottajalle. Kuopion yliopistolla on tutkittu XRake-projektissa (XBI/XRAKE-projekti 2002) merkintätapoja ja menetelmiä heterogeenisten järjestelmien integroimiseen XML-rajapintoja käyttäen. Plugit-hankkeessa on tutkittu kontekstinhallintaa sekä eri järjestelmien välistä käyttäjän tunnistamista ja autentikointia. PlugIT:ssa on myös kehitetty suunnittelumenetelmä komponenttipohjaisten sovellusten kehittämiseksi. Tutkimusten tuloksia sovelletaan tässä mallissa soveltuvin osin. Sovellusten tarjoamat palvelut kuvataan verkkopalvelukuvauskielen (Web Service Description Language WSDL) avulla (Web Services Activity, 2004). 1.2 Ongelmat ja voimat Ongelmat Eri organisaatioilla on käytössään sekä organisaation sisällä että organisaatioiden välillä runsaasti erilaisia ohjelmistoja, joiden kyky yhteistoimintaan toisten ohjelmien kanssa on puutteellista. Ongelmana on kuinka tarjotut palvelut löydetään, tunnistetaan ja kuinka palveluiden semantiikka kyetään hallitsemaan. Lisäksi palvelua vailla olevan on kyettävä esittämään ja toimittamaan palvelupyyntö palvelua tarjoavalle sovellukselle ja päinvastoin. Lisäksi organisaatiot kehittyvät ja muuttuvat nopeasti ajan mukana. Palvelupyynnön toteuttaminen toteutetaan usein verkostoituneesti, jolloin tuotantoprosessista voi muodostua monimutkainen ketju, jossa kunkin osan keskinäiset suhteet ja toteutusjärjestys on hallittava. Tarvitaan koordinaatiota. Asiakkaan pyytämä palvelu voi koostua useista palvelupyynnöistä. Koordinaation avulla asiakkaalle voidaan taata hänen haluamansa palvelu. Koska palvelupyyntö koostuu erillisistä palvelupyynnöistä, joiden suoritukset voivat kokonaispalvelua koottaessa riippua toisistaan, tarvitaan transaktioiden hallintaa. Ongelmaksi muodostuu muodostuvan palvelukokonaisuuden transaktioiden hallinta. Koska palvelupyyntöjen toteuttaminen tuotannossa voi muodostaa pitkän tuotantoketjun, jolloin reaaliaikaisuuden vaatimusta ei voida toteuttaa, ei RPC-tyyliä voida käyttää prosessien toteuttamisessa. Lisäksi yhteistoiminnallisuuden toteuttaminen vaatii eri tiedostomuotojen ja tiedonsiirtotekniikoiden hallintaa kuten rakenteiset dokumentit, binääritiedostot, kokonaisina (block) tai tietovirtoina (stream) siirrettävät dokumentit. Eri vaatimusten toteuttaminen standardilla tavalla voi olla mahdotonta, jolloin joudutaan rakentamaan ongelman ratkaisemiseksi epästandardeja ratkaisuja kuten palvelupyynnön liitteenä toimitettavien binääritiedostojen kuten esimerkiksi kuvatiedostojen siirtämiseksi pyynnön mukana osapuolelta toiselle. Tämä voi tapahtua esimerkiksi http-protokollan mukaisesti MIME-koodattuna lohkoina (Alonso, 2004). Eri yritysten järjestelmien integroiminen on kallista, hankalaa ja hidasta. Yhteistoiminnallisuuden aikaansaaminen vaatii tiedolta formaalia esitysmuotoa. Jotta tietoa voitaisiin käyttää virheettömästi, on sen syntaksi kyettävä esittämään siten, ettei tiedon käsitteleminen aiheuta eri järjestelmissä virheitä (poikkeuksia). Tiedolla on myös merkitys. Tieto on kyettävä määrittelemään siten, että se merkitsee kaikille samaa ja vain samaa. Jo tiedosta sopiminen voi olla integraatiossa vaikeaa. Eräs ratkaisu tiedon ongelmaan ovat koodistot koodistopalvelimineen. Aluksi ajateltiin, että verkkopalveluiden avulla muodostetaan yleisiä kauppapaikkoja, jossa yritykset tarjoavat palveluitaan ja josta asiakkaat löytävät palvelut ja kauppaa käydään automaatti- SELVITYS 15 11

12 sesti verkkopalveluiden avulla. Siihen on vielä pitkä matka. Ongelmana on luottamus. Kuinka voidaan varmistua, että palveluntarjoajan identiteetti on se, miksi hän sen ilmoittaa, jottei tapahdu väärinkäytöksiä? Kuinka voidaan varmistaa tuntemattoman palveluntarjoajan tarjoaman palvelun laatu? Entäpä huomenna, onko palveluntarjoajaa olemassa? Yrityskumppaneiden on tunnettava toisensa, luotettava toiseen ja varsinkin, jos toisen palvelua käytetään osana omaa tuotetta, vaikuttaa huonon alihankkijan suorittama palvelu omaan yrityskuvaan. Verkottuminen tapahtuu suljetummin esimerkiksi siten, että yritykset, jotka tuntevat toisensa, muodostavat tuotantorenkaita. Tai yritys voi rakentaa oman tuotemerkin alihankkijoiden palveluiden avulla vastaten palvelun laadusta Monoliittisten arkkitehtuurien ongelmat Palveluarkitehtuurin näkökulmasta monoliittisuus tarkoittaa kerran (one time), yhteen tarkoitukseen (one purpose) ja yhdellä tavalla (one way). Useimmilla yrityksillä ei ole ohjelmistoja, jotka toteuttaisivat yritystason arkkitehtuurin (ESA) periaatteita. Yritykset kärsivät tästä ongelmasta monin tavoin. Usein yrityksellä on useita ohjelmistoja, jotka on kehitetty tai hankittu koordinoimatta niiden välistä yhteistoimintaa järjestelmällisesti. Seurauksena tästä on järjestämätön monimutkaisuus. Tässäkin tapauksessa automaation lisääminen onnistuu, se vain on kallista, hidasta ja lisää monimutkaisuutta entisestään. Monoliittisuuteen liittyvä tiukka sidonta (tight coupled) hidastaa kykyä muutoksiin. Tällöin yrityksen IT-osastosta tulee kehityksen jarru. IT-osasto suhtautuu kaikkeen kehitykseen negatiivisesti pyrkiessään välttämään työmäärän paisumista ( ei onnistu... ). Tämä hankaloittaa yrityksen liiketoimintastrategioiden suunnittelua ja toteutusta. Tarvitaan joustavuutta. Tiukka sidonta aiheuttaa sen, että johonkin ominaisuuteen vaadittu muutos voi vaikuttaa myös muihin tekijöihin. Esimerkiksi, jos CRM-järjestelmä käyttää toisen järjestelmän tietovarastoja. Tiukka sidonta merkitsee esimerkiksi sitä, että sen sijaan, että tietoja tarjoava sovellus tarjoaisi operaation avulla vastauksen tehtyyn kyselyyn (API-rajapinnan kautta), järjestelmän tietoja käytetäänkin sen tietokantaresurssin kautta. Mikäli tietokantaresurssiin tehdään muutoksia, on muutos huomioitava myös toisessa järjestelmässä. Mitä enemmän riippuvuuksia ohjelmistojen välillä on, sitä hankalammaksi ja kalliimmaksi muutoksiin vastaaminen ja ylläpito muodostuvat Voimat Palvelupyynnön esittäjän palvelupyyntö on välitettävä palveluntarjoajalle ja muunnettava palveluntarjoajan ymmärtämään muotoon. Sovellukset voivat toimia erilaisilla alustoilla. Sovellukset voivat olla perinnejärjestelmiä (legacy), joilla on erittäin vajavainen kyky yhteistoimintaan. Sovellusten välinen kommunikointi on kyettävä toteuttamaan joustavasti, tehokkaasti, turvallisesti ja skaalautuvasti. Asiakkaan tulee kyetä esittämään palvelupyyntö usealle sovellukselle (one-to-many) ja asiakkaan tulee kyetä saamaan vastaus monelta sovellukselta (many-to-one). Tarvitaan siis kykyä manyto-many tyyppiseen viestintään. Organisaatiot toimivat tiimeissä, joita on kyettävä muodostamaan dynaamisesti. Tämä tarkoittaa sitä, että muodostettaessa ryhmiä niiden käyttöoikeudet voidaan hallita oletusarvoisesti ryhmän organisatorisen aseman perusteella. Jotta tämä saavutettaisiin, on ohjelmistoilla oltava kyky mallintaa organisaatiota. Liiketoimintaprosessit voivat olla monimutkaisia. Prosessi voi sisältää vaatimuksia suoritusjärjestyksestä. Prosessin aiheuttamat poikkeukset on osattava käsitellä. Prosessin on kyettävä esittämään vaihtoehtoisia skenaariota siitä kuinka menetellä kussakin tilanteessa. Yritysten toiminta on dynaamista. Liiketoiminnan perusteet ovat aina samat. Kilpailukyky muodostuu siitä, kuka tuntee parhaiten asiakkaan tarpeet, tunnistaa oman liiketoimintansa vahvuudet ja heikkoudet ja pystyy tarjoamaan asiakkaalle parasta mahdollista palvelua kilpailukykyisesti. Jotta tämä onnistuu, tarvitaan joustavuutta. 12 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15

13 1.2.4 Tutkimuksen sisältö Tutkimuksen toisessa luvussa käydään lävitse verkkopalveluiden perusteita. Kolmannessa luvussa tutustutaan yritystason palveluarkkitehtuureihin. Luvussa korostetaan yrityksen siirtymäpolkua monoliittisistä sovelluksista yhteistyötä tekeviin komponenttipohjaisiin sovelluksiin. Yritystason sovellusten yhteistoiminnallisuus toteutetaan verkkopalveluarkkitehtuurien avulla. Eri tilanteissa tarvitaan erilaisia ratkaisuja. Yrityksen on kussakin tapauksessa mietittävä, mikä on sille parasta. Neljännessä luvussa esitellään dynaamisen integrointimallin teoreettinen perusta. Esitellään mallin perusarkkitehtuuri ja keskeisimmät hypoteesit. Liiketoimintaprosessin mallintamiseksi esitellään arkkitehtuurin määrittelyprosessi, jossa lähtökohtana ovat yrityksen liiketoimintaprosessit ja liiketoimintaentiteetit. Prosessit muodostavat palveluketjuja. Palvelukeskeisen arkkitehtuurin keskeisimpiä tehtäviä on prosessin mallintaminen. Viidennessä luvussa kuvataan dynaaminen arkkitehtuuri ja toimintaympäristö. Luvussa kuvataan komponentit, rajapinnat, koordinaationhallinnan ja transaktioiden perusteet. Luvussa kuusi sovelletaan dynaamista arkkitehtuuria terveydenhuollossa mallintamalla tuotantoprosessia palvelukomponenttien avulla. Kahden skenaarion avulla esitetään kuvitteellinen tilanne sekä perusterveydenhuollosta että erikoissairaanhoidosta. Viimeisessä luvussa luodaan yhteenveto ja arvioidaan tulevaa kehitystä. 1.3 Historiaa Tietojenkäsittelytehtävien historia voidaan jakaa kolmeen tai neljään jaksoon. 80-luvulle asti tietojenkäsittelytehtävät perustuivat eräajotyyppisiin järjestelmiin, jolloin ensin tallennettiin järjestelmään tarvittavat tiedot ja tallennuksen jälkeen suoritettiin tarkistusajo ja varsinainen tuotantoajo. Teknologian kehittymättömyys ja kalleus johti siihen, että tietojenkäsittelyä käytettiin yritysten prosessien hallinnassa pääasiassa hallinnollisissa tehtävissä esimerkiksi henkilöstöhallinnossa ja laskentatoimessa. Hallinnolliset tehtävät tarjosivat olemassa olevalle tietojenkäsittelymallille sopivia tehtäviä sisältäen lajittelu-, laskenta- ja tulostustehtäviä. Malli tarjosi mahdollisuuden palvelupohjaiseen tuotantoon, jossa tietojenkäsittelypalvelut ostettiin palveluoperaattorilta. Tällöin tallennusvaihe tehtiin usein itse, ja operaattori suorittu tarpeelliset tietokoneajot ja toimitti asiakkaalle asiakkaan tarvitsemat tulosteet. Käytetyintä tällainen ohjelmistopalvelu oli esimerkiksi palkanlaskennassa (palkka-ajot, tilipussit, maksatus) ja kirjanpidossa (kirjanpito, reskontrat, laskutus ja ulkoinen laskentatoimi). Teknologia kehittyi. Halvat PC-laitteet, minitietokoneet ja mikroverkot laajensivat tietokoneiden käyttöä ja loivat uusia käyttötapoja. Entistä tehokkaammat mikrotietokoneet tarjosivat käyttöliittymänsä kautta mahdollisuuden tehdä reaaliaikaisia kyselyjä, päivityksiä ja tulostuksia. Aiemmin päivitys- ja kyselytehtävät pystyttiin tekemään ainoastaan suurten yritysten tietojärjestelmissä. Tietojen ja tietojenkäsittelyn hallinta siirtyi palvelukeskuksilta yrityksille. Yritykset omistivat usein laitteensa ja ohjelmistonsa. Teknologia tarjosi aiempaa paremman palvelukyvyn, ja tietojenkäsittelyä voitiin soveltaa uusissa liiketoimintatehtävissä. Lopulta Internet ja sen globaali rakenne mahdollisti yritysten välisen tietojenvaihdon. Tyypillinen tälle ajalle ominainen yritysratkaisu oli usein se, että toimistopalvelut toimivat käyttäjien mikrotietokoneissa (fat client) ja yhteisiä palveluja olivat tiedosto- ja tulostuspalvelut (Sessions, 2000). Taloushallinto hoidettiin pääasiassa minitietokoneiden avulla, koska ohjelmistotoimittajat tarjosivat ohjelmistopalveluita omilla alustoillaan. Taloushallinnon ohjelmistot olivat luonteeltaan monoliittisia ja niiden integrointi mikroverkkoihin oli vaikeaa. 90-luvun lopulla tietojenkäsittely oli osa jokaisen yrityksen arkea, se oli jokaisella työpöydällä. Tiedon ja tiedonkäsittelyn hallinta johti siihen, että tietojenkäsittelytehtävät suoritettiin hajautetusti verkossa. Ongelmaksi muodostui vaatimus ohjelmistojen yhteistoiminnallisuudesta, ylläpidettävyydestä ja järjestelmien hallinnasta. Pyrittiin vähentämään käyttäjän työpöytäkerroksen tehtäviä (workspace tier). Asiakaskerroksen tehtäviä siirrettiin sovellustason kerrokselle (thin- SELVITYS 15 13

14 client). Tavoitteena oli, että työpöytäkerros hallitsee sovellusten esittämisen (käyttöliittymän) ja varsinaiset työtehtävät keskitetään sovelluspalvelimille, jotka käyttävät tiedonhallintaan siihen erikoistuneita tietokantapalvelimia. Siirryttiin komponenttipohjaiseen ajatteluun (component-oriented approach), mikä tarkoittaa sovellusten jakamista osiin siten, että näitä osia voidaan uudelleenkäyttää (Reuse) maksimaalisesti. Pian havaittiin, että ohjelmistojen kyky yhteistoimintaan (interoperability) oli puutteellista. Internetistä oli jo muodostunut globaali kaikkialle ulottuvat tietoverkko. Tämän vuoksi ryhdyttiin kehittämään tekniikoita kuten ebxml liiketoimintojen dokumenttien vaihtoa varten (Top-down dokumenttipohjainen lähestymistapa) ja verkkopalveluarkkitehtuuri (Web Service Architecture WSA) ohjelmistojen operaatioiden hallintaan (bottom-up prosessipohjainen lähestymistapa), joiden avulla tietoverkon kautta voitiin vaihtaa palvelupyyntöjä tai dokumentteja yritysten välillä. Syntyivät verkkopalvelut (Web services). Jo hajautuksen käyttöönotto 90-luvulla loi monimutkaisen ohjelmistoinfrastruktuurin. Verkkopalvelutekniikoiden käyttöönotto lisää edelleen monimutkaisuutta. Tämän vuoksi markkinoille on syntynyt tarvetta ja kysyntää palveluista. Vanha palvelukeskusajattelu uudessa muodossa on muodostumassa houkuttelevaksi ja kilpailukykyiseksi ratkaisuksi. Asiakas ostaa palveluita ja maksaa palveluista käytön mukaan. Ulkoistamalla osan toimintoja palveluiden avulla, yritys voi keskittyä ydintoimintoihinsa. Palvelutarjoaja voi erikoistua palvelutuotantoon ja tarjota asiakkailleen parasta mahdollista palvelua. Palveluntarjoaja voi ostaa osan palveluita toisilta palveluntarjoajilta ja niin edelleen. Palvelukeskeinen lähestymistapa (service-oriented approach) tuottaa yritysten kesken monipuolisia verkostoja, joissa toiminnan tehokkuus saavutetaan erikoistumalla. Ohjelmistot kykenevät automaattiseen yhteistoimintaan verkkopalveluiden avulla. Verkkopalveluiden avulla palvelujen rakenne ja semantiikka kuvataan, palvelut löydetään ja palveluja kutsutaan. Yritykset voivat luoda yhteistoimintaverkostoja ja sovittaa tietojärjestelmänsä yhteen siten, että voidaan luoda palvelukokonaisuuksia. Yhteistoiminta ratkaistaan palvelukeskeisen arkkitehtuurin avulla (SOA Service-oriented Architecture). Palveluoperaattori saa tulonsa myymästään palvelusta. Asiakas liittää omat tietojärjestelmänsä palveluun ja palveluoperaattori kokoaa oman palvelunsa muista palveluista. Markkinoilla on tarvetta palveluintegraattorista (service integrator), joka liittää eri palvelut toisiinsa ja luo rajapinnan asiakkaan ja palvelun välille. Palvelukeskeinen toimintamalli muuttaa ohjelmistoliiketoiminnan ansaintalogiikkaa. Ohjelmistoyrityksen on kyettävä hyödyntämään palveluliiketoiminnan antamat mahdollisuudet ja parantamaan tuotteidensa ominaisuuksia siten, että niillä on tarvittava yhteistoiminnallisuus verkkopalveluympäristössä. 14 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15

15 2 K O N T E K S T I 2.1 Yleistä Tässä luvussa esitellään perusteet ja määrittelyä palvelupohjaisen arkkitehtuurin ymmärtämiseksi. Palvelut nähdään yritysten liiketoimintaprosessien toteuttajina. Liiketoimintasovellusten konteksti palvelukeskeisessä arkkitehtuurissa pohjautuu yhteisiin sopimuksiin, määrittelyihin ja standardeihin. Ohjelmistot toimivat hajallaan verkossa. Ohjelmat ovat yhteistoiminnassa toistensa kanssa pyytäen ja tarjoten palveluita. Palvelupyyntöjä esitetään myös eri organisaatioiden välillä. Organisaatiot toimivat joustavasti ja muodostavat erilaisia tiimejä hankkeiden toteuttamiseksi (Taulukko 1). Taulukko 1: Tavoitteita ohjelmistojen välisessä integraatiossa Yrityssovellusten integraatiotavoitteita (Goals for modelling enterprise integration) Sovellusten välinen yhteistoiminnallisuus (interoperability between applications) Dynaaminen käyttäytyminen (dynamic behaviour) Tekninen riippumattomuus ja läpinäkyvyys (technical independency, transparency) Aikainen suunnittelu, myöhäinen sidonta = uudelleenkäytettävyys (aarly design + late binding = software reuse Turvallisuus, luotettavuus, jäljitettävyys (security, reliability, traceability) Asiakas esittää palveluoperaattorille palvelupyynnön. Asiakas ei tiedä kuinka palvelu rakennetaan, asiakkaalle riittää tieto eli kuvaus siitä, millaisen palvelun hän saa sitä pyydettyään. Palveluoperaattori koostaa asiakkaalle sopivan palvelun. Palvelu voi koostua muiden palveluntarjoajien palveluista. Palvelut kommunikoivat keskenään käyttäen välittäjää (Broker), joka integroi palvelut toisiinsa. Palveluintegraatio voidaan tarjota ulkopuolisena palveluna tai yritykset voivat verkostoitua ja rakentaa tarvitsemansa integraatiopalvelun (Kuva 1). Client Service1 Service Service2 ServiceN Kuva 1: Asiakas esittää palvelupyynnön Jotta palvelupyyntöjen käsittelyssä saavutetaan riittävä skaalautuvuus (scalability), tulisi kommunikaation olla asynkronista (asynchronous). Komponenttien tulisi olla tilattomia (stateless). Komponentit saavat tarvittavat tilatiedot taustalla olevalta tietokannalta (back-end data-base). Ti- SELVITYS 15 15

16 lattomuus mahdollistaa tehokkaan instanssien hallinnan (instance management), koska ei tarvitse pitää kirjaa siitä, monellako asiakkaalla on viite instanssiin. Jokaiselle asiakkaalle tarjotaan oma istunnon aikainen instanssi. Instanssien hallinta voidaan hoitaa joko alustamalla instanssi tarvittaessa (JIT just-in-time) tai käyttäen instanssipoolia (instance pooling algorithm). Toinen mahdollisuus on käyttää tilallista instanssia, jonka useat asiakkaat jakavat (shared instances) (Sessions, 2000). Tilattomuuden tavoitteesta voidaan poiketa, jos (Sessions, 2000): - Komponentin instanssilla voi olla tila, jos tila ei kohdistu tiettyyn asiakaskomponenttiin. - Olioiden ilmentymillä (object instance) voi olla tila, mutta ei komponentin ilmentymällä (component instance). - Tarvittaessa komponenttiin voidaan laittaa tila. Tällöin komponenttia ei voi hallita instanssienhallinta-algoritmien avulla. Tässä tapauksessa instanssi varataan yhden proxyn käyttöön. Tätä kutsutaan keskustelevaksi moodiksi (conversational mode). Komponentin alustana toimivalta sovelluspalvelimelta ja siinä toimivalta komponentilta vaaditaan ominaisuuksia (Sessions, 2000): - Tilatiedot eivät ole instanssissa, koska instanssienhallinta voidaan suorittaa tehokkaasti instanssienhallinta-algoritmien avulla. Samoin säikeidenhallinta voidaan hoitaa automaattisesti instanssienhallinta-algoritmien avulla. - Voidaan hyödyntää kuormituksentasausalgoritmeja (load balancing algoritms). - Käytetään resurssipooleja (resource pooling). - Sidotaan metodit transaktioihin (transactional boundary). Transaktioiden hallinta kuuluu väliohjelmistolle (middletier)-ohjelmistolle. - Turvallisuus (safety) on mukana komponenttiprosessissa. Tietoturva (security) kuuluu väliohjelmistolle. 2.2 Palvelukeskeinen arkkitehtuuri Palvelukeskeinen arkkitehtuuri (SOA Service-oriented architecture) määrittelee arkkitehtuuriset periaatteet itsenäisten systeemien yhteistoiminnan toteuttamiseksi. Systeemien autonomisuus (Autonomy) tarkoittaa niiden erillisyyttä, kykyä toimi itsenäisesti ja kykyä itse määritellä tarjoamansa toiminnallisuuden. Yhteistoiminnallisuus (interoperate) tarkoittaa kykyä toimia yhteistoiminnassa (ObjectWatch Newsletter Number 45). Palvelukeskeisen arkkitehtuuri pohjautuu seuraaviin periaatteisiin (ObjectWatch Newsletter Number 45 ): - Asynkroninen kommunikaatio sovellusten ja järjestelmien välillä. - Kyky käyttää heterogeenisia kommunikaatiokanavia eli erilaisten järjestelmien on kyettävä yhteistoimintaan. - Tietoturvallisuustekijöiden huomioonottaminen eli tunnistaminen (identifiointi) ja varmentaminen (verifiointi ja sertifiointi) sekä kyky kommunikaation salaukseen. Osapuolet todistavat (Proof) identiteettinsä toiselle osapuolelle. - Virheidenhallinta palveluketjussa (error management across the systems matrix). - Koska kommunikointi on asynkronista, tarvitaan työnkulun koordinaatiota (workflow coordination), jotta voidaan seurata palvelupyynnön käsittelytilannetta. Synkronisessa kommunikaatiossa samaa tarvetta ei ole, koska palvelupyyntö käsitellään välittömästi. 16 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15

17 2.3 Verkkopalvelut (Web-services) Palvelukeskeisen arkkitehtuurin kommunikaatiokanava toteutetaan verkkopalvelujen (Webservices) avulla. Tällöin tietojenkäsittely on palveluorientoitunutta (SOA Service-oriented Computing) (Standards for Service-Oriented Architecture, 2004). Verkkopalvelut voidaan nähdä yhteisenä kommunikointikanavana, jossa sovitaan yhteinen tiedon esitysmuoto (syntaksi ja semantiikka) ja vaihdetaan informaatiota organisaatioiden välillä. Verkkopalveluiden autonomisuus mahdollistaa hyvinkin erilaisten sovellusten integroinnin, kuten esimerkiksi graafisten kuvantamisohjelmien ja tietokantapohjaisten sovellusten yhteistoiminnan. Menetelmän vahvuutena on se, että itse integraation tekninen toteutus ei rajoita verkottumista, vaan on mahdollista suorittaa aidosti integraatiota prosessikeskeisesti esimerkiksi mallintamalla liiketoimintaprosessia ja liiketoimintaentiteettejä ja yhdistelemällä entiteettejä ja operaatioita palvelukomponenttien avulla luoden tarvittavan yhteistoiminnallisuuden. Verkkopalveluarkkitehtuuri perustuu kerrosarkkitehtuuriin, jolloin pinoon liitetään yhä uusia abstraktioita. Usein joustavuuden lisäys johtaa suorituskyvyn (performance) laskuun. Eli yhteistoiminnallisuudesta joudutaan maksamaan. Kuvassa 2 on esitetty sovellusten välinen löyhä kytkentä (loose-coupled) käyttäen verkkopalvelutekniikoita. Browser HTML Application Presentation logic XML +WS-* Other applications Business services Application Business services SQL RDBMS WM (Java,C#) Hardware (OS) Kuva 2: Verkkopalvelut ja sovellusten kommunikaatio (Standards for Service-Oriented Architecture, 2004) Verkkopalvelut toimivat kommunikaatiokanavana ja ne voidaan kuvata protokollapinon (Web service stack) avulla. Protokollapino toimitetaan vastaanottajalle kulloinkin soveltuvaa kommunikaatiokanavaa pitkin. Kuvassa 3 verkkopalvelupino muodostuu jakamalla palvelu abstraktiotason mukaisesti. Liiketoimintaprosessi alkaa ylimmältä tasolta (service negotiation), jossa sovitaan verkkopalveluissa käytettävistä protokollista, viitataan prosessinmäärittelydokumenttiin, työnkulkuun, transaktioihin ja prosessinkulkuun. Seuraavalla tasolla (workflow, discovery, registries) määritellään työnkulku jollain työnkulun kuvaamiseen soveltuvalla XML-pohjaisella kuvausnotaatiolla (esim. WSFL, BPEL4WS). Tällä tasolla ovat määrittelyt palveluiden julkaisemiseksi ja löytämiseksi (UDDI, ebxml Registry). Seuraavalla tasolla (Service description language) on palveluiden SELVITYS 15 17

18 kuvausdokumentti (WSDL, WSCL). Viestitasolla (Messaging) kuvataan viesti rakenteisen SOAPdokumentin avulla. Kaikki liikenne kuljetaan lähettäjältä vastaanottajalle SOAP-sanomassa. Jotta sanoma voitaisiin siirtää teknisiä siirtoteitä pitkin vastaanottajalle, on sovittava siirtoyhteydessä käytettävästä protokollasta. Protokollina voidaan käyttää kaikkia soveltuvia protokollia kuten esimerkiksi HTTP, HTTPS, FTP, IIOP, RMI ja SMTP. Käytännössä vain HTTP, HTTPS ovat suosteltavia protokollia, koska eri järjestelmien palomuurit hankaloittavat muiden protokollien (porttien) käyttöä. Alimpana ovat liiketoimintanäkökohdat (business issues). Tässä kerroksessa sovitaan kaikki liiketoimintaan liittyvät asiat kuten standardit, palvelun laatukysymykset sekä palveluiden järjestämiseen ja organisointiin liittyvät kysymykset. Nämä päätökset ovat lähtökohtana verkkopalvelun toteuttamisessa (Web Service Architectures, 2002). Kuva 3: Verkkopalveluprotokollapino (Web Service Architectures, 2002) Bottom-up ja top-down Palvelupyynnön ja vastauksen rakentamiseksi tarvitaan yhteistoimintaa varten useita näkökulmia. Horisontaalinen näkökulma lähtee siitä, että pyritään kehittämään menettelyjä, jotka ovat yleisiä riippumattomia liiketoiminnan erityispiirteistä. Ajatuksena on, että määrittelyt soveltuvat kaikille sellaisenaan. Tämä lähestymistapa keskittyy bottom-up tyylisesti teknisistä lähtökohdista lähtien yhteistoiminnallisuuden suunnitteluun. Esimerkiksi ensiksi määritellään asiakkaan toiminta-alusta (käyttöjärjestelmä, väliohjelmistot) ja yhteistoimintakanavat. Sen jälkeen tutkitaan olemassa olevat resurssit ja niiden tarjoama toiminnallisuus. Sen jälkeen kääritään olemassa olevat resurssit ja integroidaan niiden tarjoama toiminnallisuus yhtenäisen rajapinnan taakse. Lopuksi mukautetaan sovelluslogiikan syötteet siten, että sovellusta voidaan käyttää asiakkaan käyttämän protokollan avulla käyttäen soveltuvia kanavia. Tätä lähestymistapaa joudutaan käyttämään silloin, kun integroidaan jo olemassa olevia järjestelmiä toisiinsa (Alonso ym., 2004). Uutta järjestelmää suunniteltaessa luonteva lähestymistapa on top-down tyyli. Ongelmakenttää tarkastellaan kokonaisuutena ja määritellään toiminnallisuutta jakaen ongelmakenttä pienempiin osiin. On tutkittava myös, mitkä kerrokset eli esitys, sovelluslogiikka tai resurssikerros (presentation tier, application logic tier, resource management tier) on tarpeen toteuttaa hajautettuna. Tällä periaatteella suunniteltu uusi järjestelmä toteuttaa yleensä yhtä järjestelmäarkkitehtuuria, josta johtuen sen osien (komponenttien) välille muodostuu yleensä tiukka sidonta (tight coupling). Tämä tarkoittaa sitä, että komponenttien välillä on riippuvuuksia, jolloin muutos yhdessä komponentissa voi johtaa muutokseen toisessa komponentissa, jos rajapinnat muuttuvat. 18 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15

19 2.3.2 Etäproseduurikutsu (RPC Remote pr osedure call) - ja viestipohjainen (Message-oriented middleware MOM) -tyyli Verkkopalvelujen perustyyli on etäproseduurikutsujen käyttö (RPC-tyyli), jolloin asiakas on vailla palvelua ja pyytää palveluntuottajalta palvelua ja jää odottamaan vastausta. Vastaus kyselyyn saapuu sovitun ajan puitteissa tai käsittely päättyy poikkeukseen (esim. timeout). RPC-tyyli ei kuitenkaan sovellu pitkäkestoisten palvelupyyntöjen toteuttamiseen, vaan tällöin joudutaan yhteistoiminta rakentamaan viestipohjaisesti (message-oriented). Viestipohjaisuus tarkoittaa sitä, että asiakas lähettää palvelupyynnön omaan lähtevään työjonoonsa, josta se aikanaan siirtyy palveluntarjoajan saapuneitten pyyntöjen työjonoon odottamaan käsittelyä. Verkkopalvelumääritelmät pyrkivät kuvaavamaan yhteistoimintaa horisontaalisesti, mikä tarkoittaa sitä, että ne ovat toteutettavissa alasta ja sovelluksesta riippumatta. Alakohtaiset erityispiirteet kuten koodistot, esitysmuoto ja dokumenttimallit on sovittava erikseen (Alonso ym., 2004) Web Services (WS) -verkkopalvelumäärittely Verkkopalvelut pohjautuvat rakenteisiin dokumentteihin. Palvelupyyntö kuljetetaan SOAPsanomassa osapuolelta toiselle. Sanoma sisältää liiketoiminnan palvelupyynnön (operaatio parametreineen tai dokumentti). Omana kerroksenaan on huomioitava tietoturva, luotettavuus, koordinointi ja transaktioidenhallinta. Sanoman rakentamiseksi voidaan käyttää esimerkiksi dokumenttipohjaista OASIS:ksen ebxml-arkkitehtuuria (ebxml, 2004), (kts. Liite 2) tai IBM:n ja kumppaneiden kehittämää prosessilähtöistä verkkopalveluarkkitehtuuria (Service Oriented Architectures and Web Services, 2004). Prosessikeskeisyys tarkoittaa tässä sitä, liiketoimintaa tarkastellaan matalantason operaatikutsuina ja näiden kutsujen parametreina. Lähtökohta keskittyy liiketoimintaprosessin kuvaamiseen ja toteuttamiseen toimijaverkossa (Alonso ym., 2004). Verkkopalvelut määritellään standardisoituna tapana integroida web-perustaisia sovelluksia käyttäen XML, SOAP, WSDL ja UDDI-standardeja. Nämä standardit ovat avoimia, joten niistä ei tarvitse suorittaa lisenssimaksuja. Sen sijaan lisäpalvelut kuten WS-Security, WS-Reliable Messaging, WS-Transactions, WS-Trust määrittelyt eivät ole avoimia määritelmiä ja ovat siten riskejä integraation rakentajalle (Alonso ym., 2004). Palvelupyynnön välittämiseksi ja automatisoimiseksi tarvitaan (Ferris ym., 2003): - Palvelun löytäminen rekisterin "puhelinluettelon" avulla. Esimerkiksi UDDI (Version 3) on OASIS:n määrittely (UDDI.org, 2004). - Palvelun ominaisuuksien kuvaaminen rakenteisen dokumentin avulla. W3C:n suositukset kattavat SOAP:n (Version 1.2) ja WSDL:n (version 2.0 working draft) (Web Service Activity Statement, 2002). - Liiketoimintaprosessit toteutetaan palveluiden avulla. Palveluketjun hallintaan tarvitaan prosessinhallintavälineitä. Palvelukokonaisuuden toteuttamiseksi palvelujen toteuttamisketju siis se, missä järjestyksessä palvelut toteutetaan, on kuvattava standardilla tavalla. Palveluketjun kuvaaminen voidaan tehdä esimerkiksi BPEL kielellä (BPEL4WS Business Process Execution Language for Web Services) (BPEL4WS Specs. 1.1, 2003). - Palvelun semantiikan kuvaaminen automatisointia varten (semanttinen web) (McIlraith ym., 2003), - Tietoturva, luotettavuus, transaktioiden hallinta, palveluiden koordinaatio, luottamus toteutetaan käyttäen komponenttipohjaisia väliohjelmistoja. Sovelluspalvelinten välistä yhteistoimintaa varten on laadittu määrittelyjä kuten esimerkiksi WS-security, WS-reliable messaging,. Web-service coordination,ws-transactions, WS-trust. - Verkkopalvelujen luotettavuus (WS-reliable messaging) merkitsee, että taataan toimituksen perillemeno ja että viesti menee ainoastaan kerran (ei duplikaatteja). Malli käyttää consu- SELVITYS 15 19

20 mer/producer suunnittelumallia, jos palvelun laatu (quality of service) on omana kerroksenaan. Viestin luotettavuus voidaan varmistaa joko request/response, callback tai poll menettelyillä (Alonso ym., 2004). - Verkkopalvelujen koordinaatio (WS-coordination) on kehys, joka koostuu aktivointipalvelusta, rekisteröintipalvelusta sekä joukosta koordinaatioon liittyvistä koordinaatioprotokollista. Koordinaation avulla voidaan hallita hajautettujen sovellusten operaatioiden toteutusta, voidaan luoda konteksti ja julkaista toiminto toisissa palveluissa ja suorittaa koordinaatioprotokollan rekisteröinti. Kehys mahdollistaa transaktioiden prosessoinnin, työnkulun hallinnan sekä muiden järjestelmien toimintojen koordinoinnin heterogeenisessa ympäristössä (WS-coordination, 2003). - Verkkopalvelujen turvallisuus (WS-security) takaa sovellusten turvallisen viestienvaihdon, jossa sovellusten kesken voidaan vaihtaa mm. käyttäjätunnuksia ja salasanoja (WS-security, 2002). Verkkopalvelujen luottamus (WS-trust) auttaa osapuolia vaihtamaan valtuutustietoja (credentials) (WS-trust, 2004). Sun ja joukko muita yrityksiä ovat alkaneet laatia omaa verkkopalvelustandardia (Web Services Composite Application WS-CAF) suositusta, jonka avulla on tarkoituksena mahdollistaa komposiittisovellusten (composite application) rakentaminen. Suositus koostuu kolmesta määritelmästä (WS-CAF Announcement, 2004): - Kontekstinhallinta (Web service context WS-CTX), joka yksinkertainen kehys kontekstinhallintaan, jonka avulla osallistuja voivat jakaa saman kontekstin ja vaihtaa informaatiota. - Koordinaationhallinta (Web service coordination framework WS-CF) määrittelee ohjelmistoagentin ominaisuudet kontekstinhallitsemiseksi. Koordinaattori varmistaa, että viestit ja tulokset kommunikoivat asianmukaisesti niin, että jonkin palvelun toteutuminen tai virhetoiminto voidaan sitoa osaksi suurempaa kokonaisuutta ja luoda siten verkkopalvelukokonaisuuksia. - Transaktionhallinta (Web services transaction management WS-TXM) määrittelee transaktioprotokollat, jotka voidaan liittää (plugged) koordinaatiokehykseen ja luoda yhteistoimintaa transaktiomanagereiden, pitkäkestoisten tapahtumien ja asynkronisten liiketoimintaprosessien kesken. Sen tarkoituksena on olla siltana erilaisten transaktionhallintamallien välillä kuten esimerkiksi MQ Series:n ja JMS:n välillä. Kuvassa 4 on esitetty IBM:n verkkopalveluiden pino (Web Services Stack). Kuva 4: Verkkopalvelupino (Curbera ym., 2003) 20 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15