Web Services, een trektocht in de bergen

Naar aanleiding van de reacties op het eerdere artikel dat de invoering van Web Services niet zonder problemen hoeft te zijn is dit artikel verschenen. Het gaat in op de reacties en geeft een nog breder scala aan mogelijke probleemgebieden en hoe deze conform het boeken van een reis te omzeilen of te overwinnen zijn.



De reacties die het artikel "Webservices, het paard van Troje?" heeft losgemaakt is exact wat ik gehoopt had. Het was zeker niet de bedoeling om Webservices als iets negatiefs af te spiegelen, het artikel was bedoeld om het bewustwordingsproces op gang te brengen en zo het begrip voor de valkuilen die de hype rond Webservices met zich meebrengt naar een meer realistisch niveau te tillen. De teneur in de reacties is dat Webservices gebruiken inderdaad niet zonder problemen is, maar dat het geschetste probleem van ‘restinconsistentie’ niet iets nieuws en specifiek voor Webservices is. Wat een juiste constatering is. Maar verblindt door de mogelijkheden van Webservices worden dit soort abc-tjes snel over het hoofd gezien.



Waarschuwen is goed, doen is beter


Een aantal opmerkingen die worden geplaatst refereren aan het feit dat de ‘restinconsistentie’ niet het enige probleem is. Prettig is er de reactie van Paul Ostendorf die constateert dat het wellicht maar goed is dat niet alle problemen die het invoeren van een nieuwe techniek met zich meebrengt op voorhand bekend zijn. Het zou er weleens toe kunnen leiden dat we gaan zitten navelstaren en die stilstand is achteruitgang. Dit neemt niet weg dat het goed is om op voorhand een deel van de problemen die men tegen kan komen bij het introduceren van Webservices scherp op het netvlies te hebben. Hierdoor kan men hiermee rekening houden bij het opzetten van de architectuur en applicaties die gebruik maken van Webservices. Niet alles is mogelijk, een aantal dingen zijn erg duur en sommige dingen zijn zelfs onmogelijk. Of kunnen beter anders gedaan worden. Oneigenlijk toepassen is ook bij Webservices uit den boze. Dit is de reden dat ik het boek "Webservices, een avontuur voor managers" heeft geschreven. Daarin worden ook de op voorhand bekende uitdagingen die de implementatie van Webservices met zich meebrengt onder het voetlicht gebracht, om zodoende de invoering een beheersbaar proces te maken.
Het moet dan ook snel duidelijk worden wat de prijs is van een transactie, de all-in prijs dan wel te verstaan, zodat alle kosten die gemaakt moeten worden meegewogen worden. Naar bijna-nul inconstistentie is dan vaak erg duur, en het wordt een overleg met de business, de partners en de ICT om te bekijken wat zinvol is voor welk bedrag. Het doel is geen perfect systeem (met nul inconsistentie), maar een goed genoeg werkend systeem, met daarin bekende en acceptabele restproblemen.



Op reis


De implementatie van Webservices kan best vergeleken worden met het boeken van een vakantie. Er zijn verschillende keuzes die gemaakt worden bij de selectie van de reis, die deels plaatsvinden als een emotioneel proces en deels gestuurd worden door marketing van het aanbod. Hiermee vallen de opmerkingen van Mark Govers en Marc Lankhorst vallen direct ophun plaats. Afhankelijk van de wensen en behoeftes wordt de reis gekozen. Is de wens een rugzaktocht door de bergen, dan is de kans op onverwachte uitdagingen groter. In feite is dit een implementatie van Webservices waarbij pragmatiek een grote rol zal spelen. Gewoon beginnen en zien waar het schip strand. Veelal de gekozen aanpak door de innovatoren die hun keuze laten leiden door de hype en de eerste willen zijn met het nieuwe speeltje. Voor de consultant een dankbare klant waarbij veel geleerd en ervaren kan worden. Er wordt ook veel geld in verstookt. Het geleerde kan vertaald worden naar een meer gestructureerde reis, de georganiseerde reis door Indonesië. De reisleider zorgt voor ervoor dat de meeste problemen op voorhand bekend zijn en omzeild kunnen worden. De reizigers worden voor een groot deel aan het handje meegenomen, maar er is voldoende vrijheid om zelf dingen te ervaren. Dit is de implementatievorm van Webservices die na de innovatieveperiode zijn intrede doet, het punt waar we nu aangekomen zijn, eigenlijk. Binnenkort zal daarbij de laatste reis uit het gamma worden toegevoegd, de ‘all-in’ vakantie. Er zijn dan voldoende Webservices beschikbaar en ze kunnen gezien worden als commodity. Uitstapjes kunnen, maar de uitdaging is er grotendeels af.



