web service description language (wsdl) - tut

121

Web Service DescriptionLanguage (WSDL)

122

Web Service DescriptionLanguage (WSDL)

• XML-based ”Web IDL” (cf. CORBA IDLs)• Allows e.g. SOAP binding• Contains descriptions of three main parts, each of them

can also be given as a separate document (and latercombined to form a complete WSDL description)– the data, typically using XML schemas– operations to be performed on the data

• for the message receiver to know how to process the message– binding to a protocol or transport

• for the message sender to know how to send the message• For more info, see: W3C “Web services” activity group

– WSDL version 2.0: W3C Recommendation (June 2007)

WSDL-kieli ja erityisesti sen versio 2.0 on hyväksytty kesäkuussa 2007 W3C:n viralliseksi

suositukseksi. Yleisesti käytössä oleva versio on edelleen WSDL 1.1., jota esimerkiksi Web-

palvelujen yhteentoimivuuskysymyksiin keskittyvä WS-I organisaatio käyttää profiilimäärityksissään

(Basic Profile v. 1.0, v. 1.1 ja myös v. 1.2). Profiilimääritys käytännössä antaa ohjeistusta siitä, miten

”Web-palvelustandardeja” tulisi käyttää, jotta yhteensopivuus olisi mahdollisimman todennäköistä.

WS-I organisaation suosituksia seurataan huolella ja suurin osa suurimmista Web-palvelutyökalujen

toteuttajista huomioi ne työkalujensa uusimmissa versioissa.

Tällä kurssilla WSDL-kieli käydään läpi version 2.0 pohjalta, mutta koska myös versio 1.1. on

edelleen melko laajalti käytössä, käydään pääerot näiden versioiden välillä myös läpi.

WSDL-kielen on sanottu olevan Web-palveluille sama kuin IDL on CORBAlle. XML-pohjainen

WSDL on käytetyin tapa etsiä ja paikallistaa Web-palveluita. Se onkin näin ollen avain sovellusten

väliseen kommunikointiin Web-palvelukonseptissa. WSDL-kuvaukset ovat riippumattomia

viestinvälitysmekanismista, mutta SOAP-sidonta on yleisimmin käytetty.

Yksi hyvä tapa tutustua WSDL-kieleen ja oppia sitä on käydä läpi esimerkkejä.

123

Main parts of a WSDL 2.0 document

• The root element of a WSDL 2.0 document is description.

• The four main parts of a WSDL 2.0 document arestructured under the following subelements of description:– types: describes the kinds of messages that the service

will send and receive– interface: describes what abstract functionality the Web

service provides– binding: describes how to access the service– service: describes where to access the service

WSDL 2.0 dokumentti koostuu neljästä pääosasta:

types: kuvaa millaisia viestejä palvelu lähettää ja vastaanottaa

interface: kuvaa minkä abstraktin toiminnallisuuden Web-palvelu tarjoaa

binding: kuvaa miten palveluun voidaan ottaa yhteyttä

service: kuvaa missä palvelu sijaitsee

Nämä neljä osiota kuvataan omina alirakenteinaan juurielementin description alla. Verrattuna versioon

1.1, osa elementtien nimistä on muuttunut. Esimerkiksi juurielementti versiossa 1.1 oli nimeltään

definitions ja rajapinnan kuvaava elementti (interface) oli nimeltään portType. Myös muutamia muita

elementtien uudelleennimeämisiä on tehty. Nämä muutokset ovat olleet hyviä, sillä uudet nimet

kuvaavat niiden tarkoitusta paremmin.

124

XML Infoset for a WSDL 2.0 document (WSDL 2.0 Part 0: Primer)

Kalvolla esitetty WSDL 2.0 dokumentin informaatiosisältö. Kuva on W3C:n dokumentista WSDL 2.0

Part0: Primer. Tämä informaatiomalli kuvaa WSDL 2.0 dokumentin vaadittua rakennetta. WSDL 2.0

–kieli sisältää myös useita semanttisia rajoitteita rakennetta koskevien vaatimusten lisäksi. Näiden

rajoitteiden kuvaamiseksi ja toisaalta WSDL 2.0 dokumentin merkityksen määräämiseksi WSDL 2.0

spesifikaatio määrittelee myös nk. komponenttimallin (component model). Kyseinen komponenttimalli

vastaa informaatiomallia ja onkin esitetty abstraktina erillisenä kerroksen ko. informaatiomallille.

125

Importing and including• A WSDL definition can consist of multiple XML documents• Importing and including mechanisms can be used to combine the

different parts into one WSDL definition• WSDL 2.0

– import: importing WSDL definitions with a different namespace• required namespace attribute that specifies the other

namespace• optional location attribute that gives the processor a hint where

to find the description of the other namespace– include: importing WSDL definitions with the same namespace

• WSDL 1.1– import: allows importing WSDL definitions from separate files, the

namespaces can be different or the same

WSDL-määritykset voivat olla hyvinkin pitkiä. Usein onkin tarkoituksenmukaista jakaa tällainen

määritys useampaan erilliseen osaan (ja erillisiin tiedostoihin). Esimerkiksi tyyppimääritykset, jotka

annetaan types-osiossa, voidaan määritellä erillisessä tiedostossa, joka voidaan sitten sisällyttää

useampaankin WSDL-kuvaukseen. Tämä mekanismi tukee näin ollen myös uudelleenkäyttöä.

WSDL:n versiot 2.0 ja 1.1 poikkeavat hieman myös tämän WSDL-dokumentin osion linkittämisen

suhteen. WSDL 1.1 käyttää elementtiä import, jonka avulla päädokumenttiin voidaan sisällyttää

WSDL-määrityksiä muista tiedostoista, riippumatta siitä kuuluvatko niiden elementit samaan tai eri

nimiavaruuteen. WSDL 2.0 puolestaan käyttää elementtejä import ja include, joista edellistä käytetään

sisällyttämään eri nimiavaruuteen kuuluvat määritykset ja jälkimmäistä taas samaan nimiavaruuteen

kuuluvat määritykset.

Esimerkki (WSDL 2.0 Primer). Seuraava tiedosta credit-card-faults.wsdl määritellään rajapinta

creditCardFaults, joka sisältää neljä virhekoodia: cancelledCreditCard, expiredCreditCard,

invalidCreditCardNumber ja invalidExpirationDate. Nämä komponentit kuuluvat nimiavaruuteen

http://finance.example.com/CreditCards/wsdl.

<?xml version="1.0" encoding="utf-8" ?>

<description xmlns="http://www.w3.org/ns/wsdl”

targetNamespace="http://finance.example.com/CreditCards/wsdl"

xmlns:tns="http://finance.example.com/CreditCards/wsdl"

xmlns:cc="http://finance.example.com/CreditCards/xsd">

<documentation>

This document describes standard faults for use by Web services that process credit cards.

</documentation>

<types>

<xs:import xmlns:xs="http://www.w3.org/2001/XMLSchema"

namespace="http://finance.example.com/CreditCardFaults/xsd"

schemaLocation="credit-card-faults.xsd" />

</types>

<interface name="creditCardFaults">

<fault name="cancelledCreditCard" element="cc:CancelledCreditCard">

<documentation>Thrown when the credit card has been cancelled.</documentation>

</fault>

<fault name="expiredCreditCard" element="cc:ExpiredCreditCard">

<documentation>Thrown when the credit card has expired.</documentation>

</fault>

<fault name="invalidCreditCardNumber" element="cc:InvalidCreditCardNumber">

<documentation>Thrown when the credit card number is invalid….</documentation>

