Liite 2 - Vaatimukset arkkitehtuuriratkaisulle ja niiden toteutuminen Peppi - arkkitehtuurissa

Avoimuus

Arkkitehtuuriratkaisu ei saa edellyttää asiakkailta viimeisimpien
teknologioiden soveltamista eli integraatiot eivät saa edellyttää asiakkailta isoja järjestelmäuudistuksia.

Peppi-arkkitehtuurissa hyödynnetään uusia teknologioita (esim. OSGI), mutta sen käyttöönotto ei edellytä ulkopuolisten järjestelmien uudistamista.

Arkkitehtuuriratkaisu ei saa sisältää ohjelmistotoimittajasidonnaisia ratkaisuja

Rajapinnan käytön tulee olla ohjelmistoriippumatonta

Ratkaisussa ei saa sitoutua tiettyyn tuotteeseen/laitteistoon,
joka aiheuttaa rajoituksia tiedon tarjoajalle/vastaanottajalle.

Ratkaisu perustuu avoimen lähdekoodin tuotteisiin, eikä luo riippuvuutta tiettyyn toimittajaan. Järjestelmän palvelupohjaisuus mahdollistaa paremmin palveluiden laajentamisen ja uudelleenkäytön.

Rajapinta toteutetaan Webservice/SOAP ja Rest - tekniikoilla, joten rajapintojen käyttö ei rajoitu tiettyyn ohjelmistoon. Mikäli tarvitaan käyttöön transaktioita eri palveluiden kutsujen välillä (koosteisia palveluita), vaatii tämä käytännössä, että palvelu ohjelmoidaan samoin kuin Peppi - projektin aikana tehdyt palvelut on toteutettu. Huomioitavaa on kuitenkin se, että mikäli tiedon omistajuus on selvillä ja tiedot sijaitsevat vain yhdessä paikassa, poistaa se osaltaan tarvetta hajautetuille transaktioille. Tietoja ei siis tarvitse synkronoida useaan paikkaan transaktionaalisesti.

Palvelupohjaisessa ratkaisussa palveluiden sisäinen toteutus piilotetaan muilta palveluilta, joka vähentää sidoksia tiettyyn tuotteeseen/laitteistoon.

Ratkaisun tulee mahdollistaa palvelujen koostaminen toisista, useam- man eri viranomaisen eri teknikoilla tehtyjen järjestelmien palveluista.
Palvelujen yhdistämisessä tulee huomioida tietosuojan asettamat ra- joitteet.

Ratkaisussa hyödynnetään servicemixin integraatio-ominaisuuksia, jotka mahdollistavat integraatiot eri tekniikoilla tehtyihin rajapintoihin (esim. Webservice, Rest, siirtotiedosto)

Arkkitehtuurin määrittelyn tulee ohjata yhteisiin yleisiin ratkaisuihin, mutta sen pitää sallia toimialakohtaiset erityistarpeet.
Erityisesti on huomioitava toimialakohtaiset kansainväliset standardit.

Arkkitehtuurissa on huomioitu nykyarkkitehtuurin muodostamat ongelmat, kansalliset määritykset (M-määritykset) sekä Kuali-yhteisön arkkitehtuuriratkaisut ja teknologiavalinnat.

Arkkitehtuurin tulee tukea yleisiä tietopoliittisia linjauksia. Tietosuojaan ja tietojen saatavuuteen liittyvät linjaukset on huomioitava.

Arkkitehtuuri on selkeämpi kuin nykyinen arkkitehtuuri ja rajapintojen tietosuoja määritellään palvelukohtaisesti.

Arkkitehtuurin tulee mahdollistaa joustava siirtyminen uusien teknologioiden ja standardien käyttöön pitkällä aikavälilla

Arkkitehtuuri on mietitty modulaariseksi ja rajapintojen versiointi on huomioitu. Tämä mahdollistaa teknologioiden asteittaisen siirtymisen uusien teknologioiden käyttöön pitkällä aikavälillä.

Arkkitehtuuriratkaisun tulee käyttää standardoituja rajapintoja aina silloin, kun sellaisia on käytettävissä usean eri toimittajan tukemina.

Rajapinnat tukevat Webservice/SOAP ja Rest teknologioita.

Arkkitehtuuriratkaisu ei saa estää asiakkaan oman arkkitehtuuriratkaisun soveltamista integraatiossa

Rajapinnat tukevat Webservice/SOAP ja Rest teknologioit.

Arkkitehtuuriratkaisun tulee edistää organisaatioiden välistä yhteistyötä tietovarantojen hyödyntämisessa

Ratkaisussa rajapinnat on julkaistavissa eri organisaatioille.

Ratkaisussa pitää käyttää tekniikoita ja ratkaisuja, joihin tiedontuottajien on mahdollista integroitua helposti.

