|
 |
SOA - seuraava arkkitehtuurisi?
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ähestymistapa
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-sovelluspalvelimissa.
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.
Joni Moilanen
Kirjoittaja työskentelee Sinisessä Meteoriitissa ohjelmistoarkkitehtinä ja on MikroPC-lehden vakituinen avustaja. |
