Välitysarkkitehtuurin tavoitetila Arkkitehtuuriperiaatteet

Tässä dokumentissa kuvataan opintohallinnon järjestelmien integraatioarkkitehtuurin tavoitteet ja keinot tavoitteiden saavuttamiseksi.

Visio

Palveluihin liittyvä visio 2025: Modulaarisia (koosteisia) palveluja, jotka koostuvat mahdollisesti yksittäisistä pienemmistä palveluista.

Esimerkiksi HOPS-palvelu koostuu useammasta alemman tason palvelusta. Alemman tason palveluista esimerkkejä ovat henkilötietoja tai suoritustietoja antavia palveluja. Alemman tason palveluita voi tuottaa esimerkiksi opintohallinnon perusjärjestelmä.

• Korkeakouluilla (mahdollisesti myös kansainvälisesti) on käytössään yhteisiä palvelumoduuleja
• Oppijan tietoja hyödynnetään korkeakoulujen välillä oppijan “mukana”
• Sujuva ja jatkuva tietojen siirto moduulien välillä on erityisen tärkeää
• Tiedot säilytetään lähtökohtaisesti yhdessä paikassa.

Mitä visio tarkoittaa välitysarkkitehtuurin näkökulmasta? Siirrettävän tiedon on oltava luotettavaa ja se on pystyttävä yhdistämään oppijaan. Tämä voi tarkoittaa erilaisia valtakunnallisia ja kansainvälisiä tunnistamispalveluja.

• Ollaan mukana kehittämässä sekä käyttämässä kansainvälisessä tiedon esittämiseen liittyvissä standardeissa. Esimerkkejä tästä työstä ovat ELM (European Learner Mobility) tai MLO (Metadata for Learning Opportunities) ja SCHAC. Kansallisella tasolla esimerkkejä ovat M-määritykset, XDW-käsitemalli ja Funet EduPerson.** http://www.virtuaaliyliopisto.fi/extra/vp_svy-standardointi_fin/vp_svystudydata_fin.html
  • http://www.terena.org/activities/eurocamp/may09/slides/090519-EuroCAMP-Vic-Edup.pdf
• Tiedonsiirron tarve tulee lisääntymään nykyisestä valtavasti.
• Kertaluontoiset tiedonsiirrot ovat erilaisia eräsiirtoina, esimerkiksi kerran vuorokaudessa toteutettavia tiedonsiirtoja. Näitä tarvitaan mm. tietovarastopalvelujen ylläpitämiseen.
• Reaaliaikaista tiedonsiirtoa tarvitaan erityisesti alemman tason palvelujen käyttämisessä koosteisissa palveluissa. Esimerkiksi opiskelijan suoritustiedot tarvitaan lähes reaaliaikaisesti Hops-palveluun.
• Alemman tason palvelurajapinnat ovat hyvin määriteltyjä ja dokumentoituja. Palvelurajapintojen täytyy olla luotettavia, joten tietojen siirto täytyy pystyä varmentamaan.
• Tiedonsiirron täytyy perustua teknologisesti yhteisesti sovittuihin standardeihin (ei tuotteisiin) eli tiedonsiirrossa tukeudutaan ensisijaisesti hyviksi havaittuihin hyvin dokumentoituihin standardeihin.

Integraatioväylän määritelmä

RAKETTI-OPI:n Arkki-työryhmän määritelmä integraatioväylälle on seuraava: Integraatioväylä on keskitetty, luotettava viestiliikennepalvelu sekä joukko työkaluja, joiden avulla palvelua käyttävät korkeakoulut voivat siirtää viestejä eri tietojärjestelmien tai palvelujen välillä, sekä korkeakoulujen sisällä että eri korkeakoulujen välillä.  

Integraatioväylässä on mahdollista muuntaa viestejä muodosta toiseen (esimerkkinä SOAP-kutsu REST-muotoiseksi), rikastuttaa tai filtteröidä niitä, reitittää niitä sääntöpohjaisesti, lähettää yksi viesti useampaan kohteeseen, jnpp.  Tämän lisäksi integraatioväylä tarjoaa valmiina liittymät useisiin eri tiedonsiirtotapoihin ja -standardeihin, esim. SOAP, REST, ftp, smtp, JMS ja tiedostojärjestelmä.  Uusia liitostapoja voidaan tehdä tarvittaessa.

Integraatioväylän synonyymeja ovat mm. integraatiopalvelut, palveluväylä ja ESB.  Virallisesti Arkki-työssä käytetään vain termiä integraatioväylä.

Vaikkakin integraatioväylä on pääasiallinen tapa liittää sovellukset ja palvelut keskenään, voidaan se tietyissä tapauksissa ohittaa. Tällaisia “poikkeustapauksia” ovat ainakin seuraavat:

• Tunnetun kansallisen palvelun käyttö
• Lokaali palvelu voi kutsua toista lokaalia palvelua suorituskykysyistä suoraan

Selvityksistä ja visioista käytännön toimiin

Tässä luvussa kuvataan niitä toimia, toimijoita sekä askelmerkkejä, joita kansallisessa opintohallinnon yhteistyössä tarvitaan tulevaisuudessa.

Roadmap

