Web Services, paard van Troje

Dit artikel gaat in op de problematiek die een blinde invoering van Web Services met zich mee kan brengen. Denk goed na voordat u begint om problemen in de toekomst te voorkomen.



Webservices zijn een fantastische uitvinding en ze gaan beslist de wereld veroveren. In december vorig jaar beschreef George Lawrie in TechStrategy van Forrester zo acht stevige winstpunten als we webservices gaan gebruiken. Mooi. En het is waar ook nog wat wordt gezegd, maar in de praktijk krijg je met het invoeren van webservices er gratis een probleem bij. Je doet niks spannends, je wilt gewoon wat moderne technologie toepassen, denkt dat je slim bezig bent en hup, toch een nieuw probleem. Want als je niet goed oplet, dan lijkt het toepassen van webservices op het binnenhalen van het paard van Troje, want dat zag er ook erg aantrekkelijk uit, maar had een bedenkelijke vulling.



Het probleem in het webservices werkpaard gaat over het niet goed af kunnen handelen van afgebroken transacties. Zonder een adequaat en goed doordacht ontwerp van de webservices transactieomgeving zal dat veel onverwacht ongemak op gaan leveren. Er is wel wat aan te doen, maar ongemak gaat het geven, want webservices toepassen betekent dat er restinconsistentie in gegevensverzamelingen komt te zitten en ook dat er een niet te omzeilen window of non-integrity in transacties verscholen zit. Eigenlijk is er dus niet zoveel aan te doen, terwijl het ook absoluut duidelijk is dat de wereld richting het grootschalig gebruik van webservices koerst. Dat is prima, want er is veel winst te halen, maar opletten is noodzakelijk. Want vanwege de restinconsistentie leveren webservices vanzelf oplossingen die, als je niet goed oplet, gegevensverzamelingen belasten met inconsistentie waar je als bedrijf behoorlijk mee in de problemen kunt komen. Terwijl je als bedrijf helemaal niet van plan was nieuwerwetse dingen te doen en ook helemaal niets aan het bedrijfsproces hebt veranderd, toch moet er zeer stevig nagedacht worden bij het introduceren van webservices. Anders kun je wel eens wakker worden in Troje.



Restinconsistentie door webservices levert handmatig werk op, in plaats van dat automatisering het weg neemt


Voor bedrijven die vrolijk de webservices toer opgaan en alle mooie verhalen uit de leveranciershoek voor zoete koek aannemen, wordt het een somber verhaal. Want transacties die op webservices gebaseerd zijn hebben één heel belangrijke eigenschap, die er niet uit te slaan is al heet je Mike Tyson. Het gaat om het probleem dat een hele serie webservices in één transactie best wel eens mis kan lopen en totaan de vastgelopen webservice zijn er een stel ten onrechte uitgevoerd. Die zijn niet zomaar terug te draaien. Voorbeeld: de transactie bestaat uit vijf webservices en nummer vier in die serie doet het niet. Transactie stuk, en webservices een tot en met drie zijn goed verlopen maar inmiddels ongeldig. Terugdraaien kan niet zomaar, want die drie webservices zijn goed verlopen, dus hun resultaten kunnen door anderen al gebruikt zijn. Er zal dus iemand moeten gaan rondschreeuwen dat het niet gelukt is, waarbij alle middelen zijn toegestaan: soap, mail, sms, telefoon, televisie, satelliet…



Two-phase commit binnen webservices is kostbaar en maar zeer beperkt toepasbaar


