Dit is het vervolg op deel 1 van een tweeluik over web services. Waar het vorige deel een algemene indruk geeft van web services, duiken we hier wat dieper in de techniek.

Voor ontwikkelaars is het fenomeen web service namelijk bijna nog interessanter dan voor de rest van de business. Want waarom zou je het wiel voor de tweede keer uitvinden? Door slim te gebruiken wat anderen gemaakt hebben, hou je immers meer tijd over voor echt leuke dingen.

Web service technieken

Een web service is een applicatie die een aantal functies biedt en aan te spreken is over het Internet. Een applicatie biedt een web service omdat de interface zich houdt aan bepaalde afspraken. Alle web services spreken dezelfde taal, over hetzelfde protocol, met vaste afspraken over het formaat.

De volgende termen spelen een sleutelrol in de techniek en afspraken van web services.

• SOAP (Simple Object Access Protocol)
• WSDL (Web Service Description Language)
• UDDI (Universal Description, Discovery and Integration)

Het volgende hoofdstuk neemt ze stuk voor stuk door. Wil je gebruik kunnen maken van deze services, moet je toch weten hoe het onder de kap werkt.

SOAP

SOAP (Simple Object Access Protocol) is een setje afspraken over boodschappen die je verstuurt. SOAP is dus de manier waarop je praat met een web service. Een voordeel van SOAP is, dat het dwars door firewalls heen prikt.

SOAP lijkt op ORPC van DCOM, IIOP van CORBA of JRMP voor Java Remote Method Invocation (RMI), maar dan een stuk eenvoudiger.

Een SOAP message is namelijk een gewoon XML document met een paar extra regels. Zo heeft het een vaste opbouw en mag het geen verwijzing naar een DTD bevatten.

Hieronder zie je een fictief voorbeeld van een service die een weersvoorspelling levert, voor de volgende dag op een bepaalde locatie. Als parameter heeft de request de naam van het land waarvoor de weersvoorspelling wordt gevraagd (CountryName).

<SOAP-ENV:Envelope>
 <SOAP-ENV:Body>
  <xmlns:m="http://sandersWeatherPrediction.org"/>
  <!- een voorbeeld namespace --> 
  <m: WeatherPredictionRequest>
  <CountryName>The Netherlands</CountryName>

  </m: WeatherPredictionRequest >
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Hierop moet natuurlijk een antwoord komen dat de weersvoorspelling bevat.

<SOAP-ENV:Envelope>
 <SOAP-ENV:Body>

  <xmlns:m=" http://sandersWeatherPrediction.org"/> 
  <m: WeatherPredictionResponse >
  <Response >20 degrees Celsius and sunny</Response>
  </m: WeatherPredictionResponse e>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Het ziet er tamelijk eenvoudig uit, en dat is het ook.

WSDL

WSDL (Web Services Description Language) beschrijft web services met XML. Via WSDL geeft een web service zijn werking prijs.

Hier onder volgt een voorbeeld van een WSDL definitie. Het is een beschrijving van de eerder genoemde web service die een weersvoorspelling doet voor een bepaald land. De service heeft één operatie, GetTemp genaamd, en maakt gebruik van SOAP en HTTP.

Het <definitions> element is het root-element.

<definitions name="WeatherPrediction"
targetNamespace="http://sandersWeatherPrediction.org"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://sandersWeatherPrediction.org"
xmlns:xsd="http://www.w3.org/1999/
XMLSchema">

In WSDL zijn operaties beschreven als input en output messages. Een portType is niet meer dan een collectie van 1 of meer operaties:

<wsdl:portType name="WeatherPrediction">
 <wsdl:operation name="GetTemp" parameterOrder="p0">
  <wsdl:input 
  message="tns:WeatherPredictionRequest"/>
  <wsdl:output 
  message="tns:WeatherPredictionResponse"/>
 </wsdl:operation>
</wsdl:portType>

De message is een afspraak over de data die gecommuniceerd wordt.

<wsdl:message name="WeatherPredictionRequest">
 <wsdl:part name="CountryName" type="xsd:string"/>
</wsdl:message>
<wsdl:message 
name="WeatherPredictionResponse">
 <wsdl:part name="response"
 element="ns0:string_Response"/>

</wsdl:message>

Het element <binding> bevat een protocol (zoals SOAP) en een data format voor een bepaald port type:

