Mistä puhutaan, kun SOA-arkkitehtuurissa puhutaan palvelusta?

Entisaikaan palvelua sai kaupan kassalla tai pankin tiskillä. Digitaalisessa maailmalla palvelusta puhuminen vaatii tarkkuutta.Mitä SOA-arkkitehtuurissa tarkoitetaan kun puhutaan palvelusta, ja mistä eri näkökulmista SOA-palveluita tulisi tarkastella?

Kuluttajille tarjotaan verkkopalveluita, IT-yksikkö tarjoaa muille palveluitaan, järjestelmä tarjoaa toisille palveluita, palveluväylä tarjoaa yhteiskäyttöisiä palveluita, integraatioita tarjotaan palveluna, yrityksellä on palvelutarjontaa ja niin edelleen. Moni asia nykyään ”vedetään” (kuten TV:ssa tanssisuoritukset, lauluesitykset, sketsin roolit, urheilusuoritukset jne.) ja jos mahdollista, vielä useampi asia on ”palvelua”. Välillä ihmetyttää, voisiko joku keksiä vielä enemmän merkityksiä sanalle palvelu?

SOA-palvelut rakentuvat eri tasoilla

Myös palveluarkkitehtuurissa ”palvelu” on luonnollisesti varsin keskeinen käsite. Aiemmassa blogipostauksessa kirjoitin, kuinka SOA-hankkeen alussa on tärkeää käydä keskeiset termit läpi, jotta kaikilla on yhteinen käsitys niiden merkityksestä. Palvelun käsite ei ole tästä poikkeus.

Se, mikä loppukäyttäjälle näkyy yhtenä palveluna, vaikkapa junalipun ostamisena mobiilisovelluksella, saattaa vaatia taustalla useaa eri SOA-palvelua. Kun palvelua siis mietitään loppukäyttäjän, prosessien, arkkitehtuurin tai kehittäjän näkökulmasta, puhutaan hieman eri asioista, jotka nivoutuvat yhteen eri kerrosten kautta. Kannattaakin selkeyttää palveluiden eri abstraktiotasot (ks. kuva alla) ja luokitella SOA-palvelut teknisesti eri kategorioihin (esim. peruspalvelut, väyläpalvelut, prosessipalvelut – lue lisää esim. Enterprise SOA, Dirk Krafzig,Karl Banke,Dirk Slama, 2004).

Selkeyttääkseni asiaa olen käyttänyt mm. oheista kuvaa, jossa näkyy näitä palvelun eri abstraktiotasoja. Sivussa esimerkkejä eri abstraktiotasoille sijoittuvista palveluista.
 
Selkeyttääkseni asiaa olen käyttänyt mm. oheista kuvaa, jossa näkyy näitä palvelun eri abstraktiotasoja. Sivussa esimerkkejä eri abstraktiotasoille sijoittuvista palveluista.

Miten SOA pitäisi huomioida palveluiden suunnittelussa?

Olemme tehneet kattavaa materiaalia sidosryhmille, jotta eri tahot ymmärtäisivät, missä kaikissa ”palveluissa” palveluarkkitehtuuri tulee huomioida, ja miten se vaikuttaa missäkin vaiheessa näiden palveluiden (tai järjestelmien) kehittämisessä (määrittely, toteutus, kokonaisarkkitehtuuri jne.). Teknisille ihmisille on tuotettu vielä tarkempaa materiaalia esimerkiksi siitä, missä palvelut fyysisesti sijaitsevat (huomioiden tekninen arkkitehtuuri, ajoympäristö, SLA:t, jne.).

Esimerkki 1: pesukoneen tilaaminen verkkokaupasta

Otetaan esimerkiksi pesukoneen tilaaminen nettikaupasta (asiakkaan näkökulma). Sen takana on esim. tilaus- ja toimitusprosessi (prosessien näkökulma: voivat olla jo orkestroitavia SOA-palveluita), jonka alla on paljon lisää SOA-palveluita (arkkitehtuurinäkökulma), kuten: laske toimituskulut, hae tuotteet, tee maksu. Ja sen alla on vielä teknisiä palveluita. Yksi yhtenäinen kuluttajapalvelu rakentuu siis granulariteetiltään erilaisista palveluista, joista palveluarkkitehtuuria tarvitaan monella tasolla.

