service-oriented architecture and web services · esimerkiksi integraatioarkkitehtuurista ja soasta...

41

Service-oriented architectureand Web services

42

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.

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.

43

Needs for software integration

• Business point of view– constantly changing requirements– efficient utilization of information systems, e.g., cost-

effectiviness→security in information exchange

– etc.

• Software engineering point of view– contantly changing requirements– reuse aspect– needs for information exchange– efficiency– flexiblity– etc.

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.

44

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 goalis to achieve loose coupling among interactive software agents. A service is a unit of work done by a service provider to achievedesired end results for a service consumer.

– uses integration techniques• service coordination (possibly dynamically) from other services

Seuraavaksi tutustumme lyhyesti kolmeen eri termiin: interaktioarkkitehtuuri, palveluorientoitunut

arkkitehtuuri ja Web-palvelu. 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.

45

... and Web services

• One way to implement SOA– WSDL, SOAP– REST-like services– ebXML

• In practice – and in research – these terms get mixedevery now and then– people talk about integration architectures and service-

oriented architectures as they were the same thing– people talk about service-oriented architectures and Web

services as they were the same thing

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 (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.

46

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 run-

time

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.

47


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 develop ways to manageerror 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

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.

48


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 communication… …dynamically

• Agile management of requirements– ability to react on changing and new requirements (”a meta requirement”)

• Statelessness– If a service needs to retail its state for a longer period of time, its availability

to other clients may be impeded– Managing state information can also hinder scalability

• Service composability– it should be possible to coordinate and assemble services to form composite

services

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.

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

49

Service-Oriented Architecture (SOA)

Broker

Requestor Provider

Find

Bind

Describe,Publish

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.

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

50

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 registeredoperation (with bind operation)

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).

51

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 withBroker

– hierarchy of services

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.

52

Broker

• Registers service descriptions submitted byProviders (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

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.

53

Selectively and briefly on recent history of software engineering…

• 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 configurationchallenges

Components and program distribution

• a “natural” way to think of and manage program concepts (classes, objects) and their relationships…and thus the program structures

OO paradigm

• an abstraction level for programmersThe developmentof programminglanguages

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?

54

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 theirmanagement

– decentralized applications

• SOA can be considered ”a step to the next abstraction level”– components -> services

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).

55

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 fromsoftware engineering and business points of views

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.

56

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 clientapplications– varying features– support for Web service languages and recommendations, and

their different versions varies

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 Web-palveluihin

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 tarjoama tuki eri Web-

palvelukielille, niiden eri versiolle ja eri suosituksille vaihtelee.

57

Defining Web services

• W3C puts it: ”programmatic interfaces made available for application to applicationcommunication are referred to as Web services”

• ...or more precisely:”A Web service is a collectionof functions packaged as a single entity and published to the network for use by otherapplications”-> a hierarcy of Web services: more complicatedones are aggregated from simpler ones

• or perhaps:“XML applications mapped to programs, objects, databases, or business functions”

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: Web-

palveluhierarkian. Toisin sanoen 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.

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ä.

58

A vision of Web services

• Software will be assembledfrom a web of services

• Building applications just-in-time

• Discovering and coordinating services on the Web dynamically

• From distributed systems to de-centralized applications

PDA

PC Mobile phone

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.

59

Layers of Web services

Transport(HTTP, SMTP, FTP, JMS, IIOP, etc.)

SOAP and its extensions (for realibility, transactions etc.), WSDL, UDDI

Util

ityse

rvic

es

(sec

urit

y, tr

ansa

ctio

ns, Q

oS, e

tc.)

Collaboration services(orchestration, choreographies)

Application services

Kalvolla esitetyn kuvan alimpana kerroksena ovat viestinvälitysprotokollat. Vaikka Web-palveluita

usein sanotaan käyttävän HTTP:tä – ja näin käytännössä hyvin usein onkin – itse Web-

palvelukonseptia 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

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.

60

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!

• And many, many more…

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ä.

61

Web services - a silver bullet orreinventing 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 anypublished service (as long as the service description and security requirements are followed)

– From distributed applications to de-centralized applications

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

62

Formats and APIs• Web Service Description Language (WSDL)

– a format for describing a Web service interface, data, message types, interactions patterns, and protocol mappings

• Simple Object Access Protocol (SOAP)– a message format for invoking a Web service

– binds the WSDL description

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

63

Simple Object Access Protocol(SOAP)

64

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 is SOAP 1.2 (1st edition published 2003, 2nd edition published 2007), 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

SOAPin uusin versio 1.2 on vuodelta 2003. Sitä 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 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 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.

65

SOAP concepts• An envelope defines a framework for a SOAP message

– both application-specific and application-independent informationcan be included in the envelope

– contains a required Body and an optional Header

• Header (optional) includes application-independentinformation– 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

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.

66

SOAP envelope (mandatory)

