Webservices nog niet klaar voor transacties

Wie kent niet het begrip transactie? Alle veranderingen die binnen een transactie uitgevoerd worden, dienen alle definitief gemaakt of volledig teruggedraaid te worden. We staan niet toe dat de helft van ons werk wel bewaard wordt en dat de andere verloren gaat. Of we nu over een ouderwetse CICS-omgeving, een klassieke SQL-databaseserver of een moderne EJB-implementatie praten - de problemen, concepten en oplossingen zijn identiek. Deze bekende transactieconcepten zijn echter niet toereikend in een omgeving waar webservices met elkaar communiceren.

Informeel gesteld is een webservice een stuk code dat we via protocollen als SOAP over het Internet kunnen aanroepen. Het kan een versleten stuk COBOL-code zijn of een moderne Java- of Visualbasic-component. Met webservices kunnen we informatiesystemen over onze organisatiegrenzen heen integreren. Laten we eens een voorbeeld geven.

Veronderstel dat we bij de website van een reisbureau vluchten, hotelkamers en huurauto's kunnen boeken. Om dit te realiseren praat deze website met die van een vliegtuigmaatschappij, een hotelketen en een autoverhuurbedrijf. Hiervoor worden webservices van deze drie bedrijven aangeroepen. De bezoeker van de website merkt dat allemaal echter niet - alle communicatie vindt achter de schermen plaats. Voor de bezoeker lijkt het alsof het één website is, waar hij alles boekt.

Ongetwijfeld stelt de bezoeker wel de voorwaarde dat als zijn vakantie definitief geboekt wordt, alle drie de individuele boekingen succesvol uitgevoerd worden of alle drie niet. Het zou vervelend zijn als hij na een lange vlucht in een vreemde stad aankomt en er geen hotelboeking blijkt te zijn. Of andersom, er staat een heerlijk luxueuze hotelkamer op hem te wachten, hij kan het bubbelbad al bijna ruiken, maar er blijkt geen plaats voor hem in het vliegtuig geboekt te zijn. 

Het feit dat alle drie transacties samen geboekt worden, kunnen we toch afdwingen door de drie webservices onder de controle te plaatsen van een transactiemonitor als EJB of CICS, zult u nu denken? Een softwarematige transactiemonitor zal dit bijvoorbeeld met het two-phase commit mechamisme afdwingen. Zoiets betekent dat, na de selectie van de drie boekingen, de transactiemonitor eerst aan alle drie de webservices vraagt of ze klaar zijn om die boekingen definitief door te voeren (fase 1). Zo ja, dan wordt de opdracht gegeven de boekingen succesvol af te sluiten (fase 2). Ontvangt hij niet van alle drie een positief antwoord, dan breekt hij de gehele transactie af, en worden daarmee alle voorlopige boekingen verwijderd.

Dit is de vertrouwde manier om transacties op basis van meerdere bronnen - in dit geval webservices - te beheren. De vraag is echter of deze wel gepast is voor webservices. We geven enkele voorbeelden waarbij deze aanpak niet zo geschikt is. 

Zolang fase 2 nog niet is aangebroken, heeft de transactiemonitor wel een 'lock' uitstaan op een onderdeel van de webservice. Dat wil zeggen dat de transactiemonitor van het ene bedrijf gegevens vasthoudt die eigendom zijn van het andere bedrijf - bijvoorbeeld stoelen op een vlucht. De laatste zal daar niet blij mee zijn. Stel dat de derde webservice zeer laat reageert, dan staat ondertussen de eerste webservice lang te wachten. Dit kan de beschikbaarheid van de eerste webservice danig verstoren.

Een ander potentieel probleem ontstaat wanneer de webservice gebouwd is op een oude applicatie, die niet eens via two-phase commit aangestuurd kan worden. Als er dan tussen fasen 1 en 2 iets fout gaat, kan de zaak niet simpelweg teruggedraaid worden. Er moet dan een zogenaamde compensating-transactie ontwikkeld worden, die al het uitgevoerde werk heeft onthouden en kan terugdraaien. De transactiemonitor dient dan wel te weten dat er een dergelijke transactie is en dat deze gestart moet worden.

Het is mogelijk dat een webservice pakweg drie dagen nodig heeft, vooraleer een antwoord te geven. Niet omdat de software zo langzaam is, maar bijvoorbeeld omdat de software aan een menselijke tussenpersoon een antwoord moet vragen. De transactie heeft dan een looptijd van enkele dagen. Wat gebeurt er dan als de transactiemonitor in die periode uitvalt? In een normale situatie wordt de gehele transactie afgebroken. Transactiemonitors dienen dus met zogenaamde langlopende transacties overweg te kunnen.

En zo zijn er meer voorbeelden te bedenken waarbij de klassieke concepten van transactiebeheer niet meer toereikend zijn voor een omgeving met webservices. Kortom, het feit dat transactiemonitor de klassieke transactieconcepten ondersteunt, wil nog niet zeggen dat hij klaar is voor het beheren van transacties over een webservice. Er wordt gelukkig gewerkt aan een nieuwe verzameling concepten die wel bij deze nieuwe wereld passen. De resultaten hiervan zullen terechtkomen in de zogenaamde BTP-standaard (Business Transactions Protocol), waaraan de Oasis-organisatie werkt. Hopelijk is deze standaard snel klaar en volgen de implementaties op korte termijn, want deze zijn onontbeerlijk om in de toekomst serieuze, transactie-georiënteerde webservices te bouwen.