Omdat terugdraaien van goed uitgevoerde webservices niet zomaar kan, zijn de compensating actions bedacht, die ervoor zorgen dat goed verlopen webservices die achteraf toch niet uitgevoerd hadden moeten worden kunnen worden rechtgezet. Soms helemaal, soms deels, soms helemaal niet. Juist deze onzekerheid over hoe de inconsistentie opgelost kan worden maakt hem zo hinderlijk. Want als je niets doet valt het soms toch erg mee. Zo zal een transactie die een hele serie webservices gebruikt, maar pas de laatste in de rij betekent een juridisch bindende overeenkomst, weinig schade opleveren als deze transactie fout loopt en inconsistentie blijft bestaan. Hooguit levert het vervuiling op die periodiek kan worden opgeruimd. Maar een transactie die uit drie delen bestaat die allemaal onder de verantwoordelijkheid van één transactie worden ingezet, zoals het boeken van een reis met daarin auto, ticket en hotel, zal bij de consument pas betalend gedrag opleveren als ie alles krijgt wat ie heeft besteld. Alleen de auto en het hotel goed regelen is echt niet voldoende. Voor de reisoperator die deze transactie uitvoerde zijn de bestellingen van de auto en het hotel natuurlijk wel al gemaakt. Als je dan niets doet, kost het je een bom geld en allerlei kosten maken zonder dat er een betalende consument tegenover staat is zelfs in de meest creatieve boekhouding niet goed weg te werken.



In normale applicaties worden de ontwikkelkosten bepaald door de functionaliteit die je nodig hebt. In oplossingen die op webservices gebaseerd zijn kun je veel besparen op het bouwen van die functionaliteit (want je kunt het kopen of hergebruiken) maar worden de ontwikkelkosten voor een fors deel bepaald door de integriteit die als bedrijf wilt hebben in de gegevensverzamelingen die onderhouden worden door die webservices. Een ongemakkelijk uitgangspunt is daarbij dat 100% integriteit niet haalbaar en niet betaalbaar is, dus dat moet je dan ook niet willen. Dat we steengoede webservices oplossingen kunnen bouwen is wel duidelijk en dat is ook zeker geen sprookje. De ICT wereld gaat gewoon fors gebruik maken van webservices en dat is prima. Dat in die oplossingen iets werkbaars en betaalbaars bedacht moet worden voor de onoverkomelijke integriteitsproblemen is niet iets waar je de techneuten snel over zult horen waarschuwen. Integendeel, ze beweren juist graag dat het probleem vanzelf opgelost is met de volgende versie van een of ander hulpmiddel. Leveranciers van die webservices hulpmiddelen waarschuwen al helemaal niet, want die beweren, terecht overigens, dat als je nu alleen maar hún hulpmiddeltjes gebruikt, het allemaal wel goed komt. Dat single-vendor medicijn is kwakzalven, want ieder hoofd IT snapt natuurlijk direct dat zodra een transactie bedacht wordt waar een deel van de webservices van elders komt (gekocht, een partner, een speler in de keten ergens), het helemaal niet meer vooraf te garanderen is dat ze allemaal van een en dezelfde leverancier zullen zijn. Juist de multi-vendor eigenschappen van webservices oplossingen zijn het meeste waard, bieden het meeste flexibiliteit en wekken tegelijk het duidelijkst het integriteits- en inconsistentieprobleem op.



Als we niet opletten, zijn we over vijf jaar alleen maar bezig met het oplossen van het "webservices-probleem"


Gelukkig is de markt langzamerhand een vraagmarkt geworden en is de technology push wat naar de achtergrond verdrongen. Tenminste, voor de lagere technologische doorbraken. Niet voor zaken zoals de webservice evolutie, die niet alleen het IT-landschap volledig zal veranderen maar vooral het business landschap, de wijze waarop organisaties met elkaar zaken kunnen gaan doen en de nieuwe organisatorische verschijningsvormen die dit teweeg zal brengen. Een belangrijke technologische ontwikkeling met belangwekkende bedrijfsmatige verwachtingen, dus. Stiekem natuurlijk toch wel technology push, en daar schuilt een deel van het gevaar. Niet hetzelfde als Y2K, ook beslist met een andere achtergrond dan €, maar met misschien nog wel verstrekkender consequenties. Stel dat we in een situatie terecht komen waarin de 100% integriteit al jaren als uitgangspunt is genomen, maar waar her en der wat hikjes in zijn geweest. Want zeker in de aanloop zal het niet zo’n vaart lopen, die omvallende webservices - trouwens naar alle waarschijnlijkheid met als grootste oorzaak telecombedrijven die per ongeluk bij het graven een lijntje doorknippen, of ISP’s die net even na een patch een aantal poorten niet meer hebben opengezet, of een energiebedrijf die een half dorp in het donker zet, waar precies die ene machine staat die de derde service in een rij van vijf aan het verwerken is… Afijn, zo’n situatie, dus, waarvan men op een gegeven moment het gevoel krijgt dat er iets te wachten staat, met ondertussen enkele tienduizenden organisaties die wereldwijd via webservices in een transactioneel netwerk met elkaar samenwerken en nog enkele tienduizenden in de startblokken. Een soort schaduw net achter de horizon, waarvan niet bekend is wanneer die over de wereld zal vallen - in tegenstelling tot een soortgelijke schaduw rond W2K en €. Zo’n situatie, dus, veroorzaakt door hoge technology push, technologie bedrijven die de oplossing hadden bedacht, die het toch niet is, hebben dan voor jaren stopwerk gezorgd om al die transacties maar zo goed mogelijk in de lucht te houden. Misschien wel een gouden markt voor uitzendbureaus, die specifieke webservices Failure Contact Centers op kunnen zetten om alle misgegane transacties te melden, verhelpen, op te vangen en dergelijke.



