Ohjelmistojen integroinnille on tunnetusti tarvetta ja tämä tarve on yhä kasvamassa. Asiaa voidaan tarkastella sekä ohjelmistoteknisestä näkökulmasta

Transkriptio

1 1

2 Internetiä on käytetty paljon B2C-tyyppiseen kommunikointiin, jolloin sovelluksen asiakas/käyttäjä on ihminen. Käyttö voi tapahtua esimerkiksi selaimen avustuksella. Vaikkapa on-line kauppapaikat ovat esimerkkejä B2Ckommunikoinnista. Internetiä hyödynnetään kuitenkin yhä enenevissä määrin myös B2B-kommunikointiin. Tällöin sovellukset kommunikoivat keskenään. Jotta tämä olisi mahdollistaa, täytyy asiakassovelluksen ja palvelusovelluksen käyttää ennalta sovittua kommunikointimekanismia. B2B-integraatio voi olla tiivis perustuen olemassa oleviin RPC:tä (Remote Procedure Call) tukeviin komponenttiteknologioihin (esim. CORBA, RMI, DCOM) tai löyhä perustuen yksinkertaisempiin teknologioihin. Nämä löyhän integraation sallivat teknologiat ovat usein tekstipohjaisia, esimerkiksi yksinkertainen nimi-arvo pari, XML-pohjainen RPC tai SOAP (Simple Object Access Protocol) viesti. Lisäksi niiden avulla voidaan minimoida palomuuriongelmia (kun käytetään sopivaa protokollaa kuten HTTP). Tällä tosin on luonnollisesti myös kääntöpuolensa erityisesti tietoturvan näkökulmasta. 2

3 Ohjelmistojen integroinnille on tunnetusti tarvetta ja tämä tarve on yhä kasvamassa. Asiaa voidaan tarkastella sekä ohjelmistoteknisestä näkökulmasta että liiketoiminnan näkökulmasta. Liiketoiminnan asettamat vaatimukset ovat tyypillisesti korkean tason vaatimuksia, jotka tavalla tai toisella tarkennetaan tai joista johdetaan teknisiä vaatimuksia. Vaikka linkki näiden välillä onkin, se ei aina ole kovin selvä. Näin ollen vaikka vaatimukset saattaisivatkin kuulostaa samanlaisilta, tarkoitetaan niillä usein eri asioita. Esimerkiksi tehokkuudella liiketoiminnan näkökulmasta tyypillisesti tarkoitetaan kustannustehokkuutta, kun taas ohjelmistoteknisestä näkökulmasta sillä tarkoitetaan esim. suoritusaikaa. Näiden tulkintojen välillä on luonnollisesti kuitenkin yhteys. Vastaavasti ns. metavaatimus eli kyky vastata muuttuviin vaatimuksiin tarkoittaa käytännössä eri asioita teknisesti ja liiketoiminnan näkökulmasta. 3

4 Seuraavaksi tutustumme lyhyesti kolmeen eri termiin: integraatioarkkitehtuuri, palveluorientoitunut arkkitehtuuri ja Web-palvelu. Integraatioarkkitehtuuri määrittelee ja kuvaa tavan liittää toisiinsa ohjelmistoja, komponentteja, ohjelmistojen osia tai ohjelmistojen tarvitsemia/käyttämiä tietoja. Se ei sinänsä siis edellytä mitään erityistä palvelunäkökulmaa. Palveluorientoitunut arkkitehtuuri (SOA) on puolestaan esimerkki integraatioarkkitehtuurista. Se on siis yksi tapa toteuttaa integraatio. On myös sanottu, että SOA ei sinällään edellytä varsinaisten integraatiotekniikoiden käyttämistä; varsinainen integraatioaspekti tulee esille vasta puhuttaessa (monimutkaisemmista) palveluiden koordinoinnista. Palveluiden koordinoinnilla tarkoitetaan useiden palveluiden kommunikointia koskevia esim. interaktioiden järjestystä koskevia sääntöjä. Sillä siis tähdätään varsinaisten liiketoimintatransaktioiden määräämiseen yksinkertaisen point-topoint kommunikoinnin sijaan. Palveluiden koordinointiin palaamme myöhemmin. Kyseisestä argumentista voi tosin olla montaa mieltä, koska myös yksikertainen palveluiden välinen (point-to-point) viestinvälitys toteuttaa löyhän integraation. Dr. Hao Hen (W3C Web Services Architecture Working Group) esittämää määritelmää palveluorientoituneesta arkkitehtuurista (SOA) pidetään yleisesti hyvänä ja ehkä parhaana määritelmänä. Hen mukaan SOA on arkkitehtuurityyli, jonka tarkoituksena on saavuttaa sovellusten välinen kommunikointi mahdollisimman löysin sidoksin. He määrittelee palvelun edelleen tehtävänä, jonka palvelun tarjoaja tekee palvelun käyttäjän puolesta pyrkien saavuttamaan ko. tehtävältä edellytetyt tulokset. 4

5 Web-palvelut puolestaan tarjoavat tavan toteuttaa SOA. SOA ei sinällään ota kantaa miten kommunikointi toteutetaan. Mikäli toteutus tehdään Web-palvelukonseptin avulla, tarkoitetaan käytännössä WSDL-kielen käyttöä palvelun tietojen kuvaamiseksi ja SOAPprotokollaa varsinaisen kommunikoinnin toteuttamiseksi. Tutustumme näihin kieliin tarkemmin myöhemmin. Vaikka kyseisten kielten käytöstä ollaankin päästy käytännössä sopimukseen, on myös esitetty muita erilaisia näkemyksiä Web-palveluista. Nk. REST-like -palvelut (tai RESTful-palvelut ) toteuttavat kommunikoinnin SOAPia kevyemmin ja tehokkaammin. REST (REpresentational State Trasfer) on alun perin Roy Fieldingin väitöskirjassaan esittämä arkkitehtuurityyli hypermediajärjestelmiä varten. REST käyttää tyypillisesti HTTP-protokollaa (esim. GET ja POST operaatiot) ja se nojautuu määrättyjen standardisemantiikan omaavien korkean tason rajapintaoperaatioiden käyttöön (add, remove, set, get, ). Näin ollen resurssien tarjoamat palvelut tai operaatiot ovat ennalta määrättyjä, toisin kuin perinteisessä Web-palvelukonseptissa. Myös ebxml tarjoaa toisenlaisen, liiketoimintaorientoituneemman näkökulman Web-palveluihin. Näihin molempiin palaamme myöhemmin. Näitä kolmea käsitettä (integraatioarkkitehtuuri, SOA ja Web-palvelut) käytetään käytännössä usein hieman väärin. Esimerkiksi integraatioarkkitehtuurista ja SOAsta puhutaan lähes synonyymeinä. Sama pätee (erityisesti!) SOAn ja Web-palveluiden kohdalla. Termien käytössä kannattaakin olla väärinymmärrysten välttämiseksi huolellinen. 5

