Skip to end of metadata
Go to start of metadata

Kansallinen palveluväylä herättää paljon kiinnostusta ja siihen liittyvää keskustelua käydäänkin lukuisilla eri foorumeilla. Käytännön toteutukseen liittyvää tietoa on toistaiseksi ollut varsin niukasti saatavilla, joka on osaltaan lisännyt keskusteluissa esille nousevien kysymysten määrää. Tässä blogissa on tarkoituksena antaa tietoa käytännön toteutuksen etenemisestä sekä tarjota vastauksia usein esitettyihin avoimiin kysymyksiin.

Palveluväylä nimityksen käyttö kansallisen palveluväylän yhteydessä on herättänyt keskustelua, koska palveluväylä termillä yleisesti tarkoitetaan erilaisia ESB (Enterprise Service Bus) -ohjelmistoja. Kansallinen palveluväylä ei kuitenkaan nimestään huolimatta ole ESB-ratkaisu, vaan tiedonvälityskonsepti, jonka tehtävänä on toimia viestien välitysalustana siihen liittyneiden järjestelmien välillä. Kansallinen palveluväylä on tiedonvälityskerros, joka tarjoaa vakioidun ja tietoturvallisen tavan sekä julkaista että käyttää erilaisia tietovarantoja ja palveluita. Toteutuksessa käytettävä X-Road-ratkaisu ei tarjoa ESB-tuotteille tyypillisiä ominaisuuksia, eikä niiden kehittäminen ole kansallisen palveluväylän luonteesta johtuen edes suunnitteilla. Kansallisesta palveluväylästä ja X-Road-ratkaisusta ei siis ole tarkoituksena lähteä kehittämään kansallista ESB-tuotetta. Palveluväylän englanninkielinen nimi National Data Exchange Layer kuvaakin ehkä paremmin sitä, mistä kansallisessa palveluväylässä on pohjimmiltaan kysymys. 

Virossa on tällä hetkellä käytössä X-Road-ratkaisun versio 5.5, mutta Suomessa käyttöön tullaan ottamaan ohjelmiston tuorein versio 6, jonka pitäisi valmistua vuoden 2014 loppuun mennessä. Version 6 alpha-version testaaminen päästään kuitenkin näillä näkymin aloittamaan jo lokakuun aikana. Virolaiset tarjoavat meille uuden version asennukseen ja käyttöön liittyvää koulutusta, jonka jälkeen CSC:lle pystytetään version 6 testiympäristö, jossa pääsemme itse testaamaan uutta versiota käytännössä. Marraskuun aikana tulemme vielä saamaan version 6 beta-version ennen vuoden lopussa julkaistavaa lopullista versiota, jolla tuotantokäytön aloittaminen vuoden 2015 ensimmäisellä puolikkaalla tulee tapahtumaan.

Suomen panos version 6 kehityksessä on pääosin testauksessa ja auditoinnissa. Suomen liittyminen mukaan version 6 kehitykseen tässä vaiheessa olisi lähes väistämättä tarkoittanut aikataulujen venymistä ja version 6.0 julkaisun lykkääntymistä. Tämä olisi puolestaan tarkoittanut myös kansallisen palveluväylän käyttöönoton lykkääntymistä. Meidän kontribuutiomme version 6 kehitykseen tulee olemaan Red Hat (RHEL) -käyttöjärjestelmätuen toteuttaminen, sillä tällä hetkellä X-Road tukee vain Ubuntu 14.04 LTS -käyttöjärjestelmää. Muilta osin versio 6 tullaan ottamaan Suomessa käyttöön sellaisenaan. Jatkossa Suomi tulee kuitenkin tekemään kehitystyötä tasavertaisena kumppanina yhteistyössä Viron kanssa. Meidän näkökulmastamme yksi keskeisimpiä tulevaisuuden kehittämiskohteita tulee olemaan REST-tuen lisääminen X-Roadiin.

X-Roadista ja avoimesta lähdekoodista on myös esitetty kysymyksiä. Ihmetystä on herättänyt lähinnä se, että ohjelmiston kerrotaan olevan avointa lähdekoodia, mutta käytännössä lähdekoodi ei kuitenkaan tällä hetkellä ole vapaasti saatavilla verkossa. Viro on luovuttanut ohjelmiston Suomelle avoimen lähdekoodin EUPL-lisenssin mukaisilla ehdoilla ja lisenssi kattaa sekä ohjelmiston nykyiset että tulevat versiot. Viron linja lähdekoodin julkaisemisen suhteen on ollut tähän asti se, että koodia ei ole vapaasti julkaistu, vaan se annetaan turvapalvelimen osalta erillisestä pyynnöstä vain Viron X-Roadiin liittyneille organisaatioille. Suomen kannalta X-Roadin nykyinen versio ei kuitenkaan ole erityisen kiinnostava, koska tarkoituksenamme on ottaa käyttöön ohjelmiston tuorein versio 6, joka on kirjoitettu kokonaan uudelleen ja toteutustekniikkakin on vaihtunut C- ja C++-kielistä Javaan ja Rubyyn. Lisäksi myös X-Roadin käyttämien SOAP-sanomien rakennetta on uudistettu.

