Het artikel van Marcel Noordzij heeft een fascinerende titel: "Webservices, het paard van Troje?". De valkuilen die de schrijver ziet, zijn echter geen specifieke webservice eigenschappen. Webservices hebben hun kuren, maar inconsistentie van transacties is zo oud als de weg naar Rome. Het paard blijkt een hoax.
Er doen veel verschillende omschrijvingen van web services de ronde. Laten we er in ieder geval een gebruiken die wordt ondersteund door de bedenkers van de standaard zelf, zoals OASIS en het W3C. De volgende definitie is bedacht door de W3C Web Services Architecture Working Group die deel uit maakt van de W3C Web Services Activity.
Een webservice is een software toepassing die communicatie over een netwerk met andere systemen ondersteunt. De interface van deze toepassing wordt beschreven in het formaat WSDL (Web Service Description Language). Andere systemen communiceren met de toepassing via SOAP (Simple Object Access Protocol) berichten, op basis van XML.
Uit deze omschrijving volgt dat het unieke van een webservice alleen het communicatiemiddel is, dat op het heen en weer sturen van berichten is gebaseerd. De webservice standaards zijn weliswaar nieuw, maar de aanpak niet. CORBA (Common Object Request Broker Architecture) en JMS (Java Message Service) zijn naar hetzelfde principe gemodelleerd. Je zou ook alle transacties van een systeem kunnen afhandelen via e-mail, dat werkt eigenlijk hetzelfde.
Inconsistentie is dan ook eigenlijk geen probleem van het gebruik van webservices. Het is een fenomeen dat kan optreden bij alle vormen van 'message based' communicatie waar transacties uit volgen. De oorzaak hiervan is niet inherent aan de techniek, maar een risico van het gekozen business model.
Criticasters van webservices hebben het bijvoorbeeld vaak over het probleem van een gecombineerde webservice-reservering van vliegtuig, hotel en huurauto. Er is dan een gevaar voor discrepantie als een van de deeltransacties niet doorgaat. Dat klopt, maar webservices hebben hier niets mee te maken; de aanpak van de touroperator des te meer.
Touroperators worden business process orchestrators genoemd. Dit soort organisaties leveren wel een eindproduct, maar produceren zelf feitelijk niets; ze knopen alleen de juiste diensten aan elkaar. Het risico van inconsistentie is dus onderdeel van het unique selling point van de touroperator. Het is deel van zijn werk.
Of de touroperator nu webservices gebruikt of niet, de kans op inconsistentie blijft. Als de touroperator vroeger gewoon belde met de vliegtuigmaatschappij, het hotel en de autoverhuurder, was een annulering even ingrijpend. Het is dus niet het middel, maar de business die risicovol is.
De touroperator moet er natuurlijk wel voor zorgen dat hij zijn zaakjes voor elkaar heeft. Webservices bieden de mogelijkheid tot het maken van afspraken met zijn partners.
Uitgebreide procesbeschrijvingen zijn waardeloos op het moment dat het aantal mogelijke gebeurtenissen, wijzigingen en partners snel toeneemt. Een lichtgewicht contractmodel is beter. Een webservice levert zo'n model door een WSDL beschrijving.
Een contract kan bijvoorbeeld voorschrijven dat iedere dienst moet bestaan uit drie subservices:
Door brede ondersteuning van alle grote software producenten bieden webservices juist veel meer mogelijkheden om inconsistentie te voorkomen dan eerdere "messaging" methoden.
Een integratielaag kan bijvoorbeeld de coördinatie van diensten regelen. Standaards zoals BPEL4WS (Business Process Execution Language for Web Services), Microsoft's XLANG en IBM's WSFL (Web Services Flow Language) zijn het workflow gereedschap van slimme orchestrators. "Two-phase commit" voor atomaire transacties en "compensating actions" (het achteraf terugdraaien van de transactie, geen SMS naar de beheerder) zijn veelgebruikte toepassingen.
Er is ook nog de toekomst. BEEP (Blocks Extensible Exchange Protocol) levert aantal nieuwe standaards voor "connection management". XML Digital Signatures en WSS (Web Service Security) bewaken de data integriteit van lopende transacties.
Natuurlijk kan het nog steeds mis gaan. Wanneer een willekeurige berichtenservice wordt gebruikt voor het aanzwengelen van deeltransacties, behoort een afgebroken transactie per definitie tot de mogelijkheden. Een oplossing voor inconsistentie moet dus niet gezocht worden in het middel waarmee de berichten worden verstuurd.
De afspraken die in het business model tussen partners worden gemaakt, bepalen wat er gebeurt bij een afgebroken transactie. Als hier geen rekening mee wordt gehouden, is het gebruik van welke messaging service dan ook vragen om problemen.
Webservices bieden meer mogelijkheden dan ooit om transacties netjes af te handelen, ook tussen verschillende partijen. Laten we dus niet de webservices de schuld gaan geven en het paard achter de wagen spannen.
Sander Nagtegaal