Esimerkki 2: aikataulun haku

Aikataulunhaku voidaan tarjota ihmisille käyttöliittymän kautta. Haku voi olla teknisesti yksinkertainen ”haeAikataulu” SOA-palvelu, joka palauttaa hakuparametrien mukaiset aikataulut kysyttäessä. Vaihtoehtoisesti aikataulunhaku voi olla tekninen prosessi, jossa haetaan tietoa useista taustajärjestelmistä (esimerkiksi tiedot junien, busseien ja vaikkapa lentokoneiden aikatauluista).

Joidenkin mielestä ”aito” SOA-palvelu ei ole (tai ei teoriassa tulisi olla) pelkästään ”lahetaTilaus”-operaatio, joka palauttaa esimerkiksi tilausnumeron, vaan vaikkapa tilaustenhallintapalvelu, joka vastaa kokonaisuudessa tilausten hallinnasta ja ohjaa tilauksen operaatiosta toiseen. Toisaalta, teoria ei aina vastaa käytäntöä, ja eteneminen kohti palveluarkkitehtuuria vaatii myös näitä peruspalveluita.

Onko tulevaisuus pelkkää palvelua?

Pitkällä aikavälillä palveluarkkitehtuuri häivyttää järjestelmien välisiä rajoja. Kuten ihan ensimmäisessä bloggauksessa kirjoitin, SOA-hallinnan tavoite on edistää järjestelmien yhteiskäyttöisyyttä, jotta järjestelmät pystyvät käyttämään ristiin toistensa palveluita ja tieto liikkuu järjestelmästä toiseen. Mennäänkö tässä jossain vaiheessa niin pitkälle, että käsissä on yksi valtava SOA-palveluiden nippu – kaikki ”järjestelmät” liitetään toisiinsa kuin Lego-palikat, ja täydellisessä SOA-maailmassa tehdään vain palveluita, ei enää järjestelmiä?

Sitä odotellessa, SOA-projektien sujuvuuden takaamiseksi kannattaa muistaa tarkkuus, kun puhutaan palveluista – kenen näkökulmasta ja mistä palveluista puhutaan.

***

Elävän elämän SOA-hankkeessamme on noin neljän kuukauden ajan suoritettu käynnisteleviä toimenpiteitä aiemman kertomani mukaan. Ensimmäiset yhteiset projektit liiketoiminnan kanssa ovat käynnistymässä, ja kaikki tähän asti esitellyt mallit ja toimintatavat otetaan nyt oikeasti käyttöön. Lisää kuukauden kuluttua.

palveluarkkitehtuuri




Tero Rönkä | Chief SOA Architect

Tero Rönkä | Chief SOA Architect

Teron erityisosaamista on liiketoiminnan ja IT:n yhdistäminen sopivia tekniikoita hyödyntäen. Hän on käytännönläheisenä arkkitehtinä keskittynyt viime vuodet integraatioihin ja palvelupohjaisiin ratkaisuihin, aina toteutuksesta hallinnointiin. Terolle on tärkeää olla tempautumatta nopeatahtisen arjen vietäväksi: hän tarkastelee asioita analyyttisen rauhallisesti ja arvostaa konkreettisia lopputuloksia. Hänen johtoajatuksensa on, että ylimitoitettujen toiveiden ja täydellisyyden tavoittelun sijaan kannattaa keskittyä lopputuloksiin, jotka ovat konkretisoitavissa hyödyksi arjessa. Vapaa-ajalla Tero tuulettaa ajatuksia polkupyörän selässä ja frisbeegolfkentällä.

Kirjoittajan kaikki blogitekstit

Tilaa blogikirjoitukset sähköpostiisi




Seuraa meitä somessa

LinkedIn Twitter Facebook YouTube YouTube