hyväksymispäivä arvosana arvostelija Palvelukeskeinen arkkitehtuuri liiketoimintanäkökulmasta Jukka Ruotsalainen Helsinki 30.11.07 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Väliohjelmistot Lea Kutvonen/Toni Ruokolainen
HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty/Section Tietojenkäsittelytieteen laitos Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Jukka Ruotsalainen Työn nimi Arbetets titel Title Palvelukeskeinen arkkitehtuuri liiketoimintanäkökulmasta Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year 30.11.2007 Essee Tiivistelmä Referat Abstract Kurssiin kuuluva essee palvelukeskeisistä arkkitehtuureista. Sivumäärä Sidoantal Number of pages 17 Avainsanat Nyckelord Keywords Tietojenkäsittelytiede, soa, palvelu, liiketoimintanäkökulma, malli Säilytyspaikka Förvaringställe Where deposited Muita tietoja Övriga uppgifter Additional information
Sisältö 1 Johdanto...1 2 SOA:n lyhyt historia...2 2.1 Mikä on SOA...3 2.2 SOA:n ratkaisemat haasteet...4 2.2.1 Kokonaisarkkitehtuurin hallinta...4 2.2.2 Ohjelmistologiikan ja liiketoimintalogiikan erottaminen...5 2.2.3 Nopeampaa sovelluskehityst...5 2.2.4 Sijaintiriippumattomuus...5 2.2.5 Tehokas kapselointi...6 2.2.6 Muutoksenhallinta...6 2.2.7 Tehokas uudelleenkäyttö...6 2.2.8 Löysät sidokset...6 2.2.9 Tietotekniikan selkeämpi hyöty liiketoiminnalle...7 2.2.10 Nopeammat muutokset palveluissa...7 2.2.11 Standardisointi, oma universumi...7 2.2.12 Selkeämmät ohjelmointimenetelmät...7 2.2.13 Joustavampi testaus...8 2.2.14 Järjestelmäriippumaton...8 2.2.15 Ei sovellu kaikkeen...8 3 Kritiikki...9 3.1 Ohjelmisto, joka käyttää web palveluita (web services) on palvelu keskeinen...9 3.2 SOA on vain markkinointitermi web -palveluille...9 3.3 SOA on vain markkinointitermi hajautetulle web -palveluille...9 3.4 Jos ymmärrät web-palveluita, ei sinulla ole ongelmia rakentaa SOA-pohjaisia järjestelmiä..10 3.5 Kun siirrytään SOA:n kaikki järjestelmät alkavat toimimaan yhdessä...10 4 Johtopäätökset...11 5 Lähteet...12 ii
1 1 Johdanto Tämä essee on kirjoitettu syksyn 2007 kurssille Väliohjelmistot. Essee käsittelee väliohjelmistoja erityisesti liiketoimintanäkökulmasta. Väliohjelmistot ja etenkin SOA (Service Oriented Architecture ovat nyt kaikkien huulilla ja niihin perustuvia ratkaisuja toteutetaan kiihtyvällä vauhdilla IBM, HP, BEA, Ocarcle, SAP etunenässä [SOA07]. Perinteisesti tietotekniikan ja liiketoiminnan välinen suhde on on jäänyt ohueksi. Tietotekniikan liiketoimintafunktiota ja merkitystä liiketoiminnalle ymmärretään harvoin, se nähdäänkin usein vain välttämättömyytenä, kulueränä; harvoin liiketoiminnan mahdollistajana ja edellytyksenä. Vaikka palveluorientoituneista järjestelmistä (Soa, Service Oriented Architecture, Palvelukeskeiset arkkitehtuurit) puhutaan jo lähes hypeksi asti on tässä arkkitehtuurissa merkittävä ajatuksellinen ero verrattuna perinteisiin arkkitehtuureihin. Perinteisesti tietotekniset projektit ja järjestelmät ovat olleet hitaasti toteutettavia ja kalliita. Osaratkaisuna on nähty täysin valmiit ohjelmistot, näissä ongelmana on vain se, että ne harvoin palvelevat yrityksen liiketoimintaa täysimääräisesti, vaikka niillä kyetäänkin usein tuottamaan yrityksen tarvitsemat palvelut ja toiminnot, näiden tuottaminen tapahtuu vain tehottomasti. Yritysostot ja tiivistyvä yhteistyö pitää yritykset jatkuvassa muutoksessa [ELA07] ja koska liiketoiminta on jatkuvasti yhä sähköisempää ovat yritykset käytännössä täysin riippuvaisia tietojärjestelmistään, tämän voi jokainen todeta omin silmin työpaikallaan liiketoiminta-alasta riippumatta. SOA arkkitehtuurin suurimpana erona verrattuna muihin arkkitehtuureihin on on tarkastelu liiketoiminnan kannalta. Tässä arkkitehtuurissa tietojärjestelmät nähdään tuottamassa palveluita muihin järjestelmiin (toisilleen) ja järjestelmät voivat myös käyttää muiden järjestelmien tuottamia palveluita tuottaakseen taas uusia palveluita. Järjestelmät sidotaan toisiinsa hyvin löysästi ja ympäristöriippumattomasti esimerkiksi. XML-pohjaisilla sanomilla. Liiketoimintanäkökulmasta katsottuna SOA lisää myös kilpailua, sillä ohjelmistoprojektit voidaan kilpailuttaa palveluina ja tietojärjestelmältä vaadittavat ominaisuudet voidaan määrittää hyvinkin täsmällisesti. Lisäksi liiketoimintanäkökulmasta katsottuna tietojärjestelmälle tukee olemassaolon oikeutus, sillä se liittyy suoraan harjoitettavan liiketoiminnan prosesseihin, itseasiassa se mahdollistaa kyseisen prosessin. Tämä essee pyrkii valottamaan SOA:n synnyn ja kehittyneet ominaisuudet, sillä kuten tavallista uudet tarpeet ovat syntyneet siitä että jotain uutta on tarvittu ja joku vanha ei ole sitä tarjonnut, eikä SOA syntynyt sattumalta.
2 2 SOA:n lyhyt historia Ohjelmistokehityksessä voidaan havaita selviä trendejä ja muotiaaltoja. Viimeisen 15 vuoden aikana kehitys on ollut melko selvää. Ohjelmointikieliä ja menetelmiä on kehitetty siten, että ohjelmistojen monimutkaisuus ja toiminnallisuus voitaisiin piilottaa eli kapseloida käyttäjältä/ohjelmoijalta. Ohjelmointikielet ja niiden kehitys on ollut hyvin teknologialähtöistä, ne eivät ole ollut asiakasyritysten kehittämiä. 90 -luvulla kehitetyt oliopohjaiset kielet kuten Java ja c++ ratkaisivat monta ongelmaa ohjelmoijan näkökulmasta. Esimerkiksi Java tarjosi kattavat valmisfunktiot ja mahdollisti ohjelmiston rakenteen mallintamista ennen varsinaista ohjelmointia esim. UML työkaluilla [ELA07]. Yritysten näkökulmasta syntyi taas uusi edellisten järjestelmien kanssa yhteensopimaton arkkitehtuuri, eikä esim. java tarjonnut prosessien ja tapahtumien mallintamista. Sama trendi näkyy myös esim. ohjelmistojen käyttöliittymäsuunnittelussa. Ohjelmistoihin rakennetaan ominaisuuksia mutta ketään ei tunnu kiinnostavan tukevatko ominaisuudet käyttäjän todellisia tavoitteita tai päämääriä. Hyvänä esimerkkinä voidaan pitää tällä kertaa nimeltä mainitsematonta yritysten asiakkuudenhallintasovellusta. Ohjelmisto on hidas ja toimii vain tietyllä selainversiolla, lisäksi käyttäjä ei voi helposti suodattaa vain häntä koskevaa informaatiota tai esim. nähdä mikä informaatio on uutta ja mihin hänen pitäisi keskittyä. Java mahdollisti komponenttien uudelleenkäytön, mutta siitä ei ollut paljon hyötyä, sillä uudelleenkäyttö oli mahdollista vain toisissa Java sovelluksissa ja lisäksi meillä saattoi olla 30 komponettia, jotka tekivät saman asian, mutta niiden toteutustapa ja yhteensovittaminen oli lähes mahdotonta. [ELA07].Ei olut myöskään tapaa tiedottaa uusista komponenteista. SOA:n historian voidaan katsoa alkaneen vuonna 1996 kun Garter -tukimusyhtiön tutkija Yefim V natis. Kirjoitti SOA is a software architecture that starts with an interface definition and builds the entire application topology as a topology of interfaces, interface implementations and interface calls ". Vuonna 2000 W3C sai hyväksyttttäväksi SOAP määritelmän joka määrittää SOA:n xml sanomien rakenteen (tuolloin web services). Ohjelmistoteollisuus ymmärsi hyvin nopeasti avoimen mitä tahansa dataa välittävän viestinvälitysmuodon merkityksen. Tarkemmin ajateltuna SOA on ollut looginen askel, sillä SOA järjestelmät ja niiden perusarkkitehtuuri on pitkän teknologisen kehityksen tulos. Kukapa olisi uskonut vielä 15 vuotta
3 sitten että Internet mahdollistaa tulevaisuudessa rajattoman tiedonvaihdon kenen kanssa tahansa ajasta ja paikasta riippumatta. Yritysten maa/osastokohtaiset sovelluksilta ei mitenkään voitu osata vaatia/olettaa tuonkaltaista valmiutta tai toiminnallisuutta. Omalla tavallaan SOA on siis aikansa lapsi. 2.1 Mikä on SOA Palveluorientoituneita järjestelmiä voidaan katsoa ainakin kahdesta eri näkökulmasta. Teknologisesta näkökulmasta SOA -järjestelmät ovat sellainen lähestymistapa ohjelmistokehitykseen, jossa palvelut tarjoavat uudelleenkäytettävää toiminnallisuutta hyvin ja täsmällisesti määritellyillä rajapinnoilla. SOA tarjoaa lisäksi hakemistopalvelun ja menetelmät siihen kuinka palvelut voidaan löytää ja paikallistaa ohjelmiston suoritusaikana [KKL07]. Liiketoiminnallisesta näkökulmasta katsottuna SOA -järjestelmät ovat systemaattinen tapa saattaa organisaation sisäisessä käytössä olevia vanhoja monoliittisia järjestelmiä käyttöön yrityksen ulkopuolisille toimijoille, sekä yrityksen uu- Kuva 1: SOA:sta on moneksi ja se voidaan nähdä siin järjestelmiin [KKLO7]. Yritysten järjestelmiin usealla eri tavalla on vuosin saatossa kerääntynyt valtavat tietovarastot erilaista dataa ja tähän dataan pitäisi päästä käsiksi. Laki ja asiakkaat vaativat lisää palveluita, esimerkkinä vaikkapa pankkien itsepalvelut, joissa pankkien vanhoihin järjestelmiin on luotu www-käyttöliittymä asiakkaita varten. Tulevaisuudessa ihmiset tulevat vaatimaan ns. raakapalveluita, esim. julkisesti tuotetusta paikkatiedosta tietoa sellaisessa muodosta, josta kansalaiset voivat tuottaa uusia palveluita. Liiketoiminnallisesta näkökulmasta teknologialla ei ole itseisarvoa tai olemassaolon oikeutusta, ellei se palvele liiketoiminnan päämääriä ja tarkoituksia. Palvelut voidaan määrittää vaikkapa itsensä kuvaaviksi, ehyiksi kokonaisuuksiksi, jotka tukevat nopeaa ja edullista toisistaan riippuvien hajautettujen ohjelmistojen kehittämistä. Palvelut mahdollistavat organisaatiot tarjoamaan sisäiset toimintonsa palvelukokonaisuuksina, kuten vaikkapa maksa lasku tai tee opintorahan hakemus siten, että palveluun on helppo liittyä ilman monimutkaista ohjelmointia [PAP03]. Kaikenkaikkiaan SOA:aa voidaan katsella useasta näkökulmasta, lisänäkökulmia voivat olla vaikkapa organisaation ulkopuoliset sidosryhmät [KUVA 1].
4 Lyhyesti SOA on siis arkkitehtuurimalli joka mahdollista liiketoimintaa selkeästi tukevien ja mukautuvien tietojärjestelmien rakentamisen. Liiketoimintapuolen ajattelutavan mukaan meillä tulee ensin olla liiketoiminnan tarve (business justification) koska yritysten kaikkien hankintojen tulee tukea sen liiketoimintaa. Liiketoimintapuolella sellaisella tietojärjestelmällä, joka ei palvele liiketoimintaa ei ole oikeutta olla olemassa. 2.2 SOA:n ratkaisemat haasteet Seuraavassa kuvataan seikkaperäisesti tyypillisiä ohjelmistoalustoihin ja liike-elämän tarpeisiin liittyviä perinteisempiä ongelmia ja haasteita, kuten huomaamme on SOA:lla hyvät edellytykset pureutua niistä useimpiin. 2.2.1 Kokonaisarkkitehtuurin hallinta Kuva 2: Tyypillinen organisaation spaghetti arkkitehruuri Kun organisaatiolla ei ole selkeää palveluihin pohjautuvaa standardia ja useiden tietojärjestelmien pitää kuitenkin toimia yhdessä on tästä tuloksena helposti kaaos, jossa järjestelmät on kytketty toisiinsa tapauskohtaisesti riippuen kytkettävistä järjestelmästä. Pahimmillaan yhdessä järjestelmässä saattaa olla liimattuna tusina erilaisia rajapintoja, jotta järjestelmä saadaan tarjoamaan käyttökelpoinen rajapinta muihin järjestelmiin [Kuva 2]. SOA:n etu ja vahvuus on juuri siinä, että se määrittää yhden yhtenäisen xml-pohjaisen rajapinnan. Jo tämä vähentää huomattavasti turhaa sovelluskehitystä ja luo yhtenäisempää arkkitehtuuria [KUVA 3].
5 Kuva 3: SOA -arkkitehtuuri käytännössä [SOA07] SOA mahdollistaa ns. mustalaatikko (blackbox) ajattelutavan jossa jokainen tietojärjestelmän osa nähdään jonkun kokonaisen palvelun toteuttajana. 2.2.2 Ohjelmistologiikan ja liiketoimintalogiikan erottaminen SOA mahdollistaa ohjelmistologiikan ja liiketoimintalogiikan tehokkaan erottamisen, liiketoimintalogiikka mallinnetaan ja parametrisoidaan muualle kuin ohjelmakoodiin. Pahimmillaan vanhoissa järjestelmissä esim. yrityksen tilausprosessi oli saatettu koodata suoraan ohjelmakoodiin. Liiketoiminnan pitäisi olla mahdollisimman vähän jostain tietystä ohjelmistosta, liiketoiminta voi olla riippuvainen prosessista jonka joku järjestelmä toteuttaa. Erityisen ongelmalliseksi liiketoimintalogiikan upottaminen kokonaisarkkitehtuurin kannalta. 2.2.3 Nopeampaa sovelluskehityst Kaikki SOA palvelut toteuttavat samantapaisen XML -pohjaisen rajapinnan ja tämä tarve poistaa lähes täysin sovellusparikohtaisten rajapintojen tarpeen. Eli jos meillä 12 sovellusta, jotka liitetään yhteen järjestelmään, ei meidän tarvitse luoda suoritusympäristö tai ohjelmointikieliriippuvaisia rajapintoja tuohon yhteen järjestelmään 12 kappaletta. Yksi XML -pohjainen rajapinta riittää. SOA palvelut mallinnetaan aina liiketoimintaprosessien pohjalta joten jokaista palvelua vastaa aina liiketoimintaprosessi, tarkistaminen ja pysyminen selvillä siitä missä mennään ohjelmistokehityksessä on huomattavasti helpompaa [PAP03]. 2.2.4 Sijaintiriippumattomuus Oikein toteutettuna SOA järjestelmät ovat sijaintiriippumattomia, IP-protokollan ansiosta vastinpalvelu voi olla vaikka 1000 kilometrin päässä tai viereisessä huoneessa. Palvelun
6 sijainti tai tarjoaja voi hakemistopalvelun ansiosta myös muuttua suoritusaikana (WSDL) [PAP03]. 2.2.5 Tehokas kapselointi SOA kapseloi todelliset liiketoimintafunktiot palveluiksi joita muut järjestelmät voivat käyttää tarkasti määritellyllä rajapinnalla, käyttäjän kannalta palvelu on musta laatikko, jonka toiminnallisuudesta hänellä ei tarvitse olla tarkempaa tietoa. Palvelun tarjoamin perustuu standardeihin ja avoimiin internet protokolliin. 2.2.6 Muutoksenhallinta Muutoksenhallinta on päivän muotitermi ja yritysten yleinen trendi. Ei pyritä pitämään jotain tiettyä tilaa vaan tehdään asioita jotka vaativat asioiden jatkuvaa kyseenalaistamista. Tyypillinen tietojärjestelmäarkkitehtuuriin läheisesti liittyvä haaste on uusien yritysten fuusioituminen. Monoliittiset tietojärjestelmät jotka on toteutettu sekalaisella arkkitehtuurilla eivät ole kuin poikkeuksellisesti kyvykkäitä reagoimaan liiketoimintaprosessien muutoksiin. Yrityksessä tapahtuu ensin joku muutos liiketoimintaprosessissa ja tämän jälkeen tuo muutos heijastuu tietojärjestelmiin. Ei ole kenenkään edun mukaista, että tietojärjestelmät eivät kykene vastaamaan ja reagoimaan tuohon muutokseen. SOA pohjaisia järjestelmiä on helppo integroida ja päivittää vastaamaan liiketoiminnan muuttuvia tarpeita. 2.2.7 Tehokas uudelleenkäyttö SOA arkkitehtuuri mahdollistaa vanhojen perinnejärjestelmien tehokkaan uudelleenkäytön [MAT07]. Erityisesti julkisella hallinnolla on käytössä paljon vanhoja tietojärjestelmiä, jotka sinänsä toimivat moitteetta, mutta viranomaisten lakisääteinen ja yhteistyö ja kansalaisten parempi palvelu edellyttää rajapintoja ja yhteistoimintaa muihin järjestelmiin. Viranomainen voi kapseloida vaikkapa vanhat pääteohjelmansa moderneiksi palveluiksi. 70 luvulta peräisin olevaan väistörekisteri voidaan esimerkiksi asentaa virtuaalitietokoneeseen ja ohjata laitteistoa virtuaalisen näppäimistön kautta SOA komponentilla. 2.2.8 Löysät sidokset Palveluorientoituneessa arkkitehtuurissa kaikilla järjestelmillä on niin yhtenevät XML pohjaiset rajapinnat ja viestit välitetään siten, että parhaimmillaan järjestelmät saadaan keskustelemaan keskenään hyvinkin yksinkertaisesti, lisäksi viestejä voidaan tulkata toisesta järjestelmästä toiseen sopiviksi helposti. SOA järjestelmissä. SOA järjestelmän hakemisto-
7 palvelu auttaa myös löytämään oikeat palvelut sekä. Hakemistopalvelua voidaan käyttää sekä palveluiden suoritusaikaiseen löytämiseen, että uusien palveluiden suunnittelussa ja kehittämisessä. 2.2.9 Tietotekniikan selkeämpi hyöty liiketoiminnalle Suurin muutos minkä SOA on yritysten kannalta tuonut on se, että nyt tietotekniikka palvelee entistä enemmän yrityksen liiketoiminnallisia tarpeita ja niiden mallintaminen ja kuvaaminen toimiviksi ohjelmistoiksi on helpompaa. Kuvaaminen taas mahdollistaa sovelluskehittäjille entistäkin tarkemmat ja selvemmät määritykset siitä mitä oikeasti halutaan. Tämä pureutuu tehokkaasti klassiseen ongelmaan jossa tilaaja (yritys) ei oikein tiedä mitä se tarvitsee ja toimittaja ei oikein osaa toimittaa koska ei oikein tiedä mitä asiakas haluaa. Lopulta asiakas tilaa jotain ja toimittaja toimittaa jotain. SOA luo omalta osaltaan yhteisen kommunikaatiokielen asiakkaan ja toimittajan välille. Ilman yhteistä kieltä lopputulos saattaa olla kelvollinen, mutta yhtä hyvin projekti saattaa päättyä täydelliseen kaaokseen. 2.2.10 Nopeammat muutokset palveluissa Kuten aiemmin olemme jo havainneet, kuvaa SOA palvelu aina jonkun liiketoiminnan palvelun. Palvelu voi tarkoittaa vaikkapa valuuttakurssien hakemista jollekin tietylle päivälle. Yritys voi halutessaan vaihtaa valuuttakursseja tarjoavan yrityksen helposti toiseen. Yritysten tulee vain sopia vaihdettavan tiedon metamalli ja muutokset on tämän jälkeen yksinkertaista toteuttaa. 2.2.11 Standardisointi, oma universumi Soa rakentuu tunnetuille internet -pohjaisille standardeille kuten HTTP, FTP, SMTP, XML, DTD, WSDL, RFD, ebxml, BTP, BPML jne. Yksinkertaisimmillaan SOA pohjaisen järjestelmän rakentaminen on vain XML -pohjaisten sanomien käsittelyä. 2.2.12 Selkeämmät ohjelmointimenetelmät Erityisesti on huomattavaa, että SOA-arkkitehtuuri rajoittaa palveluiden toteutustapoja ja tuottaa sellaisia järjestelmiä joiden on lähtökohtaisesti helppo liittyä toisiinsa, koska niiden väliset rajapinnat on standardisoitu riittävän pitkälle. SOA ei sido ohjelmistokehittäjiä jonkun tietyn sovelluskehittimen tai teknologian käyttöön.
8 2.2.13 Joustavampi testaus SOA -järjestelmissä jokaisella palvelulla tulee olla liiketoiminnallinen tarve, lisäksi tämän tarpeen tulee olla kuvattuna prosessina. Niinpä palvelun ns. mustalaatikko (black box) testaus on hyvin yksinkertaista. Testattavaksi jää karkeasti vain XML muotoisten sanomien lähettäminen ja tarkistaminen että kaikki toimii kuten pitääkin. Erityisesti jos joku vanha järjestelmä on SOA toteutuksen pohjalla voidaan luottaa että vanha järjestelmä toimii niin kuin sen pitääkin. Virhetilanteiden analysointi ja mallintaminen on helpompaa, sillä toiminnallisuutta verrataan jo kuvattuun logiikkaan ja xml-sanomat ovat usein melko helposti ihmisen ymmärrettävissä [SOA07]. 2.2.14 Järjestelmäriippumaton SOA ei perustu minkään tietyn valmistajan teknologiaan tai ohjelmistoalustaan, se voidaan toteuttaa tarvittaessa täysin avoimella lähdekoodilla ja ohjelmistoilla. Usein kaupallisten toimijoiden ohjelmistot toki tuovat merkittävää lisäarvoa ainakin suurissa ja monimutkaisissa järjestelmissä, kuvassa 4 on kuvattu tyypillinen SOA ajoympäristö [PAP03]. 2.2.15 Ei sovellu kaikkeen SOA -järjestelmistä keskusteltaessa tulee muistaa, että ne eivät ole ratkaisu kaikkeen. SOA järjestelmät vaativat yleensä enemmän suorituskykyä kuin hyvin optimoidut järjestelmät, pahimmillaan ns. overhead (ylikuorma) joka syntyy xml sanomien käsittelystä ja luomisesta ja järjestelmien jatkuvasta viestiliikenteestä saattaa tuottaa sellaista kuormitusta, jonka käsittely esim. 5-10 vuotta sitten olisi ollut käytännössä mahdotonta. Lisäksi SOA soveltuu parhaiten tiedonvälitykseen ja jalostamiseen, ei niinkään näyttävien pelien ohjelmointiin.
9 3 Kritiikki SOA on matkallaan kohdannut monenlaista kritiikkiä. Suurin osa perustuu väärinkäsityksiin tai vanhentuneeseen tietoon ja ne voidaan perustella aiheettomiksi. Seuraavassa olen listannut tyypillisimmät väärinkäsitykset vastaperusteluineen. Suurimman osan kritiikistä ja väärinkäsityksistä voi selittää melko inhimillisesti: jos ihminen haluaa, voi hän nähdä SOA:ssa hajautettua laskentaa tai web-palveluita, kuten ensimmäisessä kappaleessa elefantista totesimme. 3.1 Ohjelmisto, joka käyttää web palveluita (web services) on palvelu keskeinen Tämä liittyy siihen, kuinka SOA (palvelukeskeisyys) on määritelty, SOA palvelut ovat kehittyneet web-servicestä, mutta SOA -palveluiden suunnitteluun, määrittelyyn ja toteutukseen liittyy huomattavasti enemmän asioita kuin pelkkien palveluiden toteuttamiseen. Mainittavia asioita ovat mm. kokonaisarkkitehtuuri ja se, että SOA palvelu toteuttaa jo määritelmänsä mukaan aina jonkun liiketoimintaan liittyvän prosessin [SOC05]. 3.2 SOA on vain markkinointitermi web -palveluille SOA termiä on käytetty markkinoinnissa hyvinkin värikkäästi, sen määritelmää ei omista kukaan, se on hieman sama kuin kännykkä. On totta, että web -palveluita käytetään yhtenä osana tyypillisessä SOA toteutuksessa, mutta tämä ei tarkoita että SOA olisi sama asia kuin web -palvelut [SOC05]. Terminä SOA ei ole markkinointiosastojen tuote tai kenenkään tavaramerkki. SOA:lla on laillinen ja melko vakaa asema arkkitehtuurina ja se täyttää myös tietojärjestelmien arkkitehtuureille asetettuja vaatimuksia. SOA:n ajatusmaailma ja toiminnallisuus voitaisiin toteuttaa myös ilman web-palveluiden teknologiaa. 3.3 SOA on vain markkinointitermi hajautetulle web -palveluille On totta että SOA:n perusajatus pohjautuu voimakkaasti hajautukseen ja verkottuneiden resurssien ristikkäiseen yhteiskäyttöön. Jossain määrin sitä voidaan pitää myös hajautettuna palveluna, mutta siinä voidaan nähdä myös paljon muutakin. On huomattava, että SOA on itsessään ensimmäinen ohjelmistoarkkitehtuuri, jossa otetaan selkeästi kantaa siihen faktaan, että yrityksissä ohjelmistot mallintavat pääasiallisesti yritysten toimintaprosesseja eikä tietotekniikka ole vain irallinen tukipalvelu vaan yhä
useammin liiketoiminnan mahdollistaja [SOC05]. Aiemmat yleisimmät arkkitehtuurit eivät nähneet yritysten prosesseja mitenkään erityisenä avaintekijänä. 10 3.4 Jos ymmärrät web-palveluita, ei sinulla ole ongelmia rakentaa SOA-pohjaisia järjestelmiä Teknisessä mielessä tämä on melko totta, mutta SOA:n avain onkin juuri siinä, että ne rakennetaan voimakkaasti liiketoiminnallisesta näkökulmasta. SOA -järjestelmän suunnittelu ja toteuttaminen vaatiikin usein liiketoimintaan erikoistuneiden konsulttien ja tietotekniikan ammattilaisten saumatonta yhteystyötä [SOC05]. 3.5 Kun siirrytään SOA:n kaikki järjestelmät alkavat toimimaan yhdessä Tämä väite on suurimmilta osin markkinoinnin hypeä. On totta, että kun kaikki järjestelmät toteuttavan SOA:n mukaiset informaatioväylät se mahdollistaa niiden välisen kommunikaation, mutta se ei vielä takaa sitä, että nämä järjestelmät ymmärtäisivät toisiaan SOC05].
11 4 Johtopäätökset Palveluorientoituneet järjestelmät ovat mullistaneet ja muuttaneet liiketoimintaa tukevan tietotekniikan kehittämistä. SOA:lla on saatu aikaiseksi riittävän tarkasti määritelty sovelluskehitysympäristö, jonka avulla voidaan tuottaa lähes kaikki yritysten tarvitsemat palvelut mutta samalla turvata yritysten välinen terve kilpailu ja järjestelmien sitoutumattomuus tietyn valmistajan tiettyyn teknologiaan. Tulevaisuudessa SOA järjestelmät tulevat kehittymään yhä enemmän autonomisimmiksi, ne pystyvät jakamaan resurssikuormaansa dynaamisesti, monitoroimaan ja valvomaan tietoturvaansa ja palveluiden laatua. Parasta tässä on se, että kun SOA 2.0 järjestelmille alkaa tulla kysyntää ovat ne melko yhteensopivia myös vanhempien järjestelmien kanssa ja vanhoihin järjestelmiin voidaan integroida myös uutta toiminnallisuutta. Suurin muutos minkä SOA on yritysten kannalta tuonut on se, että nyt tietotekniikka palvelee entistä enemmän yrityksen liiketoiminnallisia tarpeita ja niiden mallintaminen ja kuvaaminen toimiviksi ohjelmistoiksi on helpompaa. Kuvaaminen taas mahdollistaa sovelluskehittäjille entistäkin tarkemmat ja selvemmät määritykset siitä mitä oikeasti halutaan. Tämä pureutuu tehokkaasti klassiseen ongelmaan jossa tilaaja (yritys) ei oikein tiedä mitä se tarvitsee ja toimittaja ei oikein osaa toimittaa koska ei oikein tiedä mitä asiakas haluaa. Lopulta asiakas tilaa jotain ja toimittaja toimittaa jotain. SOA luo omalta osaltaan yhteisen kommunikaatiokielen asiakkaan ja toimittajan välille. Mikäli näin ei menetellä lopputulos saattaa olla kelvollinen, mutta yhtä hyvin projekti saattaa päättyä täydelliseen kaaokseen.
12 5 Lähteet KKL07 Kontogiannis, K., Lewis, G. A., Smith, D. B., Litoiu, M., Muller, H., Schuster, S., and Stroulia, E. 2007. The Landscape of Service-Oriented Systems: A Research Perspective. In Proceedings of the international Workshop on Systems Development in SOA Environments (May 20-26, 2007). International Conference on Software Engineering. IEEE Computer Society, Washington, DC, 1. DOI= http://dx.doi.org/10.1109/sdsoa.2007.12 PMP03 Papazoglou, M.P. and D. Georgakopoulos (2003): Service-Oriented Computing. In: Communications of the ACM, 46(10):25-28, October 2003. DAA07 ELA07 MAT07 PAP03 SOA07 Dan, A., Johnson, R., and Arsanjani, A. 2007. Information as a Service: Modeling and Realization. In Proceedings of the international Workshop on Systems Development in SOA Environments (May 20-26, 2007). International Conference on Software Engineering. IEEE Computer Society, Washington, DC, 2. DOI= http://dx.doi.org/10.1109/sdsoa.2007.5 Elfatatry, A. 2007. Dealing with change: components versus services. Commun. ACM 50, 8 (Aug. 2007), 35-39. DOI= http://doi.acm.org/10.1145/1278201.1278203 Matsunaga, A., Tsugawa, M., and Fortes, J. A. 2007. Integration of text-based applications into service-oriented architectures for transnational digital government. In Proceedings of the 8th Annual international Conference on Digital Government Research: Bridging Disciplines & Domains (Philadelphia, Pennsylvania, May 20-23, 2007). ACM International Conference Proceeding Series, vol. 228. Digital Government Research Center, 112-121. Papazoglou, M.P. (2003): Service-Oriented Computing: Concepts, Characteristics and Directions. Keynote for the 4th International Conference on Web Information Systems Engineering (WISE 2003),December 10-12, 2003. IEEE CS. Service Oriented Architecture For Dummies Published by Wiley Publishing, Inc. 111 River Street Hoboken, NJ 07030-5774 WIK07 Wikipedia, http://en.wikipedia.org/wiki/service-oriented_architecture, 28.11.2007 SOC05 Service-Oriented Architecture: Concepts, Technology, and Design By Thomas Erl Publisher: Prentice Hall PTR Pub Date: August 04, 2005 ISBN: 0-13-185858-0 Pages: 792