Webservices missen semantiek

Stel, ik wil een website maken waarmee bezoekers kunnen kijken welke films er op dat moment draaien in de voor hun 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 deze 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 in staat zijn een lijst met films te produceren en het moeten bioscopen zijn gevestigd in de stad van de bezoeker. Als alles correct verloopt, krijg ik dan keurig een rijtje webservices terug. Vervolgens hoef ik deze webservices dan slechts één voor één aan te roepen, de lijstjes netjes samen te voegen, en klaar is kees. 

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, dient deze wel altijd operationeel te 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 minder bekende NTT Communications. De UDDI-organisatie zorgt ervoor dat als een aanbieder van een webservice zijn gegevens bij de ene installatie registreert, dat dit binnen 24 uur naar de drie andere gerepliceerd wordt. Zover klinkt alles prima.

Waar de UDDI-organisatie echter niet voor verantwoordelijk is, is de inhoud van de database. Daarvoor zijn de eigenaars van de webservices zelf verantwoordelijk, zij dienen hun webservices correct te 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. Maar 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 hoe de aanroep moet plaatsvinden. Wat de parameters precies betekenen en hoe ze gebruikt moeten worden, dat staat er niet in. 

Om het probleem op te lossen, werkt de W3C momenteel aan een nieuwe taal, genaamd OWL (Web Ontology Language). Deze moet de semantische leegte gaan 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 er over de interface geen afspraken gemaakt kunnen worden. 

Het is nog te vroeg om te zeggen of OWL een succes gaat worden. In ieder geval is de voorloper, RDF (Resource Description Framework), wat al sinds 1999 een standaard is, nog steeds geen doorslaand succes. Maar laten we positief blijven en hopen dat deze taal voor het specificeren van de semantiek het wel gaat maken.