6 SOAan ja sen toteuttamiseen liittyy joukko vaatimuksia ja periaatteita, joista seuraavaksi käymme läpi tärkeimpiä. SOA pyrkii ratkaisuun, jossa palveluiden välillä on mahdollisimman vähän riippuvuuksia. Jo komponenttiteknologiat pyrkivät tähän aikoinaan, mutta eivät täysin kyenneet sitä toteuttamaan. Riippuvuuksista osa erityisesti nk. keinotekoiset riippuvuudet - on haitallisempia kuin toiset. Keinotekoiset riippuvuudet ovat sellaisia, jotka eivät ole välttämättömiä ja jotka usein johtuvat esim. valituista teknologiaratkaisuista. Erityisesti näiden keinotekoisten riippuvuuksien eliminoiminen on tärkeää esimerkiksi ylläpidettävyyden, siirrettävyyden jne. kannalta. Lisäksi tiedon yhtenäisyys tulisi kyetä määrittämään yhden palvelun sisällä, ei monen palvelun kesken. Tämä sallii riippuvuuksien minimoinnin lisäksi myös palveluiden itsenäisyyden. SOA pyrkii myös palveluiden myöhäiseen konfigurointiin ja palveluiden sidontaan. Tavoitteena on erityisesti Web-palvelukonseptissa että palveluita on mahdollista etsiä dynaamisesti ajonaikana. Tämä mahdollistaa palveluiden etsimisen juuri kyseiseen tilanteeseen, kontekstiin ja tarpeeseen. Tämä puolestaan myös edellyttää, että löydettyihin (tai tiedettyihin) palveluihin voidaan muodostaa yhteydet dynaamisesti ajonaikana. Myös myöhäinen konfigurointi ja sidonta osaltaan auttavat palveluiden välisten sidontojen minimoinnissa. Toisaalta ne saattavat aiheuttaa tehokkuusongelmia ajonaikana. 6

7 Palveluiden tulisi lisäksi olla mahdollisimman pitkäikäisiä. Pitkä ikä lisää potentiaalisesti käyttäjämäärää ja tunnettuutta...mikäli palvelu osoittautuu hyödylliseksi. Lyhytikäiset ja helposti/usein ei-saatavilla olevat palvelut ovat ongelmallisia muiden palveluiden kannalta: ne edellyttävät tarvittavien virheistätoipumismekanismien toteuttamista (esim. palvelun korvaaminen toisella palvelulla), mikä vähintäänkin aiheuttaa tehokkuusongelmia. Pitkäikäiset palvelut puolestaan antavat käyttäjille (asiakasohjelmat) mahdollisuuksia virheiden ja yhteistoiminnallisuusongelmien käsittelyyn. SOAn ja Web-palveluidenkin yksi tärkeimmistä vaatimuksista on toteutusriippumattomuus. Asiakasohjelman kannalta palvelun rajapinta on oleellinen, ei palvelun sisäinen toteutus (vrt. hajautustekniikat). Palveluilla tulisi lisäksi olla melko korkea abstraktiotaso. Tällä hetkellä käydään melko vilkkaasti keskustelua siitä, mikä on palvelun ja toisaalta komponentin (vrt. hajautustekniikat) ero ja mikä on oikea abstraktiotaso palveluille. Tähän ei ole olemassa yksiselitteistä vastausta, vaan asia on riippuvainen kulloisestakin tilanteesta. REST-hengen soveltamisessa palvelupohjaisiin järjestelmiin pyritään (kuten aiemmin todettiin) erityisen korkean abstraktiotason palveluihin edellyttämällä, että palvelun rajapinta tarjoaa ennalta määrätyn joukon (tai sen osajoukon) semantiikaltaan tunnettuja operaatioita. Tällöin pyritään paitsi palveluiden myös itse interaktion korkeaan abstraktiotasoon. Palveluiden ja komponenttien eroa mietittäessä asiaa kannattanee miettiä (myös) asiakassovellusten näkökulmasta. Tällöin voidaan karkeasti sanoa, että komponentteja tarkastellaan tyypillisesti niiden rakenteen kannalta, kun taas palveluita tarkastellaan niiden tarjoaman toiminnallisuuden kannalta. 7

8 Yksi SOAn periaatteista on pyrkiä autonomisiin palveluihin. Tällä tarkoitetaan käytännössä sitä, että osapuolet ovat itsenäisiä eivätkä ne ole keskitetysti hallittuja. Tältä osin palvelu-orientoituneet systeemit ja ehkä erityisesti Webpalvelut eroavat hajautetuista järjestelmistä. Hajautettua hallintaa korostaen Web-palveluita kutsutaan myös ei-keskitetyiksi. Autonomisuuteen liittyy myös se, että yhteyksien muodostamisen lisäksi itsenäiset osapuolet mahdollisesti myös neuvottelevat ja tekevät sopimuksia kommunikointia koskien, mieluiten dynaamisesti. Esimerkki ketteryydestä vaatimusten hallinnassa on puolestaan kyky reagoida muuttuviin ja uusiin vaatimuksiin. Tällaista vaatimusta uusiin vaatimuksiin reagoinnista ja niiden hallinnasta kutsutaan myös meta-vaatimukseksi. Tilattomuus on myös nostettu usein esille tärkeänä SOA-suunnitteluperiaatteena. Tilattomuus liittyy oleellisesti myös muihin periaatteisiin, erityisesti tavoitteeseen pyrkiä mahdollisimman löyhiin sidontoihin. Tilattomuus tarkoittaa oleellisesti sitä, että asiakassovelluksilta tulisi edellyttää mahdollisimman vähän etukäteistietoa palvelusta. Palvelukutsu ei esimerkiksi siis saisi riippua palvelun tilasta ja mahdollisesta edellisestä palvelukutsusta. Lisäksi tilainformaation hallinta saattaa haitata sekä palvelun saavutettavuutta että skaalautuvuutta. Yhdeksi SOAn suunnitteluperiaatteeksi mainitaan usein myös palveluiden 8

9 yhdistettävyys. Tämä tarkoittaa sitä, että palveluita tulisi voida yhdistellä isommiksi palveluiksi, joille niinikään pätevät kaikki SOAn mainitut SOAn vaatimukset ja periaatteet. 8

10 Tämä yleiskuva palveluorientoituneesta arkkitehtuurista on yleisesti käytetty ja sitä kutsutaan toisinaan myös Web-palvelun arkkitehtuuriksi. Sama perusarkkitehtuuri esiintyy useissa eri lähteissä, pienin nimeämismuutoksin varustettuina. Lisäksi riippuvuudet voidaan usein nähdä kaksisuuntaisiksi. SOA ei kuitenkaan ole sama asia kuten edellä todettiin - kuin Web-palvelut; Webpalvelut ovat vain yksi esimerkki SOA:n toteuttamisesta. SOA kuvaa toisin sanoen yleisen mallin eikä ole ainoastaan Web-palveluita varten. Lisäksi tässä arkkitehtuurikuvassa on ennen kaikkea kyse palvelukonseptiin liittyvistä eri rooleista ja niiden riippuvuuksista. Seuraavaksi pureudumme kaavion eri osiin tarkemmin. Esimerkkiskenaario: 1.) Palvelun tarjoaja (Provider) julkistaa palvelun (Publish) 2.) Asiakas (Requestor) etsii haluttua palvelua kutsuen rekisteripalvelua (Broker) 3.) Asiakas saa rekisteripalvelusta vastauksen, jossa kuvataan palvelu ja se miten sitä voidaan käyttää 4.) Asiakas kutsuu palvelua saadun kuvauksen perusteella 9

11 Palvelun tarjoajan tulee kuvata palvelu (describe operaatio) jollain yleisesti käytössä olevalla tavalla. Käytännössä tämä tapa on Web Service Description Language (WSDL), jota käsitellään lisää myöhemmin. Palvelun kuvaus välitetään rekisteriin (publish operaatio), josta asiakkaat voivat sitä hakea. Asiakas voi myöhemmin käyttää palvelun tarjoamia (ja mahdollisesti julkaisemia) operaatioita (bind operaatio). 10

