Transaktionsmonitor

Als eine der ältesten Formen von Middleware sind Transaktionsmonitore heute eine ausgereifte Technologie. Eine der ältesten Implementierungen sind das IMS TM und CICS von IBM. Die ersten Transaktionsmonitore boten auf Mainframes robuste Laufzeitumgebungen für große OLTP-Anwendungen. Um das Zugreifen auf gemeinsame Daten zu ermöglichen und dabei die Datenkonsistenz zu sichern, implementierten die Systeme das transaktionale Konzept.

Die nächste Generation von Transaktionsmonitoren war Client-/Server-basiert; für mehrere Jahrzehnte waren Transaktionsmonitore die dominierende Form von Middleware und spielen auch heute noch eine wichtige Rolle bei alltäglichen Vorgängen wie beispielsweise dem Abwickeln von Banktransaktionen. 1998 schätzte die Standish Group,^[1] dass weltweit ca. 68 Mio. Transaktionen pro Sekunde elektronisch abgewickelt werden und 53 Mio. davon mithilfe von Transaktionsmonitoren. Heutzutage findet man kaum noch alleinstehende Transaktionsmonitore, vielmehr sind diese in größere Laufzeit-Umgebungen (Container) mit eingebettet. Ein Beispiel hierfür ist die Jakarta EE.

Aufgrund der Vielfalt seiner Aufgaben ist es schwierig zu präzisieren, was genau ein Transaktionsmonitor ist. Turing-Preisträger Jim Gray meint dazu: “In a contest for the least well defined software term, TP Monitor would be a tough contender” (deutsch: „In einem Wettbewerb um den schwammigsten Software-Begriff wäre Transaktionsmonitor ein starker Anwärter“).

Grob gesagt integriert ein Transaktionsmonitor verschiedene Systemkomponenten (beispielsweise ein Kommunikationssystem, ein Laufzeitsystem, ein Präsentationssystem, …), um für Anwendungen/Operationen standardisierte, gleichförmige Schnittstellen zu bieten, die im Fehlerfall stets dasselbe Verhalten bieten. Man kann einen Transaktionsmonitor als ein Betriebssystem für transaktionsgeschützte Anwendungen ansehen, dessen Aufgabenspektrum sich grob in die drei Klassen Client-Server-Kommunikationsverwaltung, Transaktionsverwaltung und Prozessverwaltung aufteilen lässt.

Client-Server- und Server-Server-Kommunikation: sie erlauben die an einer Anwendung beteiligten Dienste und Komponenten auf verschiedene Art aufzurufen, bspw. mit RPCs, mit asynchronen Nachrichten, die persistente Warteschlangen nutzen (Message Oriented Middleware) usw. Transaktionsmonitore kontrollieren dabei zum Teil Kommunikationsflüsse zwischen Tausenden von Clients und Hunderten von Servern.

Transaktionsverwaltung: Die grundlegende Infrastruktur zum Ausführen verteilter Anwendungen bildet das RPC-Protokoll; es ist ein Konzept, das dafür gedacht ist, einen entfernten Prozeduraufruf eines Clients bei einem Server zu ermöglichen und ihn dabei für den Client transparent zu machen, als wäre es ein lokaler Prozeduraufruf.

Dieses Konzept funktioniert gut in Client-Server-Systemen, wenn ein Client einen Server kontaktiert; sind aber mehr als zwei Entitäten beteiligt und somit mehr als ein entfernter Prozeduraufruf in die Interaktion involviert (beispielsweise ein Client, der Prozeduren auf zwei verschiedenen Servern aufruft, oder ein Client, der eine Prozedur auf einem Server aufruft, was wiederum einen Datenbankaufruf des Servers zur Folge hat), so behandelt das RPC-Konzept diese entfernten Aufrufe unabhängig voneinander, was im Falle eines Systemfehlers die Wiederherstellung (engl.: recovery) eines korrekten Systemzustandes sehr erschwert.

Ein klassisches Beispiel, um dies zu illustrieren, ist eine Anwendung auf einem Client, die Geld von einem Bankkonto abhebt, um es auf ein anderes Konto zu transferieren. Sollte der Client zwischen beiden Aktionen abstürzen oder ein anders gearteter Fehler auftreten, wäre das abgehobene Geld verloren, gesetzt, der Client konnte seinen Zustand nicht persistent machen.

Transaktionsmonitore implementieren eine transaktionale Erweiterung des RPC-Konzeptes; sie wickeln entfernte Prozeduraufrufe in einer Transaktion mit den ihr inhärenten ACID-Eigenschaften ab. Insbesondere impliziert die ACID-Eigenschaft Atomarität, also dass entweder alle beteiligten entfernten Prozeduraufrufe abgewickelt werden oder keiner. Transaktionsmonitore implementieren damit also eine Abstraktion von RPC, genannt transaktionaler RPC (TRPC).

Eine Gruppe von Prozeduraufrufen wird bei TRPC sozusagen mit der transaktionalen Klammer BOT (beginning of transaction) und EOT (end of transaction) versehen und als Einheit behandelt. Dies sicherzustellen ist Aufgabe des sog. Transaktionsmanagement-Moduls, das die Interaktionen zwischen Clients und Servern steuert und deren Atomarität mithilfe einer Implementierung des 2-Phasen-Commit-Protokolls sichert.

Transaktionsverwaltung beinhaltet auch die Aufgabe, während des Normalbetriebs Logging (bspw. Protokollieren von Nachrichten) durchzuführen, um im Fehlerfall Wiederherstellungsmaßnahmen ergreifen zu können.

Prozessverwaltung: Zu ihren Aufgaben zählt unter anderem das Starten von Server-Prozessen, das Initialisieren von Transaktionsprogrammen und das Kontrollieren ihres Ablaufs; des Weiteren fällt auch Lastbalancierung in diesen Bereich.

Transaktionsmonitore sind in den meisten Applikationsservern integriert. Es gibt eine stattliche Anzahl kommerzieller Implementierungen von Transaktionsmonitoren, beispielsweise die beiden IBM-Produkte Customer Information Control System (CICS) und Information Management System (IMS mit integriertem Transaktionsmonitor IMS-TM), Microsoft Transaction Server, Oracle Tuxedo, NonStop TS/MP (HPE) und openUTM von Fujitsu Siemens Computers; diese sind auch in Produkt-Suiten für Enterprise Application Integration zu finden.

Ein Transaktionsmonitor sollte nicht mit einem sog. Transaktionsmanager verwechselt werden. Während das Aufgabenspektrum eines Transaktionsmanagers lediglich das Bereitstellen eines transaktionalen Kontextes für verschiedene Anwendungen/Operationen umfasst, bieten Transaktionsmonitore transaktionsorientiertes Scheduling und Management für verschiedene Ressourcen.

• Transaktionssystem

• Gustavo Alonso, F. Casati, H. Kuno, V. Machiraju: Web Services. Springer, Berlin 2003, ISBN 3-540-44008-9

1. ↑ standishgroup.com