Keskustelu kansallisen palveluväylän ympärillä on ollut kiivasta ennen kesää 2014. Kesän lomakuukaudet tuovat pienen tuumaustauon kaikille osapuolille. Itse en suoraan ole tekemisissä palveluväylän kehittämisen kanssa, mutta sen sijaan olen tekemisissä JulkICT labin ja koulutuksen pilviväylän (aka EduCloud) kanssa, jotka puolestaan tavalla tai toisella hyödyntävät tai liittyvät kansalliseen palveluväylään. Ihan alkuun lienee paikallaan muistuttaa mistä palveluväylässä on kyse:
- Kansallinen palveluväylä on tiedonvälityskonsepti, jossa eri toimintaympäristöjen palveluiden tarvitsema tieto on saatavilla avoimien rajapintojen yli kaikille tietoa tarvitseville palveluille.
- Kukin palveluväylään liitetty järjestelmä hallitsee omia tietojaan sekä vastaa siitä, että muiden tarvitsemat tiedot ovat saatavissa välitysalustan kautta ottaen huomioon tietojen käyttöön liittyvät mahdolliset rajoitukset.
- Palveluväylä ei ole yksittäinen tuote tai tekninen ratkaisu.Palveluväylä on yhteentoimivuuteen liittyvän problematiikan kattava konsepti,
- jonka ympärille yhteentoimivuutta lisäävä kehittämistoiminta voidaan organisoida.
- Kansallisen palveluväylän tarkoituksena on mahdollistaa nykyistä paremmin asiakaspalveluiden ja palveluprosessien kehittäminen palveluissa tarvittavan tiedonvaihdon ja yleispalvelut mahdollistavan ratkaisukokonaisuuden avulla.
Yllä olevissa vilahtaa monessa kohtaa yhteentoimivuuden vaatimukset. Yksi kriittinen osa yhteentoimivuuden aikaansaamiseksi on rajapinnat ja protokollat. Palveluväylän nykyinen versio perustuu SOAP teknologiaan. Tuleva versiokin on tämän hetkisten suunnitelmien mukaan perustamassa vain ja ainoastaan SOAP:iin.
Miksi SOAP eikä REST? Miksi REST tukea ei ole ja tuleeko se ja jos tulee niin koska? Yksi syy SOAP perustaan löytyy historiasta. REST tapa tehdä rajapinnat on vallannut API markkinat vasta viime vuosina. Lisäksi tapoja tehdä API toteutuksia syntyy koko ajan lisää. Onkin odotettavaa että REST:in jälkeinen “hip ja pop” tapa toteuttaa rajapintoja on SOAP/REST hybridi.
Suomeen Virosta saatu X-Road eli palveluväylä syntyi vuosituhannen alussa. Silloin tilanne rajapintojen osalta oli toinen. REST teki vasta tuloaan silloin. Nyt vaikuttaa siltä että X-Road on jäänyt ajastaan jälkeen ja vaatii merkittävämmän päivityksen. Suomessa monet eri tahot yksityisellä ja julkisella sektorilla lähes kirkuvat REST tukea.
Tarvitaan palveluväylä REST-PLUS steroideilla. REST-Plus termillä viittaan REST:iä seuraavaan toteutustapaan, joka rakentuu ottamalla REST:n ja SOAP:n hyvät puolet ja jättämällä pois huonot.
REST tarve on noussut esiin JUHTA:n perustietovarantojaoksen selvityksissä.
Tarve palveluväylän REST tuelle tuli selkeästi esiin haastattelukierroksella [Pertiva]
REST tuen tarve on tullut esiin myös SoTe sektorin palveluväylä –esiselvityksessä sekä useissa palveluväylän viitearkkitehtuurista aiemmin annetuissa lausunnoissa [Pertiva]
REST tarve on tullut voimakkaasti esiin Koulutuksen Pilviväylän kehittämisen yhteydessä, joka osaltaan perustuu tiiviiseen yhteistyöhön yli 30 koulutussektorin yrityksen kanssa.
REST tuntuu olevan perusta myös Opetushallituksen kehittämän Opintopolku.fi palvelussa. Sen rajapinnat ovat REST (JSON) perustaisia. Uskallan melko varmasti väittää, että jos lähden kysymään REST -rajapintojen tarpeellisuutta muilta sektoreilta, vastaukset ovat saman suuntaisia kuin yllä olevat lainaukset.
Näin ollen tuntuu hullulta että palveluväylässä ei olisi REST tukea. Kuten mainitsin alussa Palveluväylän tulevaan versioon (6) ei välttämättä sisälly REST tukea. Ainakin se on vielä kysymysmerkkinä väylää kehittävän Cybernetican suunnitelmassa.
Yhteinen malli digitaalisten palveluiden pohjaksi
Olen ehdottanut esimiehilleni OKM:ssä, että Suomi ottaisi vetovastuun REST tuen aikaansaamisesta Palveluväylään. Kehitystyö tehtäisiin yhdessä Viron kanssa. Työ aloitettaisiin hakemalla yhteinen näkemys REST tuesta ja sen vaatimuksista pitämällä muutama työriihi. Työriihet olisivat avoimia niille jotka katsovat että oma toiminta tulee jollain tavalla liittymään Kansalliseen palveluväylään ja sen palveluihin. Mukaan pitäisi saada niin julkisen kuin yksityisen sektorin toimijoita (plus virolaiset).
Työriihien tuloksena syntyisi malli REST tuesta johon yritykset ja julkinen sektori voivat sitoutua ja jonka päälle ovat valmiita kehittämään digitaalisia palveluita. Vuoden 2015 alusta voitaisiin alkaa toteuttamaan REST tukea tai miksei aikaisemminkin mutta muistaakseni olen nähnyt jossain kaavion jossa palveluväylän kehitys on laitettu alkamaan vasta 2015 alusta. Kehitys tulisi tehdä avoimen lähdekoodin alle, avoimesti ja läpinäkyvästi sekä iteratiivisesti. Yrityksien ja yhteisöjen on saatava olla mukana kehitystyössä ja sen hedelmien testaamisessa syksyn suunnitteluspinttien jälkeenkin.
REST tuen saaminen palveluväylään vaatii mallin uudelleen arviointia ja uusien työkalujen ja tapojen käyttöönottoa. Otetaan esimerkki. REST rajapintoja ei pysty kuvaamaan SOAP:n WSDL kielellä. Pitää ottaa käyttöön joko WADL tai RAML. Lisäksi REST rajapintojen hallinta pitää miettiä. Yksi vaihtoehto olisi rakentaan sektorikohtaisia API hallintakeskuksia. Se toimisivat kuten esimerkiksi http://www.3scale.net/api-management/. Sektorikohtaiset API hallintakeskuksien lisäksi tarvittaisiin API Metapalvelu joka puolestaan aggregoisi API:en metatietoja omaan keskitettyyn tietokantaansa. Tämä API:n API toimisi väylänä ja keinona löytää eri rajapinnat. Rajapintojen hallinta olisi edelleen vain ja ainoastaan sektorikohtaisissa keskuksissa samaan tapaan kuin avoimen datan CKAN katalogeissa on tehty.
On esitetty myös sekin vaihtoehto että hylkäämme Palveluväylän sellaisena kuin sen Virossa on tehty. Tuntuu vain siltä, että se juna/vaihtoehto meni jo.
Seuraavat stepit
Eli lyhyesti mitä nyt tulisi tehdä:
- Kutsua koolle alkusyksystä (syyskuu) työriihi “Palveluväylän REST-PLUS tuki”, mukaan em sidosryhmät
- Toisessa työriihessä (lokakuu) hyväksytään syntynyt yhteisesti (Viro ja Suomi) hyväksytty “manifesti”/ roadmap REST tuesta.
- Vuoden 2015 alusta scrum tiimi toteuttamaan suunnitelmaa avoimen lähdekoodin alle.
