6.1 Persistente Speicherung
Der Benutzeragent (User Agent) stellt für die Benutzungsoberfläche (das Tasklist Interface) und somit für den Benutzer die einzige Verbindung zum System dar. Außerdem spielt er für den Object Transaction Service (OTS) die Rolle eines Recoverable Server, das heißt einer Komponente, die nach einem Absturz ihren Zustand wiederherstellen kann und die am transak-tionalen Protokoll teilnimmt. Aus diesen Gründen ist es unbedingt notwendig, daß der Benut-zeragent fehlertolerant ist und daß die an ihn übermittelten Informationen nicht verloren gehen.
Um dies zu erreichen, bedient sich der Benutzeragent der Dienste des Storage Agent. Immer, wenn in den bisherigen Ausführungen die Rede davon war, daß der Benutzeragent sich ir-gendeine Information merkt, bedeutet dies implizit immer einen Zugriff auf den Storage Agent.
Dies gilt selbstverständlich auch, wenn der Benutzeragent wieder auf einmal abgespeicherte Informationen zugreifen muß.
neue Aufgabe ConTract
Manager
Storage Agent
Tasklist Interface und Benutzer
speichern
Benutzer-agent
angefangene Aufgabe speichern
beendete Aufgabe speichern
Abbildung 29: Die Bedeutung des Storage Agent
Prinzipiell gilt, daß jedesmal, wenn ein neuer Auftrag von der ConTract Engine oder ein teil-weise oder vollständig bearbeiteter Auftrag vom Tasklist Interface beim Benutzeragent ein-trifft, diese Information mit Hilfe des Storage Agent persistent gemacht wird. Dazu ruft der Benutzeragent die Methode
void commitSession(in SessionId session) raises ( APRICOTS_Definitions::DBError,
APRICOTS_Definitions::NotFound );
auf (siehe Schnittstellen des Benutzeragenten im Anhang), die dafür sorgt, daß die zuvor an den Storage Agent übergebenen Daten oder Änderungen unwiderruflich festgeschrieben
wer-den, bevor er weiterarbeitet. Auf diese Weise hat der Benutzeragent nach einem Neustart im-mer Zugriff auf den aktuellen Zustand aller Aufgaben: er weiß, welche neu sind, welche vom Benutzer schon in Angriff genommen wurden, bei welchen er noch auf den Ausgang der Transaktion warten muß und welche er nur aufbewahrt, bis der Benutzer sich entscheidet, sie zu löschen.
Daraus folgt natürlich, daß auch der Storage Agent sehr zuverlässig sein muß: er bietet schließlich für den Benutzeragenten den einzigen Zugriff auf persistenten Speicher. Versagt er, dann ist ein Weiterarbeiten für den Benutzeragenten nicht mehr möglich, da er nicht mehr die von den übrigen Komponenten von APRICOTS erwartete Eigenschaft garantieren kann, daß keine an ihn geschickten Informationen verloren gehen. Die Fehlertoleranz des Benutzeragen-ten hängt also direkt von der Verfügbarkeit des Storage Agent ab.
6.2 Ausfall von APRICOTS-Komponenten
Da der Benutzeragent mit vielen anderen Komponenten des APRICOTS-Systems zusammen-arbeitet wird er in der Ausführung seiner Aufgaben empfindlich getroffen, wenn die eine oder andere dieser Komponenten ausfällt.
ConTract Engine Storage
Agent
OTS Tasklist
Interface
Benutzer-agent
Sysadmin Interface
Abbildung 30: Die mit dem Benutzeragenten interagierenden Komponenten von APRICOTS
6.2.1 OTS nicht verfügbar
Falls das OTS entweder ausgefallen oder nicht erreichbar ist, gibt es für den Benutzeragenten keine Möglichkeit, festzustellen, in welchem Zustand sich eine Transaktion befindet. Dies ist aber insbesondere beim Neustart unerläßlich, da sonst der Benutzer unter Umständen an einer Aufgabe arbeitet, deren Transaktion schon längst abgebrochen ist. Die einfachste Möglichkeit wäre hier, gemäß dem vom OTS verwendeten Ansatz des presumed Abort vorzugehen, die Transaktion als gescheitert anzusehen und, sobald das OTS wieder verfügbar ist, entsprechend zu votieren.
Falls jedoch das OTS nicht ausgefallen ist und die Transaktion also nicht abgebrochen werden müßte, der Benutzeragent aber aufgrund eines Kommunikationsfehlers keine Verbindung her-stellen kann, würde ein Vorgehen nach dem presumed Abort zu einem unnötigen Verlust des vom Benutzer bisher Erreichten führen. Es gilt hier also abzuwägen, was wichtiger ist: Soll der Benutzer weiterarbeiten, auch wenn er von der Transaktionverwaltung abgeschnitten ist und eventuell das von ihm mühsam erarbeitete Ergebnis hinterher weggeworfen wird; oder soll er seine Arbeit unterbrechen und die vorliegenden Aufträge sicherheitshalber unangetastet lassen?
Um es dem Benutzer zu ersparen, an einer eigentlich schon abgebrochenen Aufgabe zu arbei-ten, wird in dieser Implementierung des Benutzeragenten der Ansatz des presumed Abort ver-folgt.
Für Aufgaben, die zu Transaktionen gehören, bei denen durch das OTS schon eine Prepare-Nachricht verschickt wurde, liegt der Fall jedoch anders. Da der Benutzeragent durch das Ak-zeptieren dieser Nachricht erklärt, sowohl an einer erfolgreichen Beendigung als auch an einem Zurücksetzen der Transaktion teilnehmen zu können, kann er in diesem Fall nicht einfach von einem Abbruch ausgehen, sondern muß solange versuchen, Kontakt mit dem OTS aufzuneh-men, bis er von diesem den Ausgang der Transaktion erfährt.
6.2.2 Storage Agent nicht verfügbar
Einen genauso unangenehmen Fall stellt der Ausfall des Storage Agent dar. Der Benutzeragent ist darauf angewiesen, bestimmte Daten persistent speichern zu können, da die ihn aufrufenden Komponenten davon ausgehen, daß das, was sie an ihn übermitteln, nicht verloren geht. Insbe-sondere bei einem Neustart braucht der Benutzeragent unbedingt die von ihm abgelegten Da-ten.
Während also ein Arbeiten ohne OTS noch denkbar ist, kann der Benutzeragent ohne die Ver-fügbarkeit des Storage Agent nicht mehr für einen korrekten Programmablauf garantieren; bei-spielsweise ist eine sinnvolle Teilnahme am transaktionalen Protokoll nicht mehr möglich.
Aus diesen Gründen stellt der Benutzeragent in der vorliegenden Fassung die Arbeit ein und liefert eine entsprechende Exception an den Aufrufer, falls er auf den Storage Agent nicht zu-greifen kann.
6.2.3 ConTract Engine nicht verfügbar
Wenn die ConTract Engine ausfällt, die einen ConTract bearbeitet, an dessen Abarbeitung auch der Benutzer - und somit der Benutzeragent - beteiligt ist, hat dies zwei Konsequenzen: zum einen erhält der Benutzeragent keine neuen Aufgaben und zum anderen kann er die durch den Benutzer fertig bearbeiteten nicht an die Engine zurückliefern.
Während das erste kein Problem darstellt, ist zu überlegen, was der Benutzeragent tun kann, wenn er die vom Tasklist Interface über die Schnittstelle (siehe Schnittstellen im Angang)
void giveDoneTask(
in string taName,
in string tasklistInfo,
in APRICOTS_Definitions::FileSequence params) raises (AgentError);
übermittelten Arbeitsergebnisse des Benutzers nicht an die ConTract Engine weiterleiten kann.
Eine Möglichkeit besteht darin, der Oberfläche einen erfolgreichen Ablauf vorzutäuschen, die Aufgabe zwischenzuspeichern und später noch einmal zu versuchen, selbständig die ConTract Engine zu kontaktieren. Da das System jedoch das Prinzip des presumed Abort verwendet, wird die zu dieser Aufgabe gehörende Transaktion früher oder später sowieso abgebrochen, wenn die ConTract Engine als der Transaction Originator ausfällt. Aus diesem Grunde ist es sinnvoll, dem Benutzer sofort eine Fehlermeldung zukommen zu lassen. Er hat dann die Mög-lichkeit, seine Arbeit über die giveTouchedTask-Schnittstelle des Benutzeragenten abspei-chern zu lassen und kann die erarbeiteten Ergebnisse für zukünftige gleiche oder ähnliche Auf-gaben verwenden.
6.2.4 Tasklist Interface nicht verfügbar
Der Fall, daß das Tasklist Interface nicht verfügbar ist, stellt keinen Fehlerfall und somit auch kein Problem dar, da der Benutzeragent genau zu dem Zweck entwickelt wurde, den Benutzer dem System gegenüber zu repräsentieren, wenn dieser beispielsweise am Feierabend die Be-nutzungsoberfläche herunterfährt.