Tarvitaan kansallinen opintohallinnon järjestelmien tulevaisuuden roadmap.

Korkeakoulujen (ja konsortioiden) on tuotettava samanlainen roadmap, joka on linjassa kansallisen tason roadmapin kanssa.  Se kuvaa samalla  järjestelmäpalvelujen tarpeen ja priorisoi palvelut, mikä mahdollistaa korkeakoulujen koordinoidut hankinnat yhteistyön merkeissä.

Kansallinen tietoarkkitehtuuri

Kaikessa kehitystyössä on huomioitava kansallinen ja/tai kansainvälinen tietoarkkitehtuuri. Tämä on palvelujen onnistuneen integroinnin kannalta kaikkein tärkein asia, sillä eri järjestelmien ja palvelujen on ymmärrettävä toisiaan. Tämä ei kuitenkaan tarkoita sitä, että palvelun sisäisen tietomallin tarvitsee olla sama kuin kansallisen tietomallin, kunhan yhteensopivuus säilyy.

Uusia kansallisia tietomalleja syntyy kehitysprojektien yhteydessä; mukana olevat korkeakoulut ovat vastuullisia mallin ensimmäisen version luomisessa. Jos olemassaolevaa kansallista määrityksiä ei palvelun tekemistä aloitettaessa ole, on selvitettävä vastaavien kansainvälisten määritysten olemassaolo. Mikäli kansainvälisiäkään määrityksiä ei ole, projektissa olevat korkeakoulut tuottavat määrityksistä ensimmäisen - riittävän hyvän - version yhdessä RAKETTI-OPI:n tietomallikoordinaattorin kanssa; tietomallikoordinaattori on kaikkien mallien omistaja ja ylläpitäjä (sen jälkeen kun ensimmäinen versio on valmistunut).

Koordinaattorin velvollisuuksiin kuuluu mm. konfliktien ratkominen (esim. kansallinen tietomalli on olemassa, mutta se ei aivan sovellu uuden palvelun tarpeeseen), mallien ylläpito (esim. lainsäädäntö, kansainvälisten määritysten uusien versioiden ottaminen huomioon).

Selkeällä kansallisten määritysten tuottamis- ja hallintaprosessilla voimme paremmin vaikuttaa kansainvälisiin määrityksiin.

Palvelut

Korkeakouluille alkaa lähitulevaisuudessa muodostumaan lokaalisti tai valtakunnallisesti substanssipalveluja, jotka integroidaan tietovarantoihin integraatioväylän avulla. Esimerkiksi TipTop-hanke tuo mukanaan korkeakouluille yhteisiä palveluja.

Substanssipalvelut tekevät yhden prosessin tai prosessin osan kokonaan. Esimerkkejä: ilmoittautuminen, arvostelu, maksu. (Järjestelmäpalvelut - oma luokkansa - tukee substanssipalveluja olematta itse niitä.)

Substanssipalveluista koostetaan toimijoille - mm. oppijoille, opettajille ja virkailijoille - käyttöliittymällisiä palveluja.  Koostaminen tapahtuu sovelluskomponenttien ja integraatioväylän avulla.

Integraatioväyläratkaisun valinta

Opintohallinnon järjestelmien tulevaisuus on palvelukeskeinen (SOA, Service Oriented Architecture).  Ensisijaisena tavoitteena on valita avoimen lähdekoodin ratkaisu, mikäli sopiva sellainen on olemassa.  Valitsemalla ja käyttämällä samaa ratkaisua opintohallinnon järjestelmien integraatioväylänä saadaan kasvatettua osaamista valitusta ratkaisusta, mikä tulee helpottamaan ja edesauttamaan integraatioiden tekemistä tulevaisuudessa.

Tällä hetkellä Apache Foundationin ServiceMix (http://servicemix.apache.org) on vahvin kandidaatti opintohallinnon järjestelmien tulevaisuuden integraatioväyläksi. Se on jo käytössä Metropolian Peppi-järjestelmässä; myös OPH on valinnut sen tulevan KSHJ:n alustaksi.

RAKETTI-OPI:n INTEGRAATIO-ryhmä järjesti kesäkuussa 2011 kaksipäiväisen koodileirin (Code Camp), jossa jo tutustuttiin ServiceMixiin ja tehtiin sen päälle yksi KSHJ-skenaario (hakijoiden ja hakijatietojen lähetys korkeakoulujen järjestelmiin).  Tulokset olivat lupaavia, ja ServiceMix tuotteena kiinnosti osallistujia.

Seuraavalla koodileirillä lokakuussa (18.-20.10.2011) syvennämme ServiceMix-osaamista järjestämällä kolmipäiväinen leirin; sen ensimmäisenä päivänä järjestetään ServiceMIx-koulutus (18 ilmoittautunutta, kiinnostusta on).  Seuraavina kahtena päivänä tullaan rakentamaan koosteinen palvelu (SOA) ServiceMixin päälle. Koodileirin toimet tulevat jo osaltaan lisäämään ServiceMixin osaamista ja ymmärtämystä korkeakouluissa. Jos ServiceMix valitaan virallisesti käytetyksi alustaksi, sen tehokas hyödyntäminen tulee vaatimaan lisäpanostuksia koulutukseen.