Mikkelin kaupunki hyödyntää nyt Palvelutietovarantoa verkkosivuillaan

Mikkelin kaupunki on alkanut näyttää Suomi.fi-palvelutietovarannosta tuotuja tietoja kaupungin omilla verkkosivuilla. Palvelutiedot tulevat kaupungin verkkosivujen Palvelut-kohtaan suoraan Palvelutietovarannosta. Palvelutietoja voidaan rikastaa tuomalla esimerkiksi kuvia WordPressistä.

Mikkelin kaupunki on muutenkin toiminut Palvelutietovarannon käyttöönotoissa edelläkävijänä, sillä se vei ensimmäisenä kuntana tietonsa Palvelutietovarantoon. Jo palvelun pilotointivaiheessa pidettiin selvänä, että jatkossa kaupungin verkkosivuilla olevat palvelutiedot tulevat PTV:stä. Mikkelin Palvelutietovarannon pilotointiprojekti käynnistyi syksyllä 2015. Toukokuussa 2016 käynnistettiin varsinainen verkkosivuprojekti. Kaikki kaupungin palvelut oli tallennettu kehitetyn PTV-käyttöliittymän kautta lokakuussa 2016.

”Projekti sujui kokonaisuudessaan hyvin, emmekä kohdanneet suuria teknisiä haasteita. Haasteellisemmaksi osoittautui sisällöntuotannon uudelleenorganisointi sekä sivustojen visuaalinen toteutus, nyt kun osa tiedoista tulee PTV:n ja osa WordPressin kautta. Nämä vaiheet viivyttivät verkkosivujen julkaisua marraskuun alkuun 2017”, kertoo Mikkelin kaupungin palvelukehityspäällikkö Heli Hänninen.

Palvelutietojen kuvaamisen suurin hyöty on asiakaslähtöisyys

Mikkelin kaupungin digitalisoinnissa periaatteena on ollut yksi tieto yhdessä paikassa yhteen kertaan. Sama periaate pätee myös Palvelutietovarantoon.

”Valitseepa asiakas tietolähteekseen kaupungin omat sivut tai Suomi.fi-verkkopalvelun, löydetty tieto on sisällöltään sama. Kunnan verkkotoimittajien ei tarvitse ylläpitää tietoja useaan eri paikkaan vaan tieto on jaettavissa Palvelutietovarannosta useisiin eri lähteisiin.  Lisäksi Suomi.fi tukee Asiointipisteiden yhteispalvelua tuomalla palvelutarjoomaan myös valtion ja maakuntien palvelut”, Hänninen toteaa.

Hännisen mukaan PTV:n hyödyt realisoituvat erityisesti tarkasteltaessa palvelua asiakasnäkökulmasta. Lisäksi hän muistuttaa, että Palvelutietovaranto on Suomi.fi-verkkopalvelun kivijalka, jonka rinnalle on mahdollista rakentaa laajempaa palveluekosysteemiä.

”Asiakashan ei perinteisesti tee eroa sille, tuottaako palvelun valtio, kunta vai maakunta. Palvelutietojen tulisi olla löydettävissä palvelu-, ei organisaatiolähtöisesti. Tietomalli tukee kuntia irtautumaan organisaatiolähtöisestä viestinnästä, jolloin kuvaukset sisältävät asiakkaan kannalta olennaisia tietoja. Palvelutietovaranto rakentaa myös kunnille yhteistä palvelukieltä, joka mahdollistaa muun muassa kuntavertailun”.

Seuraavaksi toimintamallien selkeyttämistä ja linjauksia sisällöntuotantoon

Jatkossa Mikkelissä aiotaan selkeyttää talon sisäisiä toimintamalleja ja tehdä linjauksia sekä tyylimalleja sisällöntuotantoon. Palvelutietovarannon tietoja on jatkossa mahdollista hyödyntää esimerkiksi kunnan toteuttamissa mobiilisovelluksissa.

”Julkisessa hallinnossa on pitkät perinteet asioiden esittämisestä organisaatiolähtöisesti. Nyt meillä on mahdollisuus luoda yhteisen palvelupuheen kulttuuria asiakkaan hyödyksi. PTV-ympäristö kehittyy jatkuvasti ja kuntien kannattaa ilman muuta olla kehityksessä mukana”, muistuttaa Hänninen.

Mikkelin kaupungin verkkosivut: https://www.mikkeli.fi/
Mikkelin kaupungin pilotin myötä syntynyt Kunta-Api: https://www.kunta-api.fi/

Palveluväylään lisää tehoa – kuormantasaajan käyttö mahdolliseksi

Suorituskykyä ja toimintavarmuutta lisää

Suomi.fi-palveluväylään liitettävien palveluiden suorituskykyä ja toimintavarmuutta voidaan jatkossa merkittävästi parantaa, kun seuraava palveluväylän versio (versio 6.16.x) julkaistaan syksyllä. Uudessa versiossa on mahdollista käyttää ulkoista kuormantasaajaa tasaamaan liityntäpalvelinten kuormitusta. Tämä tarkoittaa sitä, että liityntäpalvelimia voi olla useita. Tällöin ne kaikki tarjoavat saman palvelun palveluväylään mutta väylän suuntaan ne näkyvät kuitenkin vain yhtenä rajapintana. Ulkoinen kuormantasaaja huolehtii rajapinnassa siitä, että viestiliikenteen kuormitus jaetaan tasaisesti klusterissa olevien eri liityntäpalvelinten kesken. Tällöin palvelukutsuja voidaan käsitellä yhtäaikaisesti huomattavan paljon enemmän verrattuna yhteen palvelukutsuja käsittelevään liityntäpalvelimeen.

Palveluväylän sisäinen kuormantasaus

Aikaisemmin palveluväylässä on jo ollut mahdollista käyttää X-Roadin sisäistä ns. High Availability-toiminnallisuutta (HA), jolloin väylän sanomia välittävät liityntäpalvelimet ovat voineet olla kahdennettuja tai jopa monennettuja. Tällöin yhden liityntäpalvelimen vikaantuessa on ”vara-liityntäpalvelin” otettu käyttöön ja palvelun toiminta on jatkunut lähes keskeytyksettä. HA-toiminnallisuus ei ole kuitenkaan osannut jakaa kuormaa eri liityntäpalvelimien kesken, vaan käytännössä se on vain ohjannut kuorman jollekin liityntäpalvelimelle.

 

Kuva 1. Sisäisen kuormantasauksen periaate. Kuvassa käytetyt lyhenteet: IS = information system (tietojärjestelmä, sovellus), SS = Security Server (liityntäpalvelin).

 

Palveluväylän ulkoinen kuormantasaus

Kuormantasaus tarkoittaa sitä, että käsiteltävä kuorma jaetaan käytössä olevien liityntäpalvelimien kesken, jolloin yksittäinen palvelin ei ylikuormitu. Jos yksittäinen palvelin vikaantuu eikä sitä voida enää käyttää, osaa kuormantasaaja tällöin reitittää liikenteen uudelleen niin, ettei vikaantunutta palvelinta turhaan yritetä käyttää. Näin liikenne ohjautuu muille, toimiville palvelimille.

Kuva 2. Ulkoisen kuormantasauksen periaate.

Palveluväylän tapauksessa merkittävä asia on myös se, että vaikka klusterissa olisi useampia liityntäpalvelimia, tarvitaan palveluväylän varmenteita (autentikointi- ja allekirjoitusvarmenne) vain yhtä liityntäpalvelinta varten. Väylässä on siis virallisesti yksi liityntäpalvelin (master), joka klusterin muut liityntäpalvelimet (noodit, slavet) teeskentelevät olevansa. Klusterissa olevat liityntäpalvelimet käyttävät kaikki samoja varmenteita eikä jokainen liityntäpalvelin tarvitse omia varmenteita, mikä on merkittävä parannus varmenteiden käsittelyssä. Palveluväylän liityntäpalvelin-ohjelmisto osaa replikoida varmenteet ja käyttää niitä klusterissa olevien palvelinten kanssa oikein.

Kuormantasaajan suorituskykymittaukset

Ulkoisen kuormantasaajan käyttämistä palveluväylän tarpeisiin on testattu kevään ja kesän aikana kehitystiimin omissa suorituskyky- ja regressiotesteissä. Lisäksi ulkoinen toimittaja on tehnyt erillisen suorituskykytestauksen omassa palveluväylä-ympäristössään käyttäen omaa ulkoista kuormantasaaja.

Suorituskykytestejä varten FI-TEST -palveluväylä-ympäristöön luotiin alla oleva kuvan mukainen testauskonfiguraatio. Kuormantasausta käytettiin sekä palvelupyyntöjen lähettäjän että palveluntarjoajan päässä palveluväylän ja liityntäpalvelinten välissä. Lisäksi sekä asiakasjärjestelmän että palveluntarjoajan järjestelmien ja liityntäpalvelinten välissä käytettiin ulkoisia kuormantasaajia. Kuormaa pyrittiin tasaamaan mahdollisimman paljon.

Kuva 3. Ulkoisen kuormantasauksen testauskonfiguraatio.

 

