Palvelukuvaukset ja niiden käyttö palvelujen toteutuksessa Seminaarityö 16.11.2006 Tom Bertell
Sisältö 1 Johdanto... 1 2 Palvelun rajapinnan kuvaus... 1 2.1 WSDL 1.1... 2 2.2 WSDL käytännössä...5 3 Palvelun ominaisuuksien ja tarpeiden kuvaus... 6 3.1 WS-Policy...7 3.2 WS-Policy käytännössä... 9 4 Yhteenveto... 10 Lähteet...11
1 1 Johdanto Palveluperustainen arkkitehtuuri (Service Oriented Architecture, SOA) tarjoaa pohjan nykyaikaisten liiketoimintaprosessien toteuttavien järjestelmien suunnittelulle ja toteutukselle. Palveluperustainen järjestelmä koostuu joukosta toistensa kanssa kommunikoivia palveluita, joista jokainen toteuttaa jonkin liiketoiminnallisen kokonaisuuden [CeN04]. Palveluperustaisessa järjestelmässä palvelujen täytyy pystyä toimimaan toistensa kanssa saumattomasti riippumatta palvelujen varsinaisesta sijainnista, kommunikointiin käytettävästä liikennöintiprotokollasta tai palvelujen toteutusteknologiasta. Verkkopalvelut (Web Services) pyrkivät toteuttamaan kaikki palveluperustaisen arkkitehtuurin päävaatimukset ja ovat tästä syystä tärkeässä roolissa palvelupohjaisten järjestelmien toteuttamisessa. Palveluilla on monia toiminnallisia ja ei-toiminnallisia ominaisuuksia, jotka palvelun kutsujan täytyy tuntea ennen palvelun käyttämistä. Palvelun toiminnallisia ominaisuuksia ovat mm. palvelun sijainti, sanomien rakenne ja liikennöintiprotokolla. Palvelun ei-toiminnallisia ominaisuuksia voivat olla esimerkiksi palvelun laatuun ja tietoturvaan liittyvät ominaisuudet. Näitä palvelun käyttämisen kannalta oleellisia ominaisuuksia on pitkään kuvattu epästandardien dokumenttien avulla [Jon05]. Vasta viime aikojen nopea verkkopalveluiden käytön yleistyminen ja sen seurauksena kehitetyt uudet standardit ja määritykset ovat mahdollistaneet palvelujen ominaisuuksien kuvaamisen formaalilla ja standardin mukaisella tavalla. Formaalien ja standardien palvelukuvausten käyttö mahdollistaa työkalujen ja automatisoinnin hyödyntämisen palvelujen suunnittelussa ja toteutuksessa. 2 Palvelun rajapinnan kuvaus Jotta palvelun käyttäjä pystyisi kutsumaan palvelua, tarvitaan tietoa palvelun sanomien rakenteesta ja palvelun sijainnista. WSDL (Web Service Definition Language) [Chr01] on muodostunut standardiksi tavaksi määritellä näitä ominaisuuksia. WSDL on XML-
pohjainen kuvauskieli, joka on suunnittelulta helposti laajennettavaksi, eikä sitä ole sidottu yhteen tyyppijärjestelmään tai liikennöintiprotokollaan. 2 2.1 WSDL 1.1 WSDL keskittyy kuvaamaan mitä palvelu tekee rakenteellisella tasolla, eli minkälaisia sanomia palvelu vastaanottaa ja lähettää. WSDL ei kuvaa mitä palvelu sanomilla tekee, eikä sitä miten palvelua tulisi käyttää. WSDL määritysten ensimmäinen versio syntyi vuonna 2000, kun IBM ja Microsoft yhdistivät omat palvelunkuvauskielensä [Wee06]. NSSL (Network Application Service Specification Language) oli IBM:n kehittämä kuvauskieli, jonka rakenne oli samantapainen kuin nykyisen WSDL-kielen, mutta siinä oli tuki vain etäproseduurikutsun tyyliselle interaktiolle. SDL (Service Description Language) oli Microsoftin palvelunkuvauskieli, joka perustui sanomapohjaiseen interaktioon. Näiden kuvauskielien yhdistämisestä syntyi WSDL 1.0, jonka tarkoituksena oli tukea palvelukutsuja sekä etäproseduurikutsun tyylisinä, että sanomapohjaisina. WSDL 1.0 versiosta vuoden päästä julkaistiin hieman päivitetty versio 1.1, joka on sittemmin levinnyt laajaan käyttöön ja saanut myös lähes kaikkien suurten toimittajien tuen. Tämän luvun kuvaus perustuu WSDL määritysten 1.1-versioon. WSDL määritykset haluttiin pitää mahdollisimman yksinkertaisina, joten ne kuvaavat vain palvelun kutsumisen kannalta olennaiset ominaisuudet: sanomien rakenteen, sanomanvälitysmallin, kuljetusprotokollan ja palvelun sijainnin. WSDL-kuvaukseen voidaan kuitenkin liittää muita kuvauksia laajennusten avulla. WSDL-kuvaus jakaantuu abstraktiin osaan, jossa kuvataan mitä palvelu tekee ja konkreettisen osaan, jolla sidotaan abstrakti osa käytettävään liikennöintiprotokollaan ja sanomaformaattiin. WSDL-kuvauksen juurielementti on definitions-elementti. Sen alla oleva hierarkia koostuu seuraavista elementeistä: Tyypit (Types) ovat sanomissa käytettävien tietorakenteiden kuvauksia. Sanoma (Message) kuvaa yksittäisen sanoman (pyyntö- tai vastaussanoma) rakenteen. Porttityyppi (Porttype) kuvaa palvelun rajapinnan tarjottavien operaatioiden ja sanomien osalta.
3 Sidos (Binding) määrittelee mitä protokollia (SOAP, HTTP GET/POST, MIME) voidaan käyttää palvelun kutsumisessa. Portti (Port) määrittelee sidoksen päätepisteen osoitteen. Palvelu (Service) on hierarkian ylin taso ja se kokoaa yhden tai useamman toisiinsa liittyvän portin. Palvelukuvauksen abstraktin osan määrittelevät types-, message-, porttype- ja operationelementit ja konkreettisen osan binding-, port- ja service-elementit. Sanomissa käytettävät tietotyypit kuvataan types-elementtien avulla. XML-muotoisten tietotyyppien kuvaamiseen suositellaan käytettäväksi XML Schema-kieltä, mutta muutkin kuvauskielet kuten RelaxNG ja DTD ovat sallittuja. Muun kuin XML-muotoisen tiedon kuvaamiseen voidaan käyttää MIME-tyyppejä, OMG:n IDL-tyyppikieltä tai COBOL:in copybook-formaattia [2]. Esimerkissä 1 on kuvattu XML Schema-kielellä koosteinen tietotyyppi Auto, joka koostuu kahdesta elementistä merkki ja malli, jotka ovat yksinkertaista tietotyyppiä merkkijono. <types> <xsd:schema xmlns="http://www.w3.org/1999/xmlschema/> <xsd:complextype name="auto"> <xsd:element name="merkki" type="xsd:string" /> <xsd:element name="malli" type="xsd:string" /> </xsd:complextype> </xsd:schema> </types> Esimerkki 1: Types-elementti. Message-elementti kuvaa sanoman rakenteen ja se koostuu yhdestä tai useammasta osasta (part). Sanoman name-attribuutti identifioi sanoman WSDL-dokumentin sisällä. Message-elementti ei ota kantaa siihen, onko sanoma palvelun pyyntö- vai vastaussanoma. Type-attribuutti voi olla joko suoraan XML Scheman yksinkertainen tietotyyppi tai se voi viitata johonkin aiemmin määriteltyyn koosteiseen tietotyyppiin, kuten esimerkissä 2 viitataan esimerkin 1 tietotyyppiin Auto.
4 <message name="automalliout"> <part name="auto" type="tns:auto"> </message> Esimerkki 2: Message-elementti. WSDL-kuvauksen porttype-elementillä määritellään mitä toimintoja palvelu pystyy tarjoamaan. Porttityyppi koostuu joukosta operaatioita, jotka vastaavat sovelluksen metodeja. Operaatiot määrittelevät sisääntulevien ja ulosmenevien sanomien yhdistelmän. Sanomien järjestys määrittelee operaation sanomanvälitysmallin. Erilaisia sanomanvälitysmalleja on neljä, joista vain kaksi ensimmäistä ovat täysin tuettuja [Wee06]: 1. Palvelu vastaanottaa sanoman, eikä palauta vastausta. 2. Tavallisimmin käytetty esimerkin 3 pyyntö-vastausmalli. 3. Palvelu lähettää sanoman ensin ja saa siihen vastauksen. 4. Viimeisenä huomautustyyppinen pelkkä palvelun lähettämä sanoma ilman vastausta. <porttype name="automalli_portti"> <operation name="haeautomalli"> <input message="automalliin"/> <output message="automalliout"/> </operation> </porttype> Esimerkki 3: PortType-elementti. Sidos yhdistää palvelun porttityypin ja sanomat johonkin konkreettiseen viestinvälitysmekanismiin. Binding-elementtillä on name- ja type-attribuutit. Name-attribuutti yksilöi sidoksen ja type-attribuutti viittaa johonkin palvelun porttityyppiin. Tällä hetkellä selvästi yleisimmin käytössä oleva sidonta on SOAP-sidos, joka on kuvattu esimerkissä 4. Muita WSDL 1.0 määrityksissä tuettuja sidoksia ovat HTTP- ja MIME-sidokset.
5 <binding name="automalli_sidos" type="automalli_portti"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="haeautomalli"> <soap:operation soapaction="urn:automallipalvelu"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> Esimerkki 4: Binding-elementti. Service-elementti yhdistää palveluun liittyvät portit ja kertoo mistä palvelun löytää. Osoite annetaan URI:n avulla. Service-elementin sisällä oleva port-elementti viittaa yhteen aiemmin määriteltyyn sidokseen. <service name="automallipalvelu"> <port binding="automalli_sidos" name="automalli_portti"> <soap:address location="http://esimerkki.com/esimsovellus"/> </port> </service> Esimerkki 5: Service-elementti. 2.2 WSDL käytännössä Koska WSDL-kuvaukset ovat formaaleja ja koneluettavia dokumentteja, voidaan niiden käsittelyssä hyödyntää työkaluja ja monia palvelun toteuttamisen kannalta työläitä ja monimutkaisia vaiheita voidaan automatisoida. WSDL-kuvauksista voidaan sopivilla työkaluilla generoida palvelun tarjoajan ja palvelun pyytäjän sovellusten runko. Sama voidaan tehdä myös toiseen suuntaan, jolloin esimerkiksi perinnejärjestelmälle (legacy system) generoidaan WSDL-kuvaus olemassa olevan toteutuksen pohjalta. WSDL-kuvaus antaa joustavuutensa ansiosta monia vaihtoehtoja palvelun rajapinnan toteuttamiseen. Erilaiset rajapintojen toteutukset johtavat helposti yhteentoimivuusongelmiin palvelun tarjoajan ja käyttäjän välillä. Helpottaakseen yhteentoimivuutta toimijoiden
6 välillä WS-I-organisaatio on määritellyt profiileja verkkopalvelu-standardeille. WS-I Basic Profile 1.0 määrittelee mm, että message-elementillä saa olla vain yksi part-elementti. WS-I organisaation suositusten seuraaminen takaa parhaimman yhteentoimivuuden. Koska WSDL-kuvauksen rakenne on jaettu abstraktiin teknologiariippumattomaan osaan ja konkreettisen toteutuksen kuvaavaan osaan, niin abstraktia osaa voidaan uudelleenkäyttää rajapinnan eri toteutuksissa. Tämä mahdollistaa palvelun tarjoamisen useiden eri liikennöintiprotokollien ja sanomien tietotyyppien avulla. Vaikka WSDL mahdollistaa tietotyyppien kuvaamisen muillakin kuvauskielillä kuin XML Schema, niin käytännössä siitä on kehittynyt standardi. Yritykset, jotka ovat käyttäneet muita tyyppijärjestelmiä ovat pääsääntöisesti konvertoineet järjestelmänsä XML-pohjaisiksi[Wee06]. 3 Palvelun ominaisuuksien ja tarpeiden kuvaus WSDL-kuvaus pitää sisällään kaiken tiedon mitä palvelun kutsumiseen tarvitaan, mutta palvelulla voi olla useita ei-toiminnallisia ominaisuuksia ja vaatimuksia, joita WSDL-kuvauksessa ei voida määritellä, eikä WSDL ole siihen tarkoitettukaan. WSDL-kuvaus keskittyy tiukasti palvelun toiminnallisten ominaisuuksien määrittelyyn. Palvelun ei-toiminnallisia ominaisuuksia voivat olla esimerkiksi tietoturvaominaisuudet, transaktiot, palvelun laatuun liittyvät ominaisuudet tai liiketoimintavaatimukset. Palvelun ei-toiminnalliset ominaisuudet on tähän asti neuvoteltu palvelun tarjoajan ja palvelun kutsujan välillä suullisesti tai epästandardien dokumenttien välityksellä. Jotta palvelujen yhteistoiminta helpottuisi, näitä palvelun käytön kannalta olennaisia ominaisuuksia olisi hyödyllistä pystyä kuvaamaan yhtenäisellä ja formaalilla tavalla. Palvelun ei-toiminnallisia ominaisuuksia kuvaamista varten on kehitetty WS-Policy-kehys [Ved06].
7 3.1 WS-Policy WS-Policy esiteltiin vuonna 2002 IBM:n, Microsoftin, SAP ja BEA Systems:in toimesta. WS-Policy-kehys koostuu WS-Policy- ja WS-PolicyAttachment-määrityksistä. WS-Policy-määrityksillä kuvataan palvelun ominaisuuksien ja vaatimusten yhdistelmät. WS- PolicyAttachment-määritykset kuvaavat miten määritykset yhdistetään tiettyyn kohteeseen. WS-Policy-määritysten perustana on politiikkaväittämä (policy assertion), jolla kuvataan jokin palvelun yksittäinen ominaisuus tai vaatimus. Politiikkaväittämät kootaan politiikkavaihtoehdoiksi. Politiikka ei ota kantaa siihen mikä sen kohteena on. Politiikkavaihtoehdot määritellään kahden loogisen operaattorin ExactlyOne ja All avulla. ExactlyOneoperaatio tarkoittaa nimensä mukaisesti, että vain yksi politiikkavaihtoehto voi olla voimassa samanaikaisesti. All-operaatiolla yhdistetään joukko politiikkaväittämiä. Esimerkissä 6 on kuvattu kaksi politiikkavaihtoehtoa, joista vain toinen saa olla voimassa samanaikaisesti. Politiikkavaihtoehto 1 sisältää kaksi väittämää, joista joko väittämän A tai väittämän B pitää olla voimassa. Politiikkavaihtoehdossa 2 pitää olla voimassa molemmat väittämät C ja D. <wsp:policy> <wsp:exactlyone> <wsp:all> <!-- politiikkavaihtoehto 1--> <wsp:exactlyone> <Väittämä A/> <Väittämä B/> </wsp:exactlyone> </wsp:all> <wsp:all> <!-- politiikkavaihtoehto 2--> <Väittämä C/> <Väittämä D/> </wsp:all> </wsp:exactlyone> </wsp:policy> Esimerkki 6: Policy-elementti.
8 Politiikkaväittämät kuvaavat jonkin sovellusalueen ominaisuuksia ja tarpeita. Politiikkaväittämiä on kerätty useiksi WS-alkuisiksi määrityksiksi, joista tärkeimmät on kuvattu sovellusalueittain taulukossa 1. Määritys WS-SecurityPolicy WS-ReliableMessaging WS-AtomicTransaction Sovellusalue Todennus ja sanomatason tietoturva Luotettava sanomanvälitys Transaktioiden käsittely WS-BusinessActivity Liiketoimintatransaktiot Taulukko 1: WS-määritykset sovellusalueittain Viittaus politiikkaan voidaan lisätä WSDL-kuvauksen palvelun (service), päätepisteiden (port, porttype, binding), operaatioiden (operation) tai sanomien (message) määrityksiin. Esimerkissä 7 politiikka on liitetty WSDL-kuvauksen binding-elementtiin alielementillä PolicyReference, joka määrittelee yksikäsitteisesti missä politiikan kuvaus sijaitsee. <wsdl:binding name="turvasidos" > <PolicyReference URI="http://www.esimerkki.fi/turvaPolicy /> <wsdl:operation name="operaatio" > </wsdl:operation> </wsdl:binding> Esimerkki 7: PolicyReference-elementti. WS-Policy-määrityksissä kuvataan myös kuinka palvelun tarjoajan ja pyytäjän politiikkojen mahdollista yhteensopivuutta voidaan tutkia politiikkojen leikkauksen avulla. Ennen politiikkojen leikkauksen tekemistä pitää politiikat muuttaa normaalimuotoon. Normaalimuodossa politiikka koostuu yhdestä ExactlyOne-operaattorista, jonka sisällä on yksi tai useampia All-operaattoreita. Mikä tahansa politiikka voidaan muuttaa normaalimuotoon. Esimerkissä 8 on muutettu esimerkin 6 politiikka normaalimuotoon. Kahden normaalimuodossa olevan politiikan leikkaus valitsee molempien osapuolten väittämistä mahdolliset yhteensopivuudet elementtien nimien perusteella. Vertailu tehdään vain elementtien nimien perusteella, koska WS-Policy-kehyksen tasolla ei ole tietoa siitä miten väittämien sisältöä pitäisi tulkita.
9 <wsp:policy> <wsp:exactlyone> <wsp:all> <Väittämä A/> </wsp:all> <wsp:all> <Väittämä B/> </wsp:all> <wsp:all> <Väittämä C/> <Väittämä D/> </wsp:all> </wsp:exactlyone> </wsp:policy> Esimerkki 8: Politiikka normaalimuodossa. 3.2 WS-Policy käytännössä Kun palvelun tarjoaja on kuvannut palvelun ominaisuudet ja vaatimukset WS-Policy-kehyksen avulla ja palvelun pyytäjä osaa tulkita niitä, niin WS-Policy-kehystä voidaan hyödyntää monella tavalla. WS-Policy-kehystä voidaan käyttää WSDL:n kanssa kuvaamaan palvelun vaatimuksia palvelun pyytäjältä. Palvelun tarjoaja voi esimerkiksi vaatia, että kaikki sanomat on salattava. Toinen hyödyllinen WS-Policy-kuvausten käyttötarkoitus on palvelun käyttäjän mahdollisuus etsiä sopivaa palvelua sen WS-Policy-kuvauksen kautta määrittelemien ei-toiminnallisten ominaisuuksien perusteella. Käyttäjä saattaisi vaatia palvelulta esimerkiksi, että palvelun vastausajan pitää olla alle 5 sekuntia. WS-Policy-kehyksellä kuvattujen ominaisuuksien ja vaatimusten hyödyntäminen tapahtuu automaattisesti ilman, että palvelun pyytäjän ja palvelun tarjoajan on tarvinnut neuvotella etukäteen kuinka ominaisuuksia voidaan käyttää. WS-Policy-kehys mahdollistaa palvelun tarjoajan ja pyytäjän välisen löyhän kytkennän, koska palvelujen ominaisuuksien ja vaatimusten sidonta voidaan tehdä ajonaikaisesti. WS-Policy ei ole vielä laajassa käytössä. Jonkinlaista työkalutukea on tarjolla kuten Microsoftin Web Services Enhancements (WSE) työkalusarjan versio 2.0 ja avoimeen lähdekoodin perustuva NetBeans-kehitysympäristö Sun:in Project Tango moduulin avulla, jotka tukevat WS-Policy-kehyksen käyttöä graafisen käyttöliittymän kautta.
10 4 Yhteenveto Käyttämällä standardien mukaisia palvelukuvauksia palvelujen rajapintojen ja ominaisuuksien kuvaamiseen, voidaan toteuttaa monet palveluperustaisuuden perusvaatimukset kuten teknologiariippumattomuus, yhteentoimivuus ja löyhä kytkentä. WSDL-kuvaus on tarkoitettu palvelun rajapintojen kuvaamiseen formaalilla ja standardilla tavalla. WS-Policy helpottaa palvelujen yhteentoimivuutta, koska se kuvaa useita tärkeitä ominaisuuksia, joita tarvitaan palveluiden saumattomaan interaktioon. Onnistuakseen palvelukuvaus-standardit tarvitsevat suurilta toimittajilta tukea työkaluille, jotka mahdollistavat standardien hyödyntämisen ohjelmistokehityksen kaikissa vaiheissa. WSDL ei ole vielä virallinen W3C:n suositus, mutta se on jo vakiinnuttanut asemansa palvelujen rajapintojen kuvaamisessa ja sillä on jo lähes kaikkien suurten toimijoiden tuki. Vaikka WS-Policy ottaa vasta ensi askeleitaan ja W3C on julkaissut siitä vasta ensimmäisen luonnoksen tänä vuonna, sillä on hyvät mahdollisuudet kehittyä tärkeäksi osaksi alati kasvavaa verkkopalvelustandardien joukkoa.
11 Lähteet CeN04 Cheesman J., Ntinolazos G., The SOA Reference Model. CBDI Journal, 2004. Chr01 Christensen E., Web Service Description Language (WSDL) 1.1, 2001. http://www.w3.org/tr/wsdl. Jon05 Jones S., Toward an Acceptable Definition of Service. IEEE Software, 2005 Ved06 Vedamuthu A., et al., Web Services Policy 1.5 Framework, 2006. http://www.w3.org/tr/ws-policy. Wee06 Weerawarana S., et al., Web Services Platform Architecture. Prentice Hall, 2006.