UDDI voor dynamische webservices

Eerst was er SOAP en toen kregen we UDDI. Met SOAP (Simple Object Access Protocol) kunnen we componenten aanroepen, ongeacht waar ze zich bevinden (ergens op het LAN of het Internet) en ongeacht via welke componentenbus ze aan te roepen zijn (CORBA, Java RMI of COM). SOAP maakt gebruik van reeds bestaande standaarden als XML en HTTP.

UDDI (Universal Description, Discovery, and Integration) moet u zien als een uitbreiding op SOAP. Het is een standaard die de mogelijkheid biedt om dynamisch componenten te activeren. Let wel, als we componenten over het Internet aanroepen, dan noemen we die in de hedendaagse literatuur geen componenten meer, maar 'webservices'. Klinkt chiquer, toch?

Trouwens, het 'dynamisch aanroepen van webservices' klinkt ook interessant, nietwaar? Deze standaard is eind vorig jaar verschenen. Wat is de bedoeling van UDDI? We kennen reeds het fenomeen van samenwerkende websites. Bijvoorbeeld, wij zijn de eigenaar van website A - bezoekers kunnen bij ons CD's kopen. Omdat wij niet veel geld te investeren hadden, hebben we ons beperkt tot het opzetten van een virtuele tussenhandel. Om de CD bij u thuis te krijgen, sturen we elektronisch (uiteraard als XML-document) een bericht naar website B met de opdracht om een CD te versturen naar onze klant. Indien de website die verantwoordelijk is voor het versturen van de CD, deze niet in voorraad heeft, moet zij een elektronisch berichtje sturen naar website C. Die is van de maatschappij die de CD uitbrengt. U kunt er zich waarschijnlijk wel wat bij voorstellen.

In dit voorbeeld zijn de websites statisch gekoppeld. SOAP kan hierbij een nuttige rol spelen. Veronderstel dat alle drie bedrijven een andere componentenbus hebben gekozen: wij lieten voor onze website ons oog op COM laten vallen, B gaat voor Java RMI en C voor CORBA. Het kunnen aanroepen van de componenten ofwel webservices van de andere bedrijven is dan niet onmogelijk, maar wel een heel gedoe. SOAP schermt namelijk de verschillende API's geheel af. XML-documenten die voldoen aan de SOAP-standaard worden heen en weer gestuurd, en hiermee wordt de API van de verschillende bussen afgeschermd.

De koppelingen tussen de websites zijn in dit voorbeeld statisch van aard. Een programmeur werkzaam bij ons bedrijf, heeft dus in zijn programma een hoeveelheid code opgenomen om een webservice aan te roepen die bij bedrijf B draait. En zijn tegenhanger bij dat bedrijf heeft hetzelfde gedaan om de webservices van bedrijf C aan te roepen.

Met UDDI kunnen we de webservices dynamisch aanroepen. Ergens op het Internet komt een directory te staan, waarin bedrijven hun publieke webservices bekendmaken. Van elke webservice worden onder andere beschrijvingen, contactpersonen, parameters en datatypes geregistreerd. Deze directory fungeert als een soort gouden gids. 

De directory kan dan bezocht worden door uw eigen software en dynamisch kan uitgezocht worden welke webservices beschikbaar en relevant zijn. Adressen en specificaties kunnen dynamisch worden opgehaald en er kan dynamisch contact gezocht worden met andere websites.

Voor het gegeven voorbeeld kan dit betekenen dat onze website A, vooraleer ze met website B gaat praten, eerst onderzoekt of er nog andere websites zijn die vergelijkbare activiteiten uitvoeren als B. Als dat zo is, maakt A contact met die andere website en roept een webservice aan die beschrijft hoe duur het versturen van CD's is. Als blijkt dat zij goedkoper zijn dan website B, mag deze nieuwe partner de CD versturen. En voilà, we hebben een dynamische koppeling gerealiseerd tussen onze website A en een nieuwe partner, zonder dat onze bezoeker hier weet van heeft.

Veel leveranciers hebben zich reeds achter UDDI geschaard. Maar we weten nog niet hoe robuust het gaat worden, wat de performance zal zijn en hoe intens de acceptatie door de markt zal worden. Want het is nieuw, gloednieuw. 

Het succes van UDDI zal echter ook afhangen van een minder technisch aspect. Websites die vergelijkbare webservices bieden, zullen tevens vergelijkbare interfaces aan die services moeten geven. In mijn voorbeeld ging ik er al vanuit dat elke website die CD's verstuurt, een webservice heeft waaraan gevraagd kan worden wat het versturen werkelijk kost. Dus moeten concurrerende bedrijven afspraken gaan maken over de interfaces van hun webservices. En dit zie ik niet zo snel gebeuren. Met andere woorden, vanuit een technologisch standpunt is UDDI interessant en het zal voor sommige websites zeer zeker een uitkomst zijn. Maar bedrijfskundig zijn er flink wat hobbels te nemen.