Vorsicht Technik

Transaktion meets Web-Service

02.03.2011 von Peter Mandl
Wie lassen sich Web-Services mit der Transaktionsverarbeitung kombinieren? Eine Erläuterung von Konzepten für Service-orientierte Transaktionen.

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:

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:

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.

Schwierig: Web-Services-Transaktionen mit allen ACID-Eigenschaften

Web-Service-Transaktionen mit allen ACID-Eigenschaften, die mehrere Koordinatoren einbeziehen, sind in der Praxis sehr schwer zu realisieren. Auch der Aufbau von Infrastrukturen für langlebige Transaktionen und die Entwicklung von Kompensationstransaktionen sind ein komplexes Unterfangen. Da die an einer Transaktion beteiligten Web-Services möglicherweise auf völlig eigenständig agierenden Transaktionsplattformen ablaufen, die nur schwer in Einklang zu bringen sind, ist der praktische Einsatz der genannten Transaktionsansätze sehr problematisch. Man muss sich jeweils fragen, ob wenigstens einer der genannten Transaktionsansätze für Web-Services überhaupt praxisrelevant ist.

Aktuell gibt es noch keine verbreitete Implementierung für die Transaktionsunterstützung bei Web-Services. Strebt man mit heutigen technischen Möglichkeiten eine robuste Lösung an, so sollte der Aufruf einer Web-Service-Operation möglichst nur eine Transaktion in einer lokalen Umgebung des Web-Service-Providers auslösen.

Verteilte Transaktions-Manager, die als Koordinatoren in unternehmensübergreifenden Anwendungen zusammenarbeiten, sind derzeit noch nicht denkbar. Man stelle sich nur vor, mehrere Web-Service-Provider sind an einer Transaktion beteiligt, bei der der Koordinator ausfällt. Es bleibt abzuwarten, ob sich ein Standardisierungsansatz durchsetzen wird und welche Bedeutung er für die praktische Anwendungsentwicklung erlangt. Im Moment sind eher pragmatische und robuste Ansätze zu empfehlen. Andere Lösungsvarianten müssen sich erst noch bewähren.

Transaktionsverarbeitung: Grundlagen

Eine Transaktion dient dazu, eine endliche Folge von Operationen zusammenhängend in einem Arbeitsschritt ("Unit of Work") auszuführen. Entweder es werden alle Operationen ausgeführt oder gar keine. Der Vorgang beginnt mit dem Befehl "begin" und endet mit "commit". Mit "rollback" wird die Transaktion abgebrochen und der Vorgang in den ursprünglichen Zustand überführt. Der Beginn und das Ende einer Transaktion werden auch als Transaktionsgrenzen bezeichnet. Eine Transaktion ist ferner eine Folge von Aktivitäten oder Operationen auf Daten beziehungsweise Objekte.

Ein konsistenter Zustand eines Systems wird über diese Folge von Operationen in einen neuen konsistenten Zustand überführt, wie dies in der nächsten Abbildung verdeutlicht wird. Der Zustand zwischen dem Beginn und dem Ende einer Transaktion ist nicht konsistent. Klassisch wurde eine Transaktion nur lokal auf einem Rechner ausgeführt. Alle Ressourcen (typischerweise Datenbanken) befanden sich also auf einem Mainframe oder auf einem Server-Rechner. Im Zuge der Verteilung von Anwendungen musste man sich nun Gedanken darüber machen, wie man Transaktionen, die verteilte Ressourcen nutzen, also verteilte Transaktionen in den Griff bekommt.

Idee einer Transaktion.

Zu den wesentlichen Problemen, die in lokalen und verteilten Transaktionen behandelt werden müssen, gehören die Nebenläufigkeitskontrolle (Concurrency Control), das Recovery bei Fehlersituationen und die Koordination der beteiligten Softwareinstanzen beim Abschluss der Transaktion. Alle an einer Transaktion beteiligten Instanzen müssen sich über den Transaktionszustand sowie den Transaktionsausgang einig sein. Man sagt, sie verfügen über denselben Transaktionskontext oder befinden sich im selben Thread-of-Control.

