Service-oriented architecture and Web services

Transkriptio

1 Service-oriented architecture and Web services 81

2 Application integration Business-to-Consumer (B2C) client is a human user e.g., Application <-> Web browser interactions using HTTP/HTML Business-to-Business (B2B) client is another application interactions e.g., using HTTP/XML, SMTP/XML, etc. 82 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ä B2C-kommunikoinnista. 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.

3 Needs for software integration Business point of view constantly changing requirements efficient utilization of information systems, e.g., costeffectiviness security in information exchange etc. Software engineering point of view contantly changing requirements reuse aspect needs for information exchange efficiency flexiblity etc. 83 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.

4 Integration architectures, service-oriented architectures... Integration architecture defines and describes a way to integrate software systems components or parts of software information needed and used by software systems not necessarily a service point of view Service-oriented architecture an example of integration architecture Dr. Hao He, W3C Web Services Architecture Working Group: Service Oriented Architecture is an architectural style whose goal is to achieve loose coupling among interactive software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. uses integration techniques service coordination (possibly dynamically) from other services 84 Seuraavaksi tutustumme lyhyesti kolmeen eri termiin: interaktioarkkitehtuuri, palveluorientoitunut arkkitehtuuri ja Web-palvelu. Ensinnäkin interaktioarkkitehtuuri 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 interaktioarkkitehtuurista. 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-to-point 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.

5 ... and Web services One way to implement SOA WSDL, SOAP REST-likeservices ebxml In practice and in research these terms get mixed every now and then people talk about integration architectures and serviceoriented architectures as they were the same thing people talk about service-oriented architectures and Web services as they were the same thing 85 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 SOAP-protokollaa 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 (aiemmin käytettiin nimeä RESTfulpalvelut ) 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 Web-palveluiden 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.

6 SOA - requirements and principles from software engineering point of view As loose dependencies among services as possible aim at minimizing the dependencies, esp. the artificial ones only real dependencies the unity of information should be possible to be defined inside one service, not among several services independent services Late configuration and service binding services are possibly searched at run-time connections between services are formed dynamically at runtime 86 SOAan ja sen toteuttamiseen liittyy joukko vaatimuksia ja periaatteista, 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 palveluihin 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.

7 SOA - requirements and principles from software engineering point of view Aiming at long living services potentially increases the amount of users if the service is shown to be useful better possibilities for the users to develope ways to manage error situations, interoperability problems etc. Independence from implementation methods and techniques interfaces are important, not how the services have been implemented (c.f. distributed systems) High level of abstraction parties offer services at relatively high level of abstraction 87 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.

8 SOA - requirements and principles from software engineering point of view Autonomy services are independent and their management is decentralized in addition to establishing connections, the independent parties may also negotiate and make agreements on the forms of communition dynamically Agile management of requirements ability to react on changing and new requirements ( a meta requirement ) 88 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 Web-palvelut 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.

9 Service-Oriented Architecture (SOA) Broker Requestor Find Bind Describe, Publish Provider Dr. Hao He, W3C Web Services Architecture Working Group: Service Oriented Architecture is an architectural style whose goal is to achieve loose coupling among interactive software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. 89 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; Web-palvelut 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

10 Provider Provides services e.g., on-line hotel reservation Describes its service (in WSDL) based on the specification prepared by a service Broker describe operation Registers its service with Broker publish operation Requestor is be able to invoke a registered operation (with bind operation) 90 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).

11 Requestor Looks for services (more precisely: asks a Broker to look for services) and uses them May also create a new service by integrating services provided by Providers e.g., a travel agency using on-line hotel reservation and flight booking services Scenario: 1) invokes Broker to get services of interest (find operation) 2) selects a service/services and then invokes the corresponding Provider(s) (bind operation) Becomes a Provider if it registers itself with Broker hierarchy of services 91 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.

12 Broker Registers service descriptions submitted by Providers (e.g., using UDDI) publish operation Looks for services (i.e., executes a search) when asked find operation e.g., a travel search site for finding hotels according to given preferences Defines the service description format and an API for registering and searching services It is actually also a Provider 92 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.

13 Selectively and briefly on recent history of software engineering The development of programming languages OO paradigm Components and program distribution an abstraction level for programmers a natural way to think of and manage program concepts (classes, objects) and their relationships and thus the program structures a simple thing in principle but the component technologies themselves (RMI, (D)COM, CORBA, ) offer interesting features possibility to use components/subsystems as black boxes (the interface is essential) the programmers need to handle the interoperability problems and configuration challenges 93 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?

14 What s new in SOA then? A pure software architecture point of view In principle, SOA is not very interesting and it does not seem to offer that much new (c.f. component technologies) However, loose coupling can be implement in an interesting way using e.g. Web service technologies an agreement on Web service standars more or less: WSDL, SOAP, and possibly others (e.g. UDDI) not just for RPC document-style communication one goal is to distribute not only the services but also their management decentralized applications SOA can be considered a step to the next abstraction level components -> services 94 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 RPCtyyppiseen kommunikointiin. Lisäksi tavoitteena on paitsi ohjelmiston myös niiden hallinnan hajautus. SOA voidaankin kuitenkin katsoa tietynlaiseksi hypyksi seuraavalle abstraktiotasolle (komponentit- >palvelut).