Yksittäinen viesti kulkee järjestelmässä niin, että asiakasjärjestelmän sovellus generoi palvelukutsujen SOAP-sanomia kuormantasaajan #1 läpi asiakaspään liityntäpalvelimille (liityntäpalvelimet #1 ja #3), jotka pyytävät sanomiin vastausta palveluntarjoajan liityntäpalvelimelta (liityntäpalvelimet #2 ja #4). Kuormantasaaja #3 jakaa palvelukutsut palveluntarjoajan liityntäpalvelinten #2 ja #4 kesken. Nämä liityntäpalvelimet saavat vastaukset palvelukutsuihin palveluntarjoajan sovellukselta. Tämä sovellus tuottaa vakiovastauksen ja vastaussanomat voidaan määritellä testin konfiguroinnilla. Vastaussanoma kulkee samaa reittiä takaisinpäin, jolloin kuormantasaajat #4 ja #2 jakavat matkan varrella kuormaa.

Testissä mitattiin kuinka kauan koko viestiketjun (palvelukutsu–vastaus) suorittamiseen kuluu aikaa ja montako viestiä järjestelmän läpi kulkee. Lisäksi mitattiin sekä liityntäpalvelimien että asiakasjärjestelmän ja palveluntarjoajan sovelluksen palvelimien CPU-kuormitusta. Näin pystyttiin päättelemään mikä osa järjestelmästä mahdollisesti hidasti eniten viestin välitystä. Testin aikana palvelukutsujen määrää lisättiin niin, että testin aluksi yhtäaikaisia palvelukutsuja oli vain yksi kappale, mutta testin lopussa yhtäaikaisia kutsuja oli 250.

Testin aikana kaikissa liityntäpalvelimissa oli samanlainen alustakokoonpano, joka on käytännössä sama kuin suositeltava minimikokoonpano liityntäpalvelimelle:

  • OS: Red Hat 7
  • Keskusmuisti: 4 Gb
  • 2 CPUs
  • Levytila: 70 Gt

Seuraavissa kuvissa on esitetty sanomien läpimenomäärät ja keskimääräiset vasteajat testeissä käytetyille palvelukutsuille kullakin sanomakoolla. Kuvassa 4 näkyy kuinka monta sanomapakettia on siirretty kullakin sanomakoolla yksittäisen testin aikana. Testin suoritusaika on vakio ja viestejä lähetetään väylän siirrettäväksi niin nopeasti kuin mahdollista.

Kuva 4. Viestien läpimenomäärät kuormantasauksella ja ilman kullakin sanomakoolla mitattuna.

Kuvassa 5 näkyy palvelukutsujen keskimääräiset vasteajat kullakin sanomakoolla testien aikana.

Kuva 5. Keskimääräiset palvelukutsujen vasteajat kullakin sanomakoolla.

 

Tulokset näyttävät, että osassa testejä suorituskyky tuplaantui tai kasvoi jopa tätäkin enemmän. Toisaalta testauksen aikana huomattiin, että testauksessa palveluntarjoajan päässä käytetty vastaanottava sovellus muodostui pullonkaulaksi silloin kun käytettiin isompia sanomakokoja. Vastaanottava sovellus ei pystynyt käsittelemään saapuneita palvelukutsujen sanomia tarpeeksi nopeasti, vaan kutsut jonoutuivat ja niiden käsittely hidastui. Tästä syystä testitulokset ovat näissä testitapauksissa huonompia kuin jos vastaanottava sovellus olisi pystynyt käsittelemään palvelukutsuja yhtä nopeasti kuin liityntäpalvelimet niitä välittivät. Tämä näkyy siinä, että 100K:n kokoisissa ja sitä isommissa sanomissa kuormantasauksen vaikutus suorituskykyyn putoaa ja tasoittuu suurin piirtein samaan lukemaan kuin ilman kuormantasausta. Jälkikäteen arvioiden myös palveluntarjoajan sovellus olisi pitänyt olla kahdennettu (kaksi sovellusta olisi vastannut palvelukutsuihin), jotta palveluväylän siirtokykyä olisi saatu paremmin mitattua. Joka tapauksessa tällä testillä pystyttiin osoittamaan, että palveluväylässä pullonkaulaa sanomien välityksessä ei muodostunut. Jos pullonkaula muodostui, olivat syyt jossain muualla järjestelmässä, esimerkiksi verkkoyhteyksissä tai palvelupuolen sovelluksessa – kuten tässä tapauksessa todettiin.

Yhteenvetona voi sanoa, että palveluväylän suorituskyky osoittautui merkittävästi paremmaksi ulkoista kuormantasaajaa käytettäessä.

Ulkoisen kuormantasaajan kolme tärkeää hyötyä

Kolme suurinta kuormantasaajan tuomaa etua ovat skaalautuvuus, korkea saatavuus ja hallittavuus. Jos esimerkiksi liityntäpalvelimen toimintaan tarvitaan lisää suorituskykyä vaikkapa lisääntyneen käytön takia (palvelukutsuja tulee jatkossa yhä enemmän), voidaan nykyinen liityntäpalvelin kloonata toiseksi tai useammaksi liityntäpalvelimeksi. Kuorma jakaantuu tällöin kahdelle tai useammalle liityntäpalvelimelle. Näin yhtäaikaisten käyttäjien määrää voidaan kasvattaa ja vasteajat pienevät.

Kuormantasaajan avulla järjestelmä toimii aikaisempaa paremmin myös mahdollisissa vikatilanteissa. Kuormantasaaja poistaa vikaantuneen liityntäpalvelimen käytöstä (liikennettä ei enää ohjata sille) ja liikenne ohjautuu muille, toiminnassa oleville liityntäpalvelimille. Järjestelmän toimintavarmuutta voidaan parantaa vielä lisää kahdentamalla (HA toiminnallisuus) myös itse kuormantasaaja niin, että niitä on kaksi kappaletta toimintakunnossa. Tällöin yhden kuormantasaajan vikaantuminen ei lamauta järjestelmän toimintaa.

Hallittavuudella tarkoitetaan sitä, että liityntäpalvelinklusterin toimintaa voidaan hallita kuormantasaajan avulla. Esimerkiksi liityntäpalvelimia huollettaessa tai päivitettäessä voidaan kuormantasaajalle kertoa, että kyseinen liityntäpalvelin ei ole toimintakunnossa, eikä sille saa ohjata toistaiseksi liikennettä. Tällainen tilanne voi tulla vastaan vaikkapa päivitettäessä liityntäpalvelimen ohjelmistoa uuteen versioon, jolloin päivityksen ajaksi kyseinen palvelin otetaan pois klusterista. Palvelin palautetaan kun ohjelmisto on päivitetty.

Milloin kuormantasausta kannattaa käyttää?

Ulkoisen kuormantasaajan käyttöä kannattaa harkita ainakin siitä tapauksessa, jos yhtäaikaisia palvelukutsuja tulee (tai voi tulla) niin paljon, ettei yhden liityntäpalvelimen kapasiteetti riitä palvelemaan kaikkia palvelukutsuja riittävän nopealla vasteajalla. Lisäksi, jos äkillisiä kuormituspiikkejä on odotettavissa, voidaan palvelun toimivuus varmistaa näiden ruuhkahetkien ajalle kuormatasauksella ja lisäämällä liityntäpalvelimia klusteriin. Tarkkoja palvelukutsujen määriä, jolloin kuormantasaajan käyttö on suositeltavaa on hankalaa sanoa. Muuttuvia tekijöitä tässä yhtälössä ovat esimerkiksi palveluntarjoajan liityntäpalvelimen kapasiteetti ja suorituskyky (mm. muisti ja suoritin), sekä palveluväylään tarjottavalle palvelulle ominainen käytös, esimerkiksi miten suuria sanomia sen pitää käsitellään ja miten usein. Ohjeistusta yksittäisen liityntäpalvelimen mitoitukseen löytyy täältä: Liityntäpalvelimen tekniset vaatimukset. Arviona voisi sanoa, että silloin kun yhtäaikaisten käyttäjien määrä nousee useisiin kymmeniin tai satoihin (tai jopa tuhansiin) ja palvelun on pystyttävä käsittelemään satoja tai tuhansia sanomia lyhyessä ajassa, on kuormantasaajan käyttö suositeltavaa.

Mikäli palvelun saatavuus on ehdottaman tärkeää on kuormantasaajan käyttö tällöin perusteltua. Jos esimerkiksi ohjelmistopäivitykset on pystyttävä tekemään ilman katkosta, on kuormantasaaja ehdoton valinta, koska yksittäinen liityntäpalvelin voidaan irrottaa huoltotoimenpiteitä varten klusterista. Muut klusterin liityntäpalvelimet mahdollistavat palvelun toiminnan tällä välin.

Ulkoisen kuormantasaajan käyttämisestä palveluväylässä julkaistaan asennus- ja konfigurointiohjeet. Kannattaa huomioida, että palveluväylä mahdollistaa ulkoisen kuormantasaajan käytön, mutta kuormantasaajan hankinta, konfigurointi ja ylläpito oman palvelun käyttöön on kunkin organisaation vastuulla. Teknisenä yksityiskohtana mainittakoon, että käytettävän kuormantasaajan pitää tukea HTTP-pohjaista statustilan tarkistusta (ns. health check toiminnallisuus klusterin noodeille) sekä TCP-tason kuormantasausta. Ehdottomasti suositellaan myös, että kuormantasaajan toiminta on varmennettu HA toiminnallisuudella, jolloin yksittäisen kuormantasaajan vikaantuminen ei lamauta koko järjestelmän toimintaa.

Yhteenveto

