ConTracts

In der Praxis der Datenverarbeitung sind heute sogenannte ACID-Transaktionen weit verbrei-tet. Diese Transaktionen besitzen folgende Eigenschaften [GrRe91]:

• Atomicity (Atomizität):

Ein Zustandsübergang ist atomar, wenn es für den Beobachter so aussieht, als ob das Verlassen des Ausgangszustandes mit dem Erreichen des Endzustandes zeitlich zu-sammenfällt, das heißt, wenn es keine nach außen hin sichtbaren Zwischenzustände gibt.

• Consistency (Konsistenz):

Eine Transaktion geht von einem Zustand, in dem sämtliche Konsistenzbedingungen erfüllt sind, wieder in einen konsistenten Zustand über.

• Isolation:

Isolation bedeutet, daß sich ein Programm unter dem Schutz einer Transaktion so ver-hält, als ob keine weiteren Prozesse parallel dazu laufen würden; und zwar auch dann, wenn dies in Wirklichkeit der Fall ist.

• Durability (Dauerhaftigkeit):

Das Ergebnis einer Transaktion darf nach deren erfolgreichem Abschluß nicht mehr verloren gehen, sondern muß im Fehlerfall wieder rekonstruiert werden.

ACID-Transaktionen in der beschriebenen Form sind jedoch nur für kurze Transaktionen ge-eignet, da die Realisierung von Atomizität, Konsistenz, Isolation und Dauerhaftigkeit bei län-ger andauernden „Transaktionen“, wie beispielsweise Workflows, bisher unüberwindliche Schwierigkeiten bereitet.

Ein Ansatz zur Lösung dieses Problems stellen ConTracts (Controled Activities Controled Transaction Compound) dar. Ein ConTract besteht aus einer Beschreibung von Steps sowie einem Skript.

Ein Step stellt ein sequentielles Programm dar, das unter dem Schutz einer ACID-Transaktion abläuft. Im Skript wird dagegen der Kontrollfluß definiert, beispielsweise die Reihenfolge der auszuführenden Steps oder welche Steps parallel zu anderen abgearbeitet werden müssen. Zu-sätzlich enthält das Skript Angaben über Ein- und Ausgabedaten der einzelnen Steps.

Step Skript

Abbildung 1: Ein Skript, das aus vier Steps besteht, von denen zwei parallel bearbeitet werden Da nicht das gesamte Skript, sondern nur die einzelnen Steps unter Transaktionsschutz stehen, müssen im Fehlerfall für erfolgreich beendete Steps Kompensations-Steps ausgeführt werden.

Die Information, welcher Step zur Kompensation eines anderen Step dient, ist ebenfalls im Skript enthalten.

Diese Thematik wird in [WaeRe91], [ReSweWa] sowie in [ReSwe95] ausführlich behandelt.

2.2 APRICOTS

APRICOTS (A Prototype Implementation of a ConTract System) stellt die Realisierung eines Workflow-Systems auf der Basis von ConTracts dar, das zur Zeit am Institut für Parallele und Verteilte Höchstleistungsrechner der Fakultät Informatik an der Universität Stuttgart entwik-kelt wird [Schw93] [Schw95].

2.2.1 ConTract Engine und Engine Factory

Die ConTract Engine [Seif96] ist die wohl wichtigste Komponente in APRICOTS. Für jedes Skript, das abgearbeitet werden soll, wird von der Engine Factory eine ConTract Engine gene-riert. Deren Aufgabe ist die zuverlässige Abarbeitung des Skripts. Insbesondere muß sie die für die jeweiligen Steps zuständigen Stepserver aufrufen und im Fehlerfall dafür sogen, daß die benötigten Kompensationssteps ausgeführt werden.

2.2.2 Context Manager

Die bei der Abarbeitung eines Skriptes verwendeten Variablen sowie die Ein- und Ausgabepa-rameter der einzelnen Steps stellen den Kontext des ConTracts dar. Dieser Kontext wird vom Context Manager verwaltet, der dabei auch für die persistente Speicherung, die vor allem im Fehlerfall für die Recovery von Bedeutung ist, sorgt.

Resource Manager

Step Server

Context Manager

Storage Agent

ConTract Engine

Engine Factory generiert

Monitoring Interface

Tasklist Interface

Sysadmin Interface

Programming Interface

Monitoring Tasklist Benutzeragent

OTS

Abbildung 2: Die Komponenten des APRICOTS-Systems

2.2.3 Step Server

