Transaktionen sind schon seit den 80er Jahren integraler Bestandteil informationsverarbeitender Systeme. Die klassischen ACID-Transaktionseigenschaften (ACID = Atomicity, Consistency, Isolation und Durability) lassen sich jedoch nicht eins zu eins auf verteilte Anwendungssysteme im SOA-Umfeld übertragen. Derzeit erforschen Experten Konzepte für Service-orientierte Transaktionen im Umfeld von Web-Services.

Eine Einführung zum Thema Transaktionsverarbeitung finden Sie weiter unten im Text (hier gelangen Sie direkt dorthin).

Der Gedanke liegt nahe, in Web-Service-basierenden Anwendungen auch das Transaktionskonzept zu verwenden. Ursprünglich war bei der Konzeption von Web-Services eine lose Kopplung angestrebt. Dies steht im Widerspruch zur Verwaltung von verteilten Transaktionskontexten. Allerdings dachte man in den letzten Jahren viel über den Einsatz von Transaktionen in Service-orientierten Architekturen nach.

Übergreifende Transaktionen

Man könnte übergreifende Transaktionen vor allem dann brauchen, wenn mehrere Web-Services zur Erreichung eines gemeinsamen Ziels eingesetzt werden sollen, also gemeinsam atomar auszuführen sind. Einige Vorschläge zur Nutzung wurden bereits erarbeitet, allerdings hat sich noch kein Standard in diesem Umfeld herauskristallisiert. Es lässt sich grundsätzlich festhalten, dass in diesen Ansätzen keine neuen Konzepte vorgeschlagen, sondern die bereits bekannten Transaktionsmodelle auf Web-Services angewendet werden. Im Wesentlichen diskutieren Experten zwei Standardisierungs-vorschläge: atomare Transaktionen und langlebige Transaktionen mit einer Aufweichung der klassischen ACID-Eigenschaften.

Ein Glossar der im Text verwendeten Begriffe finden Sie weiter unten (hier gelangen Sie direkt dorthin).

Die Standardisierungsbemühungen verschiedener Unternehmen fließen in der Oasis (Organization for the Advancement of Structured Information Standards) zusammen und sind in den Ansätzen ähnlich. Für Web-Service-Transaktionen existieren heute folgende Spezifikationen, die alle als Grundlage das Koordinator-Teilnehmer-Modell favorisieren:

• WS-Coordination mit den Koordinationstypen WS-Atomic-Transaction und WS-Business-Activity (WS-C, WS-AT und WS-BA),

• Business Transaction Protocol (BTP),

• Web Services Composite Application Framework (WS-CAF).

Bei den klassischen verteilten Transaktionen verwendet man aufgrund fehlender Protokollstandards heute in der Praxis meist nur einen Transaktionskoordinator, der meist über die XA-Schnittstelle mit Transaktionsteilnehmern (Ressourcen-Managern) zum Zwecke der Transaktionskoordination und -terminierung kommuniziert. Web-Services-Umgebungen erschweren die Situation, da die Services von unterschiedlichen Middleware-Herstellern stammen können. Ein gemeinsames 2PC-Protokoll ist zwingend notwendig, damit sich mehrere Web-Service-Provider an einer verteilten Transaktion beteiligen können.

Die Standardisierungsvorschläge berücksichtigen diese Anforderung. Die Lösungsansätze stützen sich auf das Simple Object Access Protocol (Soap). Die einzelnen Ansätze sollen kurz skizziert werden. Wir beginnen mit dem WS-C/AT/BA-Ansatz, der aus heutiger Sicht wohl die besten Aussichten auf eine Weiterentwicklung hat.

WS-C/AT/BA: WS-Coordination stellt im Rahmen eines erweiterbaren Frameworks Basisdienste bereit, die Transaktionskontexte verwalten, Transaktionen aktivieren sowie Teilnehmer registrieren. Die Spezifikation definiert mehrere Dienste eines Koordinators. Dies sind der Activation Service, der Registration Service und mehrere, nicht weiter festgelegte Coordination Services. Der Activation Service dient der Erzeugung eines Transaktionskontexts, der Registration Service ermöglicht einem Web-Service-Provider, sich in einer verteilten Transaktion zu registrieren, und der Coordination Service ermöglicht die Festlegung eines Koordinationsprotokolls. Die Spezifikation ist so allgemein gehalten, dass verschiedene Koordinationstypen möglich sind.

In der obigen Abbildung ist das typische Zusammenspiel der Komponenten skizziert. Die Anwendung AP1 erzeugt zunächst einen Transaktionskontext beim Coordinator-Service A und sendet anschließend eine Nachricht, also den Aufruf eines Web-Service, an die Anwendung AP2. AP2 macht die Transaktion nun beim zuständigen Coordinator-Service B bekannt und registriert diese, wobei ein zu verwendendes Koordinationsprotokoll festgelegt und zwischen den beteiligten Registration-Services ausgetauscht wird. Anschließend nutzen sie das abgestimmte Protokoll für die Koordinierung der Transaktion. Im Beispiel sind zwei Instanzen im Einsatz, die bei der Commit-Bearbeitung zusammenarbeiten müssen.