een goede webservices oplossing heeft een bekende restinconsitentie - en die is niet nul


Het probleem van restinconsistentie en windows of non-integrity lossen zich niet vanzelf op. Zodra organisaties in ketens gaan werken, of diensten uitbesteden of inkopen, ligt het voor de hand daarvoor webservices te gebruiken. Die zijn daar juist voor bedoeld en zeker geschikt voor. Dan wordt het ook belangrijk vooraf te ontwerpen hoe met inconsistentie en non-integriteit wordt omgegaan, want dan is het probleem hanteerbaar en blijft de oplossing betaalbaar. Zonder een ontwerp van compensatie bij foutgelopen transacties, wordt het webservices verhaal erg treurig. Want geen enkel hulpmiddel voorkomt het optreden van het probleem en daarom verdient het aandacht. Bij de top van de IT afdeling, bij de architect, bij de ontwerpers en bij de ontwikkelaars.



Begrippen


Transacties: Hiermee wordt in dit kader een business transactie bedoeld, geen database (ACID) transactie.
Restinconsistentie: De "fouten" die overblijven nadat een transactie onverwacht is afgebroken
Window of non-integrity: De tijd die verstrijkt tussen het uitvoeren van de eerste en de laatste webservice in een transactie, eventueel uitgebreid met de tijd die nodig is voor herstelwerkzaamheden in het geval van een onverwacht einde van een transactie
Two-phase commit: Manier waarop twee verschillende systemen samen toch een transactie kunnen doen die terug te draaien is (ACID) omdat beide systemen overeenkomen om de gegevens van de transactie pas "officieel" beschikbaar te stellen indien de volledige transactie slaagt.
Compensating actions: Activiteiten die uitgevoerd worden door de transactiecoordinator indien een van de stappen mislukt. Dit kan uiteenlopen van het bijwerken van de database tot een sms "HELP!" naar de beheerder.
ACID transactie: Acronym, betekent dat een transactie als geheel slaagt of faalt (Atomair) De database in een consistente staat achterlaat (Consistent), De gegevens pas aan andere processen zichtbaar maakt als de transactie afgelopen is (Isolatie) en dat de gegevens bewijsbaar niet meer verloren gaan na een transactie (Durability)



Uitleg webservices