Rajapinnat tukevat Webservice/SOAP ja Rest teknologioit.

Ratkaisussa pitää käyttää tekniikoita ja ratkaisuja, joille löytyy referens- sejä.

Rajapinnat tukevat Webservice/SOAP ja Rest teknologioita, joille löytyy paljon referenssejä.

Skeemojen suunnittelussa tulisi noudattaa yhteisesti sovittuja käy- täntöjä (JHS 170 linjaa XML- skeemojen suunnittelutyyliksi ”Gar- den of Eden”)

Rajapintojen suunnittelussa hyödynnetään Raketti-hankkeen skeemoja (M-määritykset).

Nykyisten olemassa olevien rajapintamääritysten tulee olla sovitettavis- sa tulevaan rakenteeseen sellaisenaan.

Servicemix mahdollistaa vanhojen rajapintojen sovittamisen järjestelmään.

Eheys

Synkronisen palvelupyyntö-palvelu- rakenteen hallinnan pitää toimia. Rajapinnassa kulkeville sanomille pitää määritellä vakiotiedot, jotka takaavat synkronoinnin. Esimerkiksi autentikointitavat pitää linjata.

Synkroninen viestintä on mahdollista rajapintojen avulla.

Tarvitaan Master-tiedon ja kopioidun tiedon sijoitussuunnitelma.

Peppi-projektin tavoitteena on selkiyttää tiedon omistajuutta eri palveluiden välillä ja poistaa turhat tiedon synkronoinnit.

Turvallisuus

Arkkitehtuuriratkaisun tulee täyttää yleiset tietosuojan ja tietoturvan vaatimukset

Rajapinnat on mahdollista suojata tietoliikenneteknisesti, autentikaation ja auktorisoinnin avulla.

Arkkitehtuuriratkaisun on taattava tiedon tietoturvallinen siirto asiakas- järjestelmän ja kohdejärjestelmän rajapinnan välilla

Siirrettävä tieto voidaan suojata kryptauksen avulla.

Järjestelmän tulee huomioida tietosuojavaatimukset.

Rajapinnat on mahdollista suojata tietoliikenneteknisesti, autentikaation ja auktorisoinnin avulla.

Tiedon käyttöä tulee pystyä valvomaan (kuka käyttää)

Palveluissa tiedot versioidaan sekä tallentaan tiedon tallentajan tunnisteet. Tämän avulla voidaan seurata palveluiden käyttöä sekä poistaa osaltaan auktorisoinnin tarvetta.

Ratkaisussa pitää huomioida käyttäjän tunnistus

Palveluissa tiedot versioidaan sekä tallenetaan tiedon tallentajan tunnisteet.

Arkkitehtuuriratkaisu ei saa edellyttää tietojen käyttöä suoraan operatii- visesta kannasta, vaan se pitää pystyä eristämään palvelukerroksella.

Palvelut toteutetaan rajapintoja vasten, jolloin palvelut eivät ole liitoksia muiden palveluiden sisäiseen toteutukseen.

Siirrettävien tietojen aikaleimat pitää määritellä ja toteuttaa yhtenäisesti.

-

Ratkaisussa pitää huomioida valtuutus.

-

Ratkaisussa pitää huomioida pääsynhallinta.

-

Ratkaisussa pitää huomioida lokitus.

Lokitus huomioidaan palvelu- ja käyttöliittymämoduulissa.

Ratkaisussa pitää huomioida poikkeustilanteiden hallinta.

Poikkeustilanteet jaetaan eri luokkiin ja poikkeustilanteiden hallinta määritellään jokaiselle luokalle erikseen.

Rajapintaratkaisussa on huomioitava häiriöseuranta ja jäljitettävyys

Häiriönseuranta toteutetaan lokituksen avulla sekä niin, että virheen sattuessa virheen aiheuttanut viesti kirjoitetaan lokiin, jolloin virhe on toistettavissa.

Rajapintojen autentikoinnin ja autorisoinnin tulee olla mahdollista pal- velutasolla.

Palvelurajapinnat liitetään autentikoinnin/autorisoinnin piiriin.

Saavutettavuus

Ratkaisun tulee tukea sekä suora- että eräkäyttöä.
Ratkaisun pitää sisältää useita eri tiedonsiirtotapoja.
Ratkaisun on sisällettävä sekä reaaliaikaiset että massasiirtoa tukevat rajapinnat.

Ratkaisu tukee eri protokollilla tehtäviä integraatioita ja palveluista voidaan koostaa uusia palveluita, joihin mahdollista tehdä tuki massasiirroille.

Arkkitehtuuriin tulee olla sovitettavissa legacy-rajapintojen hyödyntä- minen niiden luonnollisen elinkaaren mukaisesti