12 Palvelun käyttäjä (Requestor) voi etsiä haluttuja palveluita rekisteristä antamalla sopivia hakukriteerejä. Saatuaan rekisteriltä vastauksena hakuehtoihin sopivat palvelut, palvelun käyttäjä voi ottaa yhteyttä valitsemaansa palveluun. Rekisteristä saadaan käytännössä palvelujen kuvaukset (WSDL), jotka sisältävät kaiken tarvittavan tiedon: mitä operaatioita on tarjolla, mitä parametrejä ne edellyttävät ja miten palveluun otetaan yhteyttä. On kuitenkin huomioitavaa, että tämä skenaario on vain esimerkki. Palvelun käyttäjän ei luonnollisestikaan tarvitse etsiä palvelua rekisterissä mikäli sillä on jo tarvittavat tiedot palvelun käyttämiseen. Palvelun käyttäjä (Requestor) voi itse asiassa toimia myös palvelun tarjoajan roolissa (Provider): palvelun käyttäjä voi muodostaa uuden palvelun yhdistämällä muita palveluja ja rekisteröimällä tämän uuden korkeatason tai monipuolisemman palvelun. Näin voidaan muodostaa hierarkisia palveluita. 11

13 Rekisteri (esimerkiksi UDDI rekisteri) sisältää joukon palvelujen julkaisemia kuvauksia. Se kategorisoi kuvaukset, jotta niiden etsintä eri kriteerein olisi joustavaa. Palvelun julkaiseminen ja toisaalta palvelujen etsiminen tapahtuu määriteltyjen operaatioiden avulla. Rekisterin tulee määritellä palvelun kuvaus ja API täsmällisesti, koska niitä tulee voida käyttää muista sovelluksista käsin (ei siis tarkoitettu ihmisten luettaviksi). Myös rekisteri voidaan nähdä itse asiassa palvelun tarjoajana: sen tarjoama palvelu on palvelurekisteri, jolta voidaan kysellä muita palveluja ja niiden yhteystietoja. 12

14 Ohjelmistuotannon välineiden ja ohjelmointikielten kehityksessä abstraktiotason nosto on aina näytellyt merkittävää osaa, eikä ole mitään syytä olettaa tähän trendiin tulevan muutosta jatkossakaan. Esimerkiksi ohjelmointikielten kehitys yleisesti on pyrkinyt tarjoamaan ohjelmoijille korkeamman ja ohjelmoijaystävällisemmän abstraktiotason ohjelmien kirjoittamiseksi. Olioperustainen ohjelmistokehitys (ja olioperustaiset ohjelmointikielet) tarjosivat/tarjoavat luonnollisen tavan ajatella ohjelmien käsitteitä (luokat ja oliot) ja niiden suhteisiin perustuvaa ohjelmien rakennetta. Komponentit ja hajautustekniikat edelleen tarjoavat korkeamman abstraktiotason oliokieliinkin verrattuna. Hajautus on periaatteessa yksinkertainen asia, mutta eri komponenttiteknologioilla (RMI, (D)COM, CORBA, ) on kiinnostavia ominaisuuksia. Ensinnäkin ne sallivat integroitavien komponenttien/alisysteemien käsittelemisen mustana laatikkona (rajapinta oleellinen). Komponenttien yhteiskäyttöön ja niiden konfigurointiin liittyvät ongelmat on käytännössä jätetty ohjelmoijien ratkottaviksi. Mikä tulee siis olemaan seuraava abstraktiotason nosto? Jos se on SOA, niin miten se eroaa periaatteellisella tasolla hajautustekniikoista? 13

15 Mitä uutta SOA tarjoaa olemassa oleviin ajattelutapoihin ja tekniikoihin verrattuna? Jos asiaa tarkastellaan puhtaasti ohjelmistoarkkitehtuurisesta näkökulmasta, ei SOA periaatteessa vaikuta kovinkaan kiinnostavalta eikä e näytä tarjoavan oleellisesti paljonkaan uutta (vrt. hajautusteknologiat). Edellä mainitut SOAn periaatteet ja vaatimukset voidaan hyvin pitkälle katsoa samoiksi odotuksiksi ne, joita hajautustekniikoilta aikoinaan odotettiin ja edellytettiinkin: korkea abstraktiotaso, toteutuskieli- ja/tai alustariippumattomuus, autonomisuus, mahdollisimman löyhät sidonnat, tavoitteena itsenäiset ja pitkäikäiset komponentit, ketteryys vaatimusten hallinnassa jne. Hajautustekniikat eivät kuitenkaan kyenneet kovin hyvin vastaamaan näihin haasteisiin. SOAlta ja Web-palveluilta odotetaankin paljon näiden haasteiden näkökulmasta. Esimerkiksi löyhät sidonnat voidaan toteuttaa mielenkiintoisesti Web-palveluteknologioita hyödyntäen, joista käytännössä ollaan päästy sopimukseen (WSDL ja SOAP, näihin palataan myöhemmin). Lisäksi muitakin eroja tuntuu löytyvän. SOAa ja Web-palveluita ei ole tarkoitettu vain RPC-tyyppiseen kommunikointiin. Lisäksi tavoitteena on paitsi ohjelmiston myös niiden hallinnan hajautus. SOA voidaankin kuitenkin katsoa tietynlaiseksi hypyksi seuraavalle abstraktiotasolle (komponentit->palvelut). 14

16 SOAa ei kuitenkaan kannata eikä pidä tarkastella vain puhtaasta ohjelmistotuotannollisesta näkökulmasta. SOAn ehkäpä suurin uutuusarvo on siinä, että se tuo ohjelmistoteknistä ja liiketoimintaorientoitunutta näkökulmaa lähemmäksi toisiaan, tai ainakin se mahdollistaisi tämän. Tämä ei ole ollut yhtä selvästi näkyvissä ennen (vrt. olioperustaisuus tai hajautustekniikat). SOA mahdollistaa palveluekosysteemit (kuten niitä usein kutsutaan), jotka koostuvat palveluista, joilla omat liiketoimintaprosessit. Tällöin liiketoimintaprosessien ja niiden vaatimusten ymmärtäminen oleellista palveluiden toteuttamisessa. Osittain tämän vuoksi, kuten aiemmin mainittiin, oleellisena erona komponenttiteknologioihin verrattuna on se, että komponentteja tarkastellaan yleensä niiden rakenteen kannalta, kun taas palveluita tulisi tarkastella niiden tarjoaman toiminnallisuuden kannalta. Käsitteiden kanssa on syytä kuitenkin olla huolellinen: esim. palvelu ja arkkitehtuuri tarkoittavat eri asioita ohjelmistokehityksen ja liiketoiminnan näkökulmista. Myös esimerkiksi tehokkuudella ja uudelleenkäytöllä on eri implikaatiot: ohjelmistotekniikan kannalta nämä termit ovat tuttuja, mutta liiketoiminnan näkökulmasta näillä viitataan usein tehokkaaseen informaatiojärjestelmien hyödyntämiseen ja esim. kustannus-hyötytehokkuus analyyseihin. 15