Header (optional)

Body (mandatory)

Header Entry

Header Entry

.......

Body Entry

Body Entry

.......

SOAP message structure:

<env:Envelopexmlns:env=“http://www.w3.org/2003/05/soap-envelope”>

<env:Header>

</env:Header><env:Body>



<env:Body><env:Envelope>

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.

67

SOAP envelope

• A namespace identifying the SOAP version usedis given in Envelope element– SOAP 1.2: http://www.w3.org/2003/05/soap-

envelope– SOAP 1.1:

http://schemas.xmlsoap.org/soap/envelope• e.g.

<env:Envelopexmlns:env="http://www.w3.org/2003/05/soap-envelope">

Envelope-elementillä on nimiavuuruusmääre, joka spesifioi käytettävän SOAP version. Esimerkiksi

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

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.

68

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 bemarked as env:encodingStyle=”http://www.w3.org/2003/05/soap-encoding”

• using this encoding scheme is optional, also other encodingschemes 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 1.1

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="http://www.w3.org/2003/05/soap-envelope" >

<env:Header>….</env:Header>

<env:Body>

<m:chargeReservation env:encodingStyle="http://www.w3.org/2003/05/soap-encoding“

xmlns:m="http://travelcompany.example.org/">

<m:reservation xmlns:m="http://travelcompany.example.org/reservation">

...

</env:Body>

</env:Envelope>

Tässä esimerkissä encodingStyle attribuutin arvo http://www.w3.org/2003/05/soap-encoding 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. encodingStyle-attribuuttia 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ä.

69

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

InitialSender

FinalDestination

Intermediary 1:http://xmlkurssi.fi/i1

Intermediary 2:http://xmlkurssi.fi/i2

SOAP message path

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).

70

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

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.

71

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 firstimmediate child of the envelope

• Header entries (elements) may have the followingattributes: 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 beprocessed

• required: mustUnderstand=”true”– relay: indicates whether a SOAP header entry targeted at a SOAP

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

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.

72

SOAP roles• http://www.w3.org/2003/05/soap-envelope/role/next

– targets a header entry at whichever processor receives it– all SOAP processing nodes must support the special role

"next", which makes it possible to target a header block at the next processor in a message path.

– each SOAP node MUST act on this role• http://www.w3.org/2003/05/soap-envelope/role/none

– SOAP nodes MUST NOT act on this role• http://www.w3.org/2003/05/soap-

envelope/role/ultimateReceiver– the ultimate receiver MUST act on this role– indicates that a header block is targeted at the ultimate

SOAP receiver in a message path

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:Header>

<m:reservation xmlns:m="http://travelcompany.example.org/reservation“

env:role="http://www.w3.org/2003/05/soap-envelope/role/next"

env:mustUnderstand="true">

<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>

<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>

</m:reservation>

<n:passenger xmlns:n="http://mycompany.example.com/employees“

env:role="http://www.w3.org/2003/05/soap-envelope/role/next"

env:mustUnderstand="true">

<n:name>Åke Jógvan Øyvind</n:name>

</n:passenger>

</env:Header>

<env:Body>

...

</env:Body>

</env:Envelope>

73

SOAP body• Contains application-specific data, e.g., requests and

responses

• SOAP Fault– Used to carry error information, Fault element contains

• mandatory Code element: A local name of the code, includes fault codes

– subelements Value ja Subcode

• mandatory Reason element: A human readable explanation of the fault

• optional Node element: Intended to provide information about which SOAP node on the SOAP message path caused the fault to happen

• optional Role element: Identifies the role the node was operating in at the point the fault occurred

• optional Detail element: Intended for carrying application specific error information related to the SOAP Body

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:Body>

<m:GetPrice

env:encodingStyle="http://www.w3.org/2003/05/soap-encoding”

xmlns:m="http://example.org/2001/06/quotes">

<symbol>DIS</symbol>

</m:GetPrice>

</env:Body>

</env:Envelope>

SOAP vastaus (response):

<env:Envelope xmlns:env=" http://www.w3.org/2003/05/soap-envelope">

<env:Body>

<m:GetPriceResponse env:encodingStyle=”http://www.w3.org/2001/09/soap-encoding”

xmlns:m="http://example.org/2001/06/quotes">

<Price>34.5</Price>

</m:GetPriceResponse>

</env:Body>

</env:Envelope>

74

Fault codes (Value subelement of Code element):

A header/body block targeted at the current SOAP node is scoped with a data encoding that the current node does not support

DataEncodingUnknown

The message could not be processed, e.g., a problem with the server

Server

The message was incorrectly formed or containedincorrect information

Client

An element with mustUnderstand=”1” was notunderstood

MustUnderstand

An invalid namespace found for the SOAP envelope element

VersionMismatch

DescriptionFault codes

