Tiedonsiirto- ja rajapintastandardit

Transkriptio

1 Tiedonsiirto- ja rajapintastandardit

2 Viitekehys Julkishallinnon perustietovarantojen rajapinnat (PERA) työryhmän tulokset valmiit syksyllä 2011 Määrittelee teknisen arkkitehtuuriratkaisun tietovarantojen rajapintapalveluiden toteuttamiselle. Välitulosten ja nykyratkaisujen kuvausten perusteella SOAP ja/tai REST päällä suosiossa.

3 Viitekehys SOA - arkkitehtuuri Ei suoraan määrää teknologiaratkaisuja, mutta asettaa toteuttaville palveluille vaatimuksia, jotka rajaavat teknologiavaihtoehtoja: Palvelurajapinnan viestirakenteeseen pitää olla mahdollista lisätä uusia ominaisuuksia, ilman että aiemmin käytetty viestirakenne hajoaa. palvelurajapinta pitäisi kuvata standardilla ja alustariippumattomalla tavalla (WSDL?)

4 Viitekehys - Palveluiden tulee olla löyhästi kytkettyjä(irti toteutustavasta) -> toteutusta mahdollista muuttaa ilman rajapinnan muuttamista. - Palveluiden tulee olla helposti haettavissa (UDDI?) - Palveluiden tulee olla käytettävissä erilaisissa ympäristöissä ja erilaisissa järjestelmissä

5 WSDL WSDL-kieli jolla määritellään rajapinta. Versiota 2.0 voidaan käyttää sekä SOAP protokollaa, että RESTful tyyliin käyttävien palveluiden kuvaamiseen

6 RPC Tehokkaita ja laajan ohjelmointikielten kirjon tukevia toteutuksia olemassa. Toteutuksen valinta kuitenkin sitoo palvelun ja käyttäjän vahvasti toisiinsa. Jos tätä kierretään muuntamalla RPC kutsuja ESB:n avulla, menetetään iso osa RPC:n tehokkuudesta. Mahdollisuus mielivaltaisten operaatioiden määrittelyyn.

7 SOAP Web service WSDL kielellä kuvataan millaisella viestillä operaatiota kutsutaan, ja millainen viesti saadaan takaisin Voidaan välittää monipuolisia olioita, ja tehdä yksityiskohtaisia operaatioita niille. Viestissä voidaan välittää kokonaisia olioita Useita abstraktiokerroksia Viestien muoto vaihto kuljettaminen käsittely

8 SOAP Yleisesti käytetään XML:n ja yhdistelmää XML on hyvin tuettu, mutta käsittely raskasta HTTP universaalisti tuettu, mutta pyyntö-vastaus malli raskas siitä poikkeavissa käyttökohteissa. AMQP vaihtoehto Suunniteltu viestinvälitykseen 1.0 versiota ei vielä standardoitu, kehitys ollut käynnissä vuodesta Vaatii luonnollisesti AMQP palvelin- ja asiakasohjelmistot (Ei vielä saatavilla merkittävimpiin ESB-tuotteisiin )

9 REST Kokoelma periaatteita ja rajoitteita. Arkkitehtuuriratkaisu, kun taas SOAP standardoitu protokolla tiedon vaihtoon. Jokaisella resurssilla on uniikki tunniste (URI) jonka avulla resurssiin voidaan kohdistaa operaatioita Resursseja käsitellään aina erilaisten esitysten kautta, toisin kuin monissa SOAP ratkaisuissa GET pyyntö resurssiin /henkilo/x palauttaa tiedot henkilöstä x PUT pyyntö samaan resurssiin päivittää henkilön tiedot Kaikki resurssille suoritettavissa olevat operaatiot käyvät ilmi resurssin esityksestä. Resurssille mahdolliset operaatiot saadaan selville siis vasta kun siitä on haettu esitys On mahdollista käyttää WSDL-kieltä resurssien ja niiden operaatioiden kuvaamiseen

10 REST Hyvin vahva kytkös Käytännössä kaikki olemassa olevat toteutukset käyttävät metodit GET, PUT, POST ja DELETE määräävät mahdolliset operaatiot. Toisaalta mahdollista käyttää mitä tahansa sovelluskerroksen protokollaa joka tarjoaa halutut operaatiot, kuten SOAP. Tällöin SOAP rajapinta hoitaa uusien operaatioiden toteutuksen Menetetään yksinkertaisuus

11 Tietoturva SOAP tarjoaa laajennuksia protokollaan, joiden avulla voidaan esim. allekirjoittaa tai salata SOAP viestejä käytettävästä sovelluskerroksesta riippumatta Nämä menetelmät varsinkin yhdistettynä ovat hitaita, sillä viestin XML kehys lisää salattavan datan määrää REST arkkitehtuurissa käytetään alla olevan protokollan tietoturvamenetelmiä. HTTPS salaa yhteyden palvelimen ja käyttäjän välillä ja tunnistaa tahot. Käyttäjän tunnistus vaatii kuitenkin henkilökohtaisen sertifikaatin. Salaus ja tunnistus koskee kuitenkin vain yhteyttä, eikä välitettyjä viestejä. Jaettua avainta käyttämällä voidaan salata ja tunnistaa myös yksittäiset viestit. Tällöin viesti voidaan myös välittää useille palveluille jotka voivat tehdä omat pääsynhallintatarkastuksensa.

12 Eteneminen? Vaihtoehtoja REST ja SOAP pohjaisille ratkaisuille??? Suositaanko jompaakumpaa vai käytetäänkö molempia tilanteen mukaan? Odotetaanko PERAn loppuraporttia? Pyritäänkö vaikuttamaan PERAn linjauksiin?