</fault>

<fault name="invalidExpirationDate" element="cc:InvalidExpirationDate">

<documentation>Thrown when the expiration date is invalid.</documentation>

</fault>

</interface>

</description>

2) Edellä määriteltyjä virhekoodeja käytetään GreatH-hotellinvarauspalvelussa, joka on määritelty

alla. Rajapinta reservation perii laajentamalla creditCardFaults-rajapinnan toisesta nimiavaruudesta,

jotta virhekoodit olisivat käytettävissä reservation-rajapinnassa. Lopuksi makeReservation-operaatio

viittaa virhe-elementtiin outfaults.

<?xml version="1.0"?>

<description targetNamespace="http://greath.example.com/2004/wsdl/resSvc"

xmlns:ghns="http://greath.example.com/2004/schemas/resSvc"

xmlns:cc="http://finance.example.com/CreditCards/wsdl"

xmlns="http://www.w3.org/ns/wsdl"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

<documentation>

Description: The definition of the reservation Web service of GreatH hotel.

Author: Joe Somebody Date: 05/17/2004

</documentation>

<import namespace="http://finance.example.com/CreditCards/wsdl"

location="credit-card-faults.wsdl"/>

. . .

<interface name="reservation" extends="cc:creditCardFaults">

. . .

<operation name="makeReservation" pattern="http://www.w3.org/ns/wsdl/in-out">

<input messageLabel="In" element="ghns:makeReservation" />

<output messageLabel="Out" element="ghns:makeReservationResponse" />

<outfault ref="invalidDataFault" messageLabel="Out" />

<outfault ref="cc:cancelledCreditCard" messageLabel="Out" />

<outfault ref="cc:expiredCreditCard" messageLabel="Out" />

<outfault ref="cc:invalidCreditCardNumber" messageLabel="Out" />

<outfault ref="cc:invalidExpirationDate" messageLabel="Out" />

</operation>

</interface>

</description>

126

WSDL elements• description element

– root element of a WSDL document– merely acts as a container for the rest of the WSDL 2.0

document– used to declare namespaces that will be used throughout

the document• Data types (types section)

– defines the actual type definitions used in the WSDL document

– Types are typically given using XML Schema, but alsoother schema definition languages can be used, e.gRELAX NG and Schematron

– extensible and replaceable

Elementti types määrittelee käytettävät tietotyypit. Kuten edellä todettiin, tämä osio voidaan antaa

myös omana dokumenttinaan. Koska tyyppimääritykset annetaan omana osionaan, voidaan se helposti

korvata vaihtoehtoisella tyyppimäärittelyllä. Seuraavassa esimerkissä (WSDL2.0 Primer) määriteltävät

checkAvailability, checkAvailabilityResponse ja invalidDataError ovat viesteissä käytettävät tyypit.

127

WSDL elements (cont’d)• interface

– defines the abstract interface of a Web service as a set of abstract operations• each operation

– represents a simple interaction between the client and the service– specifies the types of messages that the service can send or receive as part of that operation– specifies a message exchange pattern (MEP) that indicates the sequence in which the associated

messages are to be transmitted between the parties.• In-bound MEPs, for which the service receives the first message in the exchange

– In-Only– Robust In-Only– In-Out– In-Optional-Out

• Out-bound MEPs, for which the service sends out the first message in the exchange– Out-Only– Robust Out-Only– Out-In– Out-Optinal-In

– contains• A required name attribute, which must be unique within the interface. • A required pattern attribute whose value must be an absolute URI that identifies the desired MEP

for the operation. • An optional style attribute whose value is a list of absolute URIs

– (RPC style, IRI style, Multipart style)

Elementti interface määrittelee abstraktin rajapinnan Web-palvelulle joukkona operaatioita, jotka on

puolestaan annettu operation-elementtien avulla. Elementti operation kuvaa puolestaan yksinkertaisen

interaktion asiakkaan ja palvelun välillä. Se määrittelee myös palvelun lähettämien ja vastaanottamien

viestien tyypit. Lisäksi se assosioi käytetyt viestimallit (message exchange patterns) yhteen tai

useampaan viestiin. WSDL 2.0 tukee seuraavia viestimalleja (message patterns):

• MEPit, jotka alkavat palvelun vastaanottamasta viestistä

o In-Only: koostuu täsmälleen yhdestä viestistä, jonka palvelu vastaanottaa. Virheviestiä ei

generoida.

o Robust In-Only: koostuu täsmälleen yhdestä viestistä, jonka palvelu vastaanottaa. Virheviesti

voidaan generoida ja se tulee lähettää viestin lähettäjälle.

o In-Out: koostuu täsmälleen kahdesta viestistä: vastaanotetusta ja lähetetystä viestistä. Vaste

(lähetetty vastaus) voidaan korvata generoidulla virheviestillä.

o In-Optional-Out: koostuu yhdestä tai kahdesta viestistä määrätyssä järjestyksessä:

vastaanotettu pyyntö ja sen jälkeen optionaalinen lähetetty vaste. Kumpi tahansa MEPin viesti

voi generoida virheen. Virheviestin suunnan tulee olla vastakkainen ko. viestille.

• MEPit, jotka alkavat lähetetystä viestistä

o Out-Only: koostuu täsmälleen yhdestä palvelun lähettämästä viestistä. Virheviestiä ei

generoida.

o Robust Out-Only: koostuu täsmälleen yhdestä palvelun lähettämästä viestistä. Virheviesti

voidaan generoida ja se lähetetään interaktion aloittajalle.

o Out-In: koostuu täsmälleen kahdesta viestistä: pyyntö ja vaste. Nämä viestit tulee olla tässä

järjestyksessä. Vaste voidaan korvata generoidulla virheviestillä.

o Out-Optional-In: koostuu yhdestä tai kahdesta viestistä: lähetetty pyyntö ja optionaalinen

vaste. Kumpi tahansa MEPin viesti voi generoida virheen. Virheviestin suunnan tulee olla

vastakkainen ko. viestille.

Esimerkki (WSDL 2.0 Primer):



targetNamespace= "http://greath.example.com/2004/wsdl/resSvc”

xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc”

xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc”

xmlns:wsdlx="http://www.w3.org/ns/wsdl-extensions">

. . .

<types> ... </types>

<interface name = "reservationInterface" >

<fault name = "invalidDataFault" element = "ghns:invalidDataError"/>

<operation name="opCheckAvailability" pattern="http://www.w3.org/ns/wsdl/in-out”

style="http://www.w3.org/ns/wsdl/style/iri" wsdlx:safe = "true">

<input messageLabel="In" element="ghns:checkAvailability" />

<output messageLabel="Out" element="ghns:checkAvailabilityResponse" />

<outfault ref="tns:invalidDataFault" messageLabel="Out"/>

</operation>

</interface>

. . .

</description>

Elementillä operation on pakollinen name-attribuutti, jonka avulla ko. operaatio identifioidaan. Name-

attribuutin arvon tulee olla yksikäsitteinen kyseisen rajapinnan (interface) sisällä. Lisäksi operation-

elementillä on pakollinen pattern-attribuutti, jolla identifioidaan käytetty viestinvälitysmalli.

Optinaalisella style-attribuutilla määritetään interaktion tyyli. Sen arvo voi olla

“http://www.w3.org/ns/wsdl/rpc”, “http://www.w3.org/ns/wsdl/style/iri” tai

“http://www.w3.org/ns/wsdl/style/multipart”. Esimerkiksi näistä ensimmäinen asettaa tiettyjä