17 Kuten aiemmin todettiin, Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja kommunikointi toteutetaan SOAPin avulla. Näihin kieliin palaamme myöhemmin. On kuitenkin todettava, että Webpalvelustandardeihin liittyy myös paljon ongelmia. Toisaalta nämä standardit kehittyvät jatkuvasti ja toisaalta esimerkiksi palveluiden koordinointiin liittyen ei standardeista olla aivan vielä päästy vastaavaan yhteisymmärrykseen. Tosin juuri tällä hetkellä näyttää siltä, että tämäkin ongelma on ratkeamassa. Sanaan standardi kannattaakin yleisesti suhtautua varauksellisesti Web-palveluihin liittyvistä teknologioista puhuttaessa: kyseessä saattaa olla lähinnä ehdotus eikä varsinaisesti standardi. Ja toisaalta standardista käytetään usein rinnakkain useita eri versioita. SOA ja Web-palvelut pyrkivät periaatteessa ratkaisemaan yhteentoimivuuteen, konfigurointiin jne. liittyvät ongelmat automaattisesti ja vieläpä ajonaikana. Esimerkiksi mikäli kutsuttavaa palvelua ei ole saatavilla tai yhteentoimivuusongelmia ilmenee, tulisi kutsuvan palvelun kyetä joko ratkomaan yhteentoimivuusongelmat tai korvaamaan ko. palvelu toisella vastaavan toiminnallisuuden omaavalla palvelulla. Tämä on kuitenkin vielä useissa tapauksissa kaukana käytännön toteutuksista siitä huolimatta, että useista standardeista onkin päästy jo yksimielisyyteen. Automaattisuuteen liittyy myös omat ongelmansa. Esimerkiksi muutosten tekeminen manuaalisesti voi olla vähintäänkin haasteellista. Tällä hetkellä on olemassa runsaasti työkalutukea Web-palveluiden ja asiakassovellusten tekemiseksi ja osin generoimiseksi. Esimerkiksi palvelun rajapintakuvaus (WSDL) voidaan generoida automaattisesti palvelun rajapinnan (esim. Java) perusteella. Nämä työkalut kuitenkin poikkeavat toisistaan sekä tarjottujen ominaisuuksien että toteutustapojen suhteen. Esimerkiksi samasta rajapinnasta (esim. Java) eri työkalut generoivat erilaisia WSDL-kuvauksia. Lisäksi eri työkalujen tarjoamatuki eri Webpalvelukielille, niiden eri versiolle ja eri suosituksille vaihtelee. 16

18 Web-palveluille on esitetty lukuisia määritelmiä. Yksinkertaisimmillaan niiden on sanottu olevan sovelluksia, joihin voidaan ottaa yhteys käyttäen standarditeknologioita (kuten XML ja HTTP). On myös sanottu, että Web-palvelu on käytännössä sama asia kuin SOAP-protokollan käyttö (tästä lisää myöhemmin). Nämä eivät kuitenkaan ole kovin hyviä määritelmiä, sillä ne ovat aivan liian laajoja. W3C puolestaan määrittelee Web-palvelun (vapaasti käännettynä) joukkona ohjelmiin liittyviä rajapintoina, jotka ovat käytettävissä sovellusten välisessä kommunikoinnissa. Tämäkin määritelmä on melko yleinen. Hieman tarkemmin määriteltynä Web-palvelun on sanottu olevan joukko funktioita, jotka on pakattu yhdeksi kokonaisuudeksi ja julkaistu verkossa muiden sovellusten käytettäväksi. Tämä määritelmä on jo selvästi parempi. Oleellista tässä on se, että näitä tarjottuja funktioita voidaan yhdistellä ja pakata uusiksi palveluiksi. Se myös implikoi Web-palveluille hyvin oleellisen piirteen: Webpalveluhierarkian. Toisin sanoen yksinkertaisimmista palveluista voidaan koostaa monimutkaisempia palveluita. Toinen oleellinen asia tässä määritelmässä on palveluiden julkaiseminen. Jotta Webpalvelu olisi aidosti vapaasti etsittävissä ja käytettävissä, edellyttää se, että palveluiden käyttäjät voivat etsiä palveluita jostain yleisesti tunnetusta markkinapaikasta. Viimeinen määritelmä kuvaa Web-palvelut XML-sovelluksina, jotka on sidottu joihinkin ohjelmiin, tietokantoihin tai liiketoimintafunktioihin. Web-palveluissa käytetään XML-pohjaisia kieliä, mutta palveluiden kutsuminen XML-sovelluksiksi voi olla myös harhaanjohtavaa. Tässä määritelmässä oleellista on se, että itse palvelun toiminnallisuus voi mitä vain ja se on voitu toteuttaa millä tahansa halutulla tavalla. Palvelun käyttöä varten tulee kuitenkin toteuttaa käytettäviä standardeja ymmärtävä ja käsittelevä interaktiota tukeva kerros. Web-palvelukonseptin voidaan ajatella olevan myös mekanismi back-end systeemien paketoimiseksi (wrapping). Tällaisia back-end systeemejä voivat olla vaikkapa tietokanta, legacy-systeemi jne. 17

19 Käyttäessään Web-palvelua ohjelma lähettää pyynnön/kyselyn XML-muodossa ja yleensä myös vastaanottaa vastauksen niin ikään XML-muodossa. Jotta kommunikaatio olisi mahdollista, täytyy viestien formaatista ja käytettävän palvelun rajapinnasta sopia. Tämän lisäksi tulee sopia siitä mekanismista, joka määrittelee miten Web-palveluja tulee julkistaa ja miten niitä voidaan etsiä. 17

20 Web-palveluiden alkuperäisen ja tavoiteltavan vision mukaisesti palveluja tulisi voida etsiä ja niitä tulisi voida käyttää dynaamisesti. Tietyn palvelun käyttöön sitominen tulisi siis olla ajonaikainen (dynaaminen) toimenpide, ei staattinen. Sovelluksia tulisi voida muodostaa olemassa olevia palveluita hyödyntäen aina kulloisenkin tarpeen mukaisesti. Nämä yhdessä edellyttävät lisäksi sen, että palveluiden koordinoinnin tulisi myös olla dynaamista. Ehkäpä yksi oleellisimmista näkökulmista on, että Web-paveluiden myötä siirryttäisiin hajautetuista järjestelmistä ei-keskitettyihin järjestelmiin. Tämä merkitsisi sitä, että tarjolla olisi verkko erilaisia (hallinnan näkökulmasta itsenäisiä ja tasavertaisia) palveluita, joita mikä tahansa sovellus voi käyttää ja mahdollisesti yhdistellä uusiksi palveluiksi. Nämä edellä esitetyt visiot ovat luonnollisesti vielä kaukana todellisuudesta. Esimerkiksi tietoturvakysymykset ja käyttöoikeudet asettavat reunaehtoja ja vaatimukia, joita ei vielä yleisellä tasolla olla täysin ratkaistu. Yksittäisiä ratkaisuja ja ratkaisuehdotuksia on esitetty, mutta yhtenäistä periaatetta ja käytäntöjä ei vielä ole. Näin ongelmiin palaamme myöhemmin. 18

