Geen webservices zonder interface

"Webservices zullen onze klassieke vorm van bedrijfsvoering voor altijd veranderen! De markt zal op zijn grondvesten trillen!" "Webservices vereisen een geheel nieuw paradigma voor software-ontwikkeling!" "Webservices zijn de bouwstenen voor collaborative e-commerce!" De voorspellingen over de impact die webservices zullen hebben, overtreffen elkaar.

Toch staan we nog maar aan het begin. Toegegeven, de standaarden zoals UDDI, SOAP en WSDL zijn al enkele maanden gereed. Maar de producten om ze in te zetten, zijn nog jong. Pas recentelijk zijn er ontwikkelproducten beschikbaar gekomen om webservices te bouwen. Maar het feit dat we producten hebben om webservices te bouwen, impliceert nog niet dat we weten hoe we ze moeten ontwerpen. Dit ontwerpen van webservices - en dan voornamelijk het ontwerpen van hun interfaces - is nog een braakliggend terrein en er zal nog veel studie naar verricht moeten worden.

Of het nu een component is, een ouderwetse transactie of moderne webservice, we dienen altijd na te denken over die interface. Welke parameters gaan er in en welke komen er uit? Omdat er al veel software beschikbaar is, zullen leveranciers producten ontwikkelen waarmee we kunnen 'wrappen'. Er wordt dan een laagje software om het oude stukje code gelegd, waarna we dan de oude code via moderne protocollen als SOAP kunnen aanroepen. Vanuit een productiviteitsstandpunt is dat een goed idee. Het staat ons toe om snel webservices te ontwikkelen. Deze aanpak wordt wel de 'inside-out' aanpak genoemd. Een bestaande interface van een intern stuk code, wordt dan voor externe applicaties toegankelijk gemaakt .

We zullen dit met een simpel voorbeeld illustreren. Stel dat er een stuk code geschreven is, waarmee we alle gegevens van een order kunnen opvragen. Deze code is opgebroken in drie functies: geef-order, geef-eerste-orderregel en geef-volgende-orderregel. U kunt zich wel voorstellen wat de respectievelijke parameters zijn. 

Met deze inside-out benadering zullen er drie webservices ontstaan met nagenoeg dezelfde verzameling parameters als de onderliggende functies. Waarschijnlijk worden er enkele parameters toegevoegd ten behoeve van transacties en beveiliging. Maar de parameter-opzet zal gehandhaafd blijven en zo ook de wijze van aanroepen: eerst dient 'geef-order' aangeroepen te worden, dan 'geef-eerste-orderregel' en vervolgens enkele malen 'geef-eerste-orderregel.' 

Het grootste nadeel van deze aanpak is dat we een zeer strakke koppeling creëren tussen de externe applicaties en onze originele drie functies. Wijzigingen in onze functies zullen erg lastig door te voeren zijn, omdat dan applicaties, waarvan wij niet de eigenaar zijn, ook aangepast dienen te worden. Ook vanuit een netwerkstandpunt is deze interface niet optimaal. Het effect is een-te-hoge frequentie van kleine aanroepen. Om alle gegevens van één order op te halen, wordt ons systeem niet één maar twee, of waarschijnlijk meerdere keren aangeroepen.

Voor vele systemen zal daarom voor de 'outside-in' benadering gekozen worden. Hier wordt dan opnieuw nagedacht over de gewenste interface van de webservice. De bestaande interface wordt dan niet gezien als het uitgangspunt. Ter illustratie nemen we weer hetzelfde voorbeeld. Bij de outside-in methode zal er slechts één webservice met één uitgaande parameter (de opgevraagde order) gecreëerd worden. Vanuit een netwerkperspectief zal dit beter zijn. De aanroepende applicatie is met één aanroep gereed. Het ordernummer wordt opgegeven en de gehele order komt terug. In en uit, klaar!

Deze order zal ongetwijfeld in de vorm van een XML-document doorgegeven worden. Dit XML-document wordt opgenomen binnen een SOAP-bericht. Het cruciale verschil tussen de interfaces van componenten en die van webservices is dat we bij de eerste simpele objecten en waarden versturen, en bij de tweede gehele documenten.

Dit uitdenken van de perfecte interface zal uitermate belangrijk zijn voor het succes van webservices. Hopelijk zullen we in staat zijn om hier op korte termijn richtlijnen voor te geven. Zoals zo vaak is het niet alleen technologie, maar ook een kwestie van de gebruikswijze, die het succes gaat bepalen.