Commits werden dabei in zwei Phasen (Zwei-Phasen-Commit) durchgeführt bei denen der eigentliche Commit nur dann ausgeführt, wenn vorher alle beteiligten Systeme erfolgreich den Prepare Befehl ausgeführt haben. Die Transaktionen werden von Transaktionsmanagern koordiniert. Der Commit kann dabei viel später und unabhängig vom eigentlichen Serviceaufruf geschehen. Neben den klassischen Transaktionssystemen wie Tuxedo, CICS oder UTM, wird die XA Spezifikation durch den JTA (Java Transaction API) Standard auch von JEE Servern wie JBoss EAP implementiert.
3) Kommunikation in Cloud Systemen
Bei der Kommunikation zwischen zwei Anwendungen werden häufig Services, z.B. Webservices, verwendet. Besonders in Cloud-Systemen wird dabei großer Wert auf Ausfallsicherheit und Skalierbarkeit gelegt. Generell sind folgende Eigenschaften wünschenswert:
- Die Kommunikation ist eine einfache Client – Server Beziehung (Anwendung 1 als Client Anwendung 2 als Server)
- Die Services sind stateless wodurch für Ausfallsicherheit kein Status repliziert werden muss
- Das Programmiermodell ist weitgehend ähnlich einem lokalen Programmiermodell, also synchroner Aufruf von Funktionen.
- Das Gesamtsystem bleibt konsistent (transaktionale Eigenschaften) bei gleichzeitig guter Performance (Skalierbarkeit) und Ausfallsicherheit (Redundanz)
Vielfach hofft man diese Eigenschaften durch Webservices und globale Transaktionen (z.B. Webservice Atomic Transaction / WS-AT) zu erhalten. Leider ist das nicht möglich.
3.1) Kommunikation mit WS-AT ist keine Client-Server Kommunikation
Wie in Abbildung 1 zu erkennen, registriert sich der Transaktionsmanager der aufgerufenen Anwendung beim Transaktionsmanager der aufrufenden Anwendung, sobald ein Service mit Transaktionsinformationen aufgerufen wird. Man hat daher eine bidirektionale Kommunikation (von beiden Richtungen werden Verbindungen aufgebaut) zwischen den Anwendungen.
3.2) Kommunikation mit WS-AT ist nicht stateless
Der Status aller aktiven Transaktionen wird vom jeweiligen Transaktionsmanager in einer lokalen Datei am Server, dem Transaktionslog, verwaltet. Dieser Status wird nicht repliziert. Informationen über die Transaktion gehen daher bei einem Serverausfall verloren. Reines Loadbalancing zur Steigerung der Verfügbarkeit ist daher nicht ohne zusätzliche Überlegungen möglich.
3.3) Ein lokales Programmiermodell kann nicht aufrechterhalten werden
Zumindest wenn man einfache Loadbalancer, wie sie in Cloud-Systemen verwendet werden, einsetzt funktionieren lokale Programmiermodelle zwischen Anwendungen mit WS-AT nicht. Als Beispiel das Anlegen eines Buchungsbeleges und das Hinzufügen einer Buchung in einer Geschäftsanwendung. Als Transaktionssystem wird JBoss EAP mit Hibernate als Datenzugriffsschicht verwendet. Die Serviceaufrufe könnten so konzipiert sein:
- Suchen eines Buchungsbeleges
- Wenn nicht gefunden, dann neuen Buchungsbeleg anlegen
- Hinzufügen einer Buchung zum Buchungsbeleg
Es wird also zuerst ein Datensatz (Buchungsbeleg) angelegt und innerhalb derselben Transaktion dieser Satz beim nächsten Serviceaufruf gesucht, um eine Buchung hinzuzufügen:
