next up previous
Next: 3.3 Integrationskonzept Up: 3 Geschachtelte dynamische Aktionen für ... Previous: 3.1 Einleitung

Subsections

3.2 Probleme bei der Kombination von geschachtelten dynamischen Aktionen und dynamischen Aktionen für kooperative Anwendungen

Konzepte zur Realisierung des Auftrags- und des Kooperationsprinzips zu integrieren ist nicht trivial, da beide Prinzipien unterschiedliche - teilweise sogar gegensätzliche - Eigenschaften der Konzepte fordern. Nachdem zuerst gezeigt wird, warum sich die Konzepte der geschachtelten dynamischen Aktionen und der dynamischen Aktionen für kooperative Anwendungen nicht einfach durch Kombination aller Eigenschaften integrieren lassen, wird genauer untersucht, wie die Konzepte jeweils durchgesetzt werden. Dazu wird nach einer genauen Betrachtung der Charakteristika beider Prinzipien herausgearbeitet, welche Eigenschaften der beiden Konzepte grundlegend für die Durchsetzung des jeweiligen Prinzips sind, und welche Eigenschaften gebraucht werden, um eine nötige Konsistenz des Konzepts zu gewährleisten. Die herausgearbeiteten Eigenschaften bilden die Grundlage für das im nächsten Abschnitt beschriebene Integrationskonzept.

,,Naiver`` Versuch der Kombination

Die dynamischen Aktionen für kooperative Anwendungen realisieren das Kooperationsprinzip und die geschachtelten dynamischen Aktionen das Auftragsprinzip. Um beide Prinzipien zu integrieren, wäre der direkteste Weg, ein Aktionskonzept zu entwickeln, welches alle Eigenschaften beider Konzepte in sich vereinigt. Dies ist allerdings nicht möglich, da sich einige Eigenschaften beider Konzepte gegenseitig ausschließen.

Strukturell lassen sich beide Konzepte miteinander kombinieren: Das integrierte Konzept besitzt sowohl eine Baumstruktur der dynamischen Aktionen als auch eine Aufteilung der dynamischen Aktionen in Kooperationsgruppen. Wie das Verhältnis von Aktionsbäumen und Kooperationsgruppen ist, muß eine genauere Betrachtung der weiteren Anforderungen ergeben. Folgende Alternativen sind denkbar: Aktionsbäume könnten zum Beispiel komplett in Kooperationsgruppen enthalten sein müssen, sie könnten eine Eins-zu-eins-Beziehung haben oder sie könnten auch orthogonal zueinander sein.

Bezüglich anderer Eigenschaften treten hingegen bei der Integration Probleme auf:

Serialisierbarkeit
  Bei den geschachtelten dynamischen Aktionen sind Aktionsbäume und auch Teilbäume einer Ebene untereinander serialisierbar. Vor- und Nachfahren müssen nicht serialisierbar sein. Bei dynamischen Aktionen für kooperative Anwendungen wird Serialisierbarkeit zwischen Kooperationsgruppen gefordert. Wenn ein Aktionsbaum einer Kooperationsgruppe entspräche, wäre die Serialisierbarkeit von vollständigen Aktionsbäumen gewährleistet. Allerdings könnte die Serialisierbarkeit von Teilbäumen nicht garantiert werden, da innerhalb von Kooperationsgruppen Kommunikation jeder Art möglich ist. Es ist auch nicht möglich, die Granularität der Kooperationsgruppen feiner zu wählen und für einzelne Subaktionen getrennte Kooperationsgruppen zu bilden, da so die Kommunikation zwischen Vater und Sohn unterbunden würde. Außerdem ist das Ziel der dynamischen Aktionen für kooperative Anwendungen, Kooperation zwischen beliebig wählbaren Partnern zu ermöglichen. Diese Partner dürfen in einem kombinierten Konzept nicht auf dynamische Aktionen desselben Aktionsbaums beschränkt sein, so daß es auch möglich sein muß, daß mehrere Aktionsbäume in einer Kooperationsgruppe liegen.

Die unterschiedlichen Serialisierbarkeitsanforderungen in beiden Konzepten lassen sich nicht trivial kombinieren.

Beide Konzepte unterscheiden sich auch in der Art, wie die Serialisierbarkeit durchgesetzt wird. Bei geschachtelten dynamischen Aktionen geschieht dieses durch das nicht-strikte Zweiphasen-Sperrprotokoll. Halten sich dynamische Aktionen an dieses Protokoll, ist Serialisierbarkeit gesichert. Bei den dynamischen Aktionen für kooperative Anwendungen wird Serialisierbarkeit hingegen dynamisch überprüft und zur ihrer Gewährleistung müssen sich die dynamischen Aktionen entsprechend einem dreiphasigen Schema verhalten. Dabei wird die Menge der zugreifbaren Objekte von Phase zu Phase so eingeschränkt, daß die bei den Phasenwechseln überprüfte Serialisierbarkeit der Kooperationsgruppen nicht durch neu entstehende unzulässige Konfliktabhängigkeiten verletzt wird.

Sichtbarkeit von Objektänderungen
 

Im geschachtelten Konzept werden alle Objektänderungen einer Subaktion zunächst nur für ihren Vater bzw. den nächsten Vorfahren in der ersten Phase sichtbar. Zum einen wird durch diese Einschränkung der Sichtbarkeit die Existenz des Auftragnehmers nach außen verborgen und damit das Auftragsprinzip durchgesetzt. Zum anderen könnte die Serialisierbarkeit von kompletten Aktionsbäumen nicht mehr garantiert werden, falls Objektänderungen von Subaktionen zu früh von dynamischen Aktionen aus anderen Aktionsbäumen gelesen werden könnten.