<wsdl:binding name="WeatherPrediction"
type="tns:WeatherPrediction">
 <SOAP:binding
 transport="http://schemas.xmlsoap.org/soap/http" 
 style="document"/>

 <wsdl:operation name="GetTemp">
  <map:java-operation name="The Netherlands" 
  signature="KExqYXZhL2xhbmcv---L1N0cmluZzs="/>
  <soap:operation
  soapAction="http://sandersWeatherPrediction.org
  /service/WeatherPrediction# The Netherlands
  #KExqYXZhL2xhbmcv---L1N0cmluZzs=" 
  style="document"/>
 </wsdl:operation>
</wsdl:binding>

Goed, nu weet je dus een beetje hoe WSDL er uit ziet. Maar waar kan je die beschrijvingen dan vinden?

UDDI

UDDI (Universal Description, Discovery and Integration) is een standaard waarmee web services gevonden kunnen worden die door bedrijven open worden gesteld voor gebruik.

Ontwikkelaars kunnen door UDDI te gebruiken op een heel gemakkelijke manier allerlei functionaliteiten in gaan bouwen in hun eigen applicaties. Zelf bouwen is duur, en je wordt er moe van: dat doen we dus liever niet. Je “leent” die functies gewoon uit de bibliotheek.

Waar moest ik ook alweer zijn?

Een UDDI Business Registry (UBR) is een applicatie die via een website online bedrijven de mogelijkheid biedt zich in te schrijven voor de UDDI standaard. Je kunt daar ook de bibliotheek van beschikbare web services doorzoeken.

Tijdens de zoekacties kan je gebruik maken van category codes zoals bijvoorbeeld NAICS (North American Industry Classification System) of SIC (Standard Industrial Classification). Je kan ook zoeken op naam van de onderneming of op basis van geografische locatie.

Er zijn een aantal UDDI Business Registries, allemaal gesynchroniseerd; de bekendste is die van Microsoft. IBM beheert ook een grote.

Okee: ik ben er, maar ik snap het niet!

De volgende termen spelen een rol in de UDDI Business Registry.

• Category Een Category is een onderverdeling van de web services. De UDDI Business Registry kent alleen geen relaties tussen categorieën; als je zoekt in een categorie, worden de subcategorieën niet meegenomen. Niet zo handig, maar niets aan te doen.
• businessEntity De businessEntity beschrijft de aanbieder van de web service. Dit is dus bijvoorbeeld een bedrijf.
• businessService De businessService is de beschrijving van de service die geboden wordt.
• bindingTemplate Een bindingTemplate biedt technische informatie over een service.
• publisherAssertion Een publisherAssertion geeft een relatie aan van de ene businessEntity met de andere. Denk hierbij aan bijvoorbeeld een business unit en het moederbedrijf.
• tModel Het tModel bevat metadata met betrekking op de service. Het is een technisch recept voor het maken van de service. Het is in feite de eisenset die een service definieert.

WSDL en het tModel

De informatie in bovengenoemde onderdelen komt uit de WSDL beschrijving van een web service. BusinessService en bindingTemplate maken bijvoorbeeld gebruik van het <port> element uit het WSDL document dat bij de betreffende service hoort. Dit element beschrijft de lokatie van de service. Andere elementen uit dit document worden beschreven in het tModel. Deze scheiding wordt aangebracht om een duidelijke structuur in de bibliotheek te krijgen.

Elk tModel heeft een naam, beschrijving en een unieke identifier (= tModelKey). Een voorbeeld is het volgende.

De tModelKey uuid:C1ACF26D-9672-4404-9D70-37B756E62AB4 identificeert het tModel Weather tModel, met als beschrijving A tModel for a non-existant Weather web service.

Je zou kunnen zeggen dat het tModel de algemene eigenschappen beschrijft van de service, terwijl businessService en bindingTemplate de specifieke implementatie weergeven. Een tModel zegt dus: “Als jij A roept, roep ik B terug”. BusinessService en bindingTemplate zeggen: “Ik bevind me op lokatie X. Ik ben gemaakt volgens methode Y”.

Een tModel is dus generiek voor een bepaalde service. Een businessService en bindingTemplate zijn specifiek. Dit is belangrijk, omdat het tModel gebruikt kan worden door consumenten bij het zoeken naar de juiste aanbieder. Er zijn dus soms meerdere web services met hetzelfde tModel. Je kunt dan zelf de beste of goedkoopste uitkiezen.