21 Kalvolla esitetyn kuvan alimpana kerroksena ovat viestinvälitysprotokollat. Vaikka Web-palveluita usein sanotaan käyttävän ja näin käytännössä hyvin usein onkin itse Webpalvelukonseptia ei ole sidottu tiettyyn viestinvälitysprotokollaan. Yhtä hyvin käytössä voisi olla esimerkiksi SMTP tai FTP. Kuvan seuraavan kerroksen muodostavat Web-palvelustandardit SOAP, WSDL ja UDDI. Näistä ensimmäistä käytetään kommunikointiin sovellusten kesken. WSDL-kieltä puolestaan käytetään kuvaamaan tarjottu Web-palvelu (tarjotut funktiot ja yhteydenottotapa). UDDI on yksi tapa toteuttaa palveluiden markkinapaikka (rekisteri), mutta muitakin vaihtoehtoja on olemassa. Palvelun mainostaminen markkinapaikassa ei palvelun pystytyksen kannalta toki ole välttämätöntä. Mikäli asiakaskunta tietää miten palveluun saa yhteyden ja miten sitä voidaan kutsua, on se tarpeetonta. Näin on usein esimerkiksi kun Web-palvelukonseptia käytetään rajoitetussa ympäristössä kuten yrityksessä. Tällöin mikäli käyttö tapahtuu palomuurien sisäpuolella, ei kommunikoinnin turvallisuuden takaamiseen tarvitse kiinnittää välttämättä huomiota. Palveluverkosto (esimerkiksi toisiaan käyttävät palvelut) edellyttää palvelujen koordinointia. Koordinointipalvelut on esitetty kuvassa kolmantena kerroksena (collaboration services). Esimerkiksi sekvenssi yksittäisten palvelujen suorittamista operaatiosta voidaan haluta koostaa yhdeksi liiketoimintatransaktioksi. Palveluiden yhdistämiseen käytetään nk. orkestointi- ja koreografiakieliä. Näistä orkestrointi tarkoittaa palveluiden yhdistämistä yhdestä tietystä liiketoimintaprosessia suorittavasta näkökulmasta, kun taas palvelukoreografia sallii useita samanaikaisia ja tasavertaisia näkymiä liiketoimintaprosessiin. Näihin palataan vielä myöhemmin. Lopuksi kuvan ylimpänä kerroksena ovat itse Web-palvelut. Kuvan kaikkia eri kerroksia koskee ja tukee joukko muita hyödyllisiä palveluja (utility services). Jotkin käytetyt ratkaisut koskevat kaikkia kerroksia ja voivat siten vaikuttaa käytettäviin formaatteihin, protokolliin ja API-määrittelyihin tai vaikkapa vaikuttaa niiden valintaan. Turvallisuusaspektit ovat 19

22 esimerkiksi hyvin tärkeitä Web-palvelujen kannalta (erityisesti liiketoimintakriittiset palvelut). Vaikka SOAP ei tällä hetkellä suoranaisesti tuekaan turvallista viestinvälitystä, on tämä puute huomioitu ja sen korjaamiseksi on esitetty ehdotuksia SOAP-laajennoksiksi ja esim. digitaalisten allekirjoitusten liittämiseksi SOAP viesteihin (SOAP Security Extensions: Digital Signature). Toisaalta turvallisuus alimmalla tasolla voi tarkoittaa vaikkapa SSL:n tai TLS:n käyttöä. Palvelun laadun huomioiminen (Quality of Service, QoS) puolestaan painottaa vastinaikojen, hinnan, transaktioiden ja muita liiketoimintainteraktioissa oleellisia asioita. 19

23 Web-palvelut voivat käytännössä olla mitä tahansa. Paketoimalla vanha legacy-systeemi Web-palveluksi sovitaan käytännössä erimielisyydestä: legacy-systeemien logiikka tai toteutusta ei tarvitse muuttaa ja ne voivat olla hyvinkin eri tavoin toteutettuja. Erilaiset ketterät liiketomintaprosessit ovat myös potentiaalisia Web-palvelukonseptin käyttökohteita. Esimerkiksi liiketoimintaoperaatiot (laskutus, tilaukset jne.) voidaan tarjota Web-palveluina. Liiketoimintasopimuksien ja liiketoimintaprosessien määritykset ovat erityisesti painotettuja RosettaNet ja ebxml kosepteissa, jotka ovat tietyssä mielessä vaihtoehtoisia näkökulmia Web-palveluihin. Näihin palataan myöhemmin. Yksi palvelun muoto voi olla vaikkapa muiden palveluiden etsintään tarkoitettu rekisteri. Rekisteristä voidaan etsiä palveluita annetuin kriteerein (esim. halvin matka). Palvelu voi myös hyödyntää muita palveluita. Esimerkiksi matkanjärjestämispalvelu voi käyttää hyväkseen sekä palvelua, jonka avulla voidaan etsiä halvimmat lennot kohteeseen annetulla aikavälillä, että palvelua, joka etsii sopivimman hotellin (annettujen kriteerien mukaisesti) matkakohteessa. Web-palveluja käytetään tietyssä mielessä vastoin sen alkuperäistä käyttötarkoitusta ja visiota etäkutsujen toteuttamiseen. Se onkin tällä hetkellä yleisin käyttömuoto. Tämä voidaan tehdä siten, että kutsun muoto on kutsuttavan ohjelman sijainnista riippumaton eli se ei siis näy kutsun muodosta (location transparency). Etäkutsujen toteuttamiseen on kuitenkin jo olemassa useita eri menetelmiä. 20

24 Web-palvelu ei tarjoa mitään mullistavan uutta. Web-palvelua voidaan ajatella ylimääräisenä kerroksena, joka mahdollistaa sovellusten välisen interaktion. Se ei korvaa eikä sen ole tarkoitus korvata olemassa olevia tekniikoita (esim. hajautustekniikat) eikä olemassa olevia ohjelmistoja. Koska kyseessä on kevyt XML-pohjainen integrointi käyttäen yleisesti hyväksyttyjä standardeja, antaa Web-palvelukonsepti mahdollisuuden silloittaa eri teknologioita. Esimerkiksi palvelu voi olla toteutettu.net ympäristössä kun taas sen asiakas voi J2EEtoteutus. Web-palvelu ei kuitenkaan ole myöskään pyörän uudelleen keksimistä. Webpalveluissa ei ole kyse niinkään hajautusteknologiasta (kuten CORBA, DCOM, RMI) vaan siinä pyritään ei-keskitettyyn järjestelmään (ainakin periaatteessa). Lisäksi Web-palvelut eivät ole ohjelmointikieli- tai alustariippuvaisia kuten esimerkiksi RMI ja DCOM. Edelleen voidaan sanoa, että yhteydet on tarkoitettu transienteiksi: palveluihin kytkeydytään dynaamisesti aina tarpeen mukaan. Palvelun käyttäjän ei tarvitse tietää palvelun toteutuksen yksityiskohtia vaan sille riittää ainoastaan palvelun kuvaus. Web-palveluissa on myös oleellista se, että palvelun käyttäjän ja palvelun välillä ei tarvitse olla ennalta määriteltyä sopimusta (tämä on kuitenkin mahdollista ebxml-konseptissa) vaan periaatteessa mikä sovellus tahansa voi käyttää julkaistua palvelua, edellyttäen että palvelun kuvausta ja mahdollisia turvallisuusvaatimuksia noudatetaan. Tämä luonnollisesti pätee annetussa ympäristössä: mikäli kyseessä on esimerkiksi yrityksen sisäisessä verkossa tarjottu palvelu, voi palvelua käyttää vain sovellukset, joiden on mahdollista ottaa palveluun yhteys. 21

25 Edellä esitetty Provider-Requestor-Broker -roolijako kuvaa erilaiset Webpalvelujen käsitteet ja konseptit. Se ei vielä ota kantaa siihen, mitkä ovat käytetyt formaatit ja APIt. Tosin myös siitä on päästy yleisesti yhteisymmärrykseen. Palvelujen kuvaukset ja viestinvälitys suoritetaan käyttäen WSDL ja SOAP - formaatteja (alunperin IBM:n ja Microsoftin ym. yhteisenä ehdotuksena). SOAP ja WSDL ovatkin jo vakiinnuttaneet asemansa. Palvelurekisteri voidaan toteuttaa esimerkiksi UDDI-rekisterinä, mutta sen rinnalle on tullut muitakin kandidaattiteknologioita pääosin UDDI:n tietynlaisen rajoittuneisuuden vuoksi. WSDL ja SOAP -spesifikaatioit kehittyvät edelleen: uuden versiot seuraavat toisiaan ja niihin liittyviä muita suosituksia ja ehdotuksia (W3C) tehdään jatkuvasti. Eri versioiden käyttö luonnollisestikin johtaa yhteentoimivuusongelmiin. Lisäksi nämä spesifikaatiot sisältävät optionaalisia sääntöjä ja kaikki toteutukset eivät välttämättä toteuta samoja optionaalisia piirteitä. Tämä saattaa myös aiheuttaa yhteentoimivuusongelmia, vaikka eri osapuolet käyttäisivätkin samoja versioita. Web Service Interoperability (WS-I) yhteisö pyrkiikin pureutumaan näihin ongelmiin antamalla suosituksia näiden spesifikaatioiden käyttötavoista ja niiden eri versioiden yhteiskäytöstä. Vaikka tavoite onkin varsin hyvä, on tehtävä silti varsin haasteellinen. WS-I yhteisön roolia käsitellään tällä kurssilla myöhemmin. 22