rajoituksia RPC-tyyppiselle kommunikaatioille. Tarkempaa tietoa näistä vaihtoehdoista löytyy

dokumentista WSDL 2.0 Part 0: Primer.

WSDL 1.1 määrittelee eri viestinvälitysmallit kuin versio 2.0. Myös niiden merkkaustapaa on

muutettu. WSDL 2.0:ssa interface-elementin (portType versiossa 1.1) alielementillä operation on

kaksi pakollista (ja yksi optionaalinen) attribuuttia: attribuutti name, joka yksikäsitteisesti identifioi

interface-elementin sekä attribuutti pattern, joka URI:n avulla identifioi käytetyn MEPin. Versiossa

2.0 elementillä operation voi olla input- ja output-alielementtejä kuten versiossa 1.1. Versiossa 1.1

MEP sen sijaan identifioituu käytettyjen input ja output –alielementtien lukumäärästä ja järjestyksestä.

Tämä ratkaisu osoittautui varsin kömpelöksi ja virhealttiiksi useissa tapauksissa, joten tehty muutos on

selkeä parannus.

128

WSDL elements (cont’d)• binding element

– specifies how the messages can be exchanged, i.e. how to bind interface to a particular transport (e.g., SOAP)

– Must supply details on concrete message formats and transmission protocols for every operation and fault in the interface.

– Attributes• name (required): defines (uniquely among all bindings in the WSDL 2.0 target

namespace) a name for this binding. • interface (optional): the name of the interface whose message format and

transmission protocols are specified• type (required): specifies what kind of concrete message format to use• protocol: WSDL 2.0 SOAP binding extension specific attiribute that specifies the

underlying transmission protocol that should be used– Subelements

• operation (optional)– references the previously defined operation in order to specify binding details for it– mep attribute: specifies the SOAP message exchange pattern (MEP) that will be used to

implement the abstract WSDL 2.0 message exchange pattern (specified in operationelement)

• fault (optional)– Can be used to reference a fault that was previously defined in an interface element, in

order to specify binding details for it.

WSDL-dokumentissa on operaatioiden kuvausten lisäksi määritelty niiden sitominen

viestinvälitysmekanismeihin. Tämä määritellään binding-elementin avulla. WSDL 2.0 sisältää SOAP-

laajennoksen, jossa kuvataan miten tämä sitominen tulee tehdä käytettäessä SOAPia

kommunikointitapana. WSDL ei itsessään oleta SOAPin käyttöä. Muitakin viestinvälitysmekanismeja

voidaan toki käyttää. Koska SOAP on kuitenkin ehkäpä se yleisin tapa ja koska se on erityisesti

standardi tapa Web-palvelukonseptissa, on WSDL-spesifikaatioon tehty tämä laajennos.

binding-elementillä on kolme attribuuttia. Pakollisella name-attribuutilla nimetään annettu sidonta

(binding). Nimen tulee olla yksikäsitteinen kyseisessä WSDL-kuvauksen kohdenimiavaruudessa.

Tähän nimeen viitataan myöhemmin endpoint-elementistä. Optionaalisella attribuutilla interface

puolestaan määritellän rajapinta (interface), jonka viestiformaatti ja kuljetusprotokolla tässä binding-

elementissä tullaan määrittämään. Pakollisella attribuutilla type puolestaan määritetään mitä

konkreettista viestiformaattia käytetään. Esimerkiksi käytettäessä SOAPin versiota 1.2, type-

attribuutin arvoksi annetaan ” http://www.w3.org/ns/wsdl/soap”

Esimerkki (WSDL 2.0 Primer):



targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"


xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"

xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"

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

. . .

<types> . . . </types>

<interface name = "reservationInterface" >

<fault name = "invalidDataFault" element = "ghns:invalidDataError"/>

<operation name="opCheckAvailability"

pattern="http://www.w3.org/ns/wsdl/in-out"

style="http://www.w3.org/ns/wsdl/style/iri"

wsdlx:safe = "true">

<input messageLabel="In" element="ghns:checkAvailability" />

<output messageLabel="Out" element="ghns:checkAvailabilityResponse" />

<outfault ref="tns:invalidDataFault" messageLabel="Out"/>

</operation>

</interface>

<binding name="reservationSOAPBinding"

interface="tns:reservationInterface"

type="http://www.w3.org/ns/wsdl/soap”

wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">

<operation ref="tns:opCheckAvailability"

wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>

<fault ref="tns:invalidDataFault" wsoap:code="soap:Sender"/>

</binding>

. . .

</description>

Tässä esimerkissä kuvataan rajapinnalle reservationInterface (määritelty edellä) SOAP-sidonta