Een voorbeeld van een tModel voor onze weersvoorspeller is het volgende:

<tModel
tModelKey="uuid:C1ACF26D-9672-4404-9D70-37B756E62AB4">
 <name>Weather tModel</name>
 <description xml:lang="en">A tModel for a non-existant
 Weather web service</ description >
 <overviewDoc>

 <description xml:lang="en">WSDL Source Document for a
 non-existing Weather web service
 </description>
 <overviewURL>
 http://sandersWeatherPrediction.org/weather.wsdl 
 </overviewURL>
 </overviewDoc>
 <categoryBag>

 <keyedReference
 tModelKey="uuid:C1ACF26D-9672-4404-9D70-37B756E62AB4"
 keyName="weather prediction" keyValue="weather"/>
 </categoryBag>
</tModel>

Met dit tModel als recept kun je een weersvoorspelling bestellen. Er kleven alleen nog wel risico’s aan het gebruik van dit tModel.

Het interpretatieprobleem verder uitgewerkt

Bij de eerder genoemde WeatherPrediction moet je een string meegeven als parameter. Deze string stelt de naam voor van een bepaald land. De return-value is de weersvoorspelling van dat land voor de dag er na.

Bij het maken van deze web service maak ik een aantal veronderstellingen. Ik ga er van uit dat:

• je de betekenis van “Weather” kent;
• je weet wat een geldige string is;
• je weet wat “de naam van een bepaald land” is.
• je library met landennamen overeenkomt met de mijne;
• de taal waarin de teruggegeven weersvoorspelling is opgesteld Engels is;
• je weet of mijn voorspellingen daadwerkelijk ergens op gebaseerd zijn (wat natuurlijk niet zo is).

Dat zijn dus best veel veronderstellingen. Nu gaat het bij deze weersvoorspelling waarschijnlijk nog wel goed. Er is waarschijnlijk geen vuiltje aan de lucht als het mis gaat, behalve als je bent gaan ballonvaren.

Het kan natuurlijk ook anders. NASA verloor in 1999 een satelliet van 125 miljoen dollar. Het apparaat was op weg naar Mars, maar explodeerde: een team van Lockheed Martin (één van de subcontractors) had andere eenheden gebruikt voor metingen dan het NASA-team.

Dit voorbeeld was te wijten aan gebrekkige menselijke communicatie, maar geeft wel aan dat je niet zo maar veronderstellingen kunt doen. Bedrijfskritische web services mogen voorlopig niet alleen op basis van een UDDI beschrijving worden gebruikt of gemaakt. Als je een SAP loonadministratie aan een Intranet koppelt, blijf dan vooral ook praten!

Er zijn wel initiatieven om dit probleem op te lossen. Zo is er in de toekomst het Semantisch Web. De W3C-talen RDF (The Resource Description Framework), digital signatures en XML zijn de basis van het Semantisch Web. In feite levert RDF metadata: gegevens over gegevens. Maar voordat het Semantisch Web er is, moet er nog veel gebeuren.

Wees ondertussen dus voorzichtig met het doen van aannames.

Een bestaande service is snel verdiend

Als je nu een web applicatie moet gaan bouwen, doe jezelf dan een plezier en kijk eerst in je favoriete UDDI business registry. Je kunt jezelf tijd, geld en moeite besparen door voor een nieuw probleem een bestaande oplossing te zoeken. Tien tegen een dat er een web service is die precies doet wat jij wilt.

Vergeet niet dat luiheid een goede eigenschap is van ontwikkelaars. Dubbel werk is duur.

Handige links

• http://uddi.microsoft.com/ De UDDI Business registry van Microsoft
• https://uddi.ibm.com/ubr/registry.html De IBM UDDI Business Registry
• http://www.uddi.org/ De OASIS UDDI site
• http://www.xml.org/ De OASIS XML site

...en een paar leuke voorbeelden

Real life voorbeelden van web services zijn teachatechie.com/GJTTWebservices/ZipCode.asmx waar je postcodes in de Verenigde Staten kunt vinden, en teachatechie.com/GJTTVBWebservices/TextToImage.asmx waar je tekst in een plaatje kunt laten omzetten.

• Home
• Artikelen
• Colofon