1

Service registries

Universal Description, Discoveryand Integration (UDDI)

2

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.

3

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

4

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)

5

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.

Nämä ovat yleisiä ”vaatimuksia” rekistereille. Ne eivät siis ole UDDI-spesifejä, mutta ne edellytetään

luonnollisesti myös UDDI-rekistereiltä.

6

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/M

anufactures

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.

7

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.

8

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.

9

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.

10

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.

11

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.

12

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:

et:e-Company-registry

e-Company Registry Number

13

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

14

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”

e-Company

15

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

//...

}

}

}

16

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

17

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

18

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:

19

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.