26 23

27 SOAPin uusin versio 1.2 on vuodelta Vaikka tämä versio onkin jo yleisesti käytössä ja myös W3C:n suositus, käytetään versiota 1.1 myös jonkin verran edelleen. SOAPia voidaan käyttää esim. tyypilliseen (yksisuuntaiseen) pyyntö-vaste kommunikointiin, jolloin pyyntöä varten otetun HTTP-yhteyden aikana palautetaan myös vaste. Sitä voidaan käyttää myös kaksisuuntaiseen pyyntö-vaste kommunikointiin (esim. HTTP-palvelin molemmissa päissä). SOAPia voidaan käyttää etäkutsujen merkkaamiseen (vrt. XML-RPC), mutta sen käyttö ei suinkaan rajoitu siihen. Verrattuna binäärisiin formaatteihin SOAP on melko tehoton. Tämä johtuu suurelta osin SOAPin XML-pohjaisuudesta: XML:n käsittely (jäsentäminen, generointi) on melko hidasta. SOAP on riippumaton kuljetusprotokollasta. Yleisimmin käytössä on HTTP, mutta esimerkiksi SMTP tai FTP käyvät myös. Esimerkiksi asynkroninen viestinvälitys (esim. käyttämällä sopivia viestinvälitysprotokollia kuten SMTP) on toteutettavissa SOAPin avulla. SOAPin käyttömahdollisuudet eivät rajoitu pyyntö-vaste kommunikointiin. Se voi toimia yhteisenä kutsuformaattina, jonka avulla voidaan esim. integroida heterogeenisia komponenttiteknologioita (CORBA, DCOM etc.) käyttäviä järjestelmiä. Se soveltuu myös hyvin Internetiä hyödyntäviin (löyhästi kytkettyihin) B2B- ja B2C-sovelluksiin. Lisäksi SOAPin arvo kevyenä protokollana on erityisen tärkeä pienille laitteille, joissa saattaa olla vain yksinkertainen HTTP-ympäristö ja XML-jäsennin, sillä niihin ei voi sisällyttää laajoja runtime-osia. SOAPin yksi tärkeistä eduista on sen laajennettavuus. SOAPin ns. header-osa mahdollistaa sen. Sen avulla voidaan esimerkiksi viestiin liittää sovellusriippumatonta informaatiota. SOAPin nimen Object on harhaanjohtava, koska SOAPissa ei ole objektiviittauksia. Tähän ja muihin SOAPin puutteisiin palataan niin ikään myöhemmin. 24

28 SOAPin pääosat ovat kirjekuori (envelope), otsikko (header) ja runko (body). Kirjekuori määrittelee kehyksen SOAP-viestille. Se sisältää otsikko- ja runkoosat. Otsikko ei SOAP-viesteissä ole pakollinen, mutta mikäli sitä käytetään, on sen oltava alussa ennen runko-osaa. SOAPin otsikko-osa (header) mahdollistaa laajennettavuuden. Sen avulla voidaan esimerkiksi viestiin liittää sovellusriippumatonta informaatiota. Tällaista informaatiota on esimerkiksi turvalliseen viestinvälitykseen liittyvät asiat ja erilainen ohjausinformaatio viestin käsittelemiseksi. SOAP kirjekuoren pakollisessa runko-osassa välitetään varsinainen sovellusspesifi tieto. Esimerkiksi pyyntö-vastaus kommunikoinnin tapauksessa siinä välitetään varsinainen pyyntö (esim. operaatiokutsu) ja vastaus. Myös virheilmoitukset merkataan runko-osaan. 25

29 SOAP-viestin juurielementti on Envelope. Sen alielementteinä ovat mahdollinen Header ja pakollinen Body. SOAP-viestin rakenne on varsin yksinkertainen. Viestin monimutkaisuus muodostuu Header ja Body osien sisäisestä rakenteesta. SOAP spesifikaatio sisältää paljon optionaalisia sääntöjä. Tämä voi aiheuttaa ongelmia käytännössä: kaksi SOAP toteutusta eivät välttämättä toteuta kaikkia (tai samoja) optionaalisia piirteitä, mikä puolestaan voi aiheuttaa kommunikointiongelmia. 26

30 Envelope-elementillä on nimiavuuruusmääre, joka spesifioi käytettävän SOAP version. Esimerkiksi <env:envelope xmlns:env=" kertoo, että kyseessä on SOAP 1.2 versio. Lisäksi siinä voidaan antaa muita nimiavaruusmäärityksiä. Käytettävä prefiksi (tässä env) voidaan luonnollisesti valita vapaasti. SOAPin eri versioiden käyttö saattaa aiheuttaa ongelmia. Esimerkiksi SOAP 1.2:a tukeva prosessori generoi virheen (VersionMismatch) kun sille annetaan SOAP 1.1 kirjekuori sille ominaisine nimiavaruusmäärityksineen. 27

31 RPC:n toteuttamiseksi palvelun käyttäjän (Requestor) ja palvelun tarjoajan (Provider) tulee sopia mekanismista, jolla metodikutsu (erit. ohjelmien määrittelemät ja käyttämät tietotyypit) koodataan XML:ksi ja toisaalta miten se dekoodataan. Attribuuttia encodingstyle voidaan käyttää tämän sopimuksen määrittelemiseen. Toisin sanoen attribuuttia encodingstyle käytetään määrittelemään sarjallistamissääntöjen koodaus. Esimerkki (SOAP 1.2 Part 0: Primer): <env:envelope xmlns:env=" > <env:header>.</env:header> <env:body> <m:chargereservation env:encodingstyle=" xmlns:m=" <m:reservation xmlns:m=" </env:envelope> </env:body>

32 Tässä esimerkissä encodingstyle attribuutin arvo kertoo, että changereservation rakenteen sarjallistamisessa on käytetty SOAPin määrittelemiä (SOAP Part 2 section 3) koodaussääntöjä. Vaikka SOAP spesifioikin nämä säännöt, niiden käyttö on optionaalista ja sovellukset voivat käyttää muitakin koodaussääntöjä sovellusspesifin datan koodaamiseksi SOAP-viestiin. encodingstyleattribuuttia voidaan käyttää SOAP 1.2 versiossa sekä otsikko- että runko-osissa, mutta SOAP 1.1 sallii sen käytön kaikkialla myös Envelope-elementissä. 28

33 SOAP-viesti voi kulkea viestin lähettäjältä vastaanottajalle useamman välittäjän kautta. Välittäjien käyttö onkin kätevä tapa välittää sama viesti useammalle taholle. Se myös antaa välittäjille mahdollisuuden käsitellä viestiä annettujen sääntöjen mukaisesti. Välittäjien käyttö Web-palvelukonseptissa on hyödyllistä: välittäjät voivat tarjota lisätoiminnallisuutta ja lisäarvopalveluita. Välittäjät yleisemminkin mahdollistavat lisäprosessoinnin SOAP-pohjaisessa viestivälityksessä edellyttämättä viestin lähettäjän ja vastaanottajan modifiointeja. SOAP-viestin käsittelijöitä, joita siis voivat olla viestin lähettäjä, välittäjät ja vastaanottaja, kutsutaan SOAP-solmuksi (SOAP node). 29

