Tiedonsiirto- ja rajapintastandardit
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 HTTP:n päällä suosiossa.
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?)
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ä
WSDL WSDL-kieli jolla määritellään rajapinta. Versiota 2.0 voidaan käyttää sekä SOAP protokollaa, että HTTP:tä RESTful tyyliin käyttävien palveluiden kuvaamiseen
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.
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
SOAP Yleisesti käytetään XML:n ja HTTP:n yhdistelmää XML on hyvin tuettu, mutta käsittely raskasta HTTP universaalisti tuettu, mutta pyyntö-vastaus malli raskas siitä poikkeavissa käyttökohteissa. AMQP vaihtoehto HTTP:lle(jonotus) Suunniteltu viestinvälitykseen 1.0 versiota ei vielä standardoitu, kehitys ollut käynnissä vuodesta 2004. Vaatii luonnollisesti AMQP palvelin- ja asiakasohjelmistot (Ei vielä saatavilla merkittävimpiin ESB-tuotteisiin )
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
REST Hyvin vahva kytkös HTTP:hen Käytännössä kaikki olemassa olevat toteutukset käyttävät HTTP:tä. HTTP:n 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 HTTP:n yksinkertaisuus
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.
Eteneminen? Vaihtoehtoja REST ja SOAP pohjaisille ratkaisuille??? Suositaanko jompaakumpaa vai käytetäänkö molempia tilanteen mukaan? Odotetaanko PERAn loppuraporttia? Pyritäänkö vaikuttamaan PERAn linjauksiin?