Mehrere Transaktionsmodelle wurden erforscht: Das klassische Transaktionsmodell wird als Flat Transaction bezeichnet. Hier gelten die strengen ACID-Korrektheitskriterien. Im Lauf der Jahrzehnte wurden weitere Transaktionsmodelle wie offen und geschlossen geschachtelte (nested) sowie langlebige (long-lived) Transaktionen implementiert. Geschachtelte Transaktionen ermöglichen den Aufruf weiterer Subtransaktionen innerhalb einer Transaktion. Bei geschlossen geschachtelten Transaktionen werden die ACID-Eigenschaften über die Gesamtransaktion hinweg eingehalten, bei offen geschachtelten Transaktionen werden die Subtransaktionen zwischendurch beendet, wodurch Inkonsistenzen in Kauf genommen werden. Kompensationsstrategien sind daher im Fehlerfall notwendig. Verteilte Transaktionen untersuchte man vor allem zur Transaktionsunterstützung in Client-Server-Architekturen. Dabei wurde die Anwendung der ACID-Korrektheitskriterien immer wieder neu diskutiert. Durchgesetzt hat sich letztendlich in der Praxis im Wesentlichen das Konzept der flachen Transaktionen, auch in verteilter Umgebung.

Bei verteilten Transaktionen hat sich das Koordinator-Teilnehmer-Modell durchgesetzt. Ein Koordinator entscheidet über den Ausgang der Transaktion und steuert die Koordination mit den Teilnehmern über ein Commit- oder Completion-Protokoll. Hierfür hat sich das Zwei-Phasen-Commit-Protokoll (2PC) etabliert, allerdings gibt es viele 2PC-Implementierungen, die nicht miteinander kompatibel sind. Wichtig ist auch, dass das 2PC-Protokoll ein blockierendes Protokoll ist und damit in der Praxis einige Probleme auftreten können, wenn der Koordinator ausfällt. Transaktionen bleiben dann offen, und Sperren werden nicht aufgelöst.

Im Folgenden werden Standards der Transaktionsverarbeitung erläutert

Standards der verteilten Transaktionsverarbeitung

Nach den ISO/OSI-Standardisierungsbemühungen der 80er Jahre, bei denen erfolglos versucht wurde, Koordinations- und Transaktionsprotokolle wie OSI-CCR und OSI-TP zu etablieren, hat die Open Group (damals noch X/Open) das Modell Distributed Transaction Processing (DTP) konzipiert. Die wesentlichen Komponenten des Modells sind in der folgenden Abbildung skizziert.

Anwendungsprogramme (AP) wickeln Transaktionen ab und nutzen dazu Ressourcen-Manager (RM) zur Bearbeitung von Daten. Ressourcen-Manager werden von Datenbank-Management-Systemen (etwa Oracle oder IBM DB2) und Message-Queuing-Systemen (Websphere MQ) bereitgestellt.

Transaktions-Manager (TM) verwalten die Transaktionskontexte lokaler und verteilter Transaktionen.

Communication Resource Manager (CRM) sind spezielle Ressourcen-Manager und dienen als Stellvertreter für alle entfernten RMs, die an der Transaktion beteiligt sind. Die Komponenten kommunizieren über standardisierte Schnittstellen. Die wesentlichen Schnittstellen sind XA zwischen TM und RM sowie TX zwischen AP und TM. Über TX startet und beendet ein AP eine Transaktion, über XA registriert sich ein RM an einer Transaktion und wickelt die Commit-Bearbeitung ab.

Das DTP-Modell hat sich bis heute als einziger "Standard" etabliert, und insbesondere das XA-Interface wird von allen Datenbankherstellern und Herstellern von Transaktions-Middleware unterstützt. Ein Standard für das Commit-Protokoll hat sich nicht etabliert. Es gibt lediglich eine Schnittstellenspezifikation (XA). Kommunizieren ein Transaktions-Manager und ein Ressourcen-Manager über XA miteinander, so erfolgt dies über ein proprietäres 2PC-Protokoll, das von Datenbankanbietern stammt.