Als Koordinationstypen sind WS-AT und WS-BA definiert. Beide setzen auf WS-C auf:

• WS-AT stellt so genannte Atomic Transactions für klassische, kurze ACID-Transaktionen bereit. Die Koordination erfolgt über ein definiertes 2PC-Protokoll, wobei zwischen einem volatilen (für Cache-Ressourcen) und einem dauerhaften (für persistente Ressourcen) 2PC unterschieden wird.

• WS-BA stellt so genannte Business Activities für langlebige Transaktionen zur Verfügung. Durch die Aufweichung der Isolationseigenschaft benötigt man Kompensationsoperationen. Auch bei WS-BA sind verschiedene Completion-Protokolle spezifiziert, um Transaktionen zu Ende zu führen. Alle WS-C/AT/BA-Nachrichten sind als XML-Nachrichten spezifiziert und werden über Soap übertragen. Die Protokolle sind in den einzelnen Spezifikationen in Form von Zustandsautomaten definiert.

• BTP: BTP ist ebenfalls eine Initiative von Oasis für Transaktionen lose gekoppelter Anwendungen. In BTP werden als Transaktionsmodelle "Atomic Business Transactions" und "Cohesive Business Transactions" definiert. Erstere sind verteilte atomare Transaktionen, Letztere sind offen geschachtelte Transaktionen. Der Koordinator erzeugt die Transaktion und ruft innerhalb dieser mehrere Services in Subtransaktionen auf. Wenn eine Subtransaktion nicht erfolgreich verläuft, kann der Koordinator über die weitere Ausführung beziehungsweise den Abbruch entscheiden. Dies muss vom Entwickler der Haupttransaktion bei der Programmierung festgelegt werden. Die strengen ACID-Korrektheitskriterien werden bei allen Transaktionsmodellen nicht als sinnvoll erachtet.

• WS-CAF: Dieses Rahmenwerk WS-CAF enthält drei Spezifikationen. WS-Context (WS-CTX) soll ein "leichtgewichtiges" Framework für die Verwaltung von Kontexten sein, wobei hier nicht nur Transaktionskontexte, sondern auch andere Konversationskontexte gemeint sind. Das WS-Coordination-Framework (WS-CF) definiert, wie sich Web-Service-Provider bei einer Transaktion registrieren können und wie das Transaktionsergebnis unter Koordinatoren und Teilnehmern kommuniziert wird. Verschiedene Koordinationsprotokolle sind möglich. WS-Transaction-Management (WS-TMX) definiert schließlich mehrere Koordinationsprotokolle wie 2PC und ein Completion-Protokoll für lang andauernde Actions mit Kompensationsunterstützung. Es werden also sowohl atomare als auch langlebige Transaktionen mit Kompensationsmechanismen spezifiziert. Die strengen ACID-Eigenschaften werden nicht angestrebt und als unangemessen für unternehmensübergreifende Transaktionen angesehen.

Resümee

In der heutigen Praxis werden überwiegend flache Transaktionen genutzt, die aber in den meisten Fällen völlig ausreichen. Über mehrere Transaktionsumgebungen verteilte Transaktionen gelten als problembehaftet. Das Zusammenspiel der beteiligten Komponenten ist insbesondere bei heterogenen Produkten recht komplex und fehleranfällig. Verkompliziert wird das Ganze bei Fehlersituationen wie zum Beispiel dem Ausfall eines Koordinators während der Commit-Bearbeitung.

Aufgrund der Komplexität der Implementierung verteilter Transaktions-Middleware sind in der Praxis eher pragmatische Ansätze vorzufinden, die nur die notwendigsten Features verteilter Transaktionen ausnutzen. Verteilte Transaktionen werden beispielsweise oft nur dann verwendet, wenn man sie unbedingt benötigt, und dann so einfach wie möglich gestaltet (also flach und nicht geschachtelt). Ein pragmatischer Ansatz ist das Transaction-per-Request-Pattern. Je Methodenaufruf an einer Dienstschnittstelle gibt es nur eine in sich abgeschlossene Transaktion, die im Server abläuft. Wenn der Methodenaufruf eines Clients abgearbeitet ist, sollte auch die Transaktion abgeschlossen sein. Hier bleibt immer noch das Problem, dass der Client gegebenenfalls aufgrund eines Netzausfalls das Methodenergebnis (Transaktionsergebnis) nicht mitbekommt. In dialogorientierten Anwendungen ist für eine eventuelle Abklärung des Ergebnisses ein entsprechender Dialog vorzusehen.

Im Folgenden lesen Sie, warum es schwierig ist, alle ACID-Eigenschaften in Web-Services-Transaktionen umzusetzen.