34 Viestipolku kulkee viestin lähettäjältä välittäjien kautta viestin vastaanottajille. SOAP spesifikaatio ei ota kantaa siihen miten viestipolku määritellään ja miten viestit välitetään eteenpäin. Spesifikaatio kuitenkin määrittelee miten välittäjänä toimivan SOAP-solmun tulee käyttäytyä (käsitellä viesti) vastaanottaessaan SOAP-viestin. Viestin lähettäjä voi olla tietoinen viestipolun välittäjistä, mutta näin välttämättä aina ole. Välittäjiä on kahdenlaisia: passiivisia (forwarding intermediaries) ja aktiivisia (active intermediaries). Passiiviset välittäjät prosessoivat viestin SOAPin sääntöjen mukaisesti (tärkeimmät asiat esitellään seuraavaksi) ja poistaa viestistä tai tarkemmin sanottuna otsikosta - jo käsittelemänsä osat ennen viestin välittämistä eteenpäin. Aktiivinen välittäjä puolestaan sääntöjen mukaisen prosessoinnin lisäksi saattaa tarjota lisäpalveluita, joita ei ole määritelty viestissä. Tällaisia lisäarvopalveluita voivat olla esimerkiksi turvallisuuspalvelut, sisällön muuttaminen ja jäljitys. 30

35 Otsikko tarjoaa käytännössä SOAPin laajennosmekanismin. Otsikko-osassa voidaan antaa sovellusriippumatonta tietoa liittyen turvalliseen viestin välitykseen, viestin käsittelyn ohjaamiseen tai vaikkapa erilaisiin laatuattribuutteihin. Mikäli otsikko-osa annetaan, tulee sen olla ensimmäinen Envelope-elementin alielementti. Otsikon osissa eli Header-elementin alielementeissä voidaan käyttää seuraavia attribuutteja: -encodingstyle (käsitelty edellä) -role: määrittelee SOAP-solmut, joiden tulee prosessoida viesti -mustunderstand: määrittelee tuleeko viestin käsittelevän SOAP-solmun prosessoida kyseinen otsikon osa. Mikäli prosessointia edellytetään, annetaan attribuutin arvoksi true. Attribuutti mustunderstand suo käytännössä sovelluksille, jotka käyttävät vanhempaa spesifikaatiota, mahdollisuuden epäonnistua tyylikkäästi kun saavat viestin, jota ne eivät ymmärrä. -relay: määrittelee tuleeko SOAP-viestin vastaanottajan (SOAP-solmu) välittää ko. otsikon osan tieto eteenpäin mikäli se ei ole käsitellyt tätä otsikon osaa. Tiedon eteenpäin välittäminen tarkoittaa, että vastaava otsikon osa generoidaan eteenpäin välitettävään viestiin. Myös relay-attribuutti saa boolean-arvot true tai false. Mikäli relay-attribuutti puuttuu, on käyttäytyminen sama kuin jos sen arvoksi olisi annettu false. 31

36 Huom. SOAP version 1.1 attribuutti actor on käytännössä sama kuin SOAP 1.2 version attribuutti role. Lisäksi attribuuttia relay ei ole käytössä SOAP 1.1 versiossa. 31

37 SOAPin otsikon elementeissä käytettävä role-attribuutti, joka määrittelee minkä SOAP-solmujen tulee prosessoida ko. otsinkon osa, voi saada kolmenlaisia arvoja: -next: vastaanottavan viestin käsittelijän (SOAP-solmu) viestipolulla tulee prosessoida ko. otsikon osa -none: minkään viestin vastaanottavan SOAP-solmun ei tule käsitellä ko. otsikon osaa -ultimatereceiver: ainoastaan viestin varsinaisen vastaanottajan tulee käsitellä ko. otsikon osa. Tämä on myös oletusarvo/oletuskäyttäytyminen mikäli attribuuttia role ei ole annettu. Esimerkki (SOAP version 1.2 Part 0: Primer): <?xml version='1.0'?> <env:envelope xmlns:env=" <env:header> <m:reservation xmlns:m=" env:role=" env:mustunderstand="true"> <m:reference>uuid:093a2da1-q r-ba5d-pqff98fe8j7d</m:reference> <m:dateandtime> t13:20: :00</m:dateandtime> </m:reservation> <n:passenger xmlns:n=" env:role=" <n:name>åke Jógvan Øyvind</n:name> env:mustunderstand="true"> 32

38 </n:passenger> </env:header> <env:body>... </env:body> </env:envelope> 32

39 33

40 SOAP-viestin runko-osa sisältää sovellusspesifistä dataa. Siihen merkataan esimerkiksi pyyntö-vaste kommunikoinnin pyyntöosat ja vastaavasti vastausosat. Samoin virheilmoituksen välitetään runko-osassa. Runko-osa on aina pakollinen SOAP-viestissä. Virheet voidaan merkata SOAP-viestiin spesifikaation määrittelemällä tavalla käyttäen Fault-elementtiä. Fault-elementti sisältää (tai voi sisältää) seuraavat alielementit: -Code: Tämä pakollinen elementti sisältää virhekoodin. Se sisältää puolestaan pakollisen Value-elementin ja optionaalisen Subcode-elementin. SOAP spesifikaatio määrittelee sisällön elementille Value. Spesifikaatio määrittelee pienen joukon virhekoodeja korkean tason SOAP-virheille. Nämä virhekoodit esitellään seuraavaksi. -Reason: Tämä pakollinen elementti sisältää virheen kuvauksen. -Node: Tämän optionaalisen elementin avulla voidaan identifioida se SOAP-solmu, joka aiheutti virheen. Tämä solmu yksilöidään URI:n avulla -Role: Tämä optionaalinen elementti identifioi viestiä operoivan SOAP-solmun roolin virheen tapahtuessa. -Detail: Tätä optionaalista elementtiä voidaan käyttää kuljettamaan sovellusspesifistä virhedataa. Tällä elementillä voi olla attribuutteja ja alielementtejä. Esimerkki onnistuneesta pyyntö-vaste -kommunikoinnista: SOAP pyyntö (request): <env:envelope xmlns:env=" > <env:body> <m:getprice env:encodingstyle=" xmlns:m=" <symbol>dis</symbol> </m:getprice> </env:body> </env:envelope> 34

41 SOAP vastaus (response): <env:envelope xmlns:env=" <env:body> <m:getpriceresponse env:encodingstyle= xmlns:m=" <Price>34.5</Price> </m:getpriceresponse> </env:body> </env:envelope> 34

42 35

43 Esimerkki (W3C, SOAP 1.1, Part 1): virhekoodi (Code-elementti) kertoo, että kyse on versio-ongelmasta. Otsikon Upgradelohko indikoi, että SOAP-solmu tukee sekä SOAP versiota 1.2 että versiota 1.1 mutta preferoi versiota 1.2. <?xml version="1.0"?> <env:envelope xmlns:env= xmlns:xml=" <env:header> <env:upgrade> <env:supportedenvelope qname="ns1:envelope Mismatch</env:Text> xmlns:ns1=" xmlns:ns2=" </env:header> <env:body> </env:body> </env:upgrade> <env:fault> </env:fault> <env:supportedenvelope qname="ns2:envelope" <env:code> </env:code> <env:reason> </env:reason> <env:value>env:versionmismatch</env:value> <env:text xml:lang="en">version 36

44 </env:envelope> 36

45 37

