SOA-projekti toteuttajan silmin

SOAsta on kirjoitettu paljon - Yleensä asiaa käsitellään yleisellä ja hieman abstraktilla tasolla, kerrotaan mitä hyötyjä SOA yrityksen tietojärjestelmille tarjoaa, mitä periaatteita palveluiden rakentamisessa tulisi noudattaa, ja niin edelleen. Tässä tekstissä näkökulma on lähempänä ruohonjuuria. Käyn läpi muutamia seikkoja joiden suhteen SOA-toteutusprojekti konkreettisesti eroaa perinteisemmistä toteutusprojekteista. Nämä olisi hyvä huomioida jo projektin alkuvaiheessa.

Asiakkaan SOA-ekosysteemin tila

Ensimmäiseksi pitää selvittää, millaiseen ympäristöön järjestelmää ollaan rakentamassa. Onko yrityksessä tehty kokonaisarkkitehtuurityötä (KA) ja jalkautettuna yhteinen SOA-strategia ja siinä kuvatut teknologialinjaukset? Onko liiketoimintaprosesseja ja SOA-palveluiden käyttäjiä jo tunnistettu? Lähtökohtaisesti toteutusprojektia aloitettaessa SOA-strategia tulisi olla jo luotuna.
Palvelukeskeisen arkkitehtuurin edut realisoituvat vasta kun koko yrityksen laajuinen ekosysteemi sykkii toiminnassa. Palvelukeskeisen arkkitehtuurin hyötyjä on mahdotonta saavuttaa, jos yksinäiseen erakko-järjestelmään toteutetaan näön vuoksi muutama irrallinen SOA-palvelu, joiden olemassaolosta muut järjestelmät eivät ole kuulleetkaan.

Aina ei kuitenkaan eletä ideaalimaailmassa, eikä projekti voi nojautua asiakkaan kypsään ja kokonaisvaltaiseen SOA-suunnitelmaan. Voi olla, että ollaan rakentamassa proof of concept -järjestelmää samalla kun asiakas vasta käynnistelee palvelukeskeistä arkkitehtuuriaan. Tässä tilanteessa ei auta kuin tehdä projektissa valistuneita arvauksia esimerkiksi siitä, millaisia palveluita järjestelmän olisi hyvä ulospäin tarjota. Jos (ja toivottavasti kun) SOA-strategian suunnittelu on jo käynnistetty, projekti määrittelee linjauksia sen kanssa tiiviissä yhteistyössä. Tärkeää on se, että SOA-strategiaa kehitetään. Koska SOA on yksittäisiä sovelluksia laajempi käsite, ei ole tarkoituksenmukaista rakentaa ensin suurta joukkoa erillisiä, toisistaan eroaviin käytäntöihin perustuvaa "SOA-sovellusta" ja ryhtyä sen jälkeen miettimään näille yhteistä SOA-strategiaa.

Toiminta keskeneräisessä SOA-ympäristössä aiheuttaa omat haasteensa. Jos SOA-kokonaisuutta ei olla vielä mietitty, projektilla ei ole tietoa siitä millaisille palveluille on tarvetta ja mihin prosesseihin niitä liitetään. Projektin aikana on kiinnitettävä kurinalaisesti huomioita SOA-palvelurajapintoihin, jotta ne eivät jäisi lapsipuolen asemaan, kun aikataulupaineet puristavat. Hyvien SOA-rajapintojen suunnittelu ja toteutus ottaa oman aikansa.

Käytämmekö omia SOA-palveluitamme, ja miten?

Kaikissa SOA-sovelluksissa on tyypillisesti jotain sisäisiä toiminnallisuuksia (webkäyttöliittymän tms kautta käytettäviä), ja joukko ulkoisia SOA-palveluja. Tällainen järjestelmä voidaan toteuttaa kahdella tavalla