Palveluväylä on suorituskykyinen tapa siirtää tietoa. Jatkossa sinne liitettyjen palveluiden suorituskykyä voidaan skaalata ylöspäin melkeinpä miten paljon vain. Tämä tehdään kuormantasauksen avulla liittämällä klusteriin lisää liityntäpalvelimia. Palveluväylä tuo tiedonsiirtoon tietoturvaa, aikaleimausta, varmenteita ja vakioituja ratkaisuja palveluiden liittämiseksi ja käyttämiseksi väylässä. Palveluväylä tarjoaa siis tietoturvalla varustettua siirtokyvykkyyttä. Ostoskanavan sanoin, ei siinä vielä kaikki: tämä kaikki on saatavilla valmiina paketoituna kokonaisuutena, jossa on mukana monipuoliset ohjeistukset. Ja se on vieläpä käytettävissä ilmaiseksi! Liity mukaan Palveluväylään

Hannu Hakala

Kirjoittaja työskentelee IT-alan palveluyritys Cybercomin palveluksessa ja on Suomi.fi-palveluväylän tuoteomistaja. Hän on innokas digitalisoitumisen puolestapuhuja: ”Mikä onkaan hienompaa, kuin tehdä digitalisaatiota kotimaan hyväksi”.

Aika ajatella digisti – Suomi.fi-palveluväylä keskiössä

Suomi.fi-palveluväylä tuli tuotantoon marraskuussa 2015 ja KaPA-laki astui voimaan 15.7.2016, mikä toi julkishallinnolle velvoitteen käynnistää liittymistoimenpiteet Palveluväylään. Palveluväylän käyttöön on oikeus myös yksityisellä sektorilla, minkä korostaminen on jäänyt hieman julkishallinnon lakivelvoitteesta tiedottamisen varjoon. Palveluväylään liittyneet organisaatiot ovat nähtävillä api.suomi.fi:stä eli liityntäkatalogista. Palveluväylässä on mukana (6.7.2017) 79 rajapintapalvelua ja 52 organisaatiota. Palveluväylän kautta on saatavilla jo nyt muun muassa kiinteistö-, ajoneuvo- ja opintotietoja. Valikoima laajenee entisestään tulevaisuudessa.

Suomi kehittää Palveluväylän taustalla olevaa X-Road -teknologiaa yhteistyössä Viron kanssa. Yhteistyö ei ole pelkästään teknistä kehittämistä; Suomen Palveluväylän ja Viron X-Teen testiympäristöt liitettiin yhteen 6.6.2017. Semic 2017 -konferenssissa kesäkuussa Viron talous- ja viestintäministeriön Janek Rozov kertoi X-Roadin olevan Viron kiireisin tie: X-Roadissa on tarjolla yli 2000 palvelua, yli 900 liittynyttä tietokantaa tai organisaatiota ja yli 500 miljoonaa tiedonsiirtoa vuosittain.  X-Road on vakiinnuttanut asemansa Virossa. Vaikka Suomen Palveluväylän luvut vielä kalpenevat Viron vastaaville, niin esimerkiksi pelkkä tunnistuspalvelu Suomi.fi-tunnistus käyttää taustalla Palveluväylää tänäkin vuonna noin 50 miljoonaa kertaa. Olisi siis aika kääntää asenne ”Eihän Palveluväylää hyödynnä vielä juuri kukaan” asenteeksi ”Totta kai me hyödynnämme Palveluväylää, miksette tekin?”

Tiedon jakeluratkaisu kehittyy syksyllä

YTI – Yhteinen tiedon hallinta -hanke on yksi hallituksen kärkihankkeista. Väestörekisterikeskuksessa toteutetaan kehitystyö YTI-hankkeen työpaketteihin omadatasta, yhteentoimivuusvälineistöstä ja monipuolisesta tiedon jakeluratkaisusta. YTI-hankkeen tavoitteena on, että kerran asiakkaalta kysyttyä tietoa ei tarvitsisi enää kysyä uudestaan, vaan tietoa pystytään käyttämään ja jakamaan yhteisesti eri organisaatioiden välillä.

Organisaatioiden välillä siirretään suuria tietomääriä, ja palveluiden sähköistyessä nopean ja helpon tiedonsiirron merkitys korostuu. Palveluväylällä on tässä iso rooli. Se mahdollistaa tiedonsiirrot organisaatioiden välillä – niin massasiirrot kuin tulevaisuudessa tiedonsiirrot omadata-periaatteellakin. Palveluväylän kehityksessä tavoitellaankin ns. kansallista integraatiokulttuuria, jossa tiedon tai tiedoston koko ja tiedonsiirron aikasykli ovat vain tekijöitä muiden joukossa siirtokanavaa ja -tapaa valittaessa eikä niistä muodostu esteitä Palveluväylän käytölle.

Pelkkä tiedon siirto ei aina riitä. Lisäksi voi olla tarpeen yhdistää eri lähteistä tulevaa tietoa tai tallentaa tietoa siirron ja jakelun ajaksi. Tiedon yhdistämiseen voidaan soveltaa ydintiedon menetelmiä. Suurten tietomäärien analysointi on lisääntymässä, joten tieto kannattaa tallentaa muodossa, joka mahdollistaa sen monipuolisen käytön. Tietoa ei myöskään aina välttämättä tarvitse siirtää, jos siihen voidaan luotettavasti viitata, esimerkiksi pysyvien tunnisteiden avulla.

Etsinnässä pilottiorganisaatioita

Palveluväylä toimittaa tällä hetkellä nopeita, mutta melko pieniä viestejä. YTIssä käynnistyy kehitystyö Palveluväylän kautta tapahtuviin suurten tietomäärien siirtoon. Etsimme nyt organisaatioita, jotka haluavat pilotoida suurten tiedostojen jakelua Palveluväylää hyödyntäen. Yhteydenotot: yhteentoimivuus@vrk.fi

Lopuksi

Semic 2017 -konferenssin aloituspuheessaan Euroopan komission Gertrud Ingestad totesi, että julkishallinnolta odotetaan laadukkaita palveluja: Kansalaiset nauttivat digitalisaation tuomista mahdollisuuksista elää vapaammin ja esimerkiksi työskennellä EU-alueella. Tämä tarkoittaa julkishallinnolle sitä, että meidän pitää olla tehokkaampia, modernimpia ja pystyä muuttumaan itse, jotta toimintatapamme vastaavat yhteiskunnan tarpeisiin.

Tähän haasteeseen meidän on tartuttava.

Jaana Nevalainen

Kirjoittaja työskentelee Väestörekisterikeskuksessa YTI-hankkeen hankepäällikkönä.

Integraatioilla iloa Suomi.fi-palvelutietovarannosta

Suomi.fi-palvelutietovaranto kokoaa tiedot julkisten organisaatioiden palveluista yhteen paikkaan. Esimerkiksi lukuisissa kunnissa on parhaillaan käynnissä kehitysprojekteja, joissa Palvelutietovarannon sisältämä tieto laitetaan hyödyttämään niin kuntalaisia kuin kuntaorganisaatiotakin. Palvelutietovarannon käyttöönottoon voi vielä saada valtiovarainministeriön rahoitusta.

KaPA-laki velvoittaa tietyt julkishallinnon organisaatiot kuvaamaan palvelunsa Suomi.fi-palvelutietovarantoon 1.7.2017 mennessä. Palvelutietovarannon tavoitteena on yhdenmukaistaa ja koota yhteen meitä kaikkia kansalaisia koskeva tieto julkishallinnon palveluista.

Moni julkinen organisaatio, erityisesti kunta, onkin ryhtynyt jo miettimään, miten Palvelutietovarantoon sisällyttämä tieto voitaisiin laittamaan palvelemaan sekä kuntaa että kuntalaisia. Työkaluksi ollaan kehittämässä erilaisia integraatioratkaisuja, joilla Palvelutietovarannon tieto saadaan näkyville julkaisujärjestelmien (esim. Drupal, WordPress) kautta esimerkiksi kunnan nettisivuille.

Palvelutietovarannon käyttöönotoista vastaava projektipäällikkö Annette Hotari kertoo, että integraatioratkaisuilla organisaatio saa selkeitä hyötyjä.

– Integraatioratkaisujen avulla tieto voidaan pitää yllä yhdessä perusrekisterissä, joka toimii tämän tiedon master-tietona. Näin tiedot voidaan päivittää vain yhteen paikkaan, josta ne ovat kaikkien saatavilla, Hotari kertoo.

Näin voidaan sekä säästää että parantaa tiedon laatua.

– Tiedon ylläpitokustannuksia voidaan pienentää, kun tieto päivitetään yhteen paikkaan. Tietojen laatuun eri järjestelmissä voi luottaa, kun ne haetaan samasta perusrekisteristä.

Mikkeli ja Turku kehittämässä omia ratkaisujaan

Esimerkiksi Mikkelin kaupunki on jo tehty pitkään töitä oman integraatioratkaisunsa kanssa. Päätöksen takana oli halu järkevöittää omaa toimintaa, kertoo Mikkelin palvelukehityspäällikkö Heli Hänninen.

– Ratkaisua ei vielä ollut kenelläkään ja olimme päättäneet, että Palvelutietovaranto tulee toimimaan palveluiden master-datana. Olimme päättäneet päästä eroon palvelutietojen ylläpidosta lukemattoman monissa eri paikoissa, Hänninen kertoo.

Mikkeli päätti toteuttaa integraatioratkaisun teknisesti KuntaAPIn kautta. Hännisen mukaan KuntaAPIn avulla Palvelutietovarannon tietoja voidaan yhdistellä muihin kunnan tietovarantoihin.