46 HTTP kommunikoi käyttäen TCP/IP-protokollaa. Asiakas identifioi palvelimen URI:n avulla, ottaa siihen yhteyden sekä lähettää HTTP kutsun (esimerkki: W3Schools, POST /item HTTP/1.1 Host: Content-Type: text/plain Content-Length: 200 Palvelin prosessoi kutsun ja lähettää vastauksen saman TCP-yhteyden aikana: 200 OK Content-Type: text/plain Content-Length: 200 SOAP voidaan sitoa useampaan protokollaan, mutta yleisin käytännössä on HTTP. SOAP spesifikaatio määrittelee HTTP-sidonnan. Siinä SOAP pyyntö-vaste kommunikointi perustuu HTTP POST metodin käyttöön, kun taas yksinkertainen SOAP vaste (pyyntö tapahtuu muuten kuin SOAPia käyttäen) on sidottu HTTP GET metodin käyttöön. 38

47 39

48 SOAP 1.2 spesifikaation osa 2 (Part 0) antaa ohjeistusta sille, milloin eri viestinvälitysmalleja (MEPs) kannattaa käyttää. Ne ovat luonnollisesti vain suosituksia, vaikkakin suositus on annettu melko vahvaan sävyyn. SOAP Respond viestinvälitysmallia tulisi käyttää silloin, kun kommunikoinnin kohdetta ei ole tarkoitus muuttaa interaktion toimesta. Se on tiedon hakemista varten. HTTP spesifikaatio kuvaa tällaisia yhteyksiä turvallisiksi. SOAP Request-Respond viestinvälitysmallia tulee käyttää silloin, kun on tarvetta informaatiolähteen manipuloimiseen. Kannattaa huomata, että HTTP POST sidonta käy siis kaikissa tapauksissa. 40

49 Esimerkki 1. HTTP GET (SOAP 1.2, Part 0: Primer) a) Pyyntö ei ole SOAP-muotoinen. Sen header-osa voi näyttää esimerkiksi alla esitetyn kaltaiselta. Accept-kentän application/soap+xml indikoi kutsuttavan resurssin suositeltavan esitystavan. Esimerkiksi selaimen ollessa kyseessä se voisi olla text/html. GET /travelcompany.example.org/reservations?code=ft35zbq HTTP/1.1 Host: travelcompany.example.org Accept: text/html;q=0.5, application/soap+xml... b) Edellä esitetyn pyynnön vastaus SOAP-viestinä voi näyttää seuraavalta: HTTP/ OK Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version='1.0'?> <env:envelope xmlns:env=" <env:header> <m:reservation xmlns:m=" Esimerkki 2. HTTP POST a) pyyntö: Tässä HTTP Content-Type kentän arvon tulee aina olla application/soap+xml. Sen optionaalinen charsetparametrivoi saada joko arvon utf-8 tai utf-16. Itse kutsuttavan resurssin URI muodostuu POST ja Host kenttien arvoista. Näin ollen alla olevassa esimerkissä URI on travelcompany.example.org/reservations POST /Reservations HTTP/1.1 Host: travelcompany.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version='1.0'?> <env:envelope xmlns:env=" > <env:header>... 41

50 b) vastaus HTTP/ OK Content-Type: application/soap+xml; charset="utf-8 Content-Length: nnnn <?xml version='1.0'?> <env:envelope xmlns:env=" > <env:header> 41

51 42

52 43

53 HTTP vastauskoodeista voidaan päätellä onnistuiko asiakkaan lähettämän viestin vastaanottaminen, ymmärtäminen ja onko se hyväksytty (2xx -alkuiset arvot) ja toisaalta mikä oli mahdollisen virheen syy. Esimerkiksi palvelinpään prosessointiongelmasta johtuva virhe voitaisiin ilmoittaa seuraavalla tavalla: HTTP/ Internal Server Error Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version='1.0'?> <env:envelope xmlns:env=" <env:body> <env:fault> <env:code>... 44

54 SOAP Listener ottaa vastaan SOAP-paketteina saapuvia viestejä ja välittää ne edelleen itse palvelulle käännettyään ne ko. palvelun natiivikielelle (esim. Java). Asiakassovelluksen (client application) tarvitsee ainoastaan tietää palvelun osoite sekä palvelun ymmärtämän/ymmärtämien viestin/viestien muoto/muodot. Kun palvelu on prosessoinut viestin ja muodostanut mahdollisen vastauksen, se tulee niin ikään muuttaa SOAP viestiksi ja välittää asiakkaalle. Web-palveluissa palvelun käyttäjä (Requestor) kutsuu (bind operaatio) valittua palvelua (Provider) lähettämällä SOAP-viestin. Yksinkertainen proxy jäsentää palvelun kuvauksen, joka annetaan WSDL-muodossa; WSDL kuvaus kertoo miten kyseistä palvelua kutsutaan. WSDL-kuvauksia onkin verrattu IDLkuvauksiin: WSDL on Web-palveluille sitä mitä IDL:t ovat CORBAlle. Koska WSDL on ohjelmallisesti luettavaa ja se sisältää tarvittavat tiedot, voidaan siitä itse asiassa generoida asiakaspään (client) stub koodia, joka toimii proxynä. WSDL-kuvausta voidaan hyödyntää myös palvelinpäässä: siitä voidaan myös generoida koodia, jonka palvelinsovelluksen toteuttaja voi sopivasti laajentaa. WSDL-kieleen perehdymme seuraavaksi. 45

55 Kun kyse on kommunikoinnista Internetiä hyödyntäen, nousee joissain tapauksissa (erityisesti liiketoiminnan kannalta kriittisissä sovelluksissa) tietoturva oleelliseksi. Tähän liittyviä asioita ovat autentikointi, tiedon salaus, digitaaliset allekirjoitukset jne. SOAP itsessään ei tarjoa tukea näiden toteuttamiseksi. On kuitenkin esitetty ehdotuksia esimerkiksi siitä, miten digitaaliset allekirjoitukset voitaisiin liittää SOAP-viesteihin. SOAPin laajennettavuus (header) mahdollistaa tämän. Web-palveluissa tämä voidaan hoitaa eri kerroksessa (kts. Layers of Web Services) eri tavoin. SOAP-viesteissä voidaan digitaalisten allekirjoitusten lisäksi antaa esimerkiksi WS-Security specifikaation ( mukaisia lisäyksiä autentikoinnin, koskemattomuuden ja luottamuksellisuuden varmistamiseksi. Lisäksi SOAPin pohjalta on kehitetty ebxml Message Service, jota käytetään ebxml-konseptissa. Tämän ja turvalliseen viestinvälitykseen palataan myöhemmin. Web-palveluiden kannalta eri laatuattribuutit (vasteajat, hinta ja muut liiketoiminnan kannalta oleelliset vaatimukset), kuten luotettavuus, ovat myös tärkeitä. SOAP ei itsessään tue myöskään näiden merkkausta. Yksi oleellinen asia Web-palveluiden kannalta on myös transaktioiden hallinta: sekvenssi yksittäisten palvelujen suorittamista operaatiosta halutaan koostaa yhdeksi liiketoimintatransaktioksi. Transaktioiden hallinta on niin ikään avoin kysymys SOAPin kannalta. Tämä kysymys onkin jätetty seuraavan kerroksen eli palveluiden koordinoinnista huolehtivan kerroksen ratkaistavaksi. Toisaalta tukea 46

56 transaktioille voidaan tarjota myös SOAP-laajennosten kautta (WS-Transactions). Sen lisäksi SOAPin laajennettavuus mahdollistaa myös tuen mm. turvalliselle viestinvälitykselle (WS-Security), reititykselle (WS-Routing) ja monimutkaisemmalle viestinvälitykselle (WS-Coordination). 46