Im vorherigen Abschnitt wurde aufgezeigt, welche Eigenschaften ein auf dynamischen Aktionen basierendes Konzept zur Integration von Auftrags- und Kooperationsprinzip haben muß. Davon ausgehend wird jetzt das Konzept der geschachtelten dynamischen Aktionen für kooperative Anwendungen vorgestellt.
Die Auftraggeber-Auftragnehmer-Beziehungen zwischen dynamischen Aktionen werden wie bei den geschachtelten dynamischen Aktionen durch eine Strukturierung in Aktionsbäume realisiert. Die Zusammenfassung von Kooperationspartnern zu Kooperationsgruppen wird von den dynamischen Aktionen für kooperative Anwendungen übernommen. Dabei dürfen sich Aktionsbäume nicht über mehrere Kooperationsgruppen erstrecken: Sofern eine (Sub-) Aktion Teil einer Kooperationsgruppe ist, müssen alle anderen (Sub-) Aktionen dieses Aktionsbaums auch dieser Kooperationsgruppe beitreten. In einer Kooperationsgruppe können mehrere Aktionsbäume enthalten sein. Eine genauere Diskussion des Verhältnisses von Aktionsbäumen von Kooperationsgruppen folgt in Unterabschnitt 3.3.1.
Die Diskussion im vorigen Abschnitt hat gezeigt, daß zur Durchsetzung des Auftragsprinzips keine Anforderungen bezüglich der Serialisierbarkeit gestellt werden müssen. Das Kooperationsprinzip hingegen fordert Serialisierbarkeit von dynamischen Aktionen aus verschiedenen Kooperationsgruppen und keine Serialisierbarkeit innerhalb einer Kooperationsgruppe. Zur Durchsetzung dieser Anforderungen wird das Kriterium der dynamischen kooperativen Serialisierbarkeit aus dem Konzept der dynamischen Aktionen für kooperative Anwendungen übernommen. Wie dort wird sie mit Hilfe des dreiphasigen Verhaltens der dynamischen Aktionen durchgesetzt.
Im Unterschied zu den geschachtelten dynamischen Aktionen wird hier nicht zwingend die Serialisierbarkeit von ganzen Aktionsbäumen oder Teilbäumen gefordert, sofern sie innerhalb einer Kooperationsgruppe liegen. Nebenläufigkeitsanomalien, zu deren Vermeidung die Serialisierbarkeit gefordert wurde, können aber individuell für jedes Objekt mit Hilfe der Mechanismen zur Sichtbarkeit von Objektänderungen vermieden werden.
In Bezug auf die Sichtbarkeit von Objektänderungen stellen Auftrags- und Kooperationsprinzip unterschiedliche Anforderungen: Zur Durchsetzung des Auftragsprinzips dürfen Objektänderungen von Auftragnehmern nur für den jeweiligen Auftraggeber sichtbar werden, wohingegen das Kooperationsprinzip nur dann durchgesetzt werden kann, wenn Objektänderungen zumindest für die Kooperationspartner sichtbar sind. Das Konzept der dynamischen Aktionen für kooperative Anwendungen als Realisierung des Kooperationsprinzip stellt gar keine Mechanismen zur Einschränkung der Sichtbarkeit von Objektänderungen zur Verfügung, d. h. Objektänderungen sind nach Freigabe durch die ändernde dynamische Aktion für alle anderen dynamischen Aktionen sichtbar.
Diese beiden Anforderungen werden integriert, indem die Sichtbarkeit von Objektänderungen individuell durch die Applikationen gesteuert werden kann: Mit der weiter unten in Unterabschnitt 3.3.2 genauer beschriebenen Objektkontrolle kann ein Auftraggeber gezielt für jedes Objekt entscheiden, ob die Änderungen des Auftragnehmers an diesem Objekt nur für ihn oder auch für andere dynamische Aktionen sichtbar sind.
Die Objektkontrolle läßt sich nicht nur auf Auftraggeber und Auftragnehmer anwenden, sondern auch auf Kooperationsgruppen: Die Mitglieder einer Kooperationsgruppe können für einzelne Objekte festlegen, wie lange Änderungen nur innerhalb der Kooperationsgruppe sichtbar sind. Diese Erweiterung der Objektkontrolle auf Kooperationsgruppen wird in Unterabschnitt 3.3.3 beschrieben.
Kooperation soll zwischen (Sub-) Aktionen auch aus unterschiedlichen Aktionsbäumen möglich sein. Da Kooperationspartner sich in derselben Kooperationsgruppe befinden müssen und mit den kooperierenden dynamischen Aktionen die jeweiligen kompletten Aktionsbäume auch zu derselben Kooperationsgruppe gehören müssen, enthält eine Kooperationsgruppe also einen oder mehrere komplette Aktionsbäume, wie exemplarisch in Abbildung 3.1 dargestellt ist.
In diesem Beispiel können beliebige (Sub-) Aktionen aus den beiden Aktionsbäume innerhalb von K1 miteinander kooperieren, während eine Kooperation mit einer Aktion aus K2 nicht möglich ist. Die dynamischen Aktionen A1 und A2 haben mehrere Sohnaktionen zur Erledigung von Unteraufträgen erzeugt. Um diese Aufträge durchzuführen, kann es zum Beispiel nötig sein, daß A1,2 und A2,1 miteinander kooperieren, wodurch die gesamten Aktionsbäume von A1 und A2 derselben Kooperationsgruppe beitreten müssen.
Eine Objektkontrolle kann nur dann erworben werden, wenn höchstens Vorfahren der anfordernden dynamischen Aktion die Objektkontrolle über das betreffende Objekt besitzen.
Eine dynamische Aktion kann also zu einem beliebigen Zeitpunkt die Objektkontrolle über ein Objekt anfordern. Wenn die Aktionsverwaltung ihr diese gewährt, kann sie die Objektkontrolle solange behalten wie nötig und anschließend wieder abgeben. Während eine dynamische Aktion die Objektkontrolle über ein Objekt hält, kann sie sicher sein, daß das Objekt nur von ihr selbst oder ihren Nachfahren geändert oder gelesen werden kann. Das Objekt existiert während dieser Zeit praktisch nur für dynamische Aktionen innerhalb des Teilbaums, dessen Wurzel die dynamische Aktion ist, die die Objektkontrolle hält.
Es können mehrere dynamische Aktionen gleichzeitig die Objektkontrolle über dasselbe Objekte besitzen, sofern sie alle untereinander in einem Vorfahre-Nachfahre-Verhältnis stehen. Objekte sind dann nur für die dynamischen Aktionen sichtbar, die in dem Teilbaum liegen, dessen Wurzel die tiefste dynamische Aktion im Baum ist, die eine Objektkontrolle hält. Wenn in Abbildung 3.1 zum Beispiel die dynamischen Aktionen A1 und A1,2 die Objektkontrolle auf einem Objekt o1 besitzen, wäre es für die dynamischen Aktionen A1,2, A1,2,1 und A1,2,2 sichtbar.
Der Mechanismus der Objektkontrolle hat Ähnlichkeit mit dem nicht-strikten Zwei-Phasen-Sperrverfahren der geschachtelten dynamischen Aktionen (siehe Abschnitt 2.6.2), wobei Anfordern und Freigeben von Sperren dem Anfordern und Abgeben der Objektkontrolle entsprechen. Zwischen beiden gibt es aber einen entscheidenden Unterschied: Die Sperren müssen zweiphasig angefordert und freigegeben werden. Dieses bedeutet zum einen, daß Sperren einer dynamischen Aktion auf die bearbeiteten Objekte nicht unabhängig voneinander angefordert werden können, da sobald eine Sperre auf einem Objekt freigegeben wurde, keine weitere Sperre mehr angefordert werden kann. Zum anderen ist es deshalb auch nicht möglich, daß eine dynamische Aktion auf einem Objekt mehrfach hintereinander eine Sperre anfordert und wieder freigibt. Objektkontrollen hingegen können von einer dynamischen Aktion für jedes Objekt mehrfach angefordert und abgegeben werden. Außerdem gibt es keine Abhängigkeiten zwischen den Objektkontrollen, die eine dynamische Aktion auf unterschiedliche Objekte besitzt. Die Applikation ist dadurch in der Lage, Objektkontrolle für jedes Objekt individuell so anzufordern und abzugeben, wie es ihre Semantik erfordert.
Zur Realisierung des Auftragsprinzips lassen sich mit Hilfe der Objektkontrolle die Ergebnisse und damit die Existenz eines Auftragnehmers nach außen verbergen, indem der Auftraggeber vor dem Start des Auftragnehmers die Objektkontrolle über alle Objekte erwirbt, die der Auftragnehmer ändert.
Die Eigenschaft der dynamischen kooperativen Serialisierbarkeit fordert innerhalb von Kooperationsgruppen keine Serialisierbarkeit von dynamischen Aktionen, wodurch es zwischen diesen dynamischen Aktionen zu Nebenläufigkeitsanomalien kommen könnte. Diese können aber mit Hilfe der Objektkontrollen verhindert werden: Solange eine dynamische Aktion eine Objektkontrolle für ein Objekt besitzt, ist ein Zugriff für alle anderen dynamischen Aktionen außer den Nachfahren verboten, wodurch bei diesem Objekt für die Zeit der gehaltenen Objektkontrolle keine Nebenläufigkeitsanomalien auftreten kann. Während die dynamische kooperative Serialisierbarkeit zwischen nicht-kooperierenden dynamischen Aktionen unabhängig von den jeweils zugegriffenen Objekten Nebenläufigkeitsanomalien ausschließt, können zwischen Kooperationspartnern durch die Objektkontrolle solche Anomalien mit feiner Granularität, nämlich für jedes einzelne Objekt, verhindert werden. Dadurch können die Situationen, in denen die Applikation mögliche Nebenläufigkeitsanomalien berücksichtigen muß, auf solche reduziert werden, an denen tatsächlich Informationsfluß stattfinden soll und aus diesem Grund die Objektkontrolle abgegeben werden muß.
Die Tatsache, daß eine Objektkontrolle nur Objektzugriffe vom Besitzer der Objektkontrolle und dessen Nachfahren erlaubt, läßt sich auch bei der Kooperation nutzen: Angenommen zwei Brüder kooperieren miteinander, dann findet gezielt zwischen diesen beiden ein Informationsfluß über ein oder mehrere Objekte statt. Die Inhalte dieser Objekte sind aber auch für andere dynamische Aktionen les- und änderbar, was dazu führen kann, daß durch unerwartete Objektänderungen unbeteiligter dynamischer Aktionen der Informationsfluß zwischen den Kooperationspartnern unterbrochen wird. Indem die Vater-Aktion der kooperierenden Brüder für die betroffenen Objekte eine Objektkontrolle erwirbt, wird dieser Informationsfluß vor Unterbrechungen geschützt. Lediglich weitere nebenläufige Brüder einschließlich ihrer Nachfahren könnten den Informationsfluß der kooperierenden dynamischen Aktionen noch stören. Da die dynamischen Aktionen, die den Informationsfluß überhaupt noch stören könnten, alle Nachfahren derselben dynamischen Aktion sind, hat die Applikation oft weitere Informationen über deren Verhalten und kann so das Risiko gut einschätzen, ob der Informationsfluß durch nicht-kooperierende dynamische Aktionen gestört und damit unterbrochen werden könnte. Allgemein läßt sich ein Informationsfluß zwischen zwei kooperierenden dynamischen Aktionen schützen, indem ein gemeinsamer Vorfahre, falls er existiert, die Objektkontrolle über die gemeinsam genutzten Objekte erwirbt.
 |
