Joni Moilanen | 9.3.2004

Arkkitehtuuririntamalla on muodostumassa uusi trendi. Kaikkialla on hiljalleen alkanut esiintyä termi service-oriented architecture eli tuttavallisesti SOA. Mitä tämä sitten käytännössä merkitsee ja miten se vaikuttaa sovelluskehittäjiin ja -arkkitehteihin?

Gartnerin arvion mukaan vuoteen 2008 mennessä 60% yrityksistä toteuttaa tietojärjestelmänsä SOA-mallin mukaisesti. Kun katsoo, miten vakavasti Microsoft, IBM ja muut isot pelurit suhtautuvat SOAan, saattaa se hyvinkin olla mahdollista. Tätä auttaa myös se, että vanhat järjestelmät on mahdollista muuttaa SOA-kelpoisiksi jälkeenpäinkin.

SOA != web services

Ensimmäinen ja yleinen virhekäsitys on, että SOAn kuvitellaan merkitsevän arkkitehtuurin toteuttamista web serviceillä tai muutaman web service - rajapinnan ulospäin avaamista.

Ensinnäkin "service" SOA:ssa ei viittaa ainoastaan web serviceihin - vaikka voivat ne toki olla niitäkin - vaan mihin tahansa rajapintaan, joka mahdollistaa sanomien lähettämisen ja vastaanoton. Näin ollen SOAn mukaiset rajapinnat voidaan rakentaa COMilla, CORBAlla, JMS:llä, MSMQ:lla ja tietenkin alustariippumattomilla web serviceillä. Web service on siis protokolla muiden joukossa, kun taas SOA on kokonainen paradigma.

Service-rajapinta ei myöskään välttämättä merkitse sitä, että se olisi julkaistu yrityksen ulkopuolisille tai valituille kumppaneille. Hyvin toteutettu SOA helpottaa myös sisäistä kehitystä, sillä prosesseja on helpompi hallita ja uudelleenkäyttää.

SOA = prosessirajapinnan lisäys

Aikaisempia oppeja olio-ohjelmoinnista tai n-tier -arkkitehtuurien mukaisista järjestelmistä ei tarvitse unohtaa. Nämä voivat edelleen olla järjestelmän perustana, kunhan eivät näy liiketoimintalogiikkaa käyttäville.

SOA tuo entiseen  malliin uuden palvelukerroksen, joka yksinkertaistaa oliorajapintoja käyttöliittymiä ja integrointia kehittäviin päin. Palvelukerroksesta voidaan sen jälkeen ohjata suurempia kokonaisuuksia kerralla.

Kyse ei ole kuitenkaan puhtaasta facade-patternista, vaikkakin pattern-guru Martin Fowler saattaakin SOAn yhteydessä puhua remote facadesta

Käyttöliittymäkehittäjien ja integroijien ei tarvitse sisäistää miten järjestelmän sisäinen oliomalli toimii, vaan he kutsuvat yksinkertaisia palvelurajapintojen komentoja kuten "Lisää tilaus" tai "Tarkista luottotiedot".

Tärkeää on se, että palvelurajapinta julkistaa kokonaisiin prosesseihin liittyviä kutsuja, jotka käsittelevät kerralla suurempia kokonaisuuksia. Näin saadaan myös vähennettyä ja yksinkertaistettua "kallista" liikennettä käyttöliittymän, ja liiketoimintalogiikkakerroksen, sekä erityisesti joukko-operaatioihin optimoitujen relaatiotietokatojen välillä.

SOAn löyhästi kytketty (loosely-coupled) malli tuo myös joustavuutta, sillä vaikka alla piilevä implementaatio muuttuisi, ei se välttämättä näy palvelurajapinnassa mitenkään. Prosessien muuttuessa palvelurajapintaa kutsutaan eri tavalla sitä kontrolloivassa ratkaisussa.

Esimerkiksi BizTalk Serverin kaltaiset message broker -tuotteet on helppo valjastaa kontrolloimaan prosessia. Graafinen orkestraatio mahdollistaa muutokset prosessinkulkuun ilman muutoksia koodiin, mikäli palvelurajapinnat on selkeästi toteutettu. Näin tekniikka ei sanele yrityksen liiketoiminnan suuntaa tai hidasta muutoksen toteuttamista, kuten pitääkin olla.

Lisää skaalautuvuutta

Skaalautuvuutta helpottaa esimerkiksi se, että käyttöliittymän lomakkeelle voidaan hakea SOA-rajapinnan avulla kaikki tiedot yhdellä pyynnöllä useamman pienen sijaan. Kuten vanha sääntö sanoo: "On parempi siirtää 1000 tavua yhdellä kertaa, kuin yksi tavu 1000 kertaa".

Esimerkiksi web-sivu voi sisältää useita, dynaamisia elementtejä, joihin tiedot haetaan tietokannasta. Usein näkee ratkaisuja, joissa yhden sivun näyttämiseksi tehdään useita pyyntöjä tietokantaan. Tämä merkitsee ennen pitkää huonoa skaalautuvuutta, jota ei aina välimuistiratkaisuillakaan voida korjata.

Forresterin tutkimuksen mukaan käyttäjä poistuu sivulta, ja harvoin palaa, mikäli lataukseen menee neljä sekuntia pidempään. Parempi lähestymis­tapa skaalautuvuuden ja suorituskyvyn kannalta olisi siis tietojen nouto kannasta yhdellä pyynnöllä. Saadulla paketilla täydennetään sitten portaalin tai käyttöliittymän lomakkeen tiedot.

Valkoiset hevoset apuun

SOA merkitsee uusia haasteita sovellusten toteuttamiseen, mikä merkitsee myös muutoksia työkalurintamalla. Esimerkiksi Microsoftilla on tulossa liuta teknologioita ja tuotteita, jotka helpottavat SOA-mallisten sovellusten toteuttamista ja SOA tulee näkymään laajemmin varmasti myös Java-puolen tarjonnassa, erityisesti J2EE-sovellus­palvelimissa.

Yksi tärkeimmistä parannuksista seuraavassa Visual Studio .NETissä on epäilemättä Whitehorse-koodinimellä kulkeva mallinnustyökalu, joka on kehitetty erityisesti SOAa ajatellen. Aiheesta löytyy vielä suhteellisen niukasti tekstejä ja varsinkin kuvia, mutta jotain käsitystä saa esimerkiksi MSDN TV:n Whitehorse-videosta.

Muita Microsoftin SOAa tukevia teknologioita ovat esimerkiksi Indigo ja äskettäin julkaistu BizTalk Server 2004. Shadowfax on SOAa toteuttava esimerkkiarkkitehtuuri, jota toteutetaan yhteisövoimin GotDotNetin Workspaces-projektina.

Java-rintamalla tullaan näkemään erilaisia parannuksia ja laajennuksia J2EE-toteutuksissa, kuten WebSpheressä ja WebLogicissa. Esimerkiksi Blue Titan Softwaren Network Director 2.0 tuo WebLogiciin SOA-laajennuksen.

Oli käyttöjärjestelmä tai kehitysalusta mikä tahansa, SOA on selkeästi suunta, mihin ollaan menossa. Se ei tietenkään sovi kaikkiin tilanteisiin, mutta tietojärjestelmiä toteuttaessa sitä kannattaa harkita yhtenä vaihtoehtona.