Ausgangspunkt für die Entwicklung des vorgestellten Integrationskonzepts war die Beobachtung, daß zwischen den Aktivitäten der Benutzer eines verteilten Systems oft Beziehungen existieren. Diese Beziehungen resultieren in einem Informationsfluß zwischen den Transaktionen, die ein verbreitetes Mittel zur Beschreibung solcher Aktivitäten in verteilten Systemen sind.
Eine Betrachtung der in der Praxis auftretenden Arbeitsabläufe hat gezeigt, daß der Informationsfluß fast immer nach einem von zwei Prinzipien verläuft: dem Auftrags- oder dem Kooperationsprinzip. Diese beiden Prinzipien stellen bei der Steuerung von Transaktionen unterschiedliche Anforderungen an die Nebenläufigkeitskontrolle, wohingegen die Mechanismen zur Fehlerbehandlung nicht Bestandteil des jeweiligen Prinzips sind, sondern als korrekt arbeitend vorausgesetzt werden.
Beide Prinzipien werden einzeln bereits durch bekannte erweiterte Transaktionssysteme unterstützt. Mit den offen und den geschlossen geschachtelten Transaktionen wurden die zwei bekanntesten Konzepte zur Unterstützung des Kooperations- beziehungsweise des Auftragsprinzips vorgestellt. Am Beispiel des DOM Transaktionsmodells wurde gezeigt, daß die Entwicklung eines Integrationskonzepts durch Kombination beider geschachtelter Transaktionsmodelle nicht möglich ist. Der Grund hierfür liegt darin, daß diese Transaktionssysteme nicht zwischen Fehlerbehandlung und Nebenläufigkeitskontrolle trennen, sondern zur Durchführung der Fehlerbehandlung das spezielle nebenläufige Verhalten der Transaktionen ausnutzen. Die für die Integration notwendigen Änderungen im Bereich der Nebenläufigkeitskontrolle führen daher direkt zu Problemen bei der Fehlerbehandlung.
Das CONCORD Modell versucht daher, Auftrags- und Kooperationsprinzip
nicht auf der Basis von offen oder geschlossen geschachtelten
Transaktionen durchzusetzen, sondern wählt statt dessen den Weg einer
expliziten Spezifizierung der Beziehungen zwischen den Aktivitäten der
Benutzer in Kombination mit einem versionierten Objektsystem. Die
Untersuchung dieses Ansatzes hat aber gezeigt, daß Auftrags- und
Kooperationsprinzip auf diese Weise nur durchgesetzt werden können,
indem die Anwender in großem Umfang die Aufgaben der
Nebenläufigkeitskontrolle und Fehlerbehandlung zur Konsistenzerhaltung
der Objekte übernehmen. Diese Aufgabe ist in großen verteilten
Systemen mit vertretbarem Aufwand nicht zufriedenstellend zu lösen.
Das Konzept der dynamischen Aktionen garantiert im Gegensatz zu den Transaktionskonzepten eine korrekte Fehlerbehandlung unabhängig von den eingesetzten Mechanismen der Nebenläufigkeitskontrolle. Daher lassen sich hier beide Prinzipien realisieren und auch integrieren, ohne die Fehlerbehandlung zu beeinflussen. Es existieren mit den geschachtelten dynamischen Aktionen und den dynamischen Aktionen für kooperative Anwendungen bereits zwei auf dynamischen Aktionen basierende Konzepte, die jeweils das Auftrags- beziehungsweise das Kooperationsprinzip realisieren. Durch Integration dieser beiden Konzepte wurde in dieser Arbeit ein Konzept entwickelt, welches das Auftrags- und das Kooperationsprinzip unterstützt.
Bei der Entwicklung des Integrationskonzepts wurde herausgearbeitet, daß die Mechanismen der Nebenläufigkeitskontrolle zwei verschiedene Aspekte betreffen: die Serialisierbarkeit von dynamischen Aktionen und die Sichtbarkeit von Objektzugriffen. An die Serialisierbarkeit stellen beide Prinzipien die gleiche Forderung: Sowohl Kooperationspartner als auch Auftraggeber und Auftragnehmer müssen untereinander nicht zwingend serialisierbar sein. Es wurde außerdem dargelegt, daß zur Vermeidung von unerwünschten Nebenläufigkeitsanomalien Serialisierbarkeit zwischen dynamischen Aktionen, die nicht direkt oder indirekt in Beziehung stehen, durchgesetzt werden sollte. Das im Rahmen der dynamischen Aktionen für kooperative Anwendungen eingeführte Konsistenzkriterium der dynamischen kooperativen Serialisierbarkeit setzt genau diese Anforderungen durch und wurde deshalb in das Integrationskonzept übernommen. Nach diesem Konsistenzkriterium werden dynamische Aktionen, die nicht serialisierbar sein müssen, zu Kooperationsgruppen zusammengefaßt. Zwischen dynamischen Aktionen aus unterschiedlichen Kooperationsgruppen wird Serialisierbarkeit garantiert.
Beide Prinzipien unterscheiden sich aber in ihren Anforderungen an die Sichtbarkeit von Objektänderungen, da Ergebnisse eines Auftragnehmers bei Beendigung der Aufgabe nur für den Auftraggeber sichtbar werden sollen, aber zur Kooperation Zwischenergebnisse sofort ausgetauscht werden müssen. Da es ausschließlich von der Anwendungssemantik abhängt, ob in einer bestimmten Situation das Auftrags- oder das Kooperationsprinzip angewandt wird, ist in dieser Arbeit der Mechanismus der Objektkontrolle eingeführt worden. Mit Hilfe der Objektkontrolle kann eine dynamische Aktion individuell für jedes Objekt bestimmen, wann Zugriffe allgemein und wann sie nur von der dynamischen Aktion selbst und möglichen Auftragnehmern erlaubt sind. Durch Anforderung der Objektkontrolle für die vom Auftragnehmer benutzten Objekte kann ein Auftraggeber so das Auftragsprinzip durchsetzen. Die Objektkontrolle läßt sich auch dazu verwenden, bestimmte Objekte für die Kooperation zweier dynamischer Aktionen zu reservieren, indem die Objektkontrolle für diese Objekte von einem gemeinsamen Vorfahren erworben wird. Insbesondere die in Abschnitt 3.3.3 vorgenommene Erweiterung der Objektkontrolle auf Kooperationsgruppen erlaubt die Reservierung von Objekten für alle dynamischen Aktionen, die nach dem Konsistenzkriterium miteinander kooperieren dürfen.
Das Integrationskonzept wurde mit der Zielsetzung einer größtmöglichen Verträglichkeit mit den beiden zugrundeliegenden Konzepten entwickelt. Durch die Modellierung von Schachtelung und die Einbettung in das formale Modell, welches in [Mock 1994] für die dynamischen Aktionen für kooperative Anwendungen eingeführt wurde, konnte die Verträglichkeit nachgewiesen werden. Insbesondere wurde gezeigt, daß das Integrationskonzept die Eigenschaften der Abbruch- und der Commit-Korrektheit garantiert und daß das Konsistenzkriterium der dynamischen kooperativen Serialisierbarkeit auch bei Schachtelung und Objektkontrollen erfüllt wird.
Das Integrationskonzepts wird mit dem ebenfalls hier entwickelten kooperativen Sperrverfahren für geschachtelte dynamische Aktionen realisiert. Um auch auf der Ebene der Sperrverfahren die Verträglichkeit mit den zugrundeliegenden Konzepten zu gewährleisten, basiert das eingeführte kooperative Sperrverfahren auf dem geschachtelten Sperrverfahren, welches das Konzept der geschachtelten dynamischen Aktionen realisiert, und auf dem (flachen) kooperativen Sperrverfahren zur Realisierung der dynamischen Aktionen für kooperative Anwendungen.
Zur Durchsetzung des Konsistenzkriteriums der dynamischen kooperativen Serialisierbarkeit wurde aus dem flachen kooperativen Sperrverfahren das dreiphasige Verhalten einschließlich der Validierung übernommen. Die Schachtelung der dynamischen Aktionen machte ähnlich dem geschachtelten Sperrverfahren zwei Ebenen von Sperren notwendig: die kooperativen Sperren und die Benutzungssperren. Die kooperativen Sperren setzen dabei den Mechanismus der Objektkontrolle um und garantieren durch die in Abschnitt 3.4.3 beschriebenen Vergaberegeln die dynamische kooperative Serialisierbarkeit, während die Benutzungssperren der Synchronisation von Objektzugriffen innerhalb von Aktionsbäumen dienen.
Das kooperative Sperrverfahren wurde in einer Komponente zur Sperrenverwaltung implementiert. Zu diesem Zweck wurde eine Schnittstelle beschrieben, die die notwendigen Operationen zur Anforderung und Freigabe von Sperren zur Verfügung stellt. Ausführlich wurden auch die Algorithmen und Datenstrukturen beschrieben, mit denen die Sperren verwaltet und die Vergabe der Sperren überprüft werden können.
Die Implementierung wurde für zwei Szenarien vorgestellt: zum einen als eigenständiges Modul zur Nebenläufigkeitskontrolle, welches von Anwendungsprogrammen als Bibliothek benutzt werden kann, und zum anderen als mögliche Nebenläufigkeitskontrolle des verteilten Aktionssystems für dynamische Aktionen. In beiden Implementierungen benutzt die Sperrenverwaltung zur Überprüfung der Kooperationsgruppen-Eigenschaften und zur Validierung den in [Theisohn 1996] beschriebenen verteilten Abhängigkeitsgraphen. Da nur innerhalb dieses Abhängigkeitsgraphen verteilte Berechnungen durchgeführt werden müssen und die Sperrenverwaltung so konzipiert ist, daß sie ihre Entscheidung über eine Sperrenvergabe aufgrund von lokalen Informationen trifft, kann sowohl im eigenständigen Modul als auch im verteilten Aktionssystem die identische Komponente zur Sperrenverwaltung verwendet werden. Schließlich wurde noch zur Demonstration des kooperativen Sperrverfahrens eine interaktive Nutzerschnittstelle für die Nebenläufigkeitskontrolle entwickelt.
Der in dieser Arbeit eingeführte Mechanismus der Objektkontrolle erlaubt es, den Informationsfluß zwischen dynamischen Aktionen zu steuern, ohne die durch die dynamische kooperative Serialisierbarkeit bestimmte konsistente Ausführung der dynamischen Aktionen zu verletzen. Dadurch wird es möglich, durch weitergehende Mechanismen zur Steuerung der Sichtbarkeit von Objektänderungen die Beziehungen zwischen unterschiedlichen dynamischen Aktionen noch gezielter zu unterstützen. In der Realisierung des Auftragsprinzips ist zum Beispiel eine weitere Kapselung von Auftragnehmern denkbar: Durch geeignete Mechanismen könnte ein Auftraggeber diejenigen Objekte spezifizieren, die der Auftragnehmer benutzen darf, oder auch bestimmte Objekte, die beispielsweise für die Kooperation mit anderen dynamischen Aktionen verwendet werden, vor Zugriff durch den Auftragnehmer schützen. Eine andere Möglichkeit von erweiterten Sichtbarkeitsregeln bestünde darin, Objektänderungen nur gezielt für explizit angegebene dynamische Aktionen freizugeben. Dadurch könnte zur Kooperation zwischen zwei beliebigen dynamischen Aktionen einer Kooperationsgruppe systemseitig ein unterbrechungsfreier und vor anderen dynamischen Aktionen verborgener Informationsfluß garantiert werden.