– Palvelutietovarannon tiedot haetaan avoimeen rajapintaan KuntaAPIin, jota kautta data on esimerkiksi www-sivujen saatavilla. Samaan rajapintaan haetaan informaatiota myös muista järjestelmistä, kuten esimerkiksi asiahallintajärjestelmästä, yhteystiedoista ja niin edelleen. Lisäksi järjestelmä mahdollistaa PTV-tiedon rikastamisen esimerkiksi kuvilla, lisätekstillä tai videoilla, Hänninen kertoo.

Uusin lisätty datalähde onkin Hännisen mukaan paikallisliikenteen aikatauludata.

– KuntaAPI on integraatioratkaisuna notkea.

KuntaAPIn ”päälle” voidaan www-sivujen lisäksi rakentaa muita järjestelmiä, esimerkiksi mobiiliapplikaatio. Rajapinta mahdollistaa näiden tietojen esittämisen ja käsittelemisen toisissa järjestelmissä sekä tietojen yhdistämisen ja rikastamisen.

KuntaAPIn rajapinnan avulla on mahdollista yhdistellä tietoja monista eri lähteistä.

Samankaltainen projekti on käynnissä Turun kaupungilla, kertoo Turun kokonaisarkkitehtuurista vastaava kehityspäällikkö Jaakko Ståhlberg. Toisin kuin Mikkeli, Turku päätti viedä olemassa olevat rekisteritietonsa Palvelutietovarantoon In-rajapinnan kautta. Turussa nettisivut näyttävät siis jatkossakin kaupungin omaa palvelutietodataa, mutta tieto päivittyy myös Palvelutietovarantoon yhdellä kertaa.

– Päädyimme omaan ratkaisuun, jossa oma yhteisten tietojen varastomme yhdenmukaistetaan Palvelutietovarannon vaateisiin ja sisällöntuottajille jää ainoastaan kertapäivitysvastuu. Omalla tietovarastollamme tuemme asiakkuuksien ja palvelujenhallinnan toimintamalliamme. Siinä myös ylläpidetään enemmän tietoa, kuin mitä Palvelutietovarannon kentät mahdollistavat. Tietoja tullaan hyödyntämään myös muissa taustajärjestelmissä, jolloin lisäkenttiä tarvitaan myös tästä syystä.

Integraatioratkaisujen kehittäminen on sujunut sekä Ståhlbergin että Hännisen mukaan hyvin. Jaakko Ståhlbergin mukaan Turku suunnitteli projektinsa melko tarkkaan, joskin muutokset Väestörekisterikeskuksen päässä Palvelutietovarannon kentissä ja rajapinnoissa aiheuttivat välillä epätietoisuutta.

Heli Hännisen mukaan Mikkelissä on täytynyt ottaa uudenlainen katse kaupungin toimintaan:

– Palvelutietojen uusi esittämistapa on vaatinut kaupungin päässä tietomallin sisäistämistä sekä töiden uudelleenorganisointia.

Turussa kehitystyötä on Ståhlbergin mukaan tehty tiukassa yhteistyössä useamman IT-toimittajan kanssa. Mikkeli puolestaan rakensi oman integraation yhdessä paikallisen kansanopiston, Otavan opiston kanssa.

Kumpikin kaupunki on avaamassa koodinsa vapaasti muiden käyttöön. Näin muut julkishallinnon organisaatiot voivat rakentaa omat sovellutuksensa Mikkelin ja Turun tekemän työn pohjalle. Turun Drupal-integraation avoin turku.fi -lähdekoodi on jo vapaasti saatavilla.

– Toivottavasti jokin kunta koodin käyttöönoton yhteydessä tekee suoran integraation Drupalista PTV:hen, ilman väliin tulevaa integraatioalustaa, niin kuin meillä, Ståhlberg vinkkaa koodin jatkokehityksestä kiinnostuneita.

Mikkelin projekti on Heli Hännisen mukaan ollut alusta asti avoimen lähdekoodin hanke. Avoimella lähdekoodilla Mikkeli yrittää myös edistää koko kansallista palveluarkkitehtuuria.

– Kuntien on uskallettava lähteä kohti kansallista palveluarkkitehtuuria ja julkisen hallinnon yhteistä asiakasta. Tekemällä asioita yhdessä julkisen hallinnon asiakaspalvelu harmonisoituu.

Käyttöönottoon tukea valtiovarainministeriöltä

Palvelutietovarannon käyttöönottoon on mahdollista hakea rahoitusta valtiovarainministeriöltä. Turun kaupunki on käyttänyt mahdollisuutta hyväkseen.

– Rahoitusprosessi työllisti jonkin verran, sillä samalla projektin sisältö suunniteltiin tarkasti niin hyvin, kuin se etukäteen oli mahdollista, kertoo Jaakko Ståhlberg.

Rahoitushaku Palvelutietovarannon käyttöönottoa varten päättyy 31.5.2017, kertoo valtiovarainministeriön neuvotteleva virkamies Pauli Kartano.

– Tämän haun jälkeen lakisääteistä käyttöönottoa ei enää tueta, joten kannattaa hakea nyt Palvelutietovarannon rahoitushaku on myös kevyempi kuin muut KaPA-rahoitushaut. Hakulomake on yhden Excel-sivun mittainen ja tukisummat määräytyvät mekaanisesti kunnan asukasmäärän, tai kuntayhtymillä ja virastoilla ja muilla organisaation henkilömäärän mukaan, Kartano muistuttaa.

Mitä viimeisiä vinkkejä Hännisellä ja Ståhlbergillä olisi omaa integraatioratkaisua suunnitteleville organisaatioille? Heli Hänninen kehottaa ryhtymään rohkeasti toimeen.

– Jos PTV-työhön ei ole vielä lähdetty, nyt viimeistään on sen aika! Juuri kunnissa kannattaakin harkita nyt KuntaAPIn kaltaista järjestelmää, jossa samalla vaivalla integroidaan useampi järjestelmä – eikä tehdä pelkkää PTV-integraatiota.

Turku voi Ståhlbergin mukaan tarjota talkoohengessä apua integraatiota harkitseville:

– Mikäli yleistä kiinnostusta löytyy, niin Turku on valmis tekemään karkean tason ohjeistuksen projektissa huomioonotettavista seikoista.

Annette Hotari suosittelee yhteistyötä:

– Kannattaa ensin olla yhteydessä naapurikuntiin ja katsoa, voisiko integraation toteuttaa yhdessä. Esimerkkinä kannattaa tarkkailla esimerkiksi Janakkalan vetämää projektia, jossa on mukana viisi muuta kuntaa ja tuloksena tulee olemaan WordPress-lisäosa, jolla tietoja voi hakea tai tallentaa Palvelutietovarantoon.

– Ja tottakai tukitiimimme tukee käyttöönottoja tarjoamalla aihekohtaisia koulutuksia ja työpajoja, Hotari lupaa.

237 painallusta myöhemmin

Näkövammaisten liitto julkaisi loppuvuodesta 2016 videon verkkopalvelujen saavutettavuudesta. Hauskan tarinan taustalla on tutkittua tietoa suomalaisten julkisten verkkopalveluiden toimivuudesta (tai tässä tapauksessa toimimattomuudesta) tasavertaisesti kaikille käyttäjille. Videossa konkretisoituu se, että digitaaliset palvelut eivät ole vielä yhdenvertaisesti kaikkien kansalaisten käytettävissä. Jotakin asialle pitäisi tehdä.

 

EU:n saavutettavuusdirektiivi

EU:n alueella on unionin arvion mukaan sähköisiä julkisia palveluja tarjoavia verkkosivustoja noin 380 000 kappaletta. Julkisten organisaatioiden www-sivustojen määräksi arvioidaan noin 760 000 kappaletta. Näiden palvelujen kehittämiseen käytetään vuosittain arviolta 2 miljardia euroa. Tarkkaa tietoa Suomessa olevista palveluista ei ole, mutta julkisten toimijoiden www-sivustoja ja sähköisiä asiointipalveluja lienee satoja tai tuhansia.

Isoista markkinoista huolimatta palvelujen saavutettavuus vaihtelee merkittävästi EU-maasta toiseen, eikä yhdenmukaisia sisämarkkinoita saavutettavien palvelujen kehittämiseksi ole syntynyt. Samalla kansalaisten mahdollisuus toimia yhdenvertaisesti digitaalisessa yhteiskunnassa ei ole toteutunut.

Tilanteen korjaamiseksi Euroopan parlamentti hyväksyi viime lokakuussa direktiivin julkisten verkkopalvelujen ja mobiilisovellusten saavutettavuudesta. Direktiivi astui voimaan joulukuussa 2016. Se koskee Suomessa vähintään kaikkia niitä organisaatioita, joita hankintalakikin koskee (mm. kaikki kunnat, kuntayhtymät ja valtion virastot). Soveltamisala Suomessa tarkentuu kansallisen lainsäädännön myötä.

Aikataulu

Kansallinen lainsäädäntö tulee voimaan viimeistään 23.9.2018 alkaen. Saavutettavuusdirektiiviä sovelletaan vaiheittain:

  • Ennen 23.9.2018 julkaisemattomiin verkkopalveluihin (eli uudet verkkopalvelut) 23.9.2019 alkaen
  • Verkkopalveluihin, jotka on julkaistu ennen 23.9.2018 (eli vanhat verkkopalvelut) 23.9.2020 alkaen
  • Mobiilisovelluksiin 23.6.2021 alkaen
  • Ekstranetien ja intranetien sisältöön, jotka on julkaistu ennen 23.9.2019, vasta kun sivustot uudistetaan perinpohjaisesti (eli palvelujen elinkaaren mukaan)