1. Hybridimalli: rakennetaan järjestelmän sisäiset toiminnot perinteisemmällä arkkitehtuurilla (esim. JSF-EJB-tietokanta) ja toteutetaan tämän rinnalle SOA-palvelut erikseen
2. Puhtaasti pelkkiin SOA-palveluihin perustuva malli: kaikki sovelluksen toiminnot, myös sisäiset, toteutetaan käyttäen SOA-palveluja

Hybridimallissa on riskinä, että SOA-palvelut jäävät muuta sovellusta heikommalle testaukselle ja muutenkin lapsipuolen asemaan. Ratkaisumalli ei myöskään luontevasti ohjaa palvelurajapintoja noudattamaan sitä SOA-periaatetta, että rakennetaan kattava joukko matalan tason palveluita joista yhdistellään karkeampia koostepalveluita. Helposti käy niin että SOA-palveluita rakennetaan vain sen verran kuin tarpeita on tunnistettu, ja uudet tarpeet vaativat uusien palveluiden toteuttamista.

Puhtaassa SOA-mallissa haasteita aiheuttaa tuottavuuden korkeana pitäminen. Palveluiden toteuttaminen on yleensä huomattavasti hitaampaa kuin perinteisen Java-toteutuksen, johtuen siitä että joudutaan huomioimaan palveluiden SOA-periaatteiden mukaisuus, WSDL:t ja XML schemat, XML-Java muunnokset, ynnä muut sovelluksen sisäisen toteutuksen kannalta ylimääräiset seikat. Koska rajapintoja rakennetaan hyvin paljon, eikä useimmille ole muuta käyttäjää kuin järjestelmä itse, tulee helposti houkutus rakentaa rajapinnat teknologialähtöisesti ja ensisijaisesti omiin tarpeisiin sopiviksi. Kuitenkin näissäkin palveluissa suunnittelu pitäisi ensisijaisesti tehdä SOA-periaatteiden mukaisesti eli huolehtia uudelleenkäytettävyydestä, löyhästä kytkennästä, estää toteutusyksityiskohtien valuminen rajapintaan, ja niin edelleen. Lisäksi suorituskyky voi aiheuttaa päänvaivaa, jos sovellus pommittaa SOA-palveluita suurella intensiteetillä, jolloin kaikki ylimääräinen, kuten XML:n käsittely, aiheuttaa ongelmia.

Etuna puhtaassa SOA-mallissa SOA-palvelut tulevat varmasti kattavasti testatuksi, niitä on varmasti riittävän kattava joukko, ja niitä voidaan käyttää aidosti koostepalveluiden rakentamiseen.

Jonkinlainen keskitie näille kahdelle vaihtoehdolle on ratkaisu, jossa palvelut on toteutettu WebService -annotoiduilla EJB:llä, ja sovelluksen sisäisesti käytetään natiivia EJB -rajapintaa ja ulkoiset SOA-asiakkaat käyttävät WSDL rajapintaa kyseisiin papuihin.

Teknologiavalinnat

SOA-maailma tuo mukanaan valintoja teknologioiden suhteen. Käytetäänkö ESB:tä, viestijonoja, prosessimoottoria, mitä sovelluspalvelinta? Ollaanko rakentamassa HTTP/SOAP -palveluita, tehdäänkö asiakkaalla SOA:a REST-rajapinnoilla, vai käytetäänkö jotain kolmatta tapaa? Jos tehdään SOAP-palveluja, mitä versiota WS-I Basic Profilesta käytetään, ja otetaanko käyttöön laajennoksia kuten WS-Security? Jos hyvin käy, tämäntyyppisiin kysymyksiin saadaan vastauksia asiakkaan SOA-linjauksista. Mikäli linjauksia ei vielä ole tai niissä ei oteta näihin kantaa, tehdään projektikohtaisia päätöksiä yhteistyössä asiakkaan kanssa.