15 What s new in then SOA? A broader point of view brings the software engineering and business points of views closer to each other! not that clear before (c.f. OO and component technologies) systems consist of service that have their own business processes business processes and their comprehension as well as understanding the requirements are essential in the development of services care and attention is needed when talking about the concepts and terms: e.g. service and architecture from software engineering and business points of views 95 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.

16 SOA and Web services Web services offer one way to implement SOA SOA and Web services aim at automatically solving problems related to interoperability, configuration etc. an agreement on the standards partly enables this challenges: a whole range of standards possible problems: nobody really knows the code, what if there is a need to understand the code. genericity/flexibility vs. automation A lot of tool support for building Web services and client applications varying features support for Web service languages and recommendations, and their different versions varies 96 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ä Web-palvelustandardeihin 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 Webpalveluihin liittyvistä teknologioista puhuttaessa: kyseessä saattaa olla lähinnä ehdotus eikä varsinaisesti standardi. 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 Web-palvelukielille, niiden eri versiolle ja eri suosituksille vaihtelee.

17 Defining Web services W3C puts it: programmatic interfaces made available for application to application communication are referred to as Web services...or more precisely: A Web service is a collection of functions packaged as a single entity and published to the network for use by other applications -> a hierarcy of Web services: more complicated ones are aggregated from simpler ones or perhaps: XML applications mapped to programs, objects, databases, or business functions 97 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). Webpalvelun on myös sanottu olevan sama asia kuin SOAP-protokollan käyttö (josta lisää myöhemmin). Nämä ovat kuitenkin liian laajoja, epämääräisiä ja vääriäkin määritelmiä. W3C määrittelee Webpalvelun (vapaasti käännettynä) joukkona ohjelmiin liittyviä rajapintoina, jotka ovat käytettävissä sovellusten välisessä kommunikoinnissa. 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. Määritelmästä myös seuraa Webpalveluille hyvin oleellinen piirre: Web-palveluhierarkian. Ts. yksinkertaisimmista palveluista voidaan koostaa monimutkaisempia palveluita. Toinen oleellinen asia tässä määritelmässä on palveluiden julkaiseminen. Jotta Web-palvelu 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.

18 A vision of Web services Software will be assembled from a web of services Building applications just-intime Discovering and coordinating services on the Web dynamically From distributed systems to de-centralized applications PC Mobile phone PDA 98 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.

19 Layers of Web services Application services Collaboration services (orchestration, choreographies) SOAP and its extensions (for realibility, transactions etc.), WSDL, UDDI Transport (HTTP, SMTP, FTP, JMS, IIOP, etc.) Utility services (security, transactions, QoS, etc.) 99 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.

20 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 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 SOAPlaajennoksiksi 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.

21 Usage examples of Web services Software migration and platform integration wrapping legacy systems to act like a Web service agreement on disagreement Agile business processes flexible integration business collaborations and agreements e.g., streamlining business operations, invoicing, shipping operations etc. Service registries and searching searching goods or services according to given requirements (e.g., best price) coordinating travel tickets or hotel reservations for a given date RPCs location transparency! 100 And many, many more Web-palvelut voivat käytännössä olla mitä tahansa. Paketoimalla vanha legacy-systeemi Webpalveluksi 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 Webpalveluihin. 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ä.

22 Web services - a silver bullet or reinventing the wheel? A silver bullet? No Web services provides rather a new layer, not a replacement for existing computing infrastructure Web services play an important role as a tool for bridging technology domains bridging is based on standard formats Reinventing the wheel? No Web services are not language nor platform dependent like DCOM, RMI etc. Web services are dynamic and disconnected; connections are transient and temporary Web service infrastructure assumes that parties can be connected without prior knowledge of each other, i.e., any client can bind to any published service (as long as the service description and security requirements are followed) From distributed applications to de-centralized applications 101 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 Webpalvelukonsepti mahdollisuuden silloittaa eri teknologioita. Esimerkiksi palvelu voi olla toteutettu.net ympäristössä kun taas sen asiakas voi J2EE-toteutus. Web-palvelu ei kuitenkaan ole myöskään pyörän uudelleen keksimistä. Web-palveluissa 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.

