Geen SOAP voor programmeurs

Iedereen heeft het over de trojka SOAP, UDDI en WSDL, de drie 'standaarden ' die het fundament van webservices vormen. Het zijn momenteel de hipste en meest gebruikte afkortingen. Ze zijn belangrijk, ze zijn al breed geaccepteerd en door velen reeds geïmplementeerd. Maar voor wie zijn ze eigenlijk bedoeld? Toch niet voor de programmeur?

Waarschijnlijk totaal overbodig, maar hier is in een notendop de verklaring van de drie afkortingen. SOAP (Simple Object Access Protocol) is de standaard XML-taal om tot webservice gepromoveerde componenten aan te roepen over protocollen als HTTP, SMTP en message queuing. UDDI (Universal Description, Discovery and Integration) is een in ontwikkeling zijnde standaard voor een directory-systeem waarin we webservices kunnen registreren, documenteren en bevragen. En WSDL (Web Services Definition Language) is een XML-taal waarmee we de interfaces van webservices kunnen beschrijven. Over het algemeen zullen deze WDSL-documenten voornamelijk door applicaties gelezen worden en beschikbaar zijn voor aanroepende applicaties.

Recentelijk zijn er vele ontwikkeltools verschenen waarmee we op eenvoudige wijze voor onze eigen componenten WSDL-documenten kunnen laten genereren, om ze zodoende via SOAP aanroepbaar te maken. Ook het aanroepen van een webservice vanuit applicaties wordt zeer eenvoudig gemaakt. De ene leverancier maakt het ons nog makkelijker dan de ander. Bij de meeste is het slechts een kwestie van het klikken op enkele buttons en klaar is Kees! Een kind kan de was doen, want alle benodigde code wordt gegenereerd. 

Toch is dit een ongewenste situatie, omdat we uiteindelijk in onze code kunnen lezen dat er een SOAP-webservice aangeroepen wordt en/of dat we onze component 'gesoapt' hebben. Laten we deze kritiek toelichten.

Voor het aanroepen van remote componenten of applicaties hebben we de afgelopen jaren vele protocollen zien komen en gaan. Eerst deden we het met platform-afhankelijke protocollen, daarop volgde DCE (Distributed Computing Environment) en vervolgens kwamen CORBA en COM. Elk protocol had zo haar eigen berichtenformaat. Voor de duidelijkheid, SOAP is geen nieuw protocol, maar een nieuw protocol-onafhankelijk berichtenformaat.

Het grote aantal veranderingen is nooit echt aangenaam geweest, maar we hebben er wel iets van geleerd, namelijk dat protocollen en berichtenformaten voor programma's afgeschermd moeten worden. Als er bepaalde protocollen en formaten gebruikt worden, moet dat dus voor een programma transparant zijn. Het is niet belangrijk voor een programma om te weten of zijn parameters als SOAP-documenten of via een ander formaat verstuurd worden. Net zo min als het belangrijk is dat we weten dat onze componenten via SOAP aangeroepen worden. Voor het programma is het alleen van belang dat zijn aanroep goed overkomt en dat het te zijner tijd een antwoord terugkrijgt.

Het afschermen van protocollen en formaten is de taak van zogenaamde middleware-producten. Hun uitdaging is SOAP zodanig te implementeren dat programma's hiervan gebruik kunnen maken, zonder dat hiervoor code aangepast moet worden. Gerenommeerde middleware-leveranciers als Bea Systems en Iona, en nieuwe spelers zoals CapeClear zijn reeds begonnen. Indien hun producten ingezet worden, weet het programma niet eens dat SOAP bestaat. Maar zij richten zich momenteel wel voornamelijk op de aan te roepen code en niet zozeer op de aanroepende code.

Gaan we wèl expliciet gebruik maken van SOAP, dan zijn de problemen eenvoudig te voorspellen. Ten eerste zullen de programmeurs uiteindelijk code moeten toevoegen om de verschillende SOAP- en WSDL-implementaties (die er nu al zijn) af te handelen. Ten tweede gaan we uiteindelijk over op SOAP versie 1.2 en dan versie 2, en telkens moet de programmeur zijn code weer aanpassen (voor de techneuten: SOAP 1.2 is niet upward compatible met 1.1). Masochistisch aangelegde programmeurs zullen dit als plezierig ervaren, maar zo hoort het niet te gaan.

Dus leveranciers van ontwikkeltools, hou maar op met het implementeren van functionaliteit waarmee programmeurs eenvoudig SOAP kunnen coderen. SOAP is niet bedoeld voor programmeurs, maar voor middleware-leveranciers. SOAP, UDDI, WSDL en webservices zijn allemaal baanbrekende ideeën, maar het gebruik ervan hoort voor de programmeurs afgeschermd te worden. Vergeet niet, het zijn middleware-standaarden en middleware hoort de programmeur niet te zien.