De bagage


Een korte recapitulatie van de reacties leert dat er toch al snel een viertal mogelijke problemen zijn bij de introductie van Webservices.
De reeds een aantal keer gememoreerde restinconsistentie die bij complexere transacties over meerdere schijven met deels gelukte acties ertoe kunnen leiden dat bij de diverse spelers in het proces een niet geheel consistent databeeld is. Dit omdat de transacties of deeltransacties niet zijn of niet kunnen worden teruggedraaid. Of dat nu ongewenst of inconsistent wordt genoemd maakt niet, er moet rekening mee gehouden worden.
Een tweede is in feite een oplossing voor het eerder geschetste probleem, nieuwe opkomende standaarden binnen Webservices. Deze maken het mogelijk om op een gestandaardiseerde manier processen en compenserende acties tot een geheel te smeden. Jammer is alleen dat het een nieuwe uitdaging introduceert, er zijn immers een aantal voorstellen die elk het probleem kunnen oplossen. Pas als er één standaard overblijft is er sprake van een succesvolle oplossing van het probleem. Tot dat moment zijn het nog bilateraaltjes tussen de betrokken partijen, single vendor oplossingen en ook deels mooie beloften die jou vandaag niet zullen helpen.
Een voor de hand liggende, maar door de hype van het moment over het hoofd geziene valkuil is het toepassen om toe te passen. Hip zijn heeft zijn prijs en moet alleen daar plaatsvinden waar het ook daadwerkelijk nuttig is. In het geval van Webservices is dit de loosely coupled integratie van systemen. Ieder systeem kan op zichzelf werken en de beschikbaarheid is niet afhankelijk van de omliggende systemen. Mocht er restinconsistentie ontstaan dan is dat een voorzien probleem waar geen van de partijen direct een functioneel probleem mee hoeft te hebben. Dat geautomiseerd of handmatig oplossen is een optie, het detecteren is een must, die additionele functionaliteit vereist.
Als afsluiter het meest belangrijke probleem, het ontbreken van voldoende afspraken. Het hebben van een Webservices afspraak is niet voldoende. Dit is puur de communicatie afdichten. Nee, belangrijk is dat de inhoud, de gegevens die met de Webservice worden uitgewisseld gestandaardiseerd worden. De uit de XML wereld herkenbare initiatieven moeten zorgen voor een standaardisatie van berichtinhoud. Denk bijvoorbeeld aan standaarden als XBRL (financiële rapportage) en HR-XML (human resource proces automatisering). Tot dat moment geldt dat alleen in de bekende omgeving Webservices toegepast worden. Wat op zich niet erg is, want vertrouwen is de basis van alles en zomaar een dienst aanbieden of gebruiken van een onbekende is niet iets wat snel zal gebeuren.
Dit alles vormt een niet te onderschatten bagage voor de reizigers die van plan zijn Webservices toe te gaan passen. Bagage om over na te denken vooral, want je kunt alles wel meetorsen, maar je moet wel goed weten waarom het mee moet.



Een laatste tip, aarzel niet, maar pak de koffers en ga op reis…



Marcel Noordzij & Mark Hoogenboom