11.3 Realisierungsaspekte

11.3.2 Kommunikation

Neben der Transaktionsverwaltung ist der TP-Monitor vor allem auch für die Kommunikation von Anwendungsprogrammen mit dem Endbenutzer, dem DBS und anderen Anwendungsprogrammen verantwortlich, wobei in zentralisierten Transaktionssystemen sämtliche Eigenschaften der eingesetzten Kommunikationsmechanismen dem Programmierer verborgen bleiben. Diese Kommunikationsunabhängigkeit sollte natürlich auch in verteilten Transaktionssystemen erhalten bleiben, bei denen unterschiedliche TP-Monitore, LDBS und Kommunikationsprotokolle beteiligt sein können. Zur Ausführung entfernter Teilprogramme stellen derzeitige TP-Monitore Transaktionsanwendungen vor allem drei unterschiedliche Ansätze zur Verfügung: Konversationen, RPC (Remote Procedure Call) sowie persistente Warteschlangen. Daneben ist zu unterscheiden zwischen synchroner und asynchroner Ausführung der entfernten Teilprogramme.

Weitverbreitet ist die Kommunikation über Konversationen im Rahmen eines sogenannten "Peer-to-Peer"-Protokolls. Dabei sind zwischen den Kommunikationspartnern zunächst Verbindungen aufzubauen, bevor eine Konversation (Dialog, Nachrichtenaustausch) über Sende- und Empfangsoperationen erfolgt [Be90, Cy91]. Dieser Ansatz wird von dem SNA-Protokoll LU6.2 sowie ISO OSI-Protokollen verfolgt sowie den darauf aufbauenden APIs zur Kommunikation (z.B. CPI-C). Er ist sehr flexibel, da nahezu beliebige Kooperationsformen realisiert werden können (z.B. können mehrere Teilprogramme asynchron gestartet werden u.ä.). Die resultierende Programmierschnittstelle ist jedoch sehr komplex und fehleranfällig. Ferner wird keine Ortstransparenz erreicht, da für lokale und entfernte Teilprogramme unterschiedliche Aufrufmechanismen verwendet werden (lokaler Prozeduraufruf vs. Kommunikation über Konversationen). TP-Monitore wie CICS oder UTM, die auf LU 6.2 aufbauen, verfolgen diesen Ansatz.

Die Alternative besteht in der Verwendung von Remote Procedure Calls (RPC) zum Starten externer Teilprogramme [Sc92, GR93]. Hierbei besteht eine Client-/Server-Beziehung zwischen den Kommunikationspartnern, wobei das rufende Programm (Client) jeweils nur einen Aufruf absetzt und stets eine Antwort vom gerufenen Programm (Server) entgegennimmt. Der Aufruf der Server-Funktionen ist meist synchron. Die Anwendungsprogrammierung wird gegenüber der Kommunikation über Konversationen erheblich vereinfacht, da eine einheitliche Schnittstelle zum Aufruf lokaler und entfernter Programme verwendet werden kann. Der RPC-Mechanismus (TP-Monitor) ist verantwortlich für Lokalisierung und Aufruf der Programme, wobei ggf. eine Kommunikation und Anpassung von Parameterformaten erfolgt. Einige neuere TP-Monitore wie Encina nutzen zur RPC-Abwicklung die Middleware-Komponente OSF DCE (s.o.), allerdings erweitert mit einer Transaktionssemantik ("transaktionsgeschützter RPC") [GR93].

Zur asynchronen Ausführung von Teilprogrammen unterstützen einige TP-Monitore das Konzept der "queued transactions" [GR93]. Dabei werden Programmaufrufe innerhalb persistenter Warteschlangen ("recoverable/reliable queues") verwaltet, die vom TP-Monitor zu bestimmten Zeitpunkten abgearbeitet werden. Das rufende Programm wartet dabei nicht auf das Ende (bzw. den Start) der auszuführenden Funktion, sondern beendet sich bereits, nachdem ihm die spätere Ausführung des Programms (nach Einfügung in die Warteschlange) zugesichert wurde. Der TP-Monitor garantiert dazu, daß das betreffende Programm genau einmal ausgeführt wird (Exactly-Once-Semantik). Operationen auf den Warteschlangen (Einfügen, Ausfügen) sind Teil der ACID-Transaktion und i.a. durch die Anwendungsprogramme vorzunehmen.
Persistente Warteschlangen sind i.a. nicht für Dialogaufgaben nutzbar, die eine direkte Bearbeitung sämtlicher Teilschritte erfordern. Dennoch weist dieses Konzept vor allem zur Transaktionsverarbeitung in heterogenen Systemen eine Reihe signifikanter Vorteile auf. Denn die verzögerte Ausführbarkeit nicht-lokaler Programmaufrufe bedeutet eine Erhöhung der Knotenautonomie (Ausführungsautonomie). Weiterhin ergibt sich eine erhöhte Unabhängigkeit gegenüber der Verfügbarkeit der Knoten, an denen eine Funktion gestartet werden soll. Denn ist der betreffende Rechner zunächst nicht erreichbar, kann der TP-Monitor des Ursprungsknotens automatisch den Aufruf zu einem späteren Zeitpunkt wiederholen. Bei synchroner Programmausführung ist dagegen eine Fehlerbehandlung im aufrufenden Programm vorzusehen. Die asynchrone Programmausführung im Rahmen von "queued transactions" erlaubt auch in vielen Fällen die zuverlässige Zerlegung einer verteilten Transaktion in mehrere kürzere Transaktionen, was z.B. für Überweisungsaufträge zwischen Banken in der Praxis Verwendung findet [BHM90]. Damit ergibt sich auch eine erhebliche Reduzierung der Sperrdauer, wodurch das Sperrproblem lang-lebiger Transaktionen umgangen wird. Auf der anderen Seite können durch den TP-Monitor nicht behebbare Fehler während der asynchronen Programmausführung (z.B. aufgrund eines Programmierfehlers) zu Inkonsistenzen führen, die durch manuelle Recovery-Aktionen auszugleichen sind. Bei synchronen Aufrufen würde dagegen im Fehlerfall die gesamte Transaktion abgebrochen.