Laten we beginnen met de uitgebreide definitie van een Web Service.
"Een Web Service is een software component die een bedrijfsfunctie implementeert en op een standaard manier toegankelijk is gemaakt voor andere applicaties, medewerkers, leveranciers en partners gebruikmakend van standaarden."
Voordat we dieper in deze definitie duiken, is een simpel voorbeeld wellicht op zijn plaats. Denk bijvoorbeeld aan de in Nederland befaamde kroketten uit de muur. In overdrachtelijke zin is dit een Web Service. Het is immers een dienst die op een standaard wijze (een glazen deurtje) toegankelijk is. Er is zelfs rekening gehouden met betaling voor de dienst, die vaak ook gestandaardiseerd is door één standaardtarief voor alle ‘diensten’ (kroketten, frikadellen, enzovoorts) te kiezen. Het gebruik is daarnaast erg simpel en eenduidig, wat het leven voor de afnemer eenvoudig maakt.
Terug naar de definitie dan zien we dat een Web Service een software component is. Het gaat bij Web Services dus niet om fysieke zaken, maar om diensten die softwarematig te regelen zijn. Het eindresultaat van deze softwarematige acties kan wel iets fysieks zijn. Denk bijvoorbeeld aan een organisatie die via een stuk software, al dan niet een Web Service, het bezorgen van de bestelde goederen regelt. Het eindresultaat van iets dat begint met een softwarematige order is een fysiek pakje. In de definitie is ook sprake van een bedrijfsfunctie. Technisch gezien is dit geen eis, maar iets als Web Service aanbieden om het aan te bieden levert geen voordelen op. Zo is het automatisch kunnen afhandelen van het bezorgproces een bedrijfsfunctie die alle betrokken partijen voordelen biedt.



Benadering industrie en de werkelijke vraag


Waar leveranciers steeds verdere stappen maken op het leveren van tools die bijvoorbeeld zorgen voor fout tolerantie, specialistische routing gebaseerd op workloads in een webservices Management oplossing, verregaande integratie van Web Service Management oplossingen met Network en Systems Management oplossingen, standaardisatie op velerlei vlak en dergelijke, gaat het uiteindelijk om zaken als: klopt mijn voorraadstand wel? Is mijn order nu wel goed verwerkt?
Een eigenschap is het, die restinconsistentie, wat betekent dat datasets nooit 100% consistent zullen zijn. Daar kun je dus maar beter van te voren bij het ontwerp goed over nadenken, in plaats van hopen dat het straks in de praktijk wel meevalt of valt af te dekken met hulpmiddeltjes. Er is gewoon geen duizenddingendoekje dat voorkomt dat inconsistentie optreedt en iedereen die het tegendeel beweert heeft niet goed nagedacht of de webservices oplossing zo klein gedefinieerd dat het single vendor en single platform geworden is. En juist aan dat soort oplossingen hebben we niet zoveel in de praktijk. Overigens, multi-vendor en multi-platform is juist een van de beloftes die webservices in zich hebben, dus dat op voorhand maar vast weggeven is niet verstandig.
Het is echter niet eenvoudig om een fraai uitziende oplossing, gebaseerd om de modernste webservices hulpmiddelen, te verkopen aan een opdrachtgever als je erbij moet vertellen dat ongeveer 2% van de gegevens niet zal kloppen. En als je niets doet aan die twee procent, dan wordt het elke dag een beetje meer. Het wordt extra moeilijk als je erbij moet vertellen dat het eigenlijk niet goed mogelijk is om het beter te maken dan die 98%, gezien het budget dat beschikbaar is gesteld voor het project.
Het kan echter nog erger. Indien het probleem wordt overgelaten aan techneuten gaat een behoorlijk percentage proberen het op te lossen - wat niet kan. In het werkelijk allerergste geval wordt zelfs gedacht dat het gelukt is met de zelf gewrochte oplossing of de allernieuwste versie van leverancier X.



Wat doe je aan het probleem


Het gaat bij het aanpakken van het probleem om een prijs-prestatieverhouding, waarbij 100% perfect geen zinvol doel is. Hoge consistentie garanderen in een transactieomgeving gebaseerd op webservices (meer dan 99%) is onvoorstelbaar kostbaar. Tijdens het ontwerp het niveau van acceptabele consistentie bepalen is daarom nodig: wat kost het ons om een bepaalde consistentie vanzelf - geautomatiseerd - te halen door dit in te bouwen in de oplossing en wat kost het ons een lager niveau te accepteren en de problemen die daaruit voortkomen periodiek te fiksen. Oftewel, betalen we vooraf voor een garantie of achteraf om ongewenst ongemak weg te poetsen
Er zijn kortweg vier routes voor de oplossing, hier weergegeven in een diagram.