Esimerkki (W3C, SOAP 1.1, Part 1): virhekoodi (Code-elementti) kertoo, että kyse on versio-

ongelmasta. Otsikon Upgrade-lohko 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=”http://www.w3.org/2003/05/soap-envelope”

xmlns:xml="http://www.w3.org/XML/1998/namespace">

<env:Header>

<env:Upgrade>

<env:SupportedEnvelope qname="ns1:Envelope“

xmlns:ns1="http://www.w3.org/2003/05/soap-envelope"/>

<env:SupportedEnvelope qname="ns2:Envelope"

xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/>

</env:Upgrade>

</env:Header>

<env:Body>

<env:Fault>

<env:Code>

<env:Value>env:VersionMismatch</env:Value>

</env:Code>

<env:Reason>

<env:Text xml:lang="en">Version Mismatch</env:Text>

</env:Reason>

</env:Fault>

</env:Body>

</env:Envelope>

75

SOAP HTTP binding• Message exchange patterns (MEPs): patterns that describe

distributed communication– e.g. Request-Respond and Respond

• HTTP request-respond MEP: the client identifies the server via a URI, connects to it using the underlying TCP/IP network, issues a HTTP request message (e.g., usingPOST) and receives a HTTP response message over the same TCP connection

• HTTP bindings with SOAP– allows the exchange of SOAP messages either as payload of a

HTTP POST request and response, or as a SOAP message in the response to a HTTP GET.

• HTTP binding with the SOAP Respond MEP (i.e., non-SOAP message acting as a request followed by a SOAP message acting as a response ) is restricted to the HTTP GET method

• HTTP binding with the SOAP Request-Response MEP is restricted to the HTTP POST method

HTTP kommunikoi käyttäen TCP/IP-protokollaa. Asiakas identifioi palvelimen URI:n avaulla, ottaa

siihen yhteyden sekä lähettää HTTP kutsun (esimerkki: W3Schools,

http://www.w3schools.com/soap/soap_httpbinding.asp):

POST /item HTTP/1.1

Host: 189.123.345.239

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.

76

Which MEP to use

• SOAP 1.2 Part 2 provides quidance when to userequest-respond and when respond MEPs

• SOAP respond, use when– an application is assured that the message

exchange is for the purposes of information retrieval (safe!)

– information resource is "untouched" as a result of the interaction

• SOAP request-respond, use when– information resource is manipulated– using HTTP POST

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.

77

Using HTTP GET and HTTP POST for SOAP MEPs

• Using HTTP GET– HTTP Accept header is used to indicate the

preferred representation of the resource being requested, e.g. “application/soap+xml”

• Using HTTP POST– HTTP Content-type header must be

"application/soap+xml“• charset parameter can take either value “utf-8” or “utf-16”

– the combination of HTTP POST and Host headers represents URI of the resource

Esimerkki 1. HTTP GET (SOAP 1.2, Part 0: Primer)

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/1.1 200 OK

Content-Type: application/soap+xml; charset="utf-8"

Content-Length: nnnn



<env:Header>

<m:reservation xmlns:m="http://travelcompany.example.org/reservation"

...

Esimerkki 2. HTTP POST

pyyntö: Tässä HTTP Content-Type kentän arvon tulee aina olla ”application/soap+xml”. Sen

optionaalinen charset-parametri voi 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





<env:Header>

...

b) vastaus

HTTP/1.1 200 OK

Content-Type: application/soap+xml; charset="utf-8“




<env:Header>

…

78

HTTP respond codes• 2xx (successful)• 3xx (redirection)• 4xx (client error)• 5xx (server error)• Example status codes of errors

– 401: the request requires HTTP authentication– 404: the requested resource is not available– 405: the peer HTTP server does not support the requested HTTP

method at the given request URI – 500: an error inside the HTTP server which prevented it form

fulfilling the request– 503: the HTTP server is temporarily overoaded, and unable to

handle the request

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/1.1 500 Internal Server Error




<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body>

<env:Fault>

<env:Code>

....

79

SOAP architecture

SOAP package, request

SOAP package, response

Proxy SOAP Listener

HTTP server

XML parserXML parser

Clientapplication

nativecall

Applicationobject

so called ”SOAP engine”

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

IDL-kuvauksiin: 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.

80

Some challenges• Security

– some solutions usable with SOAP exist• agreements on using them are needed between parties

– transport level security: SOAP over HTTP/S– SOAP message level security

• WS-Security

• QoS policies– reliability

• Distributed transactions– no support for combining invocations to a distributed transactions

• Complex message exchanges• ...many of the above mentioned inadequacies are the ”cost of

simplicity”. However, most of them are under development at W3C and OASIS.

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

(http://www-106.ibm.com/developerworks/webservices/library/ws-secure/) 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 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).

service-oriented architecture and web services · esimerkiksi integraatioarkkitehtuurista ja soasta...

Documents