Im kooperativen Konzept werden Objektänderungen von dynamischen Aktionen allgemein sichtbar. Es gibt keine Mechanismen, die die Menge der dynamischen Aktionen, die auf geänderte Objekte zugreifen können, einschränken. Zur Durchsetzung des Kooperationsprinzips ist es auch zwingend notwendig, daß Objektänderungen früh sichtbar werden, da nur so ein beidseitiger Informationsfluß zwischen laufenden dynamischen Aktionen möglich ist.

Auch bezüglich der Sichtbarkeitsregeln ist keine direkte Kombination möglich. Abhängig davon, ob eine dynamische Aktion gerade einen Auftrag ausführt oder ob sie mit einer anderen dynamischen Aktion kooperieren will, werden unterschiedliche Anforderungen an die Sichtbarkeit gestellt.

Für das Kooperationsprinzip relevante Eigenschaften von dynamischen Aktionen für kooperative Anwendungen

Das Konzept der dynamischen Aktionen für kooperative Anwendungen wird im folgenden danach untersucht, welche seiner Eigenschaften für die Durchsetzung des Kooperationsprinzip relevant sind und deshalb in das integrierte Konzept übernommen werden sollten. Das Kooperationsprinzip besagt dabei folgendes:

Kooperationsprinzip
  Mehrere dynamische Aktionen bearbeiten kooperativ Objekte. Dies bedeutet, daß Objektänderungen aufgrund von gemeinsamen Entscheidungen der dynamischen Aktionen zustande kommen können. Um diese Entscheidungen treffen zu können, müssen zwischen den beteiligten dynamischen Aktionen Informationen ausgetauscht werden. Dies geschieht über die Objekte, indem zum Beispiel solche Abläufe auftreten: Eine laufende dynamische Aktion liest Objektänderungen einer anderen laufenden dynamischen Aktion und macht auch selber Änderungen, die diese dynamische Aktion wieder liest. Kooperierende dynamische Aktionen sind in der Regel also nicht serialisierbar. Dynamische Aktionen, die nicht miteinander kooperieren wollen, müssen serialisierbar bleiben.

Zur Durchsetzung des Kooperationsprinzips setzen die dynamischen Aktionen für kooperative Anwendungen folgende Forderungen durch:

Die Dreiphasigkeit der dynamischen kooperativen Serialisierbarkeit wird dazu benötigt, die geforderte Serialisierbarkeit von Kooperationsgruppen durchzusetzen. Dieser Mechanismus eignet sich sehr gut dazu, dieses Konsistenzkriterium durchzusetzen, allerdings gäbe es hierzu auch andere Möglichkeiten. Dreiphasigkeit ist also nicht zwingend zur Durchsetzung des Kooperationsprinzips notwendig.

Das Kooperationsprinzip fordert, daß kooperierende dynamische Aktionen nicht serialisierbar zu sein brauchen, während nicht-kooperierende dynamische Aktionen dieses sein müssen. Um diese Anforderungen systemseitig überwachen zu können, müssen die Kooperationspartner dem System mitgeteilt werden, welches bei den dynamischen Aktionen für kooperative Anwendung automatisch beim Zutritt zu einer Kooperationsgruppe geschieht. Da die Kooperationspartner einer dynamischen Aktion aber nicht immer schon bei ihrem Start feststehen, bietet die dynamische kooperative Serialisierbarkeit den dynamischen Aktionen die Möglichkeit, in der ersten Phase ohne Serialisierbarkeitsanforderungen auf Objekte zuzugreifen und so ihre Kooperationspartner zu finden. Erst bei der Bildung der Kooperationsgruppen, also beim Wechsel in die zweite Phase, wird nachträglich überprüft, ob die Objektzugriffe der ersten Phase bezüglich der jetzt gebildeten Kooperationsgruppen erlaubt waren.

Für das Auftragsprinzip relevante Eigenschaften von geschachtelten dynamischen Aktionen

Analog zum vorherigen Abschnitt wird jetzt das Konzept der geschachtelten dynamischen Aktionen betrachtet.

Auftragsprinzip
  Das Auftragsprinzip besagt, daß eine dynamische Aktion nicht alle ihre Aufgaben selbst erledigen muß, sondern daß sie Teilaufgaben an andere dynamische Aktionen delegieren kann. Außenstehenden dynamischen Aktionen muß der Auftragnehmer verborgen bleiben, damit es für sie so aussieht, als ob alle Tätigkeiten von einer einzigen dynamischen Aktion ausgeführt worden wären.

Das Auftragsprinzip wird durch folgende Eigenschaften der geschachtelten dynamischen Aktionen realisiert:

Die Anforderungen der Serialisierbarkeit von Aktionsbäumen aus dem Konzept der geschachtelten dynamischen Aktionen wird nicht zur Durchsetzung des Auftragsprinzips benötigt. Das Verbergen der Auftragnehmer vor äußeren dynamischen Aktionen wird nur durch die Sichtbarkeitsregeln realisiert. Serialisierbarkeit bewirkt, daß Aktionsbäume konsistent frei von Nebenläufigkeitsanomalien ablaufen können.

Das Auftragsprinzip beinhaltet auch eine Forderung an die Fehlerbehandlung: Ein Abbruch des Auftragnehmers darf nicht zum Abbruch des Auftraggebers führen. Diese Forderung ist bei den geschachtelten dynamischen Aktionen schon umfassend gelöst worden (siehe Abschnitt 2.6.2) und betrifft wegen der Orthogonalität von Fehlerbehandlung und Nebenläufigkeitskontrolle nicht die Entwicklung eines integrierten Nebenläufigkeitskonzepts.


next up previous
Next: 3.3 Integrationskonzept Up: 3 Geschachtelte dynamische Aktionen für ... Previous: 3.1 Einleitung


Armin Kruse- HTML version created 7/25/1997