23 Formats and APIs Web Service Description Language (WSDL) a format for describing a Web service interface, data, message types, interactions patterns, and protocol mappings Universal Description, Discovery and Intergration (UDDI) a Web service registry and discovery mechanism service descriptions are published in a UDDI registry also other types of registries exist Simple Object Access Protocol (SOAP) a message format for invoking a Web service binds the WSDL description 102 Edellä esitetty Provider-Requestor-Broker -roolijako kuvaa erilaiset Web-palvelujen 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, niiden julkaisu ja viestinvälitys suoritetaan käyttäen seuraavia formaatteja (alunperin IBM:n ja Microsoftin ym. yhteisenä ehdotuksena): WSDL, UDDI ja SOAP. Näistä SOAP ja WSDL ovat vakiinnuttaneet asemansa, mutta UDDI:n rinnalle on tullut muitakin kandidaattiteknologioita (kuten ebxml registry) pääosin UDDI:n tietynlaisen rajoittuneisuuden vuoksi. WSDL-kieltä käytetään palveluiden kuvaamiseen, kommunikointi hoidetaan SOAPin avulla ja UDDI tarjoaa rekisteripalvelun. WSDL, SOAP ja UDDI 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.

24 Simple Object Access Protocol (SOAP) 103

25 SOAP As XML-RPC, used for representing cross-platform method invocations in XML Supports multiple transport protocols: HTTP (most commonly used), SMTP etc. The object in the acronym is a bit misleading object references are missing from SOAP Looses clearly to binary RPC in performance generating and parsing XML-based data takes time Current W3C recommendation (2003) is SOAP 1.2, although version 1.1. is also still used Extensibility features can be added as layered extensions e.g., proposals for extending SOAP to carry digital signature information have been made 104 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 HTTPyhteyden 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 erimerkiksi 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 XMLjä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.

26 SOAP concepts An envelope defines a framework for a SOAP message both application-specific and application-independent information can be included in the envelope contains a required Body and an optional Header Header (optional) includes application-independent information extension mechanism used e.g. for passing directives or contextual information related to the processing of the message Body (mandatory) includes application-specific information it contains the main end-to-end information e.g., request/invocation and the parameters needed 105 SOAPin pääosat ovat kirjekuori (envelope), otsikko (header) ja runko (body). Kirjekuori määrittelee kehyksen SOAP-viestille. Se sisältää otsikko- ja runko-osat. 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.

27 SOAP message structure: <env:envelope xmlns:env= /05/soap-envelope > <env:header> <!-- optional header blocks go here --> </env:header> <env:body> <!-- requests/responses --> <!-- or Fault elements go here --> <env:body> <env:envelope> SOAP envelope (mandatory) Header (optional) Header Entry Header Entry... Body (mandatory) Body Entry Body Entry 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.

28 SOAP envelope A namespace identifying the SOAP version used is given in Envelope element SOAP 1.2: SOAP 1.1: e.g. <env:envelope xmlns:env=" 107 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.

29 encodingstyle attribute encodingstyle attribute is used to define encoding rules used to serialize parts of a SOAP message, i.e., to prescribe how to encode application-specific data (esp. concerning RPCs) in XML SOAP 1.2 Part 2 section 3 defines example SOAP encoding rules. Usage of this encoding scheme can be marked as env:encodingstyle= using this encoding scheme is optional, also other encoding schemes can be used may appear in specific parts of the header or the body in SOAP 1.2 or anywhere (also in envelope element) in SOAP 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:body> </env:envelope> 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 SOAPviestiin. encodingstyle-attribuuttia voidaan käyttää SOAP 1.2 versiossa sekä otsikko- että runkoosissa, mutta SOAP 1.1 sallii sen käytön kaikkialla myös Envelope-elementissä.

30 SOAP intermediaries A SOAP message can travel through multiple intermediaries before arriving to the final destination (message path) Useful for placing additional processing components on intermediaries without modifying the applications on the sender and ultimate destination ends A SOAP node can be the initial SOAP sender, an ultimate SOAP receiver, or a SOAP intermediary Initial Sender SOAP message path Final Destination Intermediary 1: Intermediary 2: 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ö Webpalvelukonseptissa 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).

31 Intermediary types Message path SOAP does not specify how a message path is determined and followed message senders may or may not be aware of intermediaries in the message path Forwarding intermediaries process the message according to the SOAP processing model SOAP header blocks targeted at the SOAP intermediary MUST be removed from the SOAP message prior to forwarding Active intermediaries process the message according to the SOAP processing model may undertake processing not described by header blocks in the incoming message the potential set of services provided by an active intermediary includes, but is not limited to: logging, security, content modification and tracing 110 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.

32 SOAP Header Intended for adding features and functionalities security, process flow, routing, and other QoS attributes If occurs in the envelope, it must be the first immediate child of the envelope Header entries (elements) may have the following attributes: encodingstyle, role, mustunderstand, and relay role attribute: defines who must process the header entry (intermediary destination) mustunderstand attribute: defines whether the header entry is required or optional for the recipient (defined by role attribute) to be processed required: mustunderstand= true relay: indicates whether a SOAP header entry targeted at a SOAP 111 receiver needs to be passed forward if not processed 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 relayattribuutti saa boolean-arvot true tai false. Mikäli relay-attribuutti puuttuu, on käyttäytyminen sama kuin jos sen arvoksi olisi annettu false. 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.