Vaatimukset

Direktiivin myötä luodaan EU-laajuiset, yhdenmukaiset minimitason vaatimukset julkisen hallinnon verkkopalvelujen ja mobiilisovellusten saavutettavuudelle. Lähtökohtana on standardi saavutettavuuden huomioimisesta hankinnoissa. Käytännössä standardi pohjautuu kansainvälisen, internetiä standardoivan järjestön W3C:n julkaisemaan suositukseen, ns. WCAG 2.0 -kriteeristöön. Suomessa erittäin kattavan aineiston saavutettavuuden huomioimisesta verkkopalveluissa on jo koonnut Kehitysvammaliitto. Ohjeistosta löytyy tukea niin palveluista vastaaville organisaatioille kuin verkkopalveluja kehittäville yrityksille.

Saavutettavuusdirektiivi velvoittaa jäsenmaat informoimaan verkkopalveluiden ja mobiilisovellusten käyttäjiä palvelujen saavutettavuudesta erillisellä selosteella. Lisäksi käyttäjillä on oltava mahdollisuus antaa palautetta. Jäsenmaiden tulee myös nimetä toimija, joka vastaa toimeenpanon seurannasta ja raportoinnista komissiolle. Tälle toimijalle voi tulevaisuudessa myös valittaa, jos palvelut eivät täytä annettuja saavutettavuusvaatimuksia.

Kansallinen lainsäädäntö

Suomessa direktiivin vaatima lainsäädäntötyö on alkanut valtiovarainministeriön johtamana.  Toimeenpanoa varten on asetettu työryhmä viime tammikuussa. Työryhmä valmistelee hallituksen esityksen saavutettavuusdirektiivin velvoitteiden huomioimiseksi Suomen lainsäädännössä.

Työryhmässä on mukana edustajia eri julkisen hallinnon organisaatioista ja kolmannelta sektorilta, erityisesti järjestöistä. Työskentely tapahtuu säännöllisten tapaamisten lisäksi avoimesti Innokylä-palvelussa. Kansallinen lainsäädäntö tulee velvoittamaan direktiivin mukaisesti julkisia toimijoita kehittämään palveluja käyttäjät tasavertaisesti huomioiden.

Saavutettavuuden merkityksestä

Jokainen meistä on jossakin elämäntilanteessa tai -vaiheessa esteellinen käyttäjä. Sähköisten palvelujen käyttäminen vaikeutuu merkittävästi fyysisten esteiden ilmaantuessa ikääntymisen myötä. Heikentyvä näkö, hitaampi ajattelu tai häiritsevä ympäristö tekevät nopeasti palvelujen käytöstä paljon vaikeampaa. Myös arkielämän vastoinkäymiset, kuten murtunut käsi tai rikkoontuneet silmälasit voivat antaa osviittaa saavutettavuuden merkityksestä. 237:ää painallusta voit harjoitella jo itsekin omassa verkkopalvelussasi siirtämällä hiiren sivuun ja kokeilemalla palvelun käyttöä pelkällä näppäimistöllä.

Suomessa on merkittävä määrä ihmisiä, joille ideaalitilanteeseen ja keskivertokäyttäjälle suunnitellut palvelut eivät toimi joko ollenkaan tai vaikeuttavat asiointia merkittävästi. Kyse ei siis ole erityisryhmien huomioimisesta, vaan yksinkertaisesti palvelujen paremmasta laadusta kaikille käyttäjille. Jatkossa julkisten verkkopalvelujen laatuun tuleekin kiinnittää huomattavasti enemmän huomiota. Direktiivin myötä kyse ei ole enää vapaaehtoisuudesta – pikemmin voisi kai puhua käsitteestä ”design for all by law”.

Infotilaisuuksia kunnille

Saavutettavuusdirektiivin toimeenpanosta informoidaan julkisia organisaatioita kuluvan vuoden aikana. Ensimmäiset online-infotilaisuudet kunnille järjestetään 14.3. ja 4.4. Tilaisuuksiin ilmoittautuminen on nyt käynnissä täällä.  Tilaisuudet järjestetään yhteistyössä valtiovarainministeriön, Kuntaliiton ja Väestörekisterikeskuksen kesken.

Tervetuloa mukaan kuulemaan lisää saavutettavuudesta!

Jani Ruuskanen

Kirjoittaja toimii Suomi.fi-verkkopalvelun hankepäällikkönä ja on mukana saavutettavuusdirektiivin toimeenpanon asiantuntijaryhmässä Suomen edustajana sekä kansallisen saavutettavuuden lainsäädännön toimeenpanon työryhmässä.

Suomi.fi-palveluiden tietoturva on kuin sipuli

Kansallista palveluarkkitehtuuria on alusta saakka rakennettu turvallisuus keskiössä, kertoo tietoturva-asiantuntija Pasi Korhonen. Työssä on otettu huomioon ulkopuoliset uhat – mutta myös inhimillisen erheen mahdollisuus on minimoitu. Yhteinen palveluarkkitehtuuri kaikille parantaa tietoturvaa.

Read more

Yritykset hyötyvät Suomi.fi-palveluista

Kansallinen palveluarkkitehtuuri (KaPA) rakentaa sähköisen asioinnin tukipalveluitaan yhtä lailla yrityksiä kuin julkishallintoa varten. Kun KaPA tarjoaa sähköisten palveluiden perustan, voi paukut säästää oikeaan palvelu- ja tuotekehitystyöhön. KaPAn asiakaspalvelu tarjoaa tukea palveluiden käyttöönottoa varten.

Read more

Ulkomailta oppia palveluarkkitehtuuriin

Julkishallintoa digitalisoidaan ahkerasti eri puolilla maailmaa. Myös KaPAn tekijät ovat hakeneet oppeja ulkomailta. Suomi ei todellisuudessa ole kansainvälisesti digitalisaation jälkijunassa, kertoo Janne Viskari. Read more

Suorituskykyinen Suomi.fi-palveluväylä

Suomi.fi-palveluväylä tarjoaa vakioidun tavan tietojen siirtoon organisaatioiden välillä mahdollistaen turvallisten palvelukokonaisuuksien rakentamisen kansalaisille, yrityksille ja viranomaisille. Tämän palveluväylä tarjoaa ja lupaa. Mitä sanan ”siirtoon” taakse kätkeytyy? Minkälaista dataa palveluväylässä voidaan itseasiassa siirtää ja miten suorituskykyinen se on? Yritän kirjoituksessani avata asiaa, koska useissa keskusteluissa useiden eri tahojen suunnalta on kysytty tätä ja toivottu selkeytettävän.

Historiaa

On totta, että X-Roadissa käytettävä SOAP-tiedonsiirtoprotokolla on alun perin suunniteltu pienten sanomien siirtoon. Moni on ihmettelyt, miksi ylipäätään SOAP-tiedonsiirtoprotokollaa käytetään X-Roadin perustekniikkana. Eikö olisi järkevämpää käyttää jotain nykyaikaisempaa protokollaa, vaikkapa REST/JSON-pohjaista tekniikkaa? Lyhyt vastaus on, että kun koko X-Road-järjestelmää aloitettiin suunnittelemaan 90-luvun loppupuolella Virossa, mietittiin, mikä olisi hyvä ja luotettava tapa siirtää dataa silloisissa tietoverkoissa ja käytössä olevilla protokollilla. Siihen aikaan kun varteenotettavia ja jo hyväksi koettuja protokollia ei ollut liiemmälti. Silloin päätettiin valita käyttöön XML-pohjainen XML-RPC-protokolla. XML oli tullut silloin jo laajemmalti käyttöön (vuonna 1996 julkistettiin ensimmäinen luonnosversio XML-spesifikaatiosta ) ja näytti, että siitä tulee valtaprotokolla tiedon siirtoon tietoverkoissa, joten valinta oli luonteva.

Vuonna tehtiin 2002 SOAP RPC/encoded -tuki, SOAP document/litteral wrapped -tuki valmistui vuonna 2010. Viron puolella nykyisen SOAP-protokollan vakiintuminen ja laaja käyttö ovat valideja perusteluja sille, miksi SOAP- protokollaa edelleenkin käytetään X-Roadin pohjana. Suomen puolella ei ole toistaiseksi lähdetty tekemään poikkeavaa linjausta, koska se vaatisi aika ison kehitystyön. Ajatus- ja ideatasolla tätä on jo mietitty.

REST/JSON-sovitin saatavilla

REST/JSON-pohjaisten järjestelmien liittäminen Suomi.fi-palveluväylään on kuitenkin mahdollista niin sanotun Rest Gateway -sovittimen avulla. Komponentti on saatavilla ilmaiseksi avoimena lähdekoodina Github repositoriosta. Komponenttia on testattu ja koestettu paljon ja sitä käytetään jo useissa erilaisissa palveluväyläliitynnöissä kytkemään REST/JSON-pohjainen tietojärjestelmä palveluväylään.

Suorituskyvyn parantaminen syksyn teemana kehitystyössä