Suomessa käyttöönotettavan version 6.0 turvapalvelimen lopullisen version lähdekoodi tullaan julkaisemaan avoimena lähdekoodina vuoden 2015 ensimmäisellä puolikkaalla, kun tarvittavat testit ja auditoinnit on saatu tehtyä. Keskuspalvelimen lähdekoodia ei sen sijaan Viron toivomuksesta tulla ainakaan tällä erää julkaisemaan. EUPL-lisenssi toki mahdollistaisi myös keskuspalvelimen lähdekoodin julkaisemisen ilman Viron hyväksyntää, mutta tulevan yhteistyön sujuvuuden nimissä olemme päätyneet siihen, että keskuspalvelimen lähdekoodia ei ainakaan toistaiseksi tulla julkaisemaan. Asiasta tiimoilta keskustelu Viron kanssa kuitenkin jatkuu ja uusimpia kuulumisia tullaan kertomaan tulevissa blogikirjoituksissa.

Loppuvuoden ohjelmassa on version 6 pystytyksen ja testauksen ohessa myös palveluväylään liittyvän dokumentaation tuottaminen. Mukaan tulevien organisaatioiden kannalta riittävän kattava ja selkeä dokumentaatio on ensi arvoisen tärkeä, jotta liittyminen olisi mahdollisimman vaivatonta. Dokumentaatio tulee pitämään sisällään mm. yleisiä ohjeita liittyjille, yksityiskohtaisia asennusohjeita sekä myös käytännön koodiesimerkkejä järjestelmien kytkemiseen liittyen. Pidemmällä tähtäimellä palveluväylään liittymistä helpottavien ohjelmakirjastojen toteuttaminen on myös varteen otettava vaihtoehto, sillä valmiin koodin hyödyntäminen helpottaa liittymistä ja vähentää eri organisaatioissa tehtävää päällekkäisen työn määrää. Ohjelmakirjastojen toteutukseen ei kuitenkaan ehditä vielä tämän syksyn aikana, vaan asiaan palataan varmastikin ensi vuoden aikana.

Lisää kansallisen palveluväylän kuulumisia luvassa tulevina kuukausina.

 

Kirjoittaja toimii Väestörekisterikeskuksen palveluarkkitehtuuriyksikössä kansallisen palveluväylän järjestelmäpäällikkönä

  • No labels

4 Comments

  1. Anonymous

    Miksi käytätte aikaa RHEL sovitukseen? Lähtökohtaisesti se kuulostaa turhalta resurssien haaskaamiselta jaon kaikkea muuta kuin ketterää. Varsinkin kun samaan hengenvetoon kerrotte, ettette ehdi panostamaan ohjelmakirjastoihin.

    1. RHEL-tuki on vaatimuksena monen palveluväylään liittyvän organisaation taholta, koska Ubuntu ei lähtökohtaisesti sisälly läheskään kaikkien eri palveluntarjoajien tuen piiriin, jotka organisaatioiden järjestelmien ylläpidosta vastaavat. Toisaalta joissakin organisaatioissa on myös tehty periaatetason linjauksia käytettävien/tuettavien käyttöjärjestelmien suhteen. RHEL-tuen toteutuksella halutaan siis laskea palveluväylään liittymisen kynnystä tarjoamalla vaihtoehto Ubuntulle.

      Ohjelmakirjastojen tarjoaminen toki laskee myös väylään liittymisen kynnystä, kun toteutuksessa voidaan hyödyntää valmiita komponentteja, eikä kaikkea tarvitse toteuttaa alusta lähtien. Ohjelmakirjastojen tärkeys on siis kyllä tiedostettu, mutta käytännön toteutus venyy väistämättä ensi vuoden puolelle riippumatta RHEL-tuen toteutuksesta. Jotta kirjastoista olisi aidosti hyötyä mahdollisimman monelle liittyjälle, pitää niiden tukea sekä palvelujen tarjoamista että käyttöä, jonka lisäksi pitää toteutuksia myös olla tarjolla useammalla eri toteutustekniikalla.

      1. Anonymous

        Kiitos vastauksesta. Oletteko kenties harkinneet Docker/LXC konttien hyödyntämistä, mikä tarkottaisi jakeluriippumattomuutta?

        1. Käytännön toteutuksesta ei vielä ole tehty päätöksiä suuntaan tai toiseen, vaan eri vaihtoehtoja kartoitetaan parhaillaan. Käyttöjärjestelmäriippumattomien palikoiden käyttäminen on kyllä ollut esillä, mutta Docker/LXC kontit eivät toistaiseksi ole nousseet esille keskusteluissa.