Stel, ik wil een website maken waarmee bezoekers kunnen kijken welke films er op dat moment draaien in de voor hen lokale bioscopen. Er zijn verscheidene manieren om dit te implementeren en webservicetechnologie is er één van. In feite is ze daar uitermate geschikt voor. Alhoewel?
Als ik van elke bezoeker weet in welke stad hij zich bevindt, hoef ik slechts een zoekopdracht af te vuren op de bekende uddi-database (universal description, discovery, and integration). In deze opdracht vermeld ik dat ik op zoek ben naar de webservices van bioscopen die een lijst met films kunnen produceren en die in de stad van de betreffende bezoeker gevestigd zijn. Als alles correct verloopt, krijg ik keurig een rijtje webservices terug. Vervolgens roep ik deze webservices één voor één aan en voeg ik de lijstjes netjes samen, en klaar ben ik. Een makkie – of lijkt het alleen maar eenvoudig en is de praktijk geheel anders? Laten we bij het begin beginnen.
Als we de uddi-database willen benaderen, moet deze wel altijd operationeel zijn. Dit valt onder de verantwoording van de onafhankelijke uddi-organisatie. Om een hoge mate van beschikbaarheid te garanderen is de uddi-database geïnstalleerd bij vier verschillende organisaties: IBM, Microsoft, SAP en het onbekendere NTT Communications. De uddi-organisatie zorgt ervoor dat, als een aanbieder van een webservice zijn gegevens bij de ene installatie registreert, dit binnen 24 uur naar de drie andere gerepliceerd wordt. Tot zover klinkt alles prima.
De uddi-organisatie is echter niet voor verantwoordelijk voor de inhoud van de database. Daarvoor zijn de eigenaren van de webservices zelf verantwoordelijk; zij moeten hun webservices correct documenteren. Laten we voor het gemak ook daarvan uitgaan.
Om de webservices van verschillende bioscopen te kunnen aanroepen, moet onze applicatie begrijpen hoe de interface van elke webservice in elkaar zit. Een mogelijke oplossing is dat een internationale branchevereniging een standaard definieert voor de webservice-interfaces. Met andere woorden, wat is de naam van de webservice, wat zijn de parameters en wat zijn de bijbehorende datatypes? Wij moeten er dan blind op vertrouwen dat een aanroep correct afgehandeld wordt.
Stel dat zo’n branchevereniging er niet is, hoe lossen we ons probleem dan op? Het antwoord is: door het toevoegen van semantiek. De interface van een op Soap-gebaseerde webservice is gedefinieerd met een wsdl-document (web services description language). In de uddi-database staat voor elke webservice vermeld waar de wsdl staat. Helaas is dit alleen een technische beschrijving van de parameters en de manier waarop de aanroep moet plaatsvinden. Wat de parameters precies betekenen en hoe ze gebruikt moeten worden staat er niet in.
Om het probleem op te lossen, werkt W3C momenteel aan een nieuwe taal, owl (web ontology language). Deze moet de semantische leegte opvullen. In owl kunnen we wel de semantiek specificeren. Voor webservices die voor hetzelfde doel geïmplementeerd zijn, maar afwijkende interfaces hebben, wordt een mapping gedefinieerd naar een gezamenlijke semantiek. De aanroepende applicaties moeten dan, voordat ze een wsdl-document lezen, eerst het owl-document consulteren. Daarin staat vermeld hoe de bijbehorende webservice werkt.
Owl is dus een onmisbare component voor het dynamisch aanroepen van webservices waarbij over de interface geen afspraken te maken zijn. Het is nog te vroeg om te zeggen of owl succesvol zal zijn. In ieder geval is de voorloper, rdf (resource description framework), wat al sinds 1999 een standaard is, nog steeds geen doorslaand succes. Laten we echter positief blijven en hopen dat deze taal voor het specificeren van de semantiek het wel gaat maken. < BR>
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