Syksyn aikana Suomessa tehdyssä Palveluväylän kehitystyössä on keskitytty suorituskyvyn parantamiseen, jotta palveluväylän siirtokyky tukee paremmin erityisesti Suomessa väylään liittyviä organisaatioita. Suorituskykyä on parannettu mm. optimoimalla tietokantahakujen suorittamista, kehittämällä varmenteiden tarkistuksessa käytettävän OCSP-palvelun (Online Certificate Status Protocol) toimintaa ja parantamalla välimuistin käyttöä. Viimeisimpänä isona parannuksena on julkistettu ohjeistus siitä, miten muistiasetuksia kannattaa säätää omalla palvelinalustalla. Ohjeistus auttaa jokaista palveluväylään liittynyttä organisaatiota parantamaan oman liityntäpalvelimensa suorituskykyä, koska liityntäpalvelimen asennuspaketissa asetettavat vakioasetukset eivät useinkaan sovellu suoraan käyttöön, ainakaan optimaalisella tasolla. (Lisää muistiasetuksien optimoinnista täältä). Ohjeiden lukeminen ja käyttöönotto todellakin kannattaa, koska se auttaa parantamaan liityntäpalvelimen suorituskykyä merkittävästi.

Ystävämme Virossakaan eivät ole lepäilleet laakereillaan, vaan ovat omalta osaltaan tuoneet panoksensa X-Road-väylän suorituskyvyn parantamiseksi. He ovat toteuttaneet mm. uuden SOAP Body parserin, jonka pitäisi tuoda huomattavaa suorituskyvyn parannusta ja muistin käytön optimointia viestien välitykseen. Heiltä saatujen alustavien suorituskykytestien pohjalta puhutaan useiden kymmenien prosenttien parannuksesta varsinkin suurilla (>= 1MB) ja kompleksista rakennetta sisältävillä SOAP-viesteillä. Tämä merkittävä parannus on tulossa seuraavaan julkaistavaan versioon (versio 6.9.0). Tarkempia mittaustuloksia saadaan, kunhan teemme Suomen palveluväylässä omat suorituskykymittauksemme.

Yleinen suorituskyky

Palveluväylän yleisestä suorituskyvystä puhuttaessa voidaan antaa tiettyjä yleislinjauksia siitä, minkälaiseen tiedonsiirtoon palveluväylä on suunniteltu ja missä se on parhaimmillaan. Lopulta väylän siirtokyvykkyys eri järjestelmissä riippuu monesta eri asiasta, kuten: minkälaisia viestejä halutaan siirtää, miten isoja ne ovat, mikä on käytettävän verkon siirtonopeus ja miten paljon yhtäaikaisia käyttäjiä/palvelukutsuja järjestelmässä on. Alla on listattuna muutama ohjenuora, minkälaisiin tiedonsiirtoihin palveluväylä on erityisen soveltuva:

  • Parhaimmillaan siirtokyky on siirrettäessä pieniä synkronisia viestejä
  • Sanomakoolla 100 kt ja alle suorituskyky on paras
  • Yli 500 kt sanomakoolla suorituskyky laskee jonkin verran

Suorituskykymittausten tuloksia

Jotta palveluväylän suorituskyvystä saisi paremman kuvan ja sitä voisi verrata vaikkapa oman järjestelmän tarpeisiin, on alla esitelty suorituskykymittausten tuloksia. Palveluväylän jokainen julkaistava versio suorituskykytestataan kattavasti ja mittaustulokset dokumentoidaan säännönmukaisesti. Saatuja tuloksia analysoidaan ja verrataan esimerkiksi edellisen version mittaustuloksiin, jotta nähdään, miten suorituskyky on muuttunut eri versioiden välillä.

Testit suoritetaan kuvan 1 mukaisella testijärjestelmällä. Kuormageneraattorilla ajetaan pyyntösanomia asiakaspään liityntäpalvelimelle (Security Server 1), joka pyytää sanomiin vastausta palveluntarjoajan liityntäpalvelimelta (Security Server 2). Tämä liityntäpalvelin saa vastaukset testipalvelulta. Testipalvelu tuottaa vakiovastauksen sekä siihen liittyvät liitetiedostot, ja sanomakoot voidaan määritellä testin konfiguroinnilla. Vastaussanoma kulkee samaa reittiä takaisinpäin ja testissä mitataan, miten kauan koko viestiketjun (kyselysanoma – vastaussanoma) suorittamiseen kuluu aikaa.

palveluvayla_blogi_suorituskykytestaus

Kuva 1. Suorituskykymittauksen testijärjestely.

Testit ajetaan niin, että ensin määritetään kyseisessä testiajossa siirrettävä sanomakoko. Tämän jälkeen määritellään, miten yhtäaikaisten käyttäjien määrää lisätään testin aikana. Tyypillinen skenaario on, että testin aluksi käyttäjiä on 1, jonka jälkeen määrää kasvatetaan: käyttäjämäärä nousee askelittain, suurimmillaan yhtäaikaisia käyttäjiä on normaalitapauksessa n. 150-300.

Seuraavissa kuvissa on esitetty kolme eri testimittausta 100 B, 100 K ja 500 K viestipaketeilla uusimmalla liityntäpalvelimen versiolla (versio 6.7.13) suoritettuna ja suositeltavin muistiasetuksin tehtynä. Kumpikin liityntäpalvelin on varustettu samanlaisella alustakokoonpanolla:

  • OS: Red Hat 7
  • Keskusmuisti: 4 Gb
  • 1 CPU (E5-2650 v3, 2.50 GHz)
  • Levytila: 7 Gb

Kuvissa esiintyvä lyhenne TPS tarkoittaa ’Transactions Per Second’, eli montako tapahtumaa sekunnissa tapahtuu ja ’Transactions’ termi tarkoittaa tapahtumien lukumäärää, eli montako viestipakettia on siirretty. Kullekin tietyn kokoiselle viestipaketille on esitetty aina kaksi kuvaa: mittaustulokset vasteajoille ja tapahtumamäärät testin suorituksen aikana.

100B viestipakettien mittaustulokset

palveluvayla_blogi_100b_response_times

Kuva 2. 100B viestipakettien vasteajat.

palveluvayla_blogi_100b_transactions

Kuva 3. 100B viestipakettien tapahtumamäärät.

100K viestipakettien mittaustulokset

palveluvayla_blogi_100k_response_times

Kuva 4. 100K viestipakettien vasteajat.

palveluvayla_blogi_100k_transactions

Kuva 5. 100K viestipakettien tapahtumamäärät.

500K viestipakettien mittaustulokset

palveluvayla_blogi_500k_response_times

Kuva 6. 500K viestipakettien vasteajat.

palveluvayla_blogi_500k_transactions

Kuva 7. 500K viestipakettien tapahtumamäärät.

Mittaustuloksista lyhyesti

Kuvista nähdään, että palveluväylän datan siirtokyky on hyvä tai varsin hyvä, kun viestipakettien koko ei nouse isoksi (<=500 K) ja kun yhtäaikaisten käyttäjien määrä pysyy maltillisena (<=50 yhtäaikaista käyttäjää). Edellä mainittuja arvoja suuremmilla pakettikooilla ja isommilla määrillä yhtäaikaisia käyttäjiä palveluväylän suorituskyky heikkenee. Data siirtyy, mutta jonkin verran huonommalla suorituskyvyllä. Suorituskykyyn on tulossa huomattavaa parannusta version 6.9.0 myötä. Silloin voidaan odottaa merkittävästi parempia mittaustuloksia.

Liitetiedostojen siirrosta ja suorituskyvystä

Kun on tarve siirtää väylän yli jotain muuta kuin SOAP-viestiin sisään menevää XML-dataa tai halutaan siirtää isoja tiedostoja (yleensä >=1 Mb), oikea ratkaisu on käyttää ns. SOAP Attachment -siirtotapaa. Data siirretään silloin siis liitetiedostoina väylän yli. Alla muutamia liitetiedostojen siirtoon ja suorituskykyyn liittyviä seikkoja:

  • Palveluväylän kautta siirrettävien liitetiedostojen siirtoaika muodostuu lineaarisesti tiedoston koon mukaan.
  • Ylärajaa tiedostokoolle ei ole rajoitettu, vain levytila ja käytettävissä oleva aika rajoittavat.
    • Palveluväylän kehitysympäristössä on siirretty testimielessä 30 Gt liitetiedosto ongelmitta.
  • Liitetiedostojen siirtoaika riippuu myös käytetystä laitteistosta, pääasiassa CPU:sta ja levy-IO:n ja verkko-IO:n nopeudesta.
  • Palveluväylällä saadaan useimmissa tilanteissa riittävän hyvä suorituskyky isojenkin tiedostojen siirtoon, kunhan liityntäpalvelimet ovat riittävän tehokkaita.
  • Palveluväylän kautta tehtävä tiedonsiirto on jonkin verran suoraa SOAP-kutsua tai esimerkiksi SFTP-siirtoa hitaampi. Palveluväylän kautta tiedonsiirtoon menee noin 3,3 kertaa enemmän aikaa verrattuna SFTP:n yli tiedostoa siirrettäessä.

Alla olevassa taulukossa on muutamia mittaustuloksia, joita tekemissämme testeissä on saatu.

palveluvayla_blogi_liitetiedostojen_koot

Taulukko 1. Liitetiedostojen mittaustuloksia.

Taulukossa esiintyvät termit:

SOAP direct: suora palvelukutsu tietojärjestelmien välillä (palveluväylän liityntäpalvelimet eivät osallistu viestin välitykseen)

SOAP xroad: testipalvelua käytetään palveluväylän kautta (ns. normaali tapa käyttää palveluväylää)

SFTP: siirretään tiedosto SFTP:llä

568 Mbit/s: laskennallinen siirtoaika verkon maksiminopeudella

Yhteenveto