Bei Implementierungen von Plattformen für verteilte Transaktionssysteme findet man auch häufig Corba/OTS vor. Dieser Standard gilt auch als Basis für die Implementierung verteilter Transaktionssysteme im J2EE/EJB-Umfeld. Praktische Anwendungssysteme, die unterschiedliche EJB-Application-Server verwenden und über mehrere heterogene Container verteilte Transaktionen einsetzen, sind aber in der Praxis selten anzutreffen. Für das transaktionale Zusammenspiel von Application-Servern unterschiedlicher Hersteller gibt es in der EJB-Spezifikation auch nur die Empfehlung und nicht die Vorgabe, IIOP als Protokoll für die Kontextpropagierung zu verwenden. Dies macht ein Zusammenspiel unterschiedlicher Applikations-Server heute schwierig.

Corba/OTS, JEE/JTA/JTS und auch proprietäre Lösungen lehnen sich alle an das DTP-Modell an und unterstützen es. In der folgenden Abbildung sind die Beziehungen der verschiedenen Ansätze mit dem DTP-Modell als zentralem Modell grafisch dargestellt.

Im Folgenden finden Sie ein Glossar.

Glossar zum Thema Transaktionen und Web-Services

2PC-Protokoll: Two-Phase-Commit, ein Koordinations- beziehungsweise Completion-Protokoll für verteilte Transaktionen. Die Koordination wird in zwei Phasen abgewickelt, einer Prepare- und einer Commit-Phase. Es gibt viele Implementierungen und auch Optimierungen dieses Protokolls [2].

ACID: Akronym für die Korrektheitskriterien einer Transaktion, auch als ACID-Transaktion bezeichnet. "A" steht für Atomicity, "C" für Consistency, "I" für Isolation und "D" für Duability. Wird nur ein Kriterium nicht erfüllt, sind alle anderen auch gefährdet.

Busines Activity: Im Vergleich zur strengen ACID-Transaktion aufgeweichte Form der Transaktion. Meist wird das Isolationskriterium aufgeweicht.

Corba/OTS: Corba Object Transaction Service. Verteilter, objektorientierter Transaktionsstandard.

DTP-Modell: Distributed Transaction Model der Open Group, Standard in der Transaktionsverarbeitung.

EJB: Enterprise Java Beans, Server-seitige Komponententechologie in JEE.

IIOP: In Corba spezifiziertes Protokoll zur Kommunikation verteilter Objekte.

Flache (flat) Transaktion: Transaktion, die nicht geschachtelt ist und eine kleine Anzahl von zusammengehörigen Operationen logisch zusammenfasst.

Langlebige (long) Transaktion: Transaktion, die sehr viele Operationen aufruft und gegebenenfalls im Vergleich zu einer flachen Transaktion sehr lange dauern kann.

JEE: Java Extended Edition: Java-Spezifikation mit vielen Standard-APIs für die Server-seitige Entwicklung, unter anderem gehören EJB, JMS, JSP, Servlets, JTA, JNDI, JDBC und JAX-RPC zu dieser umfassenden API-Sammlung.

JTA: Java Transaction API zum Programmieren von Transaktionen in JEE.

JTS: Java Transaction Service, standardisierte Java-Schnittstelle zu Corba/OTS, wird nur von Application-Server-Herstellern benutzt, um eine Anbindung an Corba/OTS zu implementieren.

Kompensationsoperation: Operation, die die Auswirkungen einer bereits abgeschlossenen Transaktion kompensieren soll. Dies ist in einer nebenläufigen Umgebung sehr schwierig, da die Ergebnisse einer Transaktion bereits wieder von anderen Transaktionen verarbeitet werden können. Um die Konsistenz wiederherzustellen, müsste man gegebenenfallls bereits abgeschlossene Transaktionen kaskadenförmig abbrechen. Die Sinnhaftigkeit hängt von der konkreten Anwendung ab.

