Diss. ETH No. 13976 Transactional Process Management over Component Systems A dissertation submitted to the Swiss Federal Institute of Technology Zurich for the degree of Doctor of Technical Sciences presented by Heiko Schuldt Diplom-Informatiker, Universit¨atKarlsruhe born October 20, 1969 citizen of Germany Accepted on the recommendation of Prof. Dr. H.-J. Schek, examiner Prof. Dr. G. Alonso, co-examiner 2000 Geleitwort Die Arbeit von Heiko Schuldt ist transaktionellen Prozessen gewidmet, die oberhalb von Komponenten–Systemen angesiedelt sind und daher diese Komponenten system¨ubergreifend verbinden. Dies ist ein sehr aktuelles Thema und ich m¨ochte dazu einige ¨ubergeordnete Gesichts- punkte darstellen. Anwendungsentwicklung mit Zugriff auf grosse Datenmengen findet heute nicht mehr, wie es der klassischen Lehrmeinung entspricht, auf der Basis eines einzigen Datenbank- systems statt, in dem ein unternehmensweites, f¨ur alle Anwendungen verbindliches Datenmodell vorliegt. Vielmehr m¨ochte man Anwendungen entwickeln, die in zusammengesetzten Systemen ablaufen, wobei die Komponenten wieder Datenbanksysteme sein k¨onnen, oder auch allgemeiner als Ressourcen–Verwalter oder Dienstanbieter auftreten. Manche sprechen auch von “Megaprogram- mierung” (Wiederhold, Stanford). Es geht in allen F¨allen um die Verwendung, also das Aufrufen und Ausf¨uhren wohlverstandener Bausteine und um deren Zusammenf¨ugenzu einer wohldefinierten gr¨osseren Einheit. Hierf¨ur hat man auch Begriffe wie Workflow–Management oder Prozessmanage- ment eingef¨uhrt und stellt sich solche neuen Plattformen f¨ur zuk¨unftige Anwendungsentwicklung als Bestandteil einer Middleware–Schicht in einer mehrstufigen Systemarchitektur vor. In einer solchen Umgebung besteht daher ein Programm auch nicht mehr nur aus einer Transaktion oder aus einer Sequenz von Transaktionen, die alle auf der gleichen Datenbank ausgef¨uhrt werden. Vielmehr werden viele Transaktionen als Bausteine, als “Schritte” oder “Aktivit¨aten”zu einem transaktionellen Prozess zusammengefasst, der in mehreren Datenbanksystemen ausgef¨uhrt wird und durch einen Transaktionskoordinator ¨uberwacht wird. Einzelne Schritte in gewissen Kompo- nentensystemen k¨onnen erfolgreich durchgef¨uhrt werden, bei anderen k¨onnen sich Ausnahme– oder Fehlersituation einstellen. Je nach Erfolg oder Misserfolg der bislang gestarteten Schritte ergibt sich die Notwendigkeit, weitere Transaktionen, darunter auch Kompensationstransaktionen, zur Ausf¨uhrung zu bringen oder alternative Schritte auszuf¨uhren. In jedem Fall, auch im Fehlerfall, soll ein transaktioneller Prozess zu einem wohldefinierten, vorgesehenen Ende f¨uhren. Zwischen den einzelnen Schritten eines transaktionellen Prozesses gibt es Abh¨angigkeiten, die ber¨ucksichtigt wer- den m¨ussen. Beispielsweise m¨ochte man garantieren, dass zwei Schritte innerhalb eines Prozesses entweder sequentiell ausgef¨uhrt werden m¨ussen, oder dass bei paralleler Ausf¨uhrung die Richtung eines m¨oglichen Informationsflusses vorgeschrieben ist. Weitere Eigenschaften einzelner Schritte wie Kompensierbarkeit oder Wiederholbarkeit m¨ussen ber¨ucksichtigt werden. So macht es z.B. keinen Sinn, die Ausf¨uhrung eines Schrittes zu beenden, wenn nicht sicher ist, ob man diesen Schritt wieder r¨uckg¨angig machen kann. Auch Interprozess–Abh¨angigkeiten, also Abh¨angigkeiten zwischen parallel laufenden Prozessen erfordern Koordinationsmassnahmen. So muss garantiert werden, dass ein zweiter Prozess nie einen nicht–kompensierbaren Schritt ausf¨uhrt, wenn eine Abh¨angigkeit von einem kompensierbaren Schritt eines anderen transaktionellen Prozesses besteht, dessen Ausgang noch ungewiss ist. Dagegen kann eine Abh¨angigkeit von einem nicht–kompensierbaren Schritt eines anderen Prozesses durchaus erlaubt werden. v vi Geleitwort Die Ahnlichkeiten¨ aber auch die Unterschiede zu der Laufzeitumgebung eines Datenbanksystems werden deutlich: Die Schritte einer DB–Transaktion sind Lese– oder Schreiboperationen auf persistenten Speicherobjekten. Ein Schritt eines transaktionellen Prozesses dagegen ist eine Aktivit¨at,die als DB–Transaktion auf einer DB–Komponente ausgef¨uhrt wird. Jede Aktion einer DB–Transaktion ist kompensierbar. Dagegen kann ein Schritt eines transaktionellen Prozesses entweder kompensierbar oder wiederholbar oder beides sein, oder er ist ein “Pivotschritt”, d.h. weder kompensierbar noch wiederholbar. Bei einer DB–Transaktion gibt es zwei wohldefinierte Ausg¨ange,den erfolgreichen Abschluss oder den Abbruch, der keine Spuren hinterl¨asst. Diese bei- den Ausg¨angewerden einem Programmierer garantiert. In einem transaktionellen Prozess dagegen werden weitere Ausg¨angegarantiert, die durch den Programmierer durch alternative Ausf¨uhrungen spezifiziert werden. In Analogie zu Datenbanken kann man daher auch von der Weiterentwicklung der Datenbank- technologie auf h¨oherer Ebene sprechen, von der aus man nicht Daten, sondern ganze Daten- banken anspricht und durch transaktionelle Prozesse als verallgemeinerte Transaktionen Garantien f¨ur die korrekte Ausf¨uhrung in mehreren Komponentensystemen bekommt. Die Infrastruktur heute verf¨ugbarer Middleware–Produkte in Form von Transaktionsmonitoren oder Transaktions- servern, etwa auch in COM+, ist hinsichtlich der oben aufgestellten Forderungen recht bescheiden. Man bekommt lediglich verteilte DB–Transaktionen, die durch ein Zweiphasen–Commit–Protokoll koordiniert werden. Es gibt daher nur eine “Alles–oder–Nichts”–Garantie, keine Alternativen und daher keine flexible Fehlerbehandlung, keine Ber¨ucksichtigung von Kompensations– oder Wiederholungsaktivit¨aten, keine Ber¨ucksichtigung semantischer Kommutativit¨atund daher keine Unterst¨utzung offen geschachtelter Transaktionen. Diese unbefriedigende Situation zu ¨andern, bedurfte einer Reihe grundlagenorientierter Arbeiten, auf denen die Arbeit Schuldt zun¨achst aufsetzt und die er sehr gekonnt und ¨uberzeugend weiter- entwickelt hat. In den Kernkapiteln der Arbeit stellt H. Schuldt pr¨azise aber ohne ¨ubertrie- benen Formalismus dar, was man genau unter einem transaktionellen Prozesse versteht. Er unter- scheidet folgerichtig “Process Program” als Spezifkation eines transaktionellen Prozesses von seiner Ausf¨uhrung, die er kurz “Process” nennt. Das “Process Program” ist die statische Spezifikation eines Prozesses, die man vor der Ausf¨uhrung auf Wohlgeformtheit ¨uberpr¨ufen m¨ochte. Hierbei wird festgestellt, ob die Spezifikation erlaubt, einen der gew¨unschten alternativen Ausg¨angezu erreichen, wobei man die Terminierungseigenschaften der einzelnen verwendeten Aktivit¨aten in Betracht zieht. Die Definition der korrekten parallelen Ausf¨uhrung eines oder mehrerer Prozesse ist dann die konsequente Verallgemeinerung eines traditionellen Transaktionsschedulers. Neu wird jetzt nicht nur die Kommutativit¨atvon Aktivit¨ateneingebracht, sondern der Scheduler bekommt auch die Kenntnis ¨uber die Kompensation einer ausgef¨uhrten Aktivit¨atund die Terminierungs- eigenschaft einer Aktivit¨at. H. Schuldt hat diese Grundlagen ¨ausserst sorgf¨altig und ausf¨uhrlich zusammengestellt und das sehr erw¨unschte Ziel erreicht, unter pr¨azisegegebenen Voraussetzungen zu beweisen, dass mit seinem Prozess–Scheduler alle parallel ausgef¨uhrten Prozesse garantiert ter- minieren und korrekt ausgef¨uhrt werden. Die Theorie hierzu ist leider nicht sehr einfach, aber H. Schuldt geht sehr konsequent vor und unterscheidet sorgf¨altig mehrere m¨ogliche Korrektheits- kriterien, die sich vor allem durch die Behandlung der Recovery, d.h. durch die Ber¨ucksichtigung von Fehlerf¨allen unterscheiden. Man sieht deutlich, dass die Theorie hierdurch sehr viel komplizierter wird als nur durch das alleinige Behandeln der Korrektheit paralleler Ausf¨uhrung. Selbst dies wird bei transaktionellen Prozessen komplexer, weil beispielsweise im Konfliktfall ein einzelner Prozess eine alternative Ausf¨uhrung einschlagen kann. Im traditionellen Modell dagegen ist hier nur ein vollst¨andiges R¨ucksetzen m¨oglich. Geleitwort vii Nach dieser wichtigen Grundlagenarbeit kommt der Informatik–Ingenieur Schuldt zum Zug. Er gibt Protokolle an, die relativ einfach zu implementieren sind. Sehr bemerkenswert ist dabei die Ver- wendung eines Protokolls von El Abbadi, das unter dem Namen “Ordered Shared Locks” bekannt geworden ist. H. Schuldt sieht aber bei der Anwendung dieses Protokolls allein Nachteile und kom- biniert dieses geschickt mit Zeitstempelverfahren. Er entwickelt daher beinahe so nebenbei auch ein neues Lock–Protokoll und baut geschickt die Terminierungseigenschaften in dieses Protokoll ein. H. Schuldt gibt sich ausserdem nicht damit zufrieden, dass eine Aktivit¨atbeispielsweise kom- pensierbar ist oder nicht. Vielmehr schl¨agter vor, Ausf¨uhrungskosten, insbesondere auch Kosten f¨ur die Kompensation zu ber¨ucksichtigen und damit den Scheduler “kostenbewusst” arbeiten zu lassen. Diese Idee ist deswegen bemerkenswert, weil in der Vergangenheit ein unn¨otiger Streit ent- stand ¨uber die Frage, ob man denn immer eine Kompensation habe. Im neuen Modell hat man immer eine Kompensation, nur kann sie sehr teuer sein, so teuer, dass sich ihre Ausf¨uhrung aus Kostengr¨unden verbietet. Es sind damit die Voraussetzungen geschaffen f¨urzuk¨unftige Produkte, die einen solchen Prozess- manager und daher eine deutlich bessere Infrastruktur f¨urdie Entwicklung verteilter Anwendungen zur Verf¨ugung stellen, in der flexible Ausf¨uhrung mit Ausf¨uhrungsgarantie erm¨oglicht werden kann. Z¨urich, den 28. Februar 2001 Prof. H.-J. Schek Vorwort Die vorliegende Dissertation entstand w¨ahrendmeiner