Palveluväylä on varsin suorituskykyinen tapa siirtää tietoa. Pitää muistaa, että palveluväylä tuo tiedonsiirtoon muun muassa tietoturvaa, aikaleimausta, varmenteita ja vakioituja ratkaisuja palveluiden liittämiseksi ja käyttämiseksi väylässä. Tällöin väistämättä suorituskykyyn tulee pientä alenemaa. Kaikkea kun ei voi saada yhdessä paketissa. Palveluväylä tarjoaa siis siirtokyvykkyyttä tietoturvalla varustettuna. Ja mikä parasta: tämä kaikki on saatavilla valmiina paketoituna kokonaisuutena ja vieläpä käytettävissä ilmaiseksi! Liity mukaan täältä: Liity Palveluväylään

Hannu Hakala

Kirjoittaja työskentelee IT-alan palveluyritys Cybercomin palveluksessa ja on Suomi.fi-palveluväylän tuoteomistaja. Hän on innokas digitalisoitumisen puolestapuhuja: ”Mikä onkaan hienompaa, kuin tehdä digitalisaatiota kotimaan hyväksi”.

Ontologiat Palvelutietovarannon palveluksessa: tavoitteena siilottomat palvelutiedot

Ensi vuoden lopulla päättyvä KaPA-ohjelma rakentaa parhaillaan Suomeen alustoja, ympäristöjä ja toimintamalleja, joihin lähivuosina tapahtuva kattava julkisen hallinnon ja palvelujen digitalisointi perustuu.

Koko julkishallintoa koskevan KaPA-ohjelman tavoitteena on ennen vuotta 2020 luoda Suomelle alusta, jossa palvelut perustuvat tietojen ”siilottomaan” liikkumiseen eri toimijoiden ja hallinnon alojen välillä ja automaattiseen, fiksuun asiakaskohdentamiseen. Digitaalisen palvelukoneiston on lähitulevaisuudessa alettava toimia henkilö- ja yhteisöasiakkaan kanssa kuin Downton Abbeyn hovimestari Carson: diskreetisti, ennakoivasti ja palveltava aina henkilökohtaisesti huomioiden.

Tähän ei tietenkään päästä vain ohjelmoinnin keinoin, vaan tarvitaan ihmisen ymmärrettäviä (ja samalla myös koneluettavia) käsitteitä ja käsitekokonaisuuksia. Luotavaan kansalliseen palvelutietovarantoon kuvataan yhteisen tietomallin mukaan kansalaisille, yrityksille ja viranomaisille kohdistetut palvelut ja niiden asiointikanavat yhdenmukaisesti ja asiakaslähtöisesti. Palvelujen löytämisen, älykkään kohdentamisen ja vertailtavuuden kannalta merkittävä ongelma on ollut se, että eri tahojen tuottamista hallinnon kansalaispalveluista ei ole ollut käytössä yhtenäistä kansallista tietokantaa tai rekisteriä. Palvelujen kuvauksissa käytetyissä käsiteavaruuksissa, tietorakenteissa ja tiedon koneellisessa saatavuudessa on ollut eri organisaatioissa suuria eroja eikä tilanne ole vielä juuri parantunut. Yrityspalvelujen suhteen tilanne on ollut kuitenkin parempi Yrityssuomi.fi-palvelun puitteissa pitkään jatkuneen toiminnan ansiosta.

Palvelutietovaranto: ontologiat palvelujen kuvaamisessa

Nykytilaan on tulossa muutos, kun kansallinen palvelutietovaranto (tästä eteenpäin PTV) tuli 15.7.2016 ns. KaPA-lain myötä velvoittavaksi kaikille julkisen hallinnon palveluntuottajille. Velvoittavuus ulottuu isosta ministeriöstä ja keskusvirastosta aina siihen kuuluisaan ”pieneen kuntaan”. KaPA-laki edellyttää, että julkiset palveluntuottajat kuvaavat kaikki vastuullaan olevat kansalais- ja yrityspalvelut kaikkine asiointikanavineen PTV-tietorakenteen mukaisesti ja vastaavat niiden ajantasaisesta ylläpidosta itse.

Tiedot voidaan tallentaa suoraan PTV-kantaan tai ne voidaan jakaa sinne organisaation oman järjestelmän rajapinnasta. Hallinnolla on vajaa vuosi aikaa tuottaa kaikki nämä tiedot. Käytännössä tämä merkitsee sitä, että 460 organisaatiota on tuottanut kaikista palveluistaan tiedot 1.7.2017 mennessä olettaen, että kaikki menee täysin kohdalleen ja ajallaan.

PTV:n ensimmäinen käyttökohde on Suomi.fi-palvelun tuleva versio, ns. palvelunäkymä, joka korvaa ensi vuonna nykyiset Suomi.fi- ja Yrityssuomi.fi-palvelut. Uudessa Suomi.fi-palvelussa PTV-tiedot muodostavat palveluista ja niiden käytöstä perusasiat kertovan sisällön, jota Suomi.fi-verkkotoimitus käyttää toimitettujen sisältökokonaisuuksien ja -formaattien luomisessa. PTV on samalla avointa dataa, jota myös yksityiset toimijat voivat käyttää omissa palveluissaan ja sovelluksissaan.

Ontologiat ja luokitukset palvelukuvausten ytimessä

PTV:n tietosisältö on monipuolinen ja runsas. Tavoitteena on pystyä kuvaamaan kukin palvelu ja sen asiointikanavat niin hyvin, että palvelua ei ainoastaan löydä helposti ja oikeassa kontekstissa, vaan asiakkaalle tarjotaan yhdessä paketissa esimerkiksi palvelun keskeinen sisältö, tarkoitus, asiointiajat ja -edellytykset ja mahdolliset liittyvät palvelut. Kuvausmetatiedoissa on myös kenttiä, joita asiakas ei suoraan näe, mutta jotka auttavat palvelujen kohdentamisessa ja ryhmittelyssä asiakkaille; näitä ovat ennen muuta elämäntilanne- ja kohderyhmäluokitukset.

Kustakin palvelusta ihmisasiakkaalle kertovat eniten kuvausteksti ja käyttötiedot, mutta kuvausvoiman ja ennen muuta hakulöydettävyyden takia PTV sisältää pakollisen asiasana- eli ontologiakäsitekentän. PTV on liitetty kuuteen Finto-ontologiaan: YSO-, JUPO-, LIITO-, JUHO-, TERO- ja TSR-sanasto. Näiden sisältö PTV:hen tulee KOKO-ontologian kautta, ja sillä tulisi kattaa palvelujen käsitteellisen kuvailun tarve.

Käytännössä palvelua kuvaileva henkilö noudattaa rakenteellista prosessia, jonka tietyssä vaiheessa hän saa asiasanakentän, joka alkaa kolmen syötetyn merkin jälkeen tarjota em. aineistoista ontologiakäsitteitä. Kun käsite valitaan tarkasteluun, tiedon tuottaja näkee käsitteen ylä- ja alakäsitehierarkian, jonka avulla hän voi varmistua, että kyseessä on tarkoitettu käsite sekä mahdollisesti hoksata sen tarkemman käsitteen, jolla tätä palvelua voidaan täsmällisesti kuvata. Tämä ominaisuus ei tosin ole vielä PTV:n tuotantoversiossa, vaan tulee siihen jatkokehityksessä. Ontologiakäsitteitä on suositeltu annettavaksi palvelua kohden 3–5, mutta sallittu määrä on välillä 1–10. Nolla ei ole vaihtoehto.

Ontologiakäsitteiden avulla hyvin tehty asiasanoitus nostaa relevantin palvelun esille hakutuloksissa niin tulevassa Suomi.fi-palvelussa kuin keskeisissä verkon hakukoneissa. Tämä on itsestään selvää, mutta asiasanoituksella on muitakin käyttötarkoituksia palvelunäkymän ja koko Kansallisen palveluarkkitehtuurin puitteissa. Se luo mahdollisuuksia, jos ei nyt aivan mihin tahansa, niin ainakin palveluja koskevan tiedon paljon nykyistä parempaan hyödynnettävyyteen. Muutamia esimerkkejä:

  • Verkkotoimitus voi käyttää PTV:n ontologiakäsitteitä ja niiden klustereita löytääkseen keskeiset palvelut työn alla olevaa uutta sisältökokonaisuutta varten.
  • Systemaattisesti käytetyillä ontologiakäsitteillä ja muilla metatietoelementeillä palveluja voidaan ryhmitellä ja jäsentää palvelukentän analytiikkaa ja tiedolla johtamista varten.
  • Käsitteiden avulla järjestelmä voi nostaa käyttäjän valitseman palvelun tietoihin vastaavia tai täydentäviä palveluja ”katso myös” -periaatteella.
  • Kansallisessa palveluväylässä ontologiakäsitteet voivat auttaa järjestelmiä tunnistamaan ja yhdistämään itsenäisiä aineistoja toisiinsa.

Maastouttamisen haaste alkaa vaikeasta sanasta

Sanastojen ja formaalien tietoaineistojen kanssa työskenteleville ontologiat ja niiden tarkoitus ovat selviä ainakin jollain tasolla. Itse olen edelleen innokkaan amatöörin tasolla, mutta olen sentään oppinut muun muassa, mitä ovat alakäsitteet, ekvivalenssit ja korvaavat käsitteet, miten Finto-ontologiapalvelu toimii ja miksi käsitteillä pitää olla URI-tunniste. Peruskauraa ehkä, mutta haaste konkretisoituu, kun ontologiamaailmaa tuodaan sellaisiin organisaatioihin, joissa palvelukuvaus on tähän asti tarkoittanut joko kahta tekstikappaletta verkkosivulla tai vaihtoehtoisesti pitkää hallinnollista esitystä ilman yhtään vakioitua metatietoa.