Ratkaisu tukee eri protokollilla tehtäviä integraatioit.

Integraatiopalvelun on oltava keskeisiltä osiltaan valmis ennen laajaa käyttöä.

Rajapinnat toteutetaan palveluittain eikä käyttötapaus kerrallaan.

Pitää olla palvelu, jonka avulla paikkatiedot yritystilastoista saadaan käyttäjien ulottuville.

-

Yksityisen sektorin toimijoiden on kyettävä käyttämään yhteistä raja- pintaratkaisua hakiessaan ja ylläpitäessään tietovarantojen tietoja.

Rajapinnat tai osa niistä voidaan julkaista täysin avoimiksi.

Muutos tietovarantoon ei saa aiheuttaa pakollista muutostarvetta raja- pintaan ja päinvastoin.

Rajapinnan tarkoitus on suojata muutoksilta. Rajapinnat toteutetaan tämän käsityksen mukaisesti.

Rajapintaratkaisulle pitää määritellä yhteinen poikkeus-/virheskeema se- kä yleiset linjaukset käyttäytymiselle poikkeustilanteissa

Poikkeustilanteet jaetaan eri luokkiin ja poikkeustilanteiden hallinta määritellään jokaiselle luokalle erikseen.

On toivottavaa, että SAPin vakio- IDOC-määritykset tulee ottaa mu- kaan rakenteeseen.

-

Käytettävyys

Ratkaisun on taattava eri palveluille niiden edellyttämät suorituskyvyt, tarvittaessa 24/7.

Järjestelmän palvelut ovat tilattomia, joka mahdollistaa helpon skaalautuvuuden kuorman kasvaessa.

Ratkaisun tulee tarjota valvontavälineet (sanoman sisältö, sääntöpohjai- suus)

-

Tiedon käyttöä tulee pystyä seuraamaan (tiedonsiirron onnistuminen, lokitus)

Tiedon käyttöä seurataan versiohistorian ja lokituksen avulla.

Ratkaisuun pitää kuulua asianmukainen virhekäsittely.

Virheenkäsittely rakennetaan siten, että se on yhdenmukainen koko Peppi-järjestelmässä.

Ratkaisun tulee sisältää palvelun tuottamisen toimintamallit

-

Vastuiden on oltava selkeästi määritelty (ilman harmaita alueita) -> pal- velun tuottamisen roolit

-

Tiedon on oltava saatavilla reaaliaikaisesti

Tiedot on saatavilla palvelurajapintojen kautta.

Rajapintaratkaisun tulee olla stabiili

Rajapinnat toteutetaan pohjautuen SOAP/Webservice tai Rest teknologioihin , jotka ovat tällä hetkellä yleisesti käytössä ja koeteltuja.

Rajapinnan tulee olla suorituskykyinen

Rajapinnat toteutetaan pohjautuen SOAP/Webservice tai Rest teknologioihin , jotka ovat tällä hetkellä yleisesti käytössä ja koeteltuja. Rajapintojen toteutuksissa käytetään cacheja jos se on mahdollista.

Palveluiden hallintaratkaisut, (esim. palveluhakemisto, versionhallinta, SLA-sopimukset) pitää kehittää ja ottaa käyttöön.

Palveluluiden hallintaratkaisut toteutetaan OSGI-teknologian ja dokumentaation avulla.

Rajapintojen tulisi olla tilattomia, ts. rajapintakutsun tuloksen tulee olla riippumaton sitä edeltäneistä kutsuista

Palvelurajapinnat tehdään tilattomiksi. Tila pidetään yllä käyttöliittymämoduulissa, käyttöliittymän logiikan tila, tai tallentamalla tilatieto tietueeseen. Mikäli hyödynnetään tulevaisuudessa prosessimoottoria, tila on tallentuneena prosessi-instanssiin.

Säädökset, ohjeet ja standardit

Uusien rajapintojen tulee olla sanomapohjaisia (kysymys-vastaus- sanomapareja)

Rajapinnat toteutetaan pohjautuen SOAP/Webservice tai Rest teknologioihin.

Uusien rajapintojen määrittelyssä tulee huomioida modernit internet- ja web-teknologiat (esim. HTTPS, WS-I ja SOAP)

Rajapinnat toteutetaan pohjautuen SOAP/Webservice tai Rest teknologioihin.

Rajapintaratkaisun pitää huomioida julkishallinnon tietoarkkitehtuurissa tehdyt linjaukset ja täyttää osaltaan sen vaatimukset.

-

Yhtenäisten rajapintarakenteiden (skeemat, sanastot) tulee perustua JHS 170 ja JHS 175 -suosituksiin.

Rajapintarakenteissa huomioidaan JHS-suositukset, mm. versiointi sekä skeeman rakenne.