Koordinator-Teilnehmer-Modell: Koordinationsmodell, bei dem ein Koordinator den Ausgang der Transaktion steuert.

OSI-CCR: OSI-Transaktionsstandard, CCR steht für Commitment, Concurrency and Recovery.

OSI-TP: OSI-Transaktionsstandard für ein Koordinierungsprotokoll, TP steht für Transaction Protocol.

Soap: Protokollstandard für die Kommunikation mit Web-Services.

Transaktionskontext: Zustand einer Transaktion, den alle Teilnehmer und der Koordinator einer Tran-saktion kennen müssen.

XA: Die Standardschnittstelle zwischen Ressourcen-Managern (Datenbanken) und Transaktions-Managern der Open Group zur Koordination verteilter Transaktionen. Diese API wird heute von allen Datenbank- und Application-Server-Herstellern unterstützt.

Literatur zum Thema Transaktionen und Web-Services

Im Folgenden lesen Sie ein Interview über die Praxistauglichkeit der Web-Services-Technik mit dem Autor dieses Artikels.

Vier Fragen an den Autor Professor Dr. Peter Mandl

CW: Gibt es Handlungsanweisungen, die Firmen beim Bauen von Web-Services-orientierten Systemen mit Transaktionsverarbeitung beachten sollten?

MANDL: Strebt man mit heutigen technischen Möglichkeiten eine robuste Lösung an, so sollte der Aufruf einer Web-Service-Operation möglichst nur eine Transaktion in einer lokalen Umgebung des Web-Service-Providers auslösen. Verteilte Transaktions-Manager, die als Koordinatoren in unternehmensübergreifenden Anwendungen zusammenarbeiten, sind, zumindest aus heutiger Sicht, nicht realistisch. Die Beschränkung auf eine flache Transaktion, welche die Provider-Grenzen nicht überschreitet, stellt eine robuste Lösung dar und funktioniert. Sie wird heute in der Praxis fast ausschließlich eingesetzt, wenn man Aktualisierungsoperationen in einer Transaktion verwendet.

CW: Trifft es zu, dass zwar simple Transaktionen (Credit-Check, Terminabfrage etc.) im Web-Services-Umfeld heute realisierbar sind, jedoch keine komplexen Abläufe etwa zwischen unterschiedlichen Geschäftsanwendungen?

MANDL: Meines Wissens ja. Ich kenne kein Unternehmen, das Ihren Transaktions-Manager öffentlich zur Koordination verteilter Web-Service-Transaktionen über die Unternehmensgrenze hinweg zur Verfügung stellt. Bei rein lesenden Transaktionen ist das nicht so problematisch, denn da kann man auch auf die Transaktionskoordination verzichten.

CW: Wie weit ist die Standardisierung fortgeschritten?

MANDL: Die drei wichtigen Oasis-Standards WS-C, WS-AT und WS-BA sind nun alle in der Version 1.2. Sie wurden zur Spezifikation WS-Transactions zusammengefasst, die wiederum aus den drei Subspezifikationen besteht. Die anderen Standards werden wohl nicht mehr weiterentwickelt, es scheint also, dass sich WS-Transactions durchgesetzt hat.

CW: Wie gut sind die SOA-/Web-Services-Umgebungen von Anbietern wie Oracle, IBM, Software AG, Tibco und SAP auf die verteilte Transaktionsverarbeitung vorbereitet?

MANDL: Verteilte Transaktionen in homogenen Umgebungen unterstützen die gängigen Produkte im Rahmen ihrer Implementierung. Für Web-Service-Transaktionen bieten heutige Produkte meist Implementierungen auf Basis von WS-Coordination und WS-AtomicTransaction 1.0 beziehungsweise 1.1. Microsoft berichtet beispielsweise von einer Implementierung von WS-Coordination und WS-AtomicTransaction 1.1 in der Windows Communication Foundation (WCF) sowie von erfolgreichen Interoperabilitätstests unter anderem mit den Produkten von Sun, IBM und IONA (Progress Software).