Palveluiden tietoturvaa on hyvä miettiä ensimmäisten kysymysten joukossa. Riittääkö että järjestelmän kannalta kuka tahansa voi käyttää kaikkia palveluita vapaasti, ja asiakas huolehtii palomuureilla, ESB:llä tai muilla keinoin, että rajapintoihin pääsee vain laillisia kutsujia? Vai käytetäänkö http basic authenticationia, WS-Securityä, jotain kotikutoista tapaa, tai jotain muuta? Suojataanko palveluita ("vain valvontakoordinaattorilla on oikeus muokata asiakasyhteydenoton tietoja") vai itse dataa monimutkaisempien sääntöjen perusteella ("ainoastaan henkilö itse ja hänen välitön esimiehensä saavat paluuviestissä palkkatiedot").

SOA-ohjelmistojen puolella maailma muuttuu nopeasti ja riskit on hyvä huomioida. Jos valitsemme open source palveluväylän NanoNanoESB 2.2, onko kyseinen projekti enää aktiivinen vuoden kuluttua? Ja miten tiukasti sovelluksemme on naimisissa NanoNanon kanssa, paljonko muutostyötä vaihtaminen toiseen aiheuttaisi?

Tuttujen tuotteiden ja teknologioiden merkitystä ei kannata aliarvoida. Kun tietyllä työkalulla on todistetusti saatu tuloksia aiemminkin, projektin riskit ovat pienemmät. Kompleksisten SOA-työkalujen opiskeluun kuluu aikaa ja mahdollisten ongelmatilanteiden selvittelyn vaikutus on vaikeasti etukäteen arvioitavissa.

Pelisäännöt palveluille

Kun palvelurajapintoja (esim. HTTP/SOAP-palveluihin) aletaan rakentaa, pitää linjata niiden käytännöt

Millä kielellä rajapinnat toteutetaan - suomeksi vai englanniksi?
Millä tavalla palvelut ja niissä siirrettävät käsitteet nimetään? Esimerkiksi JHS-170 määrittelee yhdellä tavalla osan tästä.
Mitä tietotyyppejä käytetään? Miten XML schemat jaetaan modulaarisesti osiin? Miten namespaceja käytetään?
Miten hoidetaan palveluiden versiointi? Miten julkaistaan rajapinta 1.1, jos muutos on epäyhteensopiva jo käytössä olevan 1.0:n kanssa?
Miten hallitaan käsitteiden väliset viittaukset? Jos järjestelmässä on käsitteet Maakunta, Kunta ja Asukas, palauttaako HaeMaakunta("Kanta-Häme") pelkän Maakunnan, myös siihen liittyvät Kunnat, vai vielä kaikki Asukkaatkin? Voiko palvelun käyttäjä määritellä tätä pyynnössä?

Tämäntyyppisiä kysymyksiä on kohtuullisesti käsitelty opuksessa "Web Service Contract Design and Versioning for SOA":

Projektinhallinta

Projektisuunnittelussa on syytä muistaa, että SOA ei synny ilmaiseksi. Toteutuksen työmäärä on perinteisiä suljettuja projekteja suurempi, työkalu- ja teknologiaympäristö monimuotoisempi, ja kehittäjiltä vaaditaan laajaa osaamista työkaluista, teknologioista ja SOA-periaatteista. Myös asiakkaalta vaaditaan aktiivista osallistumista, jotta rakennetut palvelut loksahtavat saumattomasti osaksi palvelukeskeisen arkkitehtuurin kokonaisuutta. Kaikki tämä saadaan terveessä SOA-ekosysteemissä korkojen kera takaisin palveluiden uudelleenkäytön ja yhdistelyn myötä.

Janne Mattila Janne Mattila on ohjelmistoarkkitehti ja palvelukeskeisen arkkitehtuurin asiantuntija. Hän on työskennellyt Java EE -teknologioiden parissa standardin alkuajoista lähtien, ja hankkinut laajan kokemuksen teknologioista, suunnittelumalleista ja ohjelmistokehyksistä. Mattilan vahvaa osaamista sävyttää SOA:aan liittyvien teknologioiden ja merkintäkielten erikoisosaaminen. Hänelle on projektien myötä tullut tutuksi myös kokonaisarkkitehtuuriin ja prosessien mallintamiseen liittyvät notaatiot ja työkalut.