Rajapintapalvelujen teknologia ja tietotuotemäärittelyt eivät saa olla ristiriidassa kansainvälisten säännös- ten kanssa (esim. INSPIRE direktii- viin liittyvät komission asetukset koskien paikkatietoja)

-

Arkkitehtuuriratkaisun tulee perustua yleisiin standardeihin, joiden yk- sityiskohtainen soveltaminen ei saa johtaa järjestelmätoimittajariippu- vuuksiin.

Arkkitehtuuriratkaisussa on suosittu standardeja palvelurajapinnoissa.

Ratkaisussa pitää käyttää vakiintuneita ja toimivaksi todettuja menetelmiä ja standardeja.
Rajapintapalveluiden standardien tulee olla myös käytännössä testattuja.

Arkkitehtuurin tulee huomioida toimialakohtaiset standardit

On huomioitu JHS-suositukset sekä raketti-hankkeen käsitteet sekä skeemat.

Ratkaisussa on kytkeydyttävä kansainvälisesti sovittuihin toimintata- poihin ja standardeihin (osa perustuu EU-lakeihin).

-

Ratkaisussa pitää käyttää tekniikoita ja ratkaisuja, joiden elinkaari ei ole päättymässä ja joille löytyy tuki.

Ratkaisun tulee tukeutua Valtion IT- palvelukeskuksen tarjoaman yhtei- sen integraatiopalvelun käyttöön.

-

Arkkitehtuuriratkaisun tulee tukea hajautettua palveluarkkitehtuuria

Peppi - arkkitehtuuri on suunniteltu hajautettaviksi. Tämä toteutuu mm. tekemällä palveluista tilattomia, tekemällä kutsut palveluiden välillä rajapintoja vasten.

Rajapintojen sanomaformaatin tulisi olla ”document/literal”-tyyppinen

SOAP-sanomista tehdään document/literal tai document/literal wrapped tyyppisiä sanomia.

Hallittavuus

Rajapinnasta tulee olla tekninen kuvaus.

-

Tiedon kuvauksen tulee olla saatavilla ja hyödynnettävissä.

-

Tiedot tulee olla kuvattu.

-

Rajapinnasta tulee olla käyttöohje.

-

Rajapintaratkaisulla tulee olla toimiva versionhallinta.

Palvelurajapinnoista voidaan ajaa useampaa eri versiota rinnakkain OSGI-teknologian avulla.

Rajapintamääritykset on versioitava ja ylläpidettävä versiohistoria määrittelydokumentissa.

-

Uusi versio ei saa häiritä vanhan version käyttäjiä.

Palvelurajapinnoista voidaan ajaa useampaa eri versiota rinnakkain OSGI-teknologian avulla.

Vanhat versiomääritykset on säilytettäva

Versiomääritykset säilyvät versionhallinnassa. Jokainen julkaistu versio tagataan versionhallintaan.

Rajapintapalveluissa tulee mahdollistaa tuoteversiointi ja vanhojen versioiden alasajo.

Palvelurajapinnoista voidaan ajaa useampaa eri versiota rinnakkain. Käytäntönä voidaan pitää, että ylläpidetään tarvittaessa palvelusta kolmea versiota. Tällöin päivitykset voidaan tehdä hallitusti, koska päivityksillä on siirtymäaika.

Palvelun käyttäjälle on oltava saatavissa muuttunut tieto.

-

Ratkaisun pitää sisältää päivitysrajapinnat. Päivitysten edellyttämä transaktioiden hallinta pitää huomioida.

-

Rajapintaskeemat tulisi kuvata omissa, erikseen ylläpidettävissä do- kumenteissaan.

-

Rajapintamääritysdokumenttien on löydyttävä keskitetystä paikasta (esim. Yhteentoimivuusportaali).
Perustietovarantojen sisällön ja tie- topalvelurajapintojen dokumentaatio pitää tuoda helposti ja julkisesti saa- taville.

-

Kansainvälisyys, kieliversiot ja lokalisointi

Rajapintapalveluiden tulee mahdollistaa sekä kansainvälisten että kansallisten palveluiden ja tietotuotemäärittelyjen rinnakkaisuuden

Järjestelmässä on mahdollista muuntaa tietyn palvelun palauttama viesti toisen skeeman mukaiseksi.

Muut vaatimukset (mm. taloudellisuus)

Ratkaisun tulee kestää pitkälle tulevaisuuteen ja muutosten tullessa muutostöiden kustannukset/tehtävä tulee olla ratkaisua jo käyttäville minimaalinen.

Palvelupohjaisessa arkkitehtuurissa lähtökohtana on moduulien ja palveluiden uudelleenkäytettävyys. Tämä vähentää tietojärjestelmien tekemiseen liittyviä kustannuksia tulevaisuudessa.