(binding-elementin type-attribuutin arvo ” http://www.w3.org/ns/wsdl/soap”). HTTP:tä käytetään

kuljetusprotokollana. Alielementti operation viittaa aiemmin määriteltyyn opCheckAvailability-

operaatioon, jolle tässä määritellään sidonnan yksityiskohtia. Tämä elementti ei ole pakollinen. Jos se

jätetään pois, käytetään oletussääntöjä (kts. ”SOAP binding extension in WSDL 2.0 Part 2”).

Attribuutti wsoap:mep määrittää mitä MEPiä käytetään toteuttamaan abstrakti WSDL 2.0:n MEP in-

out, joka oli puolestaan määritelty operaatiota opCheckAvailability määriteltäessä. Lisäksi attribuutti

wsoap:mep kontrolloin käytetäänkö GET vai POST –komentoa. Tässä tapauksessa

wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response aiheuttaa GETin käytön

oletusarvoisesti. GETin ja POSTin käyttöön palataan myöhemmin ja oheistusta niiden käytöstä

SOAP-sidonnassa käsitellään tarkemmin” WSDL 2.0 Part 0: Primer” –dokumentissa.

129

WSDL elements (cont’d)• Service (service section)

– contains a set of related endpoint elements that• specify how the interface bound to a particular protocol can be

accessed; a combination of a binding and a network address• define one or more transport bindings for a given interface• references a previously defined binding to indicate what

protocols and transmission formats are to be used at thatendpoint

• have attributes– name (required): gives a name, unique within this service, for this

endpoint, i.e., defines an endpoint for the service– binding (required): specifies the name of the previously defined

binding to be used by this endpoint– address (optional): specifies the physical address at which this

service can be accessed using the binding specified by the bindingattribute

Sidonta (binding) kuvaa miten viestit välitetään. Tämän jälkeen WSDL-kuvauksessa tulee vielä

määrittää missä palvelut sijaitsevat, jotta niihin voitaisiin ottaa yhteyttä. Tämä tehdään service-

elementin avulla. service-elementti sisältää endpoint-alielementtejä. Jokainen endpoint-elementti

määrittää osoitteen tietylle viestinvälitysmekanismiin sidotulle rajapinnalle (interface). Näitä endpoint-

elementtejä voi olla useita, koska palvelulle voidaan määrittää useita yhteydenottotapoja. Oletetaan

esimerkiksi, että ”checkAvailability” palvelun interface on toteutettu kahdella eri tavalla (kaksi eri

kuljetusprotokollaa): SOAP/HTTP ja SOAP/SMTP. Tällöin yksi service elementti voisi sisältää

kontaktipisteen (endpoint), joka kuvaa URL:n SOAP/HTTP:lle, sekä kontaktipisteen, joka kuvaa

sähköpostiosoitteen SOAP/SMTP:lle. Vastoin kuin WSDL:n versiossa 1.1, versiossa 2.0 service-

elementillä voi olla vain yksi rajapinta (interface), johon viitataan attribuutilla interface.

130

WSDL elements (cont’d)• Service (service section)…continued

– used, e.g., for• grouping those endpoints related to the same service interface that

are expressed by different protocols (bindings)

– a service is only permitted to have one interface• Referenced by attribute interface

– Attributes• name (required): defines (uniquely among all bindings in

the WSDL 2.0 target namespace) a name for this service• interface (required): specifies the name of the previously

defined interface that these service endpoints will support

Esimerkki (WSDL 2.0 Part 0: Primer)



targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"


xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"

xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"

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

. . .

<types> . . . </types>

<interface name = "reservationInterface" > . . . </interface>

<binding name="reservationSOAPBinding" interface="tns:reservationInterface" . . . >

. . .

</binding>

<service name="reservationService" interface="tns:reservationInterface">

<endpoint name="reservationEndpoint"

binding="tns:reservationSOAPBinding"

address ="http://greath.example.com/2004/reservation"/>

</service>

</description>

131

Service

Endpoint

Binding

Interface

Type

Service ImplementationDefinition

Service InterfaceDefinition

• Service Interface Definition encaptulates the reusablecomponents of a servicedescription

• If a party wants to implementa Web service compliant to a specific service interfacedefinition (say, Sinf), it needs to define a service implementationdefinition that describes howSinf was implemented (at the location hosted by that party)

WSDL-kuvaus voidaan ajatella kaksiosaiseksi: palvelun rajapinnan määritys (Service Interface

Definition) ja toteutuksen määritys (Service Implementation Definition). Palvelun rajapinnan määritys

on (tyypilliseen tapaan) uudelleenkäytettävä siinä mielessä, että sille voidaan antaa useita toteutuksia.

Palvelun rajapinnan määritys on Web-palvelun abstrakti kuvaus ja sitä käytetään kuvaamaan

tietyntyyppinen palvelu. Palvelun rajapinnan määritys koostuu elementeistä types, interface, ja

binding. Palvelun toteutuksen määrittely puolestaan kuvaa palvelun instanssit. Toisin sanoen, palvelun

toteutuksen määritys kertoo miten tietty rajapinta on toteutettu kyseisessä kohteessa.

Palvelun rajapinnan määrityksessä voidaan lisäksi käyttää elementtiä import, jonka avulla rajapinnan

määritys voidaan jakaa osiin: esimerkiksi tyyppimääritykset annetaan usein omana dokumenttinaan.

Tästä seuraa myös, että WSDL-kuvaus ei välttämättä ole yksi XML-dokumentti.

Erottelu palvelun rajapinnan määritykseen ja palvelun toteutuksen määritykseen on itse asiassa

oleellinen WSDL-kuvauksen registeröinnin (UDDI) kannalta. Tästä lisää myöhemmin.

132

Service registries

Universal Description, Discoveryand Integration (UDDI)

133

Universal Description, Discoveryand Integration (UDDI)

• A way to find and use Web services– publishing and searching

• Enhanced serching and discovery mechanisms– ”normal searching methods” become problematic, if the name of

the business is not known, if you want to compare severalsuppliers’ terms and conditions, if...

• Two main parts (and APIs): registration and discovery• Registration is for publishing, i.e., businesses can post

information to UDDI for other businesses to search and discover

• Interaction with the UDDI registry typically using SOAP APIs.

UDDI sai alkunsa Microsoftin, IBM:n ja Ariban yhteistyönä. Näin perustettiin UDDI.org ja mukaan

tuli pian myös muita, esimerkiksi SAP ja Hewlett-Packard. Sittemmin mukaan on tullut pitkä lista

yrityksiä. Työn motivoivana ajatuksena oli edistää Web-palvelustandardien käyttöönottoa.

UDDI tarjoaa ”markkinapaikan” Web-palveluille. Se tarjoaa API:n Web-palveluja etsimiseksi tietyin

kriteerein (discovery) sekä API:n palveluiden kuvausten tallettamiseksi (registration). Näiden APIen

käyttö tapahtuu tyypillisesti SOAPin avulla.

134

”Flavors” of UDDI registries

Trading Partner Network

ExtranetA registry deployed within a controlled environment, but with controlled access to the outside world and shared with trusted outside partners. Administrative features may be delegated to trusted parties. Data may be shared with other registries in a controlled way.

Shared/Semi-Private

Internal TestEnvironment

IntranetAn internal registry, behind a firewall, that is isolated from the public network. Access to both administrative features and registry data is secured. Data is not shared with other registries.

Private

Universal Business Registry (UBR)

Web SiteFrom an end-user’s perspective, a public registry appears to be a service in the cloud. Although administrative functions may be secured, access to the registry data itself is essentially open and public. Data may be shared or transferred among other registries.

Public

Exampleapplication

Web analogy

DescriptionRegistrytype

Kuvassa esitetty taulukko on UDDI.org:n (http://www.uddi.org/) dokumentista ”The Evolution of

UDDI” (white Paper). Taulukossa on kuvattu erilaisia UDDI-rekisterin käyttöskenaarioita. Julkiset

rekisterit ovat Internetissä käytössä olevia rekistereitä. Kuka tahansa voi etsiä niistä tietoa (julkisesti

saatavilla), mutta tietojen tallettamiseen ja muuttaminen edellyttää autentikointia.

Kätevä tapa tarkastella UDDI:a ja sen käyttöä tarkemmin on tutustua julkisiin UDDI-rekistereihin.

Lisäinfoa löytyy myös UDDI.org:n sivuilta: http://www.uddi.org

Toisaalta rekistereitä käytetään myös paikallisesti eri yrityksissä palomuurien sisäpuolella. Tällöin

tiedon suojaukseen (esimerkiksi kommunikointi rekisterin kanssa) ei tarvitse kiinnittää niin suurta

huomiota. Web-palvelukonseptia käytetään näin myös yleisemmin: koska viestinvälityksen

turvallisuus on yksi Web-palvelujen ”Akilleen kantapäistä”, ei niihin palomuurin suojassa tarvitse

kiinnittää niin suurta huomiota.

Kolmas tapa käyttää UDDI-rekisteriä on rajoittaa käyttö tiettyyn tunnettuun käyttäjäryhmään (trading

partner network). Tämä vaihtoehto on tavallaan kahden edellä mainitun vaihtoehdon välimuoto.

135

UDDI versions(from UDDI.org white paper ” The Evolution of UDDI”)

• Version 1.0, September 2000– key objective: create foundation for registry of

Internet-based business services• Version 2.0, June 2001

– key objective: Align specification with emerging web services architectures and provide more flexible taxonomy

• Version 3.0, July 2002– key objective: Support wide interaction of private

and public implementations

UDDI-rekisteristä julkaistiin ensimmäinen versio 1.0 vuonna 2000. Tässä versiossa määriteltiin ja

toteutettiin Internet-pohjaisen rekisteripalvelu perustoiminnallisuuksineen. Versiossa 2.0 ei tehty

suuria muutoksia version 1.0 ominaisuuksiin. Palvelun etsimiseen tarjottuun APIiin tehtiin vain pieniä

parannuksia ja tietomalliin tehtiin myös vain pieniä muutoksia. Versio 2.0 julkaistiin vuonna 2001.

Versiossa 3.0 keskityttiin rekisterien välisen interaktion tukemiseen esimerkiksi julkisten ja jaettujen

(tietty tunnettu käyttäjäryhmä) rekisterien välillä. Rekisterin perusominaisuuksiin ei tämän version

myötä tehty juurikaan muutoksia. Joitain hyödyllisiä ominaisuuksia on kuitenkin lisätty, esimerkiksi

tuki digitaalisille allekirjoituksille.

Tällä kurssilla tutustutaan UDDI-rekisteriin versioon 2.0. Perusominaisuudet ja tietomalli käydään läpi

yleisellä tasolla. Nämä tiedot eivät ole muuttuneet versiossa 3.0. Lisäinformaatiota versioiden välisistä

eroista löytyy esimerkiksi UDDI.org:n (http://www.uddi.org) raportista ”The Evolution of UDDI”

(UDDI.org White Paper)

136

General registry requirements• Data structure specifications for the metadata to be stored in the

registry• A set of CRUD (Create, Read, Update, Delete) operation

specifications for storing, deleting, and querying the data, in addition to

• Common registry requirements for metadata– ownership and containment: the Provider usually knows the service it

publishes, and all the subdata contained– categorization: mainly to facilitate searching and organization– a logical referencing mechanism: references are used as pointers to

other parts of the registry• Common registry requirements for the operations

– open access for read and query operations and– authentication for operations that change information (esp. public and

shared registries)

Rekistereillä - käytettiinpä niitä sitten ohjelmistokomponenttien, palveluiden tai jonkun muun

arkistointiin - on joitain yleisiä vaatimuksia. Ensinnäkin rekisterin tulisi määritellä ne tietorakenteet,

joita käytetään metatiedon tallettamiseen. Metatieto saattaa liittyä sisältöön, organisointiin ja

operaatioihin. Esimerkki metatiedosta on Web-palvelun tarjoaja (provider). Lisäksi rekisterin tulee

tarjota operaatioita, joiden avulla voidaan lisätä, etsiä, päivittää ja hävittää tietoa rekisteristä. Sekä

metatiedolle että operaatioille on olemassa myös yleisiä vaatimuksia. Rekisterin tulee sallia ja

määritellä tapa talletettavan tiedon (esim. Web-palvelu) omistus- ja sisältyvyyssuhteiden

määrittelemiseksi. Tästä on hyötyä myöhemmin palveluiden etsimisen kannalta. Koska esimerkiksi

palvelun tarjoaja tyypillisesti tietää julkaisemansa palvelut ja niiden käyttämän tiedon, on sen myös

mahdollista tämä tieto määritellä. Lisäksi rekisterin tulee tarjota tapoja luokitella talletettavaa tietoa

(palveluita). Rekistereissä käytetään tyypillisesti yleisesti hyväksyttyjä kategorisointimenetelmiä

esimerkiksi palvelun tyypin, sijainnin jne. perusteella. Luokittelu luonnollisesti helpottaa tiedon

etsimistä rekisteristä. Kolmas yleinen metatiedon tallettamista koskeva vaatimus on tarjota tapa tehdä

loogisia viittauksia eri talletettujen tietojen (palveluiden) välille. Tämä niin ikään helpottaa ja

monipuolistaa etsintää.

Yleiset vaatimuksen operaatioille koskevat lähinnä niiden käyttöoikeuksia. Tyypillisesti operaatiot,

jotka eivät muuta rekisterin tietoja (lukeminen, kyselyt), ovat vapaasti kaikkien käytettävissä

kyseisellä rekisterin näkyvyysalueella. Mikäli esimerkiksi kyseessä on julkinen rekisteri, ovat

operaatiot aidosti kaikkien käytettävissä. Jos taas kyseessä on ”yksityinen” rekisteri (esim. yrityksen

sisäisessä käytössä), on näkyvyysalue luonnollisesti määritelty. Operaatiot, joiden avulla voidaan

muokata tietoa (lisääminen, poistaminen ja muokkaus), vaativat autentikoinnin. Tämä koskee kaikkia

rekistereitä, mutta on erityisen olennainen julkisille ja jaetuille rekistereille.

137

Classification and Categorization

• For one of the main objectives: to discover services, statically (design time) or dynamically (run-time)

• In a well-populated registry, the amount of hits/matches can be large-> intelligent searches are needed-> taxonomic categorization and classsification– categorization: a process of creating categories– classification: a process of assigning object to the

categories

Englannin kielen termit ”categorization” ja ”classification” eivät ole synonyymejä. Termien ero on

hyvä ymmärtää. ”Categorization” tarkoittaa itse kategorioiden luomista kun taas ”classification”

tarkoittaa yksittäisen ilmentymän sijoittamista oikeaan kategoriaan. Näistä termeistä käytetään tällä

kurssilla suomennoksia ”kategorisointi” ja ”luokittelu”.

On olemassa eri tyyppisiä luokittelutapoja (classification schemes). Useimmat kirjastot esimerkiksi

käyttävät ”Library of Congress Classification” luokittelua. Kun hakuavaruus on suuri, ovat hierarkiset

luokittelutavat erityisen hyödyllisiä (vrt. XML!). Yahoo! on erittäin hyvä esimerkki hierarkisen

luokittelun tärkeydestä. Hakukoneen lisäksi Yahoo! tarjoaa monipuolisen luokittelutavan. Jos

esimerkiksi olet etsimässä jääkiekkovarusteiden valmistajia, niin sinun kannattaa seurata vaikkapa

seuraavaa Yahoo! :n kategoriapuuta:

Business_and_Economy/Shopping_and_Services/Sports/Hockey/Ice_Hockey/Gear_and_Equipment/

Manufactures

Luokittelun ja kategorisoinnin yksi päätavoitteesta on helpottaa ja tehostaa palveluiden (tässä

tapauksessa) etsimistä. Mikäli minkäänlaista luokittelua ei olla tehty, saattaa isosta tietomäärästä

löytyä useita kandidaatteja, joista vain osa on todella tarkoituksenmukaisia. Tämä johtuu siitä, ettei

luokittelemattoman tiedon etsimiseksi voida käyttää kovin tarkkoja hakukriteerejä. Joissain

tapauksissa saattaa haku myös olla tulokseton.

138

UDDI data structures• ”White pages”

– contact information on the service provider: name, address, phone numbers, fax numbers, Web sites, email,...

– text description– list of identifiers for identifying the business/service

• 9 digit DUNS (Data Universal Numbering System) identifier

• Thomas (Thomas Registry Suppliers IDs), Manufacturingbusinesses

• Others– ISO 3166 (Taxonomy for world geography)– UNSPSC (Taxonomy for products and services)

UDDI-rekisteriä verrataan usein puhelinluetteloon. Sen sanotaan usein sisältävän ”valkoiset sivut”,

”keltaiset sivut” ja ”vihreät sivut”. Seuraavaksi näiden tarkoitusta ja sisältöä kuvataan karkealla

tasolla.

Valkoisilla sivuilla (kuten puhelinluettelossakin) on tyypillisesti yhteystiedot, mm. palvelun tarjoajan

nimi, osoite ja yhteystiedot. Lisäksi valkoisilla sivuilla annetaan kuvaus palvelusta/tuotteesta ja lista

tunnisteita, joiden avulla ko. palvelu/tuote voidaan tunnistaa. Tunniste voi olla esimerkiksi DUNS tai

UNSPSC tunniste.

139

UDDI data structures• ”Yellow pages”

– classification information on the types and location of the services: industry type, business ID, geographical location,...

• three standard taxonomies in version 1– Industry: NAICS (Industry codes - US Govt.)– Product/Services: UN/SPSC (ECMA)– Location: Geographical taxonomy (ISO 3166)

• version 2 (March 2001) contains more taxonimies and version 3 (December 2001) contain custom taxonomies

– implemented as name-value pairs-> allows attaching any valid taxonomy identifier with a business white page

• ”Green pages”– details on how to invoke the service offered

• e.g., a pointer to the WSDL file of the business

Keltaisilla sivuilla palvelut on luokiteltu käyttäen yleisiä taksonomioita. Palvelu voidaan luokitella

esimerkiksi sen tyypin mukaan (vrt. puhelinluettelon keltaiset sivut, esim. ”autokorjaamoja”,

”urheiluliikkeitä”, ”kampaamoja” jne.) tai vaikkapa niiden sijainnin mukaan. UDDI versio 1 tarjoaa

kategorisoinnin kolmen standarditaksonomian mukaisesti:

• NAICS (North American Industry Classification System): yritysten/teollisuuden

luokittelemiseksi (esim. ”Service sector/Finance and Insurance” tai ”Manufacturing/Plastics

and Rubber Product Manufacturing”)

o http://www.census.gov/epcd/www/naics.html

• UN/SPSC (Universal Standard Products and Services Classification): tuotteiden

luokittelemiseksi (esim. ”Dry food for cats”)

o www.unspsc.org

• Geo (ISO 3166 standardi): luokittelu maantieteellisen sijainnin mukaan

o http://www.iso.org/iso/en/prods-services/iso3166ma/index.html

UDDI versiossa 2 on annettu lisää taksonomioita ja versiossa 3 on mahdollista määritellä niitä itse.

UDDI-rekisteri voi tarjota vaikkapa Web-rajapinnan tai Java API:n, joiden kautta niitä voidaan lisätä

(esim. WASP UDDI). UDDI-rekisterin vihreillä sivuilla annetaan yksityiskohtaista tietoa siitä, miten

palveluun voidaan ottaa yhteyttä. Yksinkertaisten Web-palvelujen tapauksessa tämä tarkoittaa

osoitinta WSDL-tiedostoon. Vihreillä sivuilla voidaan jossain määrin antaa tietoa myös

liiketoimintaprosesseista mikäli kyseessä on hieman monimutkaisempi tapa käyttää palvelua.

140

UDDI data model• businessEntity

– the top-level structure where most queries start– describes the business/entity for which information is

being registered• businessService

– the name and the description of the service to bepublished

– a named reference to a service• bindingTemplate

– information about the service: entry point address for accessing

– access point types: mailto, http, https, ftp, fax, phone, other

SOAPia käytetään paitsi palvelun tarjoajan ja asiakkaan väliseen kommunikointiin myös

kommunikointiin UDDI-rekisterin kanssa (haut, julkaiseminen). UDDI v. 2.0 API spesifikaatio

määrittelee n. 40 SOAP viestiä, joita voidaan käyttää ko. spesifikaation mukaisten UDDI-rekistereiden

erilaisten kysely- ja julkaisufunktioiden (näistä lisää myöhemmin) kutsumiseen. Spesifikaation

mukaiset UDDI-rekisterit tarjoavat kehyksen, jonka avulla julkaistavat palvelut kuvataan. Tämä

kuvaus annetaan XML-muodossa, jotta se olisi mahdollisimman hyvin hyödynnettävissä Web-

ympäristössä.

UDDI-rekisterin tieto kuvataan mallinna, joka koostuu viidestä rakennetyypistä: businessEntity,

businessService, bindingTemplate, tModel ja publisherAssertion. Tällä jaottelulla tähdätään rekisterin

tietojen sujuvaan ja nopeaan paikallistamiseen ja ymmärtämiseen. Nämä viisi XML-rakennetta

sisältävät edelleen alirakenteita. UDDI v. 2.0 API skeema määrittelee n. 25 pyyntömallia ja 15

vastausmallia, joista jokainen sisältää näitä rakenteita tai viittaa näihin rakenteisiin.

businessEntity-rakenteet ovat ylimmän tason rakenteita, josta kyselyt tyypillisesti alkavat.

businessEntity kuvaa palvelun tarjoajan. businessService puolestaan kuvaa julkaistavan palvelun.

bindingTemplate-rakenne sisältää tiettyyn palveluun tai palveluperheeseen liittyvää teknistä

informaatiota. Se tarjoaa sekä teknistä tietoa palvelun kontaktipinnasta että kevyen tavan kuvata

palvelun teknistä toteutusta.

141

UDDI data model (cont’d)• tModel

– a fingerprint or a collection of information thatuniquely identifies the service specification

– supports also top-level searches– a mechanism to exchange metadata about a

Web service, e.g., a pointer to a WSDL file• publisherAssertion

– a linking mechanism for businessEntitystructures

tModel-rakennetta käytetään palveluiden metatietojen välittämiseen. Metatietoa voi olla palvelun

tekstuaalinen kuvaus tai osoitin WSDL-dokumenttiin. UDDIa a ei ole suunniteltu ainoastaan WSDL-

kuvauksia varten vaan se pyrkii tarjoamaan tukea minkä tyyppisen Internetiä hyödyntävän palvelun

käyttämiseksi tahansa. Vaikka karkeasti usein ymmärretäänkin, että tModel on UDDI:n ekvivalentti

WSDL:lle, se on vain (käytännön) osatotuus: tModel voi esimerkiksi sisältää osoittimia ja viittauksia

palveluihin, jotka eivät tue SOAP:a ja käyttävät osoitteenaan muuta kuin URI:a. Toisaalta myöskään

WSDL:ää ei ole periaatteessa sidottu ainoastaan SOAPiin.

publisherAssertion-rakennetta käytetään eri businessEntity-rakenteiden linkittämiseen. Joissain

tapauksissa (esimerkiksi suuret yritykset tai kauppapaikat) palvelun tarjoajaa ei voida tehokkaasti

kuvata yhdellä businessEntity-rakenteella. publisherAssertion-mekanismi sallii useiden

businessEntity-rakenteiden linkittämisen, jolloin ko. palvelun tarjoajan eri osia voidaan kuvata

erikseen. Toisaalta näillä osilla on yhteyksiä toisiinsa, jotka ehkä halutaan tehdä näkyviksi ja

käytettäviksi myös UDDI-rekisterissä. publisherAssertion mahdollistaa tämän.

142

tModel structure• tModel attributes

– tModelKey• when the data is submitted (for the first time), the UDDI operator assigns a

unique identifier that cannot be modified, in the form of universally uniqueidentifiers (UUIDs), for the tModel.

– operator• the certified name of the Operator that owns the UDDI node to which the

tModel is registered• assigned by the UDDI Operator, cannot be modified

– authorizedName• the name provided by the Operator to the user registered the tModel• assigned by the UDDI Operator, cannot be modified

• tModel elements– name (required)

• tModel’s name– description (optional)

UDDI on tyypillisesti hajautettu useiden eri palvelinten kesken. Tietojen tallentamisen jälkeen ko.

tiedon muutokset tulee tehdä saman operaattorisolmun kautta (palvelun tarjoaja). Julkinen UDDI-

rekisteri toimii siis hieman samaan tapaan kuin DNS (Internet Domain Name System): UDDI on

useista solmuista koostuva järjestelmä, jonka tiedot synkronoidaan replikoinnilla.

tModel-rakenne sisältää kolme attribuuttia (tModelKey, operator ja authorizedName ) sekä viisi

alirakennetta, joista osa on pakollisia ja osa optionaalisia. tModelKey-attribuutti sisältää

operaattorisolmun generoiman tunnisteen (UUID) palvelulle. Tämän attribuutin arvoa ei voida

muuttaa. Attribuutti operator sisältää tiedon operaattorisolmusta eikä senkään arvoa voida muuttaa.

Attribuutin authorizedName arvo on puolestaan operaattorin antama nimi palvelun tarjoajalle.

Myöskään tätä arvoa ei voida muuttaa.

143

tModel structure (cont’d)• tModel elements

– overviewDoc (optional)• to provide overview descriptions of tModels and their intended use

– identifierBag (optional)• allows tModels to be identified according to published identifier

systems, for example, D-U-N-S numbers• an identifierBag is a list of one or more keyedReference structures,

each representing a single identification– categoryBag (optional)

• a mechanism for categorizing tModels within various taxonomies(provided by industry gorups or by UDDI)

• UDDI Operators initially support three taxonomies– for businesses to take advantage of the taxonomies, they need to provide

the relevant classification information as they register their entriesNote: various kinds of taxonomies could be used for identification or classification of all the data types in UDDI. The information about identification resides in a identifierBag structure, whereas the classification information resides in the categoryBag structure

tModel-rakenteessa name-osa on pakollinen. Vaikka kuvauksen nimi onkin pakollinen ei sen

tekstuaalista kuvausta description-elementillä ole pakko antaa. tModel-rakenteen optionaalinen

overviewDoc-elementti sisältää sanallisen kuvauksen tModel-rakenteesta ja sen tarkoitetusta käytöstä.

identifierBag-rakenne sisältää kokoelman käytössä olevista tunnisteista (esim. D-U-N-S numero) ja

categoryBag-rakenne sisältää kokoelman käytetyistä kategorisointitaksonomioista. Jotta palvelun

tarjoaja voisi aidosti hyötyä tarjotuista kategorisoinneista, tulee sen tarjota informaatiota luokittelua

varten julkaistessaan palvelujaan.

Esimerkki tModel-rakenteesta:

<tModel tModelKey=”uuid:F2387940-A310-44......”>

<name>et:e-Company-registry</name>

<description xml_lang”en”>e-Company Registry Number</description>

<categoryBag>

<keyedReference

keyName=”Yahoo Business Taxonomy”

keyValue=”Business_and_EconomyShopping_and_Services/Sports/...”

tModelKey=”uuid:3D4DE26B.7894.55....”/>

</categoryBag>

</tModel>

144

A part of an overview UDDI object model

Kuvassa on annettu vielä UDDI:in talletettavan tiedon rakenne luokkakaaviona. Tarkempi malli –

jonka perusteella kalvolla esitetty malli on tehty – löytyy UDDI.org:n sivuilta, kts. tarjottava

dokumentaatio. businessEntity sisältää tietoa talletettavan entiteetin (Web-palvelun) julkaisijasta.

businessEntity-rakenteet puolestaan sisältävävät businessService-rakenteita. businessService kuvaa

tietoa tietystä joukosta (perheestä) teknisiä palveluita. businessService-rakenteet sisältävät edelleen

bindingTemplate-rakenteita, jotka tarjoavat tiedon palveluiden kontaktipinnoista (endpoint). Näillä

bindingTemplate-rakenteilla on viite tModel-rakenteihin. Nämä viitteet osoittavat palveluiden

rajapintaspesifikaatioihin.

identifierBag sisältää tietoa käytössä olevista tunnisteista. Tunnisteita voivat käyttää businessEntity ja

tModel –rakenteet. Tunnisteita voidaan käyttää identifioimaan palvelu (tModel ) tai palvelun tarjoaja

(businessEntity ). Tunniste voi olla vaikkapa D-U-N-S (Data Universal Numbering System) numero.

Tunnisteiden käyttö ei ole pakollista, mutta niiden käyttö luonnollisesti parantaa hakuoperaatioita.

categoryBag sallii businessEntity, businessService, ja tModel-rakenteiden luokittelun jonkin saatavilla

olevan taksonomian mukaan (esim. NAICS). Myös kategorisoinnin käyttö on optionaalista, mutta sen

käyttö niin ikään parantaa hakuoperaatioita. indentifierBag- ja categoryBag –rakenteissa yksi

identifiointi/luokittelu esitetään keyedReference –rakenteen avulla avain-arvo –parina. Lisäksi

keyedReference-rakenne sisältää tunnisteen (tModelKey), jonka avulla yksittäinen keyedReference-

rakenne liitetään tiettyyn tModel-rakenteeseen. Tunniste tModelKey generoidaan palvelulle

automaattisesti siinä vaiheessa, kun uusi palvelu julkaistaan UDDI-rekisterissä.

145

UDDI SOAP APIs• publishers API

– for requesting to enter information into UDDI– to use publishers API, the client first needs to apply for an

authentication token from an operator• inquiry API

– for finding business information by category– for retrieving detailed information about businesses

(according to a given criteria)• versions of the APIs are identified using namespaces

– e.g., identifying that version v2 API is used:xmlns=”urn:uddi-org:api_v2”

• both APIs are available via HTTP POST only• APIs support Unicode that requires UTF-8 encoding

UDDIn tarjoaa APIt palveluiden julkaisemiseksi tai poistamiseksi (publishers API) sekä kyselyiden ja

etsintöjen tekemiseksi (inquiry API). Muutoksia tehtäessä – ts. käytettäessä julkaisijan API (publishers

API) – asiakkaan tulee ensin pyytää autentikointia operaattorilta. Tätä varten API tarjoaa funktion

get_authToken (tästä lisää myöhemmin). Kyselyjä voidaan puolestaan tehdä ilman autentikointia.

Seuraavaksi käymme läpi näiden API:en funktiot. Huomaa kuitenkin, että riippuen UDDI versiosta,

funktioiden määrä saattaa hieman vaihdella. Käytetty UDDI-versio identifioidaan

nimiavaruusmääreen avulla. Molemmat APIt tukevat unicode-merkistöä ja edellyttävät UTF-8

koodaustapaa ja niitä voidaan käyttää vain HTTP POST:a hyödyntäen.

Esimerkkikysely (SOAP/HTTP POST). Kutsuttava operaatio on find_business, jonka avulla voidaan

annetuin kriteerein etsiä palvelun tarjoajaa.

POST /find_business HTTP/1.1

Host: www.example.....

Content-Type: text/xml; charset=”utf-8”

Content-Length: nnnn

SOAPAction: ”find_business”

<?xml version=”1.0” encoding”UTF-8” ?>

<Envelope xmlns=http://schemas/xmlsoap.org/soap/envelope/>

<Body>

<find_business xmlns=”urn:uddi-org:api_v2” ... >

<name>e-Company</name>

</find_business>

</Body>

</Envelope>

146

Inquiry APIs

a complete tModel recordget_tModelDetaila complete businessService recordget_serviceDetaila complete businessEntity recordget_businessDetaila complete bindingTemplate recordget_bindingDetailto get details from registry, to retrieve...get_xxx functionstModels that match the specified criteriafind_tModelservices associated with a specified businessfind_servicebusiness that matches the specified criteriafind_businessbindings associated with specified servicesfind_bindingto search the registry for...find_xxx functionsDescriptionFunction name

Koodiesimerkki (IBM, UDDI4J). Huomaa jälleen, että riippuen versiosta (UDDI4J) ja ennen kaikkea

käytettävästä ympäristöstä, esimerkin kaltainen UDDI-rekisterin käyttöönotto saattaa hieman vaihdella

(funktiot, parametrit jne.).

import java.net.*;

import java.util.*;

import com.ibm.uddi.util.*;

import com.ibm.uddi.datatype.*;

import com.ibm.uddi.datatype.business.*;

import com.ibm.uddi.response.*;

import com.ibm.uddi.client.*;

public class MyClient {

public static void main(String[] args) throws Exception {

try {

// luodaan proxy yhteyden ottamiseksi palveluun (service endpoint)

UDDIProxy uddi = new UDDIProxy();

uddi.setInquiryURL

(http://www-3.ibm.com/services/uddi/testregistry/inquiryapi);

// etsitään palveluita (tarjoajia), joiden nimi alkaa merkkijonolla “Sport”

// find_business –operaation paremetrit: palveluntarjoajan nimi,

// “properties” (esim. tapa lajitella vastaus) ja vastausjoukon maksimi koko

// (0 tarkoittaa, että kaikki kriteereihin sopivat vastaukset palautetaan)

BusinessList bList = uddi.find_business(“Sport”, null,0);

Vector bInfo = bList.getBusinessInfos().getBusinessInfoVector();

// Tehdään vastauksella mitä mieleen tulee...

for (int i = 0; i < bInfo.size(); i+) {

BusinessInfo info = (BusinessInfo) bInfo.elementAt[i];

System.out.println(“name = “ + info.getNameString());

System.out.println(“key = “ + info.getBusinessKey());

//...

}

} catch (UDDIException exception) {

//...

}

}

}

147

Publisher APIs

hides the tModel recond specified by the tModelKey. A hiddentModel record can still be referenced by another UDDI record

delete_tModel

deletes the businessService recond specified by the serviceKeydelete_servicedeletes businessEntity record specified by the businessKeydelete_business

deletes the bindingTemplate record specified by the bindingKey

delete_bindingto delete information from registrydelete_xxx func.inserts updates of a tModel recordsave_tModelinserts updates of a businessService recordsave_serviceinserts updates of a businessEntity recordsave_businessinserts updates of a bindingTemplate recordsave_bindingto save information in registrysave_xxx func.DescriptionFunction name

148

Publisher APIs (cont’d)

taking care of the securityrequests an authentication token from the operatorsite, such a token is required for all save_xxx and delete_xxx functions

get_authToken

requests for the specified authentication token to be discarded and invalidated

discard_authToken

DescriptionFunction name

149

UDDI and WSDL• UDDI is intended and designed to work with any service

description languages, WSDL is just one option• Since UDDI is extensible and flexible, WSDL information can

be stored in UDDI in several ways• To better fit with UDDI, WSDL can be devided into two

parts: – service interface: data types, interface, binding

• registered as UDDI tModels, interfaces and bindings are often representedas their own tModels that are then linked together

• overviewDoc: points to the corresponding WSDL document (when usingUDDI, the link is followed to retrieve the WSDL document)

– service implementation: endpoint, service• service can be represented as businessService and endpoint as

bindingTemplate

UDDI on suunniteltu yleiseksi tietorekisteriksi. Sitä ei siis ole suunniteltu ainoastaan WSDL-

kuvausten tallettamiseksi. Lisäksi koska UDDIn tietorakenne on joustava ja laajennettavakin (esim.

versio 3 sallii omien kategoriointien tekemisen), voidaan WSDL-dokumenttien informaatiota tallettaa

UDDI-rekisteriin eri tavoin.

WSDL:stä kannattaa muistaa se, että WSDL kuvaus voidaan koostaa erillisistä XML-tiedostoista.

Aiemmin WSDL-kielen yhteydessä todettiin, että WSDL-dokumentin elementit voidaan jakaa kahteen

osaan: palvelun rajapintaan (uudelleen käytettävät osat) ja palvelun toteutukseen (toteutusspesifi osa).

Tätä jaottelua käytetään hyväksi talletettaessa WSDL-dokumenttien informaatiota UDDI-rekisteriin.

WSDL-dokumentin rajapintaosa (elementit types, interface ja binding ) talletetaan tModel-

rakenteeseen/-rakenteisiin siten, että overviewDoc-rakenne osoittaa itse WSDL-dokumenttiin (tai sen

vastaaviin osiin). Usempaan tModel-rakenteeseen jakaminen on kätevää myös siksi, että näin WSDL:n

interface-elementti voidaan sitoa useampaan kuljetusprotokollaan binding-elementtien avulla. Näin

ollen sillä tModel-rakenteella, joka edustaa WSDL:n binding-elementtiä, on linkki siihen tModel-

rakenteeseen, joka edustaa WSDL:n interface-elementtiä Palvelun toteutusosan elementit endpoint ja

service voidaan puolestaan esittää UDDI:n bindingTemplate ja businessService –elementtien avulla.

Tällöin WSDL-dokumentin service ja endpoint –elementtien välinen sisältyvyyssuhde vastaa UDDI:n

businessService ja bindingTemplate –rakenteiden välistä sisältyvyyssuhdetta.

Esimerkki:

<tModel authorizedName=”..." operator=”..." tModelKey=”...">

<name>XXX</name>

<description xml:lang="en">XXX</description>

<overviewDoc>

<description xml:lang="en">WSDL Source Document</description>

<overviewURL>http://www.../ProductBrowsing.wsdl</overviewURL>

</overviewDoc>

<categoryBag>

<keyedReference tModelKey=”..."

keyName="uddi-org:types"

keyValue="wsdlSpec"/>

</categoryBag>

</tModel>

150

Problems with UDDI• Quality of UDDI data

– there is no mechanism to ensure that the data to be registered is sufficient, legitimate, or valid to create a useful Web service registry

– how to measure the quality of data?

• Too many options?– usage of optional and extensible fields provides flexibility...with a

price: possibly inefficient searching and discovery

• New versions– New versions of SOAP, WSDL, and UDDI are being developed,

therefore• new guidelines/approaches for mappings are also introduced• a risk of using a wrong version of a particular specification exists

UDDI-rekisterillä on joustavuudestaan ja tehdystä kehitystyöstä huolimatta myös huonot puolensa.

Ensinnäkin UDDI-rekisteriin voidaan periaatteessa tallettaa hyvin monenlaista tietoa eikä UDDI tarjoa

mitään mekanismeja tiedon oikeellisuuden, riittävyyden ja laillisuuden tarkistamiseksi. Toisaalta

tiedon laadun varmistaminen on hyvin vaikeaa, koska sen mittaaminen sinänsäkin on vaikeaa. Lisäksi

UDDI tarjoaa paljon optionaalisia rakenteita. Niiden käyttö (joustavuus) tuo mukanaan ongelmia

tiedon tehokkaan etsimisen kannalta.

Yksi kaikkien Web-palvelustandardien (SOAP, WSDL, UDDI) perusongelmista on niiden jatkuva

kehitys. Tämä voi olla ongelma yksittäisen standardin kannalta (esim. tuetaanko oikeaa SOAP-

versiota), mutta se on erityisen ongelmallista näiden standardien yhteiskäytön kannalta. WS-I (Web

Service Interoperability) organisaatio pyrkii tarjoamaan ratkaisun tähän ongelmaan. Tähän

organisaatioon ja sen toimintaan Web-palveluiden yhteentoimivuuden parantamiseksi tutustumme

seuraavaksi.

Edellä mainittujen ongelmien lisäksi on olemassa monia avoimia kysymyksiä:

• Käyttöoikeuksien määritteleminen UDDI-rekisteriin talletetulle tiedolle?

• Miten synkronoidaan ympäristö, jossa on käytössä useita rekistereitä (vain osa mahdollisesti

julkisia)?

• Miten määritellään sopimuksia eri osapuolten (palvelun tarjoajat ja käyttäjät) välille?

• jne.

web service description language (wsdl) - tut

Documents