Zur Ausführung der einzelnen im Skript enthaltenen Steps stehen der jeweiligen ConTract En-gine verschiedene aufgabenspezifische Stepserver zur Verfügung. Diesen übermittelt sie die zu erledigende Aufgabe und bekommt das Ergebnis zurückgeliefert. In der Regel wird dazu ein synchroner Aufruf verwendet, das heißt die ConTract Engine wartet, bis der Stepserver mit der Bearbeitung zu Ende ist. Warum dieses Vorgehen im Falle des Benutzeragenten nicht prakti-kabel ist, wird weiter unten diskutiert.

2.2.4 Resource Manager

Zur Bearbeitung des erhaltenen Auftrags können die Step Server wiederum auf sogenannte Resource Manager zurückgreifen. Beispielsweise wird eine Datenbank von einem Resource Manager verwaltet, über den ein Step Server auf die benötigten Daten zugreifen kann.

2.2.5 Storage Agent

Der Storage Agent wird von den anderen Komponenten des APRICOTS-Systems für die per-sistente Speicherung von Daten verwendet. Eine Ausnahme hiervon bilden die Benutzerober-flächen - das Tasklist Interface und das Monitoring Interface -, deren einziger Kontakt zum System über die Benutzeragenten erfolgt, die dann die Kommunikation mit dem Storage Agent übernehmen.

2.2.6 Benutzeragent (User Agent)

Der Benutzeragent (oder User Agent) repräsentiert einerseits genau einen Benutzer im System, andererseits bildet er auch die einzige Schnittstelle der Benutzungsoberflächen zum System, repräsentiert also auch das System gegenüber dem Benutzer. Der Benutzeragent gliedert sich in zwei Teile:

Der Monitoring-Teil, der mit dem Monitoring Interface kommuniziert, ist für die Übermittlung von Steuerbefehlen des Benutzers an die jeweiligen ConTract Engine eines ConTracts und für entsprechende Rückmeldungen verantwortlich.

Der Tasklist-Teil, den diese Arbeit zum Inhalt hat, ist aus der Sicht der ConTract Engine nichts anderes als ein interaktiver Stepserver. Folglich erhält der Agent die während der Abarbeitung eines Skriptes für seinen Benutzer anfallenden Aufgaben.

Eine genauere Beschreibung dieses Teils des Benutzeragenten erfolgt in den nächsten Kapiteln.

Wenn in diesen Ausführungen vom Benutzeragenten die Rede ist, dann bezieht sich dieser Begriff zumeist nur auf den Tasklist-Teil. Entsprechend werden auch nur die Interaktionen mit dem Benutzer betrachtet, die über das Tasklist Interface ablaufen. Der Monitoring-Teil des Be-nutzeragenten wird parallel zu dieser Arbeit entwickelt, und eine detaillierte Beschreibung dürfte sich in der zugehörigen Ausarbeitung finden [Ru96].

2.2.7 Monitoring Interface

Das Monitoring Interface bietet dem Benutzer die Möglichkeit, ConTracts zu starten, sie an-zuhalten und weiterlaufen zu lassen, sie abzubrechen, ihren Status abzufragen und dergleichen.

Diese Benutzeraktionen erreichen die zuständige ConTract Engine über den Monitoring-Teil des Benutzeragenten.

2.2.8 Tasklist Interface

Dieses Interface stellt einen elektronischen Eingangskorb des Benutzers dar. Es holt sich die Aufgaben, die der Benutzer erledigen soll, vom Tasklist-Teil des Agenten, der sie wiederum von der ConTract Engine erhalten hat, und stellt sie am Bildschirm dar. Der Benutzer kann nun eine Aufgabe zur Bearbeitung auswählen, woraufhin das Tasklist-Interface die hierfür benötig-ten Applikationen startet. Die Ergebnisse der Bearbeitung werden schließlich wieder an den Benutzeragenten geschickt, der sie an die ConTract Engine weiterleitet, von der die Aufgabe kam.

2.2.9 System Administration Interface

Das System Administration Interface (Sysadmin Interface) überwacht und verwaltet die übri-gen Komponenten des Systems. Es ist beispielsweise dafür zuständig, im Falle eines Absturzes einer solchen Komponente die erforderlichen Gegenmaßnahmen einzuleiten und eine entspre-chende Meldung an den Administrator zu senden. Außerdem bietet dieses Interface die Mög-lichkeit, neue Komponenten ins System einzubinden; etwa einen Agenten für einen neu hinzu-gekommenen Benutzer anzulegen.

2.2.10 Programming Interface

Das Programming Interface dient dazu, die weiter oben kurz beschriebenen Skripte einzuge-ben, die dann vom APRICOTS-System abgearbeitet werden können.