Ensimmäinen kuoppa tiessä on termi ontologia. Sen merkitys ei yleensä ole tuttu kenellekään palvelurajapinnassa työskentelevälle, ja nuorena filosofiaa huvikseen sivuaineopiskellut tietohallintopomokin muistaa, että ontologia tarkoittaa oppia olevaisesta. Ja nyt sitten pitäisi ryhtyä käyttämään joitakin ontologiakäsitteitä? Ensimmäinen reaktio palvelutuottajan edustajalla on usein paniikki.

PTV-käyttöönottoprojektin aivan ensimmäisissä koulutuksissa tämä tuli esille sen verran vahvasti, että teimme hieman kerettiläisen päätöksen puhua ontologiakäsitteiden sijaan asiasanoista. Lisäksi verbinä asiasanoittaa on tolkullinen ja ihan oikeaa suomea, toisin kuin ontologiakäsitteistää.

Ontologioista kyllä puhumme ja totutamme hallinnon väkeä tuohon käsitteeseen, joka ajan mittaan varmaankin asettuu hallinnon kenttään. Tällä hetkellä käynnissä ovat PTV:n käyttöönottokoulutukset organisaatioille ja niiden osana on PTV-metatietokoulutus, jossa ontologiat ovat esillä. Kokemuksemme mukaan käytännönläheisellä, oikein ajoitetulla ja esimerkkipohjaisella opetuksella voidaan vieraiden käsitteiden hetteikkö läpäistä varsin hyvin.

Ontologiakäsitteiden valintamyymälässä

Vaikka teknisenä suorituksena kuvaavan ontologiakäsitteen valinta on yksinkertainen, se voi olla kognitiivisena suorituksena vaikea, ainakin aluksi. Valitettavasti yhä edelleen on tavallista, että organisaation oma näkökulma näkyy vahvasti metatietojen käytössä, mutta kun palvelua kuvaillaan PTV:n vaatimusten mukaan, näkökulman on oltava tiukasti asiakaslähtöinen. Palvelua on katsottava suoraan asiakkaan kantilta: mitä minä kansalais- tai yhteisöasiakkaana odotan löytäväni ja saavani, ja mitä päämäärää varten. Avainkäsitteiden valinta organisaation omasta suoriteseurantatiedostosta ei yksinkertaisesti ole hyväksyttävää.

Tässä tilanteessa ollaan eräänlaisessa valintamyymälässä: kauppias (palvelusta vastaava organisaatio) kertoo kaupan tiloissa (PTV:ssä) tuotteista (palveluista), joita juuri tässä putiikissa on tarjolla (organisaation tuottamat palvelut). Jos kauppias ei käytä niitä käsitteitä, joita kadulta sisään kävellyt asiakas ymmärtää, tuotteet jäävät hyllyyn, koska asiakas ei löydä niitä.

Kauppias ei voi käyttää tavaraa myydessään tuotteista niitä koodeja ja lähetyslistalyhenteitä, joita hän käyttää tilatessaan tavaraa tukusta. Valitettavasti palvelujen suhteen hallinto aika usein toimii juuri näin, ja tässä on toimintatavan muutos arvattavasti edessä aika monessa paikassa. Kun organisaatiossa valitaan sopivimpia ontologiakäsitteitä kuvaamaan palvelua ja sen erilaisia asiointikanavia, joudutaan tekemään aitoa ajatustyötä ja asettumaan asiakkaan rooliin. Organisaatiossa joudutaan myös käymään ajatuksella läpi, mitä ne ”meidän palvelut” itse asiassa ovat, voidaanko joitain yhdistää ja joistakin jopa luopua, ja miten asiointikanavia voisi ja pitäisi kehittää. Prosessi voi vaatia paljon, mutta myös antaa paljon.

Käsiteharmonian vaikeus ja helpottaminen

Vaikka Finto-palvelun ontologioista PTV-käytössä on vain kuusi ontologiaa, tietojen tuottajille tulee käyttöön kymmeniä tuhansia ontologiakäsitteitä. Näillä määrillä pyrkimys yhdenmukaiseen asiasanoitukseen organisaatioiden välillä olisi vain hurskas toive, mutta PTV-hankkeessa on tultu merkittävällä tavalla vastaan etenkin kuntia. Kuntien lakisääteisiin tehtäviin (n. 450) liittyvät palvelut, joita kaikki kunnat järjestävät (runsas sata), on jo tuotettu ministeriöiden avulla ns. pohjakuvaukset, joihin on liitetty valmiiksi asianmukaiset ontologiakäsitteet. Kunta voi lisätä ontologiakäsitteitä, jos katsoo tarpeelliseksi, mutta ei poistaa valmiiksi annettuja. Sama pätee näiden palvelujen tekstimuotoisiin kuvauksiin.

Tämän menettelyn avulla vastaava palvelu eri kunnissa löytyy samoilla käsitteillä. Pohjakuvaukset antavat kunnille samalla mallin ja sapluunan, jota voi soveltaa myös kunnan vapaaehtoisesti tehtäväksi ottamien palvelujen kuvaamiseen.

Jatkossa myös muista kuin lakisääteisistä palveluista voidaan tehdä PTV-pohjakuvauksia. Nyt esimerkiksi seudullisista yrityspalveluista aiotaan mahdollisuuksien mukaan näin tehdä.

On selvää, että laatimalla PTV-pohjakuvauksia lakisääteisistä palveluista ei luoda harmonista ontologiakäsitteiden käyttöä valtion puolella yksittäisten virastojen välille. Koulutuksen, toimivien yhteistyöverkostojen ja Kansalliseen palveluarkkitehtuuriin kuuluvienn raja-aitojen purkamisen avulla voidaan luoda maaperä, jossa julkishallinnon yhteinen näkemys ja pelisäännöt ulottuvat myös ontologioiden hyödyntämiseen ja yhteiseen kehittämiseen.

Tähän on kieltämättä matkaa, mutta suunta lienee selvä. Jatkossa semanttista harmoniaa voidaan kenties edistää yhdistämällä taustaprosesseissa vakioituja ja määriteltyjä käsitteitä toisiinsa. Tällä hetkellähän Finto-palvelussa julkaistujen ontologioiden käsitteiltä puuttuvat määrittelyt lähes kokonaan, mihin on käytännössä välttämätöntä saada muutos. Jotta määriteltyjen käsitteiden välille tulevaisuudessa voidaan luoda merkityssuhteita järjestelmätasolla, tarvitaan teknisen alustan lisäksi sellaista laajempaa tiedon yhteentoimivuuden raamia, jota on jo alettu työstää hallituksen digitalisaatio-kärkihankkeessa (yhteinen tiedon hallintamalli ja -työväline).

Suomi on monikielinen maa

Kun ontologioita aletaan soveltaa kansallisella tasolla sellaisiin palvelurakenteisiin, joista on säädetty lailla, emme voi ohittaa sen paremmin kansalliskielten asemaa kuin Suomen kansainvälistymistäkään. Ontologiaresurssien on oltava käytettävissä suomen lisäksi vähintään ruotsiksi ja englanniksi; tämä on se taso, jolla Suomi.fi ja Yrityssuomi toimivat tällä hetkellä ja joka siirtyy myös tulevalle Suomi.fi-palvelulle ensi vuonna.

Tosiasia on, että kansallisista ontologioista osa on julkaistu vain suomeksi ja tarve niiden kieliversioille on muuttumassa akuutiksi KaPA-lain ja palveluarkkitehtuurin myötä. Tästä seuraa työtä ja sen organisointia varsin erikoistuneessa sektorissa; käsitteistöjen kieliversiointi ei ole kevyttä työtä etenkään silloin, kun niiden sovellusala on koko maa ja sen asukkaat.

Ontologia on käyttötavaraa

Ontologioissa on kaksi ulottuvuutta, joita on kehitettävä ja ylläpidettävä koko ajan. Käsiteavaruuden sisällön on oltava relevantti maailman tilaan nähden, mikä on varsin valtava prosessi. Ontologioiden sisällönkehitykseen on syytä saada mukaan koko palvelutietoja tuottava yhteisö ja heille on tarjottava selkeät välineet käsitetarpeiden välittämiseen sinne, missä ontologioiden sisällöstä varsinaisesti päätetään. Itse käsittelyprosessi kaivannee myös hieman tuunausta nykyisestä.

Kun sisältö on laadukasta, sitä on voitava myös käyttää. Digitalisaatio merkitsee käsitteiden ja semantiikan aina vain syvenevää kotiutumista sähköiseen maailmaan, niin tallentamisen kuin käyttötapausten osalta. Tästä seuraa, että ontologiat on julkaistava luotettavassa teknisessä ympäristössä, josta niitä voidaan käyttää suoraan rajapintakyselyillä, ladata toisiin järjestelmiin ja tarkastella raportointien yhteydessä. Palvelutietovarannon ja muun kansallisen palveluarkkitehtuurin välineistön yhteydessä 404- ja ”rajapinta ei vastaa” -tilanteille ei voi jättää tilaa.

Marko Latvanen

Kirjoittaja työskentelee Valtiokonttorin Suomi.fi-ryhmässä verkkotoimittajana ja ”KaPA-duunarina”.

Kirjoitus on alun perin julkaistu Sanastokeskus TSK:n Terminfo-verkkolehdessä 3/2016.

 

Katso koulutusvideo Palvelutietovarannon metatiedoista ja ontologiakäsitteistä