Abbildung 3.2 zeigt einen möglichen Ablauf der dynamischen Aktionen aus Abbildung 3.1. In diesem Beispiel ist zu sehen, wann die einzelnen dynamischen Aktionen die Objektkontrolle über ein Objekt o1 besitzen, und es läßt sich daran veranschaulichen, wie durch die Objektkontrolle das Auftragsprinzip realisiert und Kooperation zwischen dynamischen Aktionen unterstützt werden kann.
Zu Beginn vergibt A1 einen Auftrag an A1,1. Um die Ergebnisse des Auftragnehmers vor fremden dynamischen Aktionen wie zum Beispiel A2 und A3 zu schützen, fordert A1 vor dem Auftrag eine Objektsperre über das Objekt o1 an, das das Ergebnis von A1,1 enthalten wird. A1,1 erwirbt für die Zeit ihrer Berechnung auch eine Objektsperre auf o1, um eigene Zwischenergebnisse vor anderen dynamischen Aktionen zu verbergen und erst ihr Endergebnis nach außen sichtbar zu machen. Zwischen den Zeitpunkten t1 und t2 wollen die dynamischen Aktionen A1,2,1 und A1,2,2 miteinander kooperieren, indem sie mehrfach über o1 Informationen austauschen. Um diese Informationen, die nur für diese beiden dynamischen Aktionen bestimmt sind, vor dem Zugriff anderer dynamischer Aktionen zu schützen, erwirbt ihr gemeinsamer Vater A1,2 für die Zeit der Kooperation eine Objektsperre auf o1. Nachdem alle Aufträge von A1 erledigt worden sind, möchte sie ihr Ergebnis der anderen Toplevel-Aktion derselben Kooperationsgruppe A2 zur Verfügung stellen. Dafür muß sie die Objektsperre abgeben, damit A2 anschließend die Möglichkeit hat, selbst eine Objektsperre zu erwerben und dieses Objekt zu bearbeiten.
Wenn zwei dynamische Aktionen aus unterschiedlichen Kooperationsgruppen über ein Objekt miteinander kooperieren, gibt es einen Moment, indem die eine dynamische Aktion die Objektkontrolle bereits abgegeben, die andere die Objektkontrolle aber noch nicht angefordert hat. Genau dann kann bei validierten Kooperationspartnern eine noch nicht validierte dynamische Aktion aus einer anderen Kooperationsgruppe auf dieses Objekt zugreifen. (In Abbildung 3.2 ist der Zeitpunkt t3 zum Beispiel ein solcher Moment, in dem A3 auf das Objekt zugreifen könnte.) Die dynamische kooperative Serialisierbarkeit verbietet in diesem Fall aber, daß einer der beiden Kooperationspartner erneut auf das Objekt zugreift, da dann die Serialisierbarkeit von dynamischen Aktionen aus unterschiedlichen Kooperationsgruppen nicht mehr gewährleistet werden könnte. Die fremde dynamische Aktion hat also durch ihren Zugriff eine weitere Kooperation über dieses Objekt unmöglich gemacht.
Dieser Fall soll mit Hilfe der Objektkontrolle vermieden werden. Zu diesem Zweck betrachtet man die Kooperationsgruppe selbst als ,,virtueller`` Vater aller Toplevel-Aktionen dieser Kooperationsgruppe und erlaubt, daß für eine Kooperationsgruppe auch Objektkontrollen erworben werden können. Kooperation über Objekte, für die die Kooperationsgruppe die Objektkontrolle besitzt, sind dann vor Unterbrechungen durch dynamische Aktionen außerhalb der Kooperationsgruppe geschützt, aber für dynamische Aktionen innerhalb der Kooperationsgruppe weiter zugreifbar. Die dynamischen Aktionen aus Abbildung 3.1 bilden mit virtuellen Kooperationsgruppen-Aktionen dann die Baumstruktur aus Abbildung 3.3.
Da eine Kooperationsgruppe nur eine Strukturierung von dynamischen Aktionen ist, kann die Kooperationsgruppen-Aktion nicht selbst Objektkontrollen anfordern. Die Objektkontrollen werden stattdessen stellvertretend von den dynamischen Aktionen der Kooperationsgruppe angefordert.
