CMI-Entwurfsmuster: Base Technology

Aus THM-Wiki
Wechseln zu: Navigation, Suche
Kurs
Kursname Web-Engineering
Kurstyp Projektkurs
Dozent KQC
Semester WS 10/11
Studiengang Master


CMI steht für "Computer-Mediated Interaction" und bezieht sich auf das Musterbuch von Till Schümmer und Stephan Lukosch: "Patterns for Computer-Mediated Interaction", Wiley, 2007 (Einsicht bei Google-Books).

Im Masterkurs "Web-Engineering" werden die CMI-Patterns in diesem Beitrag dargestellt und aufgezeigt, ob das einzelne CMI-Pattern bereits auf der eStudy-Plattform zu finden ist und wie es implementiert wurde. Falls das CMI-Pattern nicht zu finden ist, wird eine mögliche Implementierung skizziert.

Die CMI-Patterns sind in drei Cluster eingeteilt: "Community Support", "Group Support" und "Base Technology". Entsprechend haben sich im Masterkurs drei Gruppen organisiert, deren Mitglieder jeweils ein oder mehrere CMI-Patterns eines Clusters beschreiben.

Im Folgenden werden die CMI-Patterns des Clusters "Base Technology" beschrieben.

Inhaltsverzeichnis

Einleitung

Das Kapitel Base Technology beschäftigt sich mit mit den technischen Anforderungen, die in einer Groupware verwendet werden können bzw. dort umgesetzt werden müssen.

Verglichen mit den anderen Kapiteln, handelt es sich hierbei um technischere Muster, die sich mit der Verwaltung von geteilten Objekten beschäftigen, bzw. erläutern wie Probleme gelöst werden können, die in diesem Zusammenhang auftreten.

Explizit lassen sich 3 Hauptkategorien unterscheiden:

  • Gemeinsam verwendete Daten müssen verwaltet werden
  • Parallele Eingaben von vielen Benutzern müssen beachtet werden
  • Zusammenarbeitende Benutzer müssen verbunden sein/werden


Alle diese Aspekte nehmen Bezug auf die Verwaltung von gemeinsam genutzten Objekten oder genereller gemeinsam genutzten Daten.

Die Definition eines gemeinsam genutzten Objekts ist das das Objekt von mehr als einem Benutzer verwendet wird.

Des Weiteren kann man nochmals zwischen synchronen und asynchronen Objekten unterscheiden.

Für das folgende Kapitel ergeben sich 3 zusammenhängende Unterkapitel:

  • Session management
  • Shared data management
  • Shared data consistency

Session management

Connect me ... or how to handle sessions

Eine Schlüsselfrage bei der Entwicklung von Groupware-Systemen ist der Sachverhalt wie verteilt agierende Benutzer mit der Groupware arbeiten und ihre Systeme mit der Groupware kommunizieren.


Für den Aufbau einer synchronen Session kann man sich vorstellen, dass das Groupware-System diese Sessions als eine Art reales Treffen verwaltet. (Collaborative Session (Roseman and Greenberg, 1996c))


Im Regelfall läuft eine Session nach folgendem Schema ab.

  • Ein Benutzer startet eine Session
  • Andere Benutzer treten dieser Session bei
  • Teilnehmer verlassen die Session sobald diese fertig ist.

Dabei kann man zwischen expliziter und impliziter Verwaltung unterscheiden.

Bei der expliziten Verwaltung kann ein Benutzer die Session z.B. über eine Einladung betreten (Invitation) oder es wird ein Dienst zur Verfügung gestellt der alle laufenden Session anzeigt und diese betretbar macht (Interaction Directory).

Die implizite Verwaltung beobachtet die Aktivitäten der Benutzer und verbindet Benutzer automatisch innerhalb einer Session, sobald sie erkennt das z.B. an dem selben Dokument gearbeitet wird.


In beiden Fällen geht es immer um synchrone Aktivitäten. Diese benötigen von sich aus weit komplexere Mechanismen um in der Groupware abgebildet werden zu können.

Es ist wesentlich schwieriger Werkzeuge zur Verfügung zu stellen, die es erlauben gleichzeitig mit den gleichen Daten zu arbeiten.

Bevor Benutzer zusammen an gemeinsam verwendeten Daten arbeiten können, ist es erforderlich, die Benutzer in einer kontextabhängigen Schicht auf technischer Seite zu verbinden.

Das heißt konkret das die Benutzer in einer "Collaborative Session" verwaltet werden, was auch das Hauptmuster dieses Abschnitts darstellt.

Collaborative Session

--Hg13399

Intent

Erlaubt Benutzern die synchrone Zusammenarbeit zu planen und zu koordinieren.

Context

Es existiert eine Gruppen von Benutzern, die synchron miteinander arbeiten wollen. Dabei hat man bedenken, wie diese synchrone Zusammenarbeit bewerkstelligt werden kann.


Problem

Damit Benutzer synchron zusammenarbeiten können, benötigen sie eine Umgebung auf die alle Zugriff haben um die synchrone Aktivität zu planen. Diese Umgebung ist in diesem Computer gestützten Umfeld natürlich weder etwas konkretes, noch etwas das man sehen oder anfassen kann. Deshalb ist es schwer solch eine Umgebung bereit zu stellen.

Scenario

Michele und Anna haben sich dazu entschieden eine virtuelle Diskussion/Besprechung abzuhalten. Thematisch soll die Erzeugung von XML im Rahmen des VRML Supports der Spieleengine besprochen werden.

Beide einigen sich darauf die Besprechung am 2. April abzuhalten, leider haben beide vergessen einen konkreten Treffpunkt festzulegen. Somit verstreicht der Termin am 2. April ohne das sich beide am gleichen Ort getroffen haben.

Symptoms

Dieses Muster sollte angewendet werden falls ...

  • es Benutzern nicht möglich ist synchrones Zusammenarbeiten zu planen und zu koordinieren
  • die Benutzer eine Menge Zeit benötigen, mit der eigentlichen synchronen Zusammenarbeit zu beginnen, da im Vorfeld erst entsprechende Tools verwendet werden müssen.

Solution

Der Kontext des synchronen Zusammenarbeit wird als ein geteiltes Session Object modelliert. Dazu ist es nötig den aktuellen Staus der Session zu visualisieren und die Benutzer dabei mit Tools zu unterstützen die folgenfe Funktionalität erfüllen:

  • Starten der Session
  • Beitritt zur Session
  • Verlassen der Session
  • Beenden der Session

Sobald ein Benutzer eine Session beitritt, werden automatisiert Tools gestartet, die zur weiteren Zusammenarbeit benötigt werden.

Dynamics

Im Session-Objekt ist der Kontext der synchronen Zusammenarbeit definiert. Zum Beispiel könnten folgende Aspekte aufgeführt sein:

  • Zieldefinition
  • Zeitpunkt
  • Ort
  • Status der Session

Des Weiteren sind Link zu benötigten Tools vorhanden und es werden alle Benutzer aufgeführt die an der Session teilnehmen.

Es lassen sich 3 Szenarien bestimmen, bei denen ein Client mit dem Session-Objekt interagiert:

  • Einer neuen Session erzeugen und beitreten
Sobald Benutzer eine neue Session starten wollen, erzeugt das System ein neues Session-Objekt und fügt Links zu den entsprechenden Tools ein.
Sobald die Session initialisiert wurde, wird das Benutzer-Objekt des beitretenden Benutzers der Session hinzugefügt.
Ferner werden die Tools auf dem System des Benutzers gestartet. die Session geht in den Status "running" über
  • Einer laufenden Session beitreten
Das Benutzer-Objekt wird der Session hinzugefügt und die Tools beim Benutzer gestartet.
  • Verlassen einer Session
Das Benutzer-Objekt wird aus der Session entfernt und alle Tools beendet.



Rationale

Dieses Muster konzentriert sich darauf alle Einstellungen der Zusammenarbeit wie:

  • Welche Benutzer nehmen Teil
  • Welche Tools werden verwendet
  • Weitere Meta-Informationen

In einer separaten Datenstruktur zu Kapseln und somit den Teilnehmern, wie auch dem System zur Verfügung zu stellen.

Es erleichtert somit das finden von laufenden Aktivitäten im Gesamtsystem oder eines bestimmten Systemteils. Somit können synchrone Aktivitäten schneller und vor allem einfacher gefunden werden.

Da auch dem System die Meta-Informationen der Aktivität zur Verfügung stehen, ist es möglich das System mit dem Starten und Stoppen von verwendeten definierten Tools zu beauftragen, die in Unterschiedlichen Situationen benötigt werden.

Benutzer können sich somit auf die eigentliche Arbeit konzentrieren und müssen sich ferner nicht mit technischen Einzelheiten der Organisation herumschlagen.


Check

Wenn dieses Muster verwendet werden soll, sollten folgende Fragen beantwortet werden:

  • Wie soll eine Session geladen werden? Wann wird die Session gestartet? Ist es möglich dem Benutzer eine Schnitstelle anzubiten die eine neue Session erzeugt?
  • Wie können Benutzer eine Session identifizieren? Macht es Sinn den Sessions einen Namen zu geben? Falls Ja, können diese Namen von Benutzern vergeben werden?
  • Wo werden alle laufenden Sessions verwaltet? Ist es möglich einen Service anzubieten der alle oder eine Auswahl an Sessions anzeigen kann?
  • Wo können benötigte Tools ausgewählt werden? Soll dies vor dem Start einer Session erfolgen oder während der Session?

Danger Spots

Sobald man Sessions zwischen mehreren Benutzern teilt, muss sichergestellt sein das die Informationen für jeden Benutzer konsistent sind. Andernfalls könnte es passieren das bei einigen Teilnehmern nicht alle benötigten Tools gestartet werden (Wenn diese während einer Session ausgewählt werden)

Wenn Benutzer aus einer Session ungewollt austreten, sei es durch Ausschalten des Computers oder verlieren der Netzwerkverbindung, bleiben die Daten des Benutzers in der aktuellen Session vorhanden. Um zu erkennen ob Benutzer während einer synchronen Session noch verfügbar sind, können Timeouts verwendet werden, die dann das Session-Objekt bereinigt.

Weiterhin können auch andere Server/Client-seitige Mechanismen verwendet werden um solche Szenarien zu erkennen und abzufangen.

Known Uses

COAST modelliert kollaborative Sessions als geteilte Applikationsmodelle. Die Objekte beinhalten Referenzen zum geteilten Domänen-Modell (Die Benutzerdaten die in der Session verwendet werden). Wenn Benutzer einer Session beitreten möchten, können sie ihr Benutzerobjekt im Applikationsmodell einfügen, sie landen dann in einer Liste von interessierten Benutzern.

DreamTeam modelliert eine kollaborative Session als ein sog. "replicated Object". Dabei besitzt jeder Benutzer eine Kopie der Sessioninstanz. Solange eine Session noch nicht gestartet wurde, sind in dem Objekt alle Meta-Informationen zur Session ersichtlich. Sobald die Session gestartet wurde, enthält das Session-Objekt die Representation der Benutzer die an der Session teilnehmen und referenziert die Tools die verwendet werden.

GroupKit ist eine Groupware Plattform, die auch auf einer Session-Metaphore basiert (Roseman and Greenberg, 1996b). Ein Manager kommuniziert dazu mit einer zentralen Instanz um herauszufinden welche Session aktuell verfügbar sind.

Jede Session beinhaltet eine Reihe von Konferenz-Applikationen die von teilehmenden Benutzern in der Session verwendet wird.

Related Patterns

BELL (4.2.4):

Erlaubt Benutzern bei Leitern von Session nachzufragen ob sie der Session beitreten können.


Interaction Directory(4.2.4):

Erlaubt Benutzern Session zu finden die für sie Interessant sind


Invitation(4.2.5):

kann dazu verwendet werden andere Benutzer einzuladen an einer Session teilzunehmen.

Room(4.2.1):

stellt einen virtuellen Raum zur Verfügung, indem sich Benutzer treffen können um eine Zusammenarbeit zu beginnen
Ein Raum kann Tools oder geteilte Dokumente beinhalten und bietet die Möglichkeit Materialien der asynchrone Arbeit persistent ab zu speichern.

User List(4.4.1):

Erlaubt das Identifizieren von Benutzern, die für eine Zusammenarbeit zur Verfügung stehen

Replay(5.1.4):

Ermöglicht Benutzern das Beitreten, Verlassen und den Wiedereintritt in eine Session zu unterschiedlichen Zeitpunkten.

Session (Sørensen, 2002):

Eine Session dient dazu in einer Client/Server-Anwendung Daten zu speichern. Diese Session-spezifischen Daten werden solange vom Server gespeichert, bis die Session verfällt bzw. aktiv ist.
Die "Kollaborative Session" konzentriert sich auf das Management von Tools und Meta-Informationen für interagierende Benutzer.

Session (Guerrero and Fuller, 1999):

fokussiert nicht die Organisation von Sessions. Obwohl es sich mit kollaborativen Sessions beschäftigt, enthält eine Sessioninstanz keine Informationen über Applikationen die in der Session verwendet werden.

Abstract Session (Pryce, 1997):

erlaubt einem Server-Objekt, das von vielen Clients verwendet wird, den Status jedes einzelnen Clients zu verfolgen, das er bedient.
Dies nennt man auch Service Access Point (SAP).


I Am Alive (Saridakis, 2003):

beauftragt einen Client Nachrichten zu senden, die zeigen das der Client immer noch verfügbar ist.
Sobald diese Nachrichten nicht mehr ankommen, wird der Benutzer aus der Session entfernt.

Are You Alive (Saridakis, 2003):

Dieses Muster schaut in regelmäßigen Abständen ob ein Client verfügbar ist. Falls nicht wird er aus der Session entfernt.

Session Timeout (Sørensen, 2002):

legt ein Zeitlimit für einen Benutzer fest indem er auf das Session-Object zugreifen muss, bevor er aus der Liste der Teilnehmer entfernt wird.

Realisierung auf der eStudy-Plattform

eModeration!?

Persistent Session

--Hg13399

Intent

Stellt Ergebnisse aus einer kollaborativen Session zur Verfügung oder ermöglicht die Wiederaufnahme der Session.

Context

Man hat eine "Collaborative Session" (5.1.1) verwendet.

Problem

Nachdem eine Zusammenarbeit in einer kollaborativen Session stattgefunden hat, möchte man die Ergebnisse anschauen oder die Session fortsetzen. Diese Daten stehen aber nicht mehr zur Verfügung.

Scenario

Paul hat 2 Marketing Spezialisten, Steven und Andrew, damit beauftragt, einen Projektflyer, für ein zukünftiges Spiel, zu erstellen. Während einem einführenden "face-to-face"-Meeting wurden diverse Dokumente erstellt, die für die Diskussion am nächsten Tag verwendet werden sollen. Paul hat alle Dokumente eingesammelt und mit nach Hause genommen. Am Abend fühlt sich Paul krank und kann am nächsten Morgen an der Diskussion teilnehmen. Steven und Andrew müssen nun mit Ihrer Arbeit von vorne beginnen, da Ihnen die Dokumente fehlen die am Vortag erstellt wurden.


Symptoms

Dieses Muster sollte verwendet werden wenn ...

  • Benutzer arbeiten zusammen in synchronen Sessions und benötigen die Resultate, die aber nicht verfügbar sind.
  • Benutzer in einer "Collaborative Session" müssen die selben Aufgaben wieder und wieder erledigen.
  • Die Groupware ist nicht in der Lage, Resultate zu speichern, die für die Wiederaufnahme einer Session verwendet werden müssen oder einer Nachbetrachtung der Ergebnisse dienen.

Solution

Es erfolgt eine Speicherung der Ergebnisse einer synchronen "Collaborative Session" auf einem zentralen Server. Wenn diese geteilten Informationen repliziert werden, soll das Muster "Mediated Updates" verwendet werden, um eine Master-Kopie zu erstellen und alle Änderungen zu dieser Master-Kopie zu verwalten. Diese Daten können dann dazu verwendet werden die Session wieder aufzunehmen oder eine Nachbetrachtung abzuhalten.

Dynamics

Bei der Verwendung des Musters "Mediated Updates", können alle Änderungen der Daten nachvollzogen werden. Bei diesem Muster müssen Benutzer bei jeder Änderung eine Nachricht an den Server senden, sobald die geteilten Informationen verändert wurden. Der Server sorgt dann für die Verteilung an alle teilnehmenden Benutzer. Immer wenn der Server eine "Update"-Nachricht erhält, werden die Änderungen auch der Master-Kopie hinzugefügt.

Es muss eine Schnittstelle bereitgestellt werden, die die Nachbetrachtung und die Wiederaufnahme der kollaborativen Session ermöglicht.

Rationale

Da der zentrale Server alle Änderungen an den geteilten Daten mitverfolgt, können Benutzer einer kollaborativen Session auf alle relevanten Daten zugreifen. Sei es zur Wiederaufnahme der Session oder zur Nachbetrachtung.


Check

Bei der Verwendung des Musters sollte auf folgende Punkte geachtet werden:

  • Wo werden die Ergebisse der Session gespeichert?
  • Wie können Benutzer die Ergebnisse einsehen? Ist es möglich ein Tool bereitzustellen das die Ergebnisse darstellt oder sollen die Benutzer die selben Tools verwenden, die auch zur Erstellung der Daten verwendet wurde?
  • Macht es Sinn eine neue Session zu starten, die auf den Ergebnissen eine vorangegangenen Session basiern? ist es möglich die Benutzerschnittstellen so anzupassen, das es ermöglicht wird mit den vorhandenen Daten weiter zu arbeiten?


Danger Spots

Wenn der zentrale Server nicht verfügbar ist, ist es den Benutzern nicht möglich die Ergebnisse anzuschauen oder eine neue Session auf der Basis dieser Daten zu beginnen.

Um diesem aus dem Weg zu gehen könnten z.B. mehrere zentrale Server verwendet werden, die die Daten untereinander replizieren. Eine weiter Möglichkeit wäre eine dezentrale Lösung, wo z.B. der Client der als letztes mit der Session gearbeitet hat und somit über die aktuellen Daten verfügt, diese an die anderen Teilnehmer zu verteilen.

Known Uses

COAST (Schuckmann et al., 2000):

speichert die Daten persistent verteilt auf mehrere Mediatoren. Diese Mediatoren überwachen die Clients und halten die replizierten Daten aktuell und synchron. Sobald ein Client Veränderungen vornimmt (was transaktionsbasiert abläuft), werden die Mediatoren mit einem Log benachrichtigt und die Daten werden aktualisiert.
Die Speicherung auf den Mediatoren ist persistent. Dies ermöglicht das alle Ergebnisse jederzeit eingesehen werden können oder zur Wiederaufnahme einer "Collaborative Session" verwendet werden können.

CBE (Prakash et al., 1999):

stellt einen computer-basierten geteilten sog. Workspace zur Verfügung, der die Zusammenarbeit über das WWW ermöglicht.
CBE verwendet Dienste des Gruppenkommunikations-Servers Corona (Shim et al., 1997).
Corona zeichnet alle Aktualisierungen die es von Clients erhält auf und stellt eine persistente Speicherung der Ergebnisse zur Verfügung.

DreamObjects (Lukosch, 2003a):

unterstützt Transaktionen zwischen synchronen und asynchronen Tätigkeiten. Dabei kann jeder Teilnehmer den aktuellen Status einer Session speichern, laden und verteilen. Um die mögliche Problematik mit einem zentralen Server zu umgehen, werden die Protokolle SMTP und NNTP verwendet um die Ergebnisse an alle Teilnehmer zu verteilen.

Related Patterns

Collaborative Session(5.1.1):

kann das Muster PERSISTENT SESSION verwenden um Ergebnisse einer Session abzuspeichern.

Mediated Updates(5.2.5):

beschreibt wie man Update-Nachrichten über zusammenarbeitende Clients verteilt und zur Speicherung einen zentralen Server verwendet.
Diese Funktionalität kann auf dem zentralen Server leicht erweitert werden, damit die Daten persistent gespeichert werden.


Room(4.2.1):

stellt einen virtuellen Raum zur Verfügung, indem sich Benutzer treffen können um eine Zusammenarbeit zu beginnen
Ein Raum kann Tools oder geteilte Dokumente beinhalten und bietet die Möglichkeit Materialien der asynchrone Arbeit persistent ab zu speichern.

Replay(5.1.4):

berücksichtigt ein Problem das auftreten kann, falls Session-Daten persistent gespeichert wurden und eine lange Zeit vergangen ist. Unter Umständen können nicht alle Benutzer nachvollziehen, wie das Ergebnis der vorangegangenen Session zustande kam. Eine einfacher Restore der Session reicht unter Umständen nicht aus, da Teilnehmer in der Lage sein müssen, nachzuvollziehen wie der Aktuelle Stand der Session zustande gekommen ist.


Keep Session Data in the Client (Sørensen, 2002):

beschreibt wie man Session-spezifische Daten auf Clientseite verwalten kann und kann verwendet werden falls kein Server zur Verfügung steht der die Daten speichern kann. Es wird jedoch nicht definiert wie Daten gespeichert werden können, wenn eine Session beendet wurde.

Keep Session Data in the Server (Sørensen, 2002):

beschreibt die Vorgänge die involviert sind, sobald Session-spezifische Daten auf einem Server verwaltet werden. Auch dieses Muster dient mehr dazu diese Daten während einer laufenden Session zu verteilen und nicht um Ergebnisse pesrsitent zu speichern.

Realisierung auf der eStudy-Plattform

eModeration!?

State Transfer

--Peter Gabriel

Intent

Erlaubt die Integration von Nachzüglern in laufende Interaktionen.

Context

Erlaubt Benutzern das Beitreten, Verlassen und erneute Beitreten einer COLLABORATIVE SESSION, zu unterschiedlichen Zeitpunkten.

Problem

Benutzer arbeiten gemeinsam in einer COLLABORATIVE SESSION, aber nicht alle nehmen von Anfang an teil. Einige kennen nicht die Zwischenergebnisse der COLLABORATIVE SESSION, was die Zusammenarbeit schwieriger macht.

Scenario

John und Charley haben, ohne dass es jemand weiß, am Schlüsselmanagement der Game-Engine gearbeitet. Nun möchte Paul an den weiteren Schritten teilnehmen und fragt, ob er ihrer COLLABORATIVE SESSION beitreten kann. Allerdings kennt Paul nicht den gegenwärtigen Status der Arbeit von John und Charley.

Symptoms

Dieses Muster sollte angewandt werden wenn...

  • Benutzer es nicht geschafft haben, die COLLABORATIVE SESSION von Anfang an teilzunehmen
  • Benutzer die Zwischenergebnisse nicht kennen und deshalb nicht an der Zusammenarbeit teilnehmen können
  • Benutzer den gegenwärtigen Interaktionsfokus und Zusammenhang verstehen sollen.

Solution

Den Nachzüglern muss der aktuelle Stand von gemeinsamen Objekten mitgeteilt werden. Da alle derzeitigen Teilnehmer den aktuellen Stand der gemeinsamen Objekte kennen , kann das System irgend einen, der vorhandenen Teilnehmer bitten, die Zustandsübertragung durchzuführen.

Dynamics

Nachzügler können sich einer vorhandenen COLLABORATIVE SESSION anschließen. Um an der Zusammenarbeit teilzunehmen, benötigen sie den aktuellen Status der Sitzung. Zu diesem Zweck muss der Nachzügler jemanden finden, der ihm den aktuellen Status mitteilt. Dieser muss nun dafür sorgen, dass der Nachzügler eine folgerichtige und korrekte Einweisung über den aktuellen Stand erhält, andernfalls wird der Nachzügler Probleme haben, ordnungsgemäß teilzunehmen. Zu diesem Zweck darf der Einweisende nicht die laufende Zusammenarbeit blockieren. Zwei Fälle sind zu unterscheiden: Mit und ohne zentralem Server. Im einfachsten Fall existiert ein zentraler Server, z.B. wenn die COLLABORATIVE SESSION CENTRALIZED OBJECTS oder MEDIATED UPDATES benutzt, um Zustands-Änderungen mitzuteilen. Im Falle von MEDIATED UPDATES muss der zentrale Server so erweitert werden, dass er eine Kopie des gegenwärtigen Zustandes beibehält. Wir nennen einen solch erweiterten Server einen „Vermittler“. Ist ein zentraler Server vorhanden, kann ein Nachzügler diesen kontaktieren und den aktuellen Status der COLLABORATIVE SESSION ermitteln. Nachdem der Nachzügler den Server kontaktiert hat, wird dieser über künftige Zustandsänderungen informiert. Sobald der Nachzügler nun eine Nachricht über eine Zustandsänderung erhält, wird sie durch ihn gepuffert. Nachdem der Nachzügler in die Kommunikation miteinbezogen wurde, erstellt der Server eine Kopie des gemeinsamen Zustandes und liefert dem Nachzügler diese Kopie. Außerdem informiert der Server den Nachzügler über die neusten Änderungen des gemeinsamen Zustands. Dies kann beispielsweise durch eine logische Uhr (Lamport, 1978) und Zeitstempel für jede Nachricht, die eine Zustandsänderung beschreibt getan werden. Dadurch wird sichergestellt, dass der Nachzügler eine aktuelle Kopie des aktuellen Standes besitzt. Nachdem der Nachzügler die Kopie des gemeinsamen Zustandes empfangen hat, wendet er alle Änderungen des gespeicherten Zustands an, die er vom Server empfangen hat. Sind die Zustandsänderungen als Kommandos gekapselt, muss der Nachzügler alle gespeicherten Kommandos ausführen. Sobald der Speicher leer ist, hat der Nachzügler einen übereinstimmenden Zustand und kann an der COLLABORATIVE SESSION teilnehmen. Werden Zustandsänderungen als neue Versionen gemeinsamer Objekte verteilt, identifiziert der Nachzügler die letzten Versionen der betroffenen Objekte und ersetzt die empfangene Version durch die Letzte, z.B. indem er IMMUTABLE VERSIONS verwendet. STATE TRANSFER wird schwieriger, wenn es keinen zentralen Server gibt, der den aktuellen Zustand verteilt. Der Nachzügler muss so einen der anderen Teilnehmer als Vermittler auswählen. Da die anderen Teilnehmer die COLLABORATIVE SESSION jederzeit verlassen können, ist es wichtig, den Teilnehmer sorgfältig auszuwählen. In dem Fall, dass der vermittelnde Teilnehmer den STATE TRANSFER nicht abschließen kann, sollte ein neuer Vermittler nicht nochmals von Anfang anfangen. Für eine nähere Beschreibung der notwendigen Zusammenarbeiten, siehe DreamsObjects Platform (Lukosch, 2003a)(Lukosch, 2003b).

Rationale

STATE TRANSFER garantiert, dass ein Nachzügler den gegenwärtigen Zustand der COLLABORATIVE SESSION erhält, so dass der Nachzügler mit den anderen Teilnehmern einer Sitzung zusammenarbeiten kann.

Check

Bei Verwendung dieses Pattern muss auf folgendes geachtet werden:

  • Wie soll der Nachzügler den Zustand der Sitzung erkennen? Wird vom Nachzügler verlangt, einen Server-Namen einzugeben? Ist der Server-Name hart kodiert? Oder werden Sie ihm einen anspruchsvolleren Lookup-Mechanismus präsentieren?
  • Wie können Sie Zustandsänderungen für Nachzügler erkennen, die nicht an eine Zustandskopie der Sitzung angehängt wurden? Würden Sie Zeitstempel verwenden?

Danger Spots

Einen zentralen Server als Zustandsvermittler für Nachzügler zu betrachten ist ein Single-Point-Of-Failure. Dadurch wird ein zentraler Server zum Flaschenhals in der Netzwerk-Kommunikation. Mit DECENTRALIZED UPDATES kann man diese Probleme umgehen.

Known Uses

COAST (Schuckmann et al., 1996b) verwendet MEDIATED UPDATES und DISTRIBUTED COMMANDS, um Statusänderungen zu verteilen. Nachzügler, die einer Sitzung beitreten, kontaktieren den Vermittler, welcher den Nachzüglern den aktuellen Zustand der Sitzung mitteilt.

Collaboration Builder´s Environment (CBE). CBE (Prakash et al., 1999) verwendet eine Kommunikations-Infrastruktur, welche auf einem zentralen Corona-Server basiert (Hall et al., 1996)(Shim et al., 1997)(Shim und Prakash, 1998). Dieser Server regelt die Gruppen-Kommunikation, hält eine Kopie des gemeinsamen Zustands und protokolliert alle Nachrichten, die zwischen den Teilnehmern gesendet werden.


DreamObjects (Lukosch, 2003a)(Lukosch, 2003b) überträgt den aktuellen Stand einer Sitzung direkt zu einem Nachzügler, ohne eine zentralen Server als Vermittler zu benutzen. Der Nachzügler kann einen beliebigen Teilnehmer aus der aktuellen Sitzung als Vermittler auswählen. Verliert ein Vermittler die Verbindung, während er den Status überträgt, kann der Nachzügler einen anderen Teilnehmer zu seinem Vermittler wählen.


Dream Team (Roth, 2000b) verwendet den Teilnehmer, der die COLLABORATIVE SESSION eingeleitet hat, als Vermittler für kommende Nachzügler. Dieses wird erreicht, ohne andere Mitarbeiter in ihrer Arbeit zu blockieren. Verlässt jedoch der Sitzungs-Ersteller die Sitzung, kann dieser kein weiterer Nachzügler beitreten.


RTP / I (Mauve, 2000b) ist ein Protokoll auf Anwendungsebene, welches vom Real-Time-Transport-Protocoll (RTP) abgeleitet ist (Schulzrinne et al., 1996). RTP / I wird von kollaborativen Anwendungen benutzt und befasst sich mit verteilten, interaktiven Medien, die in Unterkomponenten aufgeteilt sind. Der Zustand der verteilten, interaktiven Medien ist für jeden teilnehmenden Standort repliziert und kann durch Ereignisse verändert werden. RTP / I bietet einige Basisdienste, wie einen Konsistenz-Dienst(Vogel und Mauve, 2001) und einen generisch „spät-beiretenden“ Service(Vogel et al., 2000). Der „spät-beitretende“ Service definiert verschiedene spät-beitretende Regeln, wie z.B. ereignis-gesteuerte „spät-beitretende“, sofortig „spät-beitretende“. Diese Richtlinien können auf die verschiedenen Unterkomponenten zugeordnet werden. Basierend auf den definierten Regeln, werden die Unterkomponenten auf die Nachzügler übertragen. Es ist die Aufgabe des „Konsistenz-Dienst“, dass die Nachzügler die Teilkomponenten im richtigen Zustand erhalten. Der „Konsistenz-Dienst“ verwendet physikalische Zeitstempel, um die erforderlichen Ereignisse in Reihenfolge zu definieren und verlangt, dass die beteiligten Seiten ihre physikalischen Uhren synchronisieren, z.B. mit Hilfe von GPS-Empfängern oder dem Network-Time-Protocol (NTP) (Mills, 1992).

Related Patterns

CENTRALIZED OBJECTS erlaubt einen zentralen Server als Zustandsvermittler für Nachzügler auszuwählen.


COLLABORATIVE SESSION erlaubt Benutzern eine koordinierte und synchrone Zusammenarbeit zu planen. Nachzügler benötigen den aktuellen Zustand der Sitzung.


DISTRIBUTED COMMAND erlaubt Zustandsänderungen zu kapseln.


IMMUTABLE VERSIONS erlaubt verschiedenen Versionen ein gemeinsames Objekt zu identifizieren.


MEDIATED UPDATES erlaubt dem Vermittler, als Zustandsübermittler für Nachzügler, gewählt zu werden.


DECENTRALIZED UPDATES machen es schwierig, einen Vermittler für Nachzügler zu finden, wenn die Teilnehmer einer COLLABORATIVE SESSION in einem Peer-To-Peer-Netzwerk kommunizieren.


REPLAY wiederholt die Route, durch die der aktuelle Zustand der COLLABORATIVE SESSION erreicht wird.


MARSHALLER (Völler et al., 2004) beschreibt, wie Objekte von einem Computer zu einem Anderen im Netzwerk übertragen werden können. Das Muster reqähnt Punkte wie serialization und deserialization.

Realisierung auf der eStudy-Plattform

Nein. Hierbei handelt es sich um ein Pattern, welches die Qualität der Zusammenarbeit an einem Projekt verbessern soll. Da die Entwicklung von eStudy mittels Tools wie SVN, Trac und Wiki betrieben wird, ist dieses Pattern quasi überflüssig.

Replay

--Peter Gabriel

Intent

Wiederholen Sie die Reihenfolge der Änderungen, durch die sich der aktuelle Stand der Zusammenarbeit entwickelt hat.

Context

Erlaubt Benutzern das Beitreten, Verlassen und erneute Beitreten in einer Zusammenarbeit, zu unterschiedlichen Zeitpunkten.

Problem

Benutzer arbeiten gemeinsam in einem Verbund, aber nicht alle nehmen von Anfang an teil. Einige kennen nicht die Zwischenergebnisse der Zusammenarbeit. Für die Nachzügler ist es schwierig den aktuellen Stand zu erfassen oder was seit ihrer letzten Teilnahme geändert worden ist.

Scenario

Paul und Susan haben äußerst erfolgreich im Pair-Programming gearbeitet. Am nächsten Tag möchte Susan die Sitzung fortsetzen, aber Paul hat Grippe und kann nicht teilnehmen. Susan bittet nun Liam mit ihr weiter zu arbeiten. Liam weiß aber nicht was in Paul´s und Susan´s vorheriger Sitzung passiert ist. Es ist schwer für ihn, mit Susan zusammen zu arbeiten.

Symptoms

Dieses Muster sollte angewandt werden wenn...

  • Benutzer es nicht geschafft haben, an der Zusammenarbeit von Anfang an teilzunehmen
  • Benutzer nicht verstehen, wie der aktuelle Stand erreicht wurde

Solution

Erfassen Sie alle Änderungen der Zusammenarbeit in einem ACTIVITY LOG. Wenn neue Benutzer der Zusammenarbeit beitreten wollen, wiederhole die festgehaltenen Änderungen, um zu zeigen, welche Änderungen zum aktuellen Stand geführt haben.

Dynamics

Um die Änderungen, welche zum aktuellen Stand geführt haben zu wiederholen, ist es nötig, alle Änderungen in einem LOG zu sichern(näheres siehe ACTIVITY LOG). Es sind Zwei Fälle zu unterscheiden: Mit oder ohne einen zentralen Server. Im einfachsten Fall kann der zentrale Server als Vermittler für Nachzügler genutzt werden. Dies wird bei CENTRALIZED OBJECTS oder MEDIATED UPDATES benutzt, um Zustands-Änderungen mitzuteilen. In beiden Fällen muss der Server so erweitert werden, dass er ein Protokoll registriert, welches alle Statusänderungen bis zum gemeinsamen Zustand aufzeichnet. Abhängig davon, wie Statusänderungen verteilt werden, kann dies entweder ein Protokoll DISTRIBUTED COMMANDS oder eine Reihe IMMUTABLE VERSION für alle gemeinsamen Objekte werden. Das Client-System dass sich einer Zusammenarbeit anschließt, wird als Nachzügler bezeichnet. Wenn ein zentraler Server vorhanden ist, kann ein Nachzügler mit dem Server in Kontakt treten und das Protokoll der Zustandsänderungen anfordern. Nachdem der Nachzügler mit dem Vermittler in Verbindung getreten ist, schließt der Vermittler den Nachzügler in künftige Kommunikation über Zustandsänderungen mit ein. Sobald der Nachzügler das Protokoll erhalten hat, wird mit der erneuten Ausführung aller Statusänderungen begonnen und in einem Benutzer-Interface ausgegeben. Nachdem der Nachzügler alle Zustandsänderungen im Protokoll durchgesehen und den aktuellen Stand nachvollzogen hat, kann er an der aktuellen Sitzung teilnehmen. Existiert kein zentraler Server und nicht alle Clients waren von Anfang an in der Sitzung: Modellieren Sie die Zustandsänderungen zu gemeinsamen Objekten. Alle Clients synchronisieren ihre Protokolle mittels des Synchronisierungs-Mechanismus für REPLICATED OBJECTS und erhalten ein Protokoll mit allen Zustandsänderungen, welches sie an die Nachzügler weitergeben können. STATE TRANSFER kann dazu genutzt werden, um Nachzüglern mit einer Kopie des Protokolls zu versorgen.

Rationale

Mit einem Protokoll, welches alle Zustandsänderungen beinhaltet, können Nachzügler die Schritte nachvollziehen, die zum aktuellen Zustand geführt haben.

Check

Bei Verwendung dieses Pattern muss auf folgendes geachtet werden:

  • Wie kann der Nachzügler den Vermittler erkennen?
  • Werden Benutzer in der Lage sein den Sitzungszustand zu wiederholen? Werden Sie alle Änderungen sehen? Werden Sie in der Lage sein die Wiederholungsgeschwindigkeit zu kontrollieren?
  • Für welche Teile der Interaktion werden Nachzügler Einblick erhalten? Gibt es private Teile der Sitzungshistorie, die geschützt werden sollen?

Danger Spots

Die Übertragung des gesamten Protokolls mit allen Zustandsänderungen kann sehr viel Zeit in Anspruch nehmen, besonders wenn der Nachzügler dem Projekt spät beigetreten ist. Um dies zu umgehen, sollte man regelmäßig Kopien des gemeinsamen Zustands erstellen, damit der Nachzügler den Zeitpunkt seines anzufordernden Protokolls, exakter wählen kann. Möglicherweise ist es nicht machbar, eine vollständige Wiederholung durchzuführen. Das System kann nur solche Teile wiederholen, die vom System durchgeführt wurden. Zusammenarbeit findet üblicherweise unter Verwendung verschiedener Interaktionskanäle statt. Die Wahrscheinlichkeit, dass nicht alle dieser Kanäle aufgezeichnet werden, ist folglich ziemlich hoch. Die vollständige Wiederholung kann zu umfangreich sein, da sie alle Operationen zeigt. Der optimale Weg, dieses Problem zu umgehen, ist die Abstraktion zwischen feinkörnigen Änderungen und High-Level-Änderungen. Sie sollten zusammengesetzte Änderungen nochmals in einem Schritt wiederholen und die Wiederholung mit Meta-Daten kommentieren.

Known Uses

Collaboration Bus (Chung et al., 1998) ist eine Groupware-Entwicklungsumgebung, die es erlaubt, Sitzungen zu wiederholen. Der Service basiert auf einem Server, der speziell für Nachzügler zur Verfügung steht und Logger genannt wird. Auf der Teilnehmerseite werden mittels eines Protokolls alle Ereignisse erfasst, die über das Benutzer-Interface geändert werden. Anschließend werden diese zum Logger gesendet. Dieses Schema stellt sicher, dass der Logger immer informiert wird, sobald auf der Teilnehmerseite eine Änderung am gemeinsam benutzten Objekt stattfindet. Möchte nun ein Nachzügler einer Sitzung beitreten, wiederholt der Logger alle aufgezeichneten Ereignisse und überträgt diese auf das Protokoll des Nachzüglers. Basierend auf den übermittelten Ereignissen, wird das Benutzer-Interface des Nachzüglers aufgebaut. Da das Protokoll sehr groß werden kann, verwendet das System eigene Kompressionstechniken. Diese basieren auf den semantischen Informationen der Ereignisse, die das Protokoll zur Verfügung stellt. Somit kann der Logger dem Nachzügler nur die Ereignisse präsentieren, die seit der letzten Statusänderung stattgefunden haben. Unwichtige Ereignisse, wie z.B. Mausbewegungen, können so gefiltert werden.


DreamObjects (Lukosch, 2003a)(Lukosch, 2003b) überträgt den aktuellen Stand einer Sitzung direkt zu einem Nachzügler, ohne eine zentralen Server als Vermittler zu benutzen. Der Nachzügler kann einen beliebigen Teilnehmer aus der aktuellen Sitzung als Vermittler auswählen. Verliert ein Vermittler die Verbindung, während er den Status überträgt, kann der Nachzügler einen anderen Teilnehmer zu seinem Vermittler wählen.


ReplayKit (Manohar und Prakash, 1995a, b) ist eine Groupware-Umgebung welche einzelne Benutzer Datensätze in Session-Objekte kapselt. Benutzer arbeiten asynchron zusammen, d.h. sie kommentieren, ändern und tauschen Session-Objekte. Das Laufzeitsystem erlaubt Wiederholungen in beliebiger Geschwindigkeit.


CatchUp (Henkel und Diwan, 2005) ist ein Plug-In für die Entwicklungsumgebung Eclipse, die Aufzeichnung und Wiedergabe von Refactorings erlaubt.

Related Patterns

ACTIVITY LOG beschreibt, wie Änderungen am gemeinsamen Zustand im Protokoll aufgezeichnet werden.


CENTRALIZED OBJECTS erlaubt einen zentralen Server als Zustandsvermittler für Nachzügler auszuwählen.


COLLABORATIVE SESSION erlaubt Benutzern eine koordinierte und synchrone Zusammenarbeit zu planen. Nachzügler benötigen den aktuellen Zustand der Sitzung.


DISTRIBUTED COMMAND erlaubt Zustandsänderungen zu kapseln.


IMMUTABLE VERSIONS erlaubt verschiedenen Versionen ein gemeinsames Objekt zu identifizieren.


MEDIATED UPDATES erlaubt dem Vermittler, als Zustandsübermittler für Nachzügler, gewählt zu werden.


DECENTRALIZED UPDATES machen es schwierig, einen Vermittler für Nachzügler zu finden, wenn die Teilnehmer einer COLLABORATIVE SESSION in einem Peer-To-Peer-Netzwerk kommunizieren.


STATE TRANSFER übertragt den aktuellen Stand der Sitzung direkt zum Nachzügler.


TIMELINE zeigt die verschiedenen Aktivitäten anhand eines Diagramms. TIMELINE kann mit einem Index von Aktivitäten verglichen werden, während REPLAY den Index ausführt.

Realisierung auf der eStudy-Plattform

Nein. Hierbei handelt es sich um ein Pattern, welches die Qualität der Zusammenarbeit an einem Projekt verbessern soll. Da die Entwicklung von eStudy mittels Tools wie SVN, Trac und Wiki betrieben wird, ist dieses Pattern quasi überflüssig.

Management of shared objects

Centralized Objects

Julian Hochstetter

Intent

Erlaubt den Fernzugriff auf gemeinsame Objekte.

Context

Wie kann ich bei der Entwicklung von Groupware Anwendungen die Daten organisieren, dass mehrere Benutzer Zugriff auf diese haben

Problem

Um die Zusammenarbeit zu erreichen, müssen die Benutzer die Möglichkeit besitzen, die Daten anderen zugänglich zu machen.

Scenario

Susan möchte das Projekt besser strukturieren und schlägt die Verwendung einer gemeinsamen Aufgabenliste vor. In dieser sollen alle Änderungswünsche verwaltet werden.

Die noch offene Frage ist jedoch, wie diese Aufgabenliste verwaltet wird, dass alle Beteiligten Ihre Aufgaben sehen und auch die Liste bearbeiten können

Symptoms

Dieses Pattern sollte zum Einsatz kommen wenn:

  • Wenn sich Personen treffen müssen weil sie sonst keine Möglichkeit haben Daten auszutauschen.
  • Benutzer gerne Daten in einer interaktive Anwendung anderen zugänglich machen möchten.
  • Benutzer nicht verstehen wie sie mit geteilten Daten arbeiten können.

Solution

Verwalten der Daten auf einer Plattform, die allen Benutzern zugänglich ist und einen einfachen Zugang der Daten ermöglichen.

Dynamics

Die wichtigste Rolle nimmt die Plattform ein, die die Daten speichert und Benutzern zur Verfügung stellt. Die Benutzer rufen die gespeicherten Daten ab und können diese bearbeiten um die anschließend wieder auf den Server zu laden, damit die anderen Teilnehmer die neue Version der Daten bekommen.

Rationale

Alle Benutzer arbeiten mit den gleichen und geteilten Daten. Des weiteren bietet dieses Pattern folgende Vorteile:

  • Alle Benutzer sind in der gleichen Plattform und können somit die Daten einfach und schnell finden.
  • Da die Daten nur einmal auf dem Server verwaltet werden, ist die Konsistenz der Daten gewährleistet.

Check

Bevor dieses Pattern angewendet wird, muss folgendes geklärt werden:

  • Welches Protokoll soll zum Einsatz kommen?
  • Wenn die Daten auf dem Server geändert werden, wie werden diese Änderungen an die Mitarbeitenden weitergegeben und wie wird die Datenkonsistenz bei gleichzeitigen Updates gewährleistet?

Danger Spots

Die zentrale Plattform ist der Flaschenhals. Wenn viele Benutzer die Daten häufig aufrufen, dann kann die Antwortzeit der Anwendung sich reduzieren und im schlimmsten Fall sind die Daten nicht mehr erreichbar, dann ist ein Zusammenarbeiten an den Daten nicht mehr möglich.

Des weiteren ist es möglich, wenn Benutzer die Daten lokal bearbeiten, dass diese dann in der Zwischenzeit veraltet sein können. Um dieses Problem zu umgehen sollte man Remote_Subscription einsetzen.

Known Uses

Related Patterns

  • Remote_Subscription: Erlaubt das benachrichtigen von Clients über Änderungen an zentralisieren Daten.
  • Replicated Objects: sollen benutzt werden, wenn die Plattform hochinteraktiv ist und die Daten häufig und von vielen Benutzern geändert werden. Replicated Objects erhöht die Antwortzeit der Plattform, die Verfügbarkeit der geteilten Daten verbessert sich jedoch.
  • Nomadic Objects: sollen zum Einsatz kommen, wenn keine permanente Netzwerkverbindung vorhanden ist, denn Nomadic Objects ermöglichen auch dann den Zugriff auf die Daten.

Realisierung auf der eStudy-Plattform

eStudy bietet die Möglichkeit des Dateiaustausches im klassischen Sinne in Form einer Dateiablage sowie mit Hilfe von Subversion das versionierte und revisionierte austauschen von Daten.

Remote Subscription

Julian Hochstetter

Intent

Der Server oder die Anwendung informiert den Client über Änderungen an gemeinsamen Daten.

Context

Wenn Daten mit Hilfe von Centralized Objects auf der Plattform für das gemeinsame Arbeiten zur Verfügung gestellt werden, dann ändern sich diese an zentraler Stelle. Nun muss die Datenkonsistenz und das informieren der Clients über Änderungen an den Daten sichergestellt werden.

Problem

Benutzer die an gemeinsam genutzten Daten arbeiten gehen davon aus, dass diese immer aktuell sind, was aber nicht der Fall sein muss.

Scenario

Susan hat es nun endlich geschafft, dass die Aufgaben in zentralisierten Daten gespeichert werden. Mit Hilfe eines Web Browser kann nun jedes Projekt Mitglied die Aufgaben ansehen und verwalten.

Charley möchte nun Sicherheits UnitTests erstellen, findet aber keinen offenen Task in der Liste und entscheidet sich an einer anderen Stelle mitzuwirken. Am Tag danach werden aber von Paul mehrere Aufgaben bezüglich Sicherheits UnitTests eingestellt, die von Charley aber nicht wahrgenommen werden.

Symptoms

Dieses Pattern sollte zum Einsatz kommen wenn:

  • Wenn das periodische Abfragen aus unterschiedlichen Gründen nicht in Frage kommt.
  • Benutzer nur visuell Informationen von einem Server empfangen.
  • Benutzer auf keinen Fall mit veralteten Daten arbeiten sollen.

Solution

Aus diesem Grund ist es wichtig, dass die Benutzer sich anmelden, um über Änderungen an gemeinsamen Daten informiert zu werden.

Dynamics

Der Server muss den Überblick über alle Clients behalten, die den Zustand des gemeinsam genutzten Objektes abonniert haben. Immer wenn sich der Zustand des Objekts ändert, informiert der Server die Clients darüber. Dies erreicht der Server indem er entweder alle informiert, dass sich etwas geändert hat, oder er beschreibt in seiner Meldung direkt was sich geändert hat. Im ersten Fall muss sich der Client selbst die Änderungen am Server abholen.

Rationale

Remote Subscription in Kombination mit Centralized Objects ermöglichen ein verteiltes MVC (Buschmann et al., 1996). Der Server verwaltet das Model, während auf Clientseite die Views und die Controller sind.

Da sich die Clients am Server anmelden, weiß der Server wen er über Änderungen informieren muss. Wenn immer sich das Model ändert, kann der Server alle Clients, die sich an diesem Model registriert haben informieren und die Clients haben eine stets aktuelle Ansicht.

Check

Bevor dieses Pattern angewendet wird, muss folgendes geklärt werden:

  • Wenn die Statusänderung und die Änderungen zusammen übertragen werden, wie wird die Statusänderung beschrieben?

Danger Spots

Wenn der Server die Änderungen nicht überträgt, sondern nur eine Statusmeldung, dass es Änderungen gab kommt es zu einem Kommunikationsaufkommen, da alle Clients die neuen Daten abholen.

Clients können nicht erreichbar sein oder gar crashen. Um dann Störungen zu vermeiden, muss der Server diesen Client aus der Liste entfernen. In manchen Situationen kann der Server die Clients nicht direkt erreichen, z.B. wenn HTTP als Protokoll zum Einsatz kommt. In solch einem Fall muss der Client eine Anfrage an den Server stellen und warten, bis der Server ihn über Änderungen informiert um dann sofort erneut nach Änderungen zu fragen.

Known Uses

  • CURE: in einer webbasierten Lernplattform (CURE, Haake et al., 2004a) werden HTML Seiten an den Client übertragen und per JavaScript ersetzt.
  • NSTP. Das Notification Service Transfer Protocol, (Patterson et al., 1996) ist ein Service, der es ermöglicht, dass gleichzeitig mehrere Benutzer an den gleichen Daten arbeiten. Die Änderungen werden synchron an die Clients übertagen.
  • Java Message Service (JMS)
  • Suite (Dewan and Choudhary, 1992) ist ein verteiltes MVC Pattern (Buschmann et al., 1996), wo das Model auf dem Server gehalten wird und die Präsentation auf dem Client statt findet. Wenn immer sich das Model ändert, wird er Controller auf Clientseite informiert und das View geupdatet


Related Patterns

  • Centralized Objects: requires the use of Remote Subscriptions to keep clients’ views up to date.
  • Decentralized Updates and Mediated Updates: mainly differ from Remote Subscriptions in that the shared objects are kept at the clients. In the case of Decentralized Updates and Mediated Updates→5.2.5, the clients hold replicas of the shared objects while Remote Subscription only considers view state. This implies that no state changes to model objects are performed on the client’s side, which makes model consistency easier to manage.
  • Model-View-Controller (Buschmann et al., 1996) can be implemented in a distributed setting using Remote Subscriptions.
  • Publisher-Subscriber (Buschmann et al., 1996) is the localized version of this pattern.


Realisierung auf der eStudy-Plattform

Replicated Objects

Jan Kammer

Intent

Erlaubt dem Benutzer den Zugriff auf gemeinsame Objekte ohne Netzwerk-Verzögerung.

Context

Verbesserung der Performance-Aspekte von Centralized Objects

Problem

Die Antwortzeit von interaktiver Software bzw. Plattformen muss möglichst gering sein. Wenn die Antwortzeit abhängig von der Client-Server Kommunikation ist, sind die Plattformen ungeeignet.

Scenario

Paul und Charley haben auf Basis von Centralized Objects einen interaktiven Diagramm-Editor implementiert. Leider sind die Verzögerungen so groß, das ein gemeinsames Arbeiten nicht möglich ist. Charley ist der Meinung das dies ein Problem des "centralized model" ist, weil alle Aktionen zuerst auf dem Server ausgeführt werden müssen, bevor die einzelnen Clients aktualisiert werden.

Symptoms

Dieses Pattern sollte Benutzt werden wenn:

  • Benutzer mit einer permanenten Netzwerkverbindung zusammen mit einer interaktiven Software arbeiten.
  • Benutzer viele Änderungen an einem großen Objekt vornehmen.
  • Die Antwortzeit der Software netzwerkbedingt zu langsam ist

Solution

Gemeinsame Daten auf den Client kopieren. Die Benutzer bearbeiten dann die entsprechende lokale Kopie.

Dynamics

Da jeder Nutzer lokal seine Daten bearbeiten kann, wird die Datenkonsistenz zu einem Problem. Um die Datenkonsistenz sicher zu stellen sollte "Decentralized Updates" oder "Mediated Updates" benutzt werden um lokale Änderungen mitzuteilen.

Nutzer die später zur Gruppe hinzukommen müssen sich alle gemeinsam benutzen Datenobjekte von einer Seite holen die bereits mitwirkt.

"State Transfer" und "Replay" sind zwei Lösungsansätze für dieses Problem.

Rationale

Seit die Benutzer lokalen Zugriff auf die Daten haben, können sie die Daten ohne Verzögerung anzeigen und bearbeiten.

Check

Vor dem Anwenden des Patterns sollten folgende Fragen geklärt werden:

  • Wie erkennen sie die gemeinsamen Daten die zum Client geschickt werden?
  • Wie teilen sie lokale Änderungen den andren Clients mit?
  • Ist die Konsistenz von kopierten Objekten ein Problem? Wenn ja, wie können sie die Konsistenz sichern wenn Updates gleichzeitig ausgeführt werden?

Danger Spots

Replication versichert das die Verzögerung beim Zugriff auf gemeinsame Objekte möglichst gering ist, aber es kann zu einer großen Verzögerung kommen wenn auf die Objekte zum ersten mal zugegriffen wird.

Replication verursacht viel Traffic, wenn dies ein Problem ist, sollte man ein partielles kopieren (replication) in Betracht ziehen.

Desweiteren sollte man das individuelle Arbeitsverhalten der Benutzer beachten. Angenommen es handelt sich um ein System um Bücher zu bearbeiten. Die Einheit für das Kopieren (replication) ist jeweils ein Kapitel. Wenn sich also ein Nutzer für ein Kapitel interessiert, wird dieses komplett geladen. Im schlimmsten Fall wollte er nur einen kurzen Blick in das Buch werfen und springt gleich weiter in das nächste Kapitel ohne Änderungen vorzunehmen. So werden Objekte unnötig komplett geladen und es entsteht viel Traffic. Um dies zu vermeiden sollten schon zu Beginn Algorithmen eingeführt werden, wann ein Benutzer ein gemeinsames Objekt benötigt und wann nicht.

Known Uses

  • GroupKit (Roseman und Greenberg, 1996a) verwaltet gemeinsame Objekte in einer hierarchischer Datenstruktur.
  • COAST (Schuckmann et al., 1996b) erlaubt Clients eine lokale Kopie des gemeinsamen Objekts zu halten. Um eine Kopie zu erhalten, müssen sich die Clients an einem zentralen Server registrieren der dann eine Kopie zur Verfügung stellt.
  • DreamObjects (Lukosch, 2003a) unterstützt kopierte Objekte für hoch interaktive Anwendungen. Alle Teilnehmer bekommen eine Kopie und lesenden Zugriff auf das lokale Objekt. Änderungen werden lokal, für den Nutzer transparent, separat gespeichert.
  • HTTP/1.1 (Fielding et al., 1999) unterstützt Caching auf Client und Serverseite. Caching auf Clientseite ist am weitesten verbreitet.

Related Patterns

  • Centralized Objects
  • Nomadic Objects
  • Decentralized Updates
  • Fail-Stop Processor (Saridakis, 2003) Gemeinsame Objekte werden kopiert um beim Ausfall eines Clients auf einen anderen Client verweisen zu können.
  • Session Failover (Dyson und Longshaw, 2004) beschreibt wie Clients zu einem anderen Server wechseln können, wenn der primäre nichtmehr verfügbar ist.
  • Caching (Kirchner und Jain, 2004a) und Local Cache (Dyson und Longshaw, 2004) beschreiben das selbe Problem wie in Replicated Objects.
  • Data Replication (Dyson und Longshaw, 2004) beschreibt auch das Kopieren von Objekten, aber in diesem Fall auf Server-Level.

Realisierung auf der eStudy-Plattform

Nomadic Objects

Jan Kammer

Intent

Zugriff auf Objekte ermöglichen ohne Netzwerk.

Context

Es wurde eine Architektur (z.B. mit Centralized Objects) geschaffen, die es Usern ermöglicht auf gemeinsame Objekte über ein Netzwerk zuzugreifen. Nun soll es möglich sein diese Objekte auch ohne bestehende Netzwerkverbindung zu nutzen.

Problem

Die Nutzer haben keine Verbindung zu dem System auf dem relevante Daten sind. Die Nutzer können ohne stabile Verbindung ihre Arbeit nicht beenden, da kein Zugriff auf die Daten besteht.

Scenario

Janet hat einige neue Features in einer Engine implementiert. Sie hat damit vor einigen Tagen begonnen und möchte ihre Arbeit nun über das Wochenende beenden. Leider kann sie dies aufgrund einer fehlenden Internetverbindung nicht. Sie hat kein Zugriff auf das Repository.

Symptoms

Dieses Pattern sollte benutzt werden, wenn:

  • Benutzer oft offline arbeiten und die Daten auf verschiedenen Endgeräten benutzen
  • Benutzer nicht überall arbeiten könne wo sie wollen
  • Benutzer an vollständigen gemeinsamen Objekten arbeiten
  • Benutzer mit unzuverlässigen Netzwerkverbindungen arbeiten (GSM)

Solution

Kopieren der Daten auf die Endgeräte und den Benutzer die Daten verändern lassen, selbst wenn keine Netzwerkverbindung besteht. Die lokalen Kopien updaten wenn wieder eine Verbindung besteht.

Dynamics

Immer wenn ein Client sich mit einem Netzwerk verbindet, werden die relevanten Daten mit einem zentralen Server oder einem Client abgeglichen. Der Client kann sich dann wieder vom Netzwerk trennen. Wenn er sich wieder verbindet, wird geprüft ob beide Seiten eine aktuelle Version des kopierten Objekts besitzen. Ein Mechanismus um dies zu erreichen ist Decentralized Updates.

Rationale

Seit die benötigten Daten auf dem Gerät des Nutzers sind, hat er immer die Möglichkeit auf die Daten zuzugreifen.

Check

Bei Nutzung dieses Patterns, sollten sie folgende Fragen beantworten:

  • Wie werden sie die relevanten Objekte die auf den Client kopiert werden erkennen?
  • Wie werden sie die Objekte erkennen die seit der letzten Verbindung geändert wurden?
  • Wie werden Änderungen übertragen?
  • Wie werden Konflikte gelöst, wenn es Änderungen auf Clientseite und auf Serverseite gibt?

Danger Spots

Es ist schwierig zu entscheiden welche Daten wirklich benötigt werden, wenn der Client keine Internetverbindung hat. Dieses ist kein reines technisches Problem, sondern Bedarf auch das Eingreifen des Benutzers.

Known Uses

  • Sync (Munson und Dewan, 1997) ist ein Framework das auf replication basiert und Klassen bereitstellt die es dem user ermöglichen gemeinsame Objekte zum implementieren.
  • IMAP (Crispin, 1996) benutzt das Kopieren von EMail-Nachrichten und Ordnern um dem Benutzer das Archivieren seiner Mails auf verschiedenen Clients zu ermöglichen. Nachrichten sowie Ordner können offline verwaltet werden. Beim Wiederverbinden mit dem Server werden die Änderungen mit dem Server synchronisiert.
  • Lotus Notes (http://www.lotus.com/notes) nutzt das Kopieren von gemeinsamen Objekten als Kernprinzip. Nutzer arbeiten gemeinsam an Centralized Objects welche in verschiedenen Notes-Datenbanken gespeichert sind.
  • offlineCURE (Lukosch et al., 2006) benutzt Nomadic Objects um den Nutzern das Arbeiten mit der Lernplattform CURE auch ohne Internetverbindung zu ermöglichen.
  • CVS ist ein System zur Versionsverwaltung von Dateien, das hauptsächlich im Zusammenhang mit Software-Quelltext verwendet wird.

Related Patterns

Realisierung auf der eStudy-Plattform

Mediated Updates

--Dknp40 12:47, 22. Nov. 2010 (CET)

Intent

Alle Updates werden von einer zentralen Instanz durchgeführt um die administrativen Aufgaben zu minimieren.

Context

Sie haben bereits DECENTRALIZED UPDATES betrachtet, um Teilnehmer über Zustandsänderungen an ihren Kopien des Gegenstands zu informieren. Jetzt soll der administrativen Aufwand für die Benachrichtigung und Wahrung der Konsistenz reduziert werden.

Problem

Teilnehmer wollen andere Teilnehmer, die Kopien der gleichen Daten halten, über Änderungen informieren. Wenn Sie die Teilnehmer direkt kontaktieren, benötigen Sie Informationen darüber wer die Teilnehmer sind und müssen eine Verbindung aufbauen. Das ist kompliziert und Fehleranfällig, da die Teilnehmer in unvorhersehbarer Weise die Verbindung verlieren oder wiederaufnehmen können.

Scenario

Michele, Ana and Maurice haben eine zeitlang am VRML-Export Feature der Game-Engine gearbeitet. Seit einer von Ihnen Probleme hatte das zentrale Code-Repository zu erreichen, einigten sich die drei Entwickler darauf Updates per Email zu verteilen. Als Noah dem Team beitrat, stelle Michele ihm das Team vor und wies die restlichen Entwickler an, auch Noah über neue Versionen per Email zu informieren. Ana war allerdings so daran gewöhnt ihre Updates nur an Michele und Maurice zu schicken, dass sie vergessen hat Noah über ihr nächstes Update zu informieren.

Symptoms

Sie sollten dieses Pattern in Betracht ziehen wenn...

  • Der Zustand des Gegenstands oft voneinander abweicht, weil Update Benachrichtigungen vergessen worden sind
  • Teilnehmer nicht wissen wer die anderen Teilnehmer sind
  • Es schwierig ist alle Teilnehmer zu verwalten, besonders wenn Sie sich regelmäßig ändern

Solution

Deshalb: Lassen Sie eine zentrale Stelle, einen Vermittler (engl. mediator) eine Liste aller Klients verwalten, die über Änderungen an den kopierten Gegenstände informiert werden müssen. Immer wenn ein Klient lokal Änderungen vornimmt, informiert er den Vermittler. Er liefert dann eine Update Nachricht an alle interessierten Teilnehmer aus.

Dynamics

Rationale

Die Klienten werden entlastet, denn der Vermittler verschickt die Update Benachrichtigungen und verteilt die Updates. Der Vermittler hat immer eine gültige und aktuelle Liste der Klienten, da sich die Klienten beim Vermittler anmelden müssen um eine Kopie zu erhalten. Da der Vermittler über alle Änderungen informiert ist, ist er der bevorzugte Ansprechpartner um die aktuelle Version des Gegenstands zu erhalten. Klienten sich nicht verbinden können oder erst später einer gemeinschaftlichen Sitzung beitreten, können dadurch immer den aktuellen Stand des Gegenstands erhalten. Dies ist in Umgebungen ohne einen zentralen Vermittler unmöglich (siehe DECENTRALIZED UPDATES).

Check

Wenn Sie dieses Pattern anwenden, sollten folgende Fragen beantwortet werden:

  • Beschreiben Sie welche Änderungen am Gegenstand vorgenommen werden müssen oder liefern Sie den neusten Zustand aus?
  • Wie wollen Sie die Teilnehmer-Listen des Vermittlers aktuell halten?
  • Wie wollen Sie garantieren, dass alle Teilnehmer die Update Benachrichtigung erhalten?
  • Werden Sie Mechanismen verwenden, z.B. wie PESSIMISTIC LOCKING um die Konsistenz gewährleisten zu können? Wenn ja, wie werden diese Mechanismen die Art und Weise der Update Benachrichtigung beeinflussen?

Danger Spots

Der Vermittler ist eine einzelne Schwachstelle und ein Flaschenhals für die Netzwerkkommunikation. Wenn Benutzer zur gleichen Zeit den Zustand des Gegenstands ändern, können Konflikte entstehen. Diese sind vom Vermittler zu beheben. Verlieren Klienten die Verbindung und nehmen Sie erst später wieder auf, muss der Vermittler dafür sorgen, dass sie alle Updates erhalten.

Known Uses

Related Patterns

  • Optimistic Concurrency Control
  • Distributed Command
  • Replicated Objects
  • Decentralized Updates
  • Mediator
  • Object Manager
  • Recoverable Distributor
  • Acknowledgement and Roll Forward

Realisierung auf der eStudy-Plattform

eStudy nutzt bereits Apache Subversion zur Versionsverwaltung des Codes. Der Unterschied besteht darin, dass sich die Klienten (hier: Entwickler) beim Vermittler (hier: SVN Repository) melden um Updates zu erhalten und nicht direkt über Updates informiert werden. Allerdings ist eine Information über Änderungen am Code möglich. Das Projekt-Management-Tool Trac protokolliert alle Änderungen und Bug-Requests und liefert über eine Mailingliste entsprechende Benachrichtigungen.

Decentralized Updates

Intent

Verteilen von lokalen Zustandsänderungen an andere Benutzer um die Konsistenz gemeinsam genutzter Objekte zu wahren.

Context

Sie haben die Grundlagen geschaffen, damit Teilnehmer auf gemeinsame Objekte zugreifen können. Was passiert nun, wenn diese verteilten Objekte geändert werden?

Problem

Benutzer verändern ihre lokalen Kopien eines Gegenstands und wollen diese Änderungen den anderen Benutzern mitteilen, die ebenfalls eine Kopie desselben Gegenstands haben. Es ist nicht möglich einen zentralen Vermittler (siehe MEDIATED UPDATES) einzurichten.

Scenario

Rodrigo und James arbeiten beide an einem Diagramm, dass die Dynamik der "Dialouge Interpretation Enginge" zeigt. Jeder besitzt eine lokale Kopie des Diagramms und entwickelt es weiter. In Folge dessen weichen die beiden Versionen immer weiter voneinander ab. Als Rodrigo und James versuchen, ihre Arbeit wieder zusammenzuführen, entstehen eine Menge Fehler, die nun manuell behoben werden müssen.

Symptoms

Sie sollten dieses Pattern anwenden wenn:

  • Benutzer durch teilen und ändern von kopierten Artefakten zusammenarbeiten
  • Der Zustand der kopierten Gegenstände auseinander geht weil Benutzer ihre Änderungen nur lokal speichern.

Solution

Deshalb: Nachdem eine Änderung am Gegenstand vorgenommen wurde, senden Sie eine Update Benachrichtigung an alle anderen Teilnehmer, die ebenfalls eine Kopie des Gegenstands verwalten. Passen Sie darauf auf, dass alle Teilnehmer die Nachricht erhalten und anhand dieser Nachricht Ihre Änderungen bei sich durchführen können.

Dynamics

Rationale

Weil letztendlich alle Teilnehmer eine Update Benachrichtigung erhalten, können Sie Ihre Kopie auf den aktuellen Entwicklungsstand abändern.

Check

Wenn Sie dieses Pattern anwenden, sollten folgende Fragen beantwortet werden:

  • Beschreiben Sie welche Änderungen am Gegenstand vorgenommen werden müssen oder liefern Sie den neusten Zustand aus?
  • Wie wollen Sie die Teilnehmer Listen und die Versionsstände der Teilnehmer aktuell halten?
  • Wie wollen Sie garantieren, dass alle Teilnehmer die Update Benachrichtigung erhalten?
  • Werden Sie Mechanismen verwenden, z.B. wie PESSIMISTIC LOCKING um die Konsistenz gewährleisten zu können? Wenn ja, wie werden diese Mechanismen die Art und Weise der Update Benachrichtigung beeinflussen?

Danger Spots

Sie kennen eventuell nicht alle Teilnehmer, die eine Arbeitskopie verwalten. In diesem Fall wird der Einsatz einer Flooding-Technik empfohlen. Bei dieser Technik informieren bereits informierte Teilnehmer ihre Freunde über die Änderung. Ein Beispiel für diese Technik ist das peer-to-peer Filesharing Netzwerk Gnutella. Update Benachrichtigungen könnten verloren gehen und nicht alle Teilnehmer informiert werden. Eine Möglichkeit dies zu verhindern ist der Einsatz von fortlaufenden Nummern für die Benachrichtigungen. Jeder Teilnehmer speichert diese Nummern. Gibt es in der Nummernfolge eine Lücke, meldet sich der Teilnehmer und bittet um das verlorene Update oder erhält eine komplett neue, aktuelle Arbeitskopie. Arbeiten mehrere Teilnehmer zur gleichen Zeit am gleichen Objekt, können Konflikte auftreten. Falls die Netzwerkbandbreite ein Flaschenhals sein kann, führen Sie DISTRIBUTED COMMANDS ein, die nur die Teiländerungen beschreiben, anstatt komplette Arbeitszustände. Verteilen Sie komplette Arbeitskopien, falls es länger dauert, die einzelnen Änderungen durchzuführen.

Known Uses

Related Patterns

  • Optimistic Concurrency Control
  • Distributed Command
  • Mediated Updates
  • Replicated Objects
  • Acknowledgment
  • Roll Forward

Realisierung auf der eStudy-Plattform

Dieses Pattern hat für eStudy keine Relevanz, da ein SVN-Repository vorhanden ist.

Distributed Command

fetn63

Intent

Durch die wieder Ausführung von befehle (COMMANDS), bleiben alle Kopie eines gemeinsamen Objekt Konsistenz.

Context

Nachdem Sie alle Clients erlauben haben „Replicated Objects„ zu modifizieren oder zu aktualisieren entweder durch „Decentralized Updates“ oder „Mediated Updates“ möchten Sie nun Ihre Netzwerk Bandbreite reduzieren.

Problem

Alle Clients Können Ihre Änderungen die Sie lokal an gemeinsamen Objekte gemacht haben übertragen. Bei der Übertragung des neues Versions eines lokal geänderte gemeinsamen Objekts, wird immer mehr als benötigen Informationen Übertragen, egal ob nur eine kleine Stück geändert wurde. Das belastet der Netzwerk und die Bearbeitung Zeit wird dadurch unnötig lange.

Scenario

Charley und Paul wollen die neue Verschlüsselung Module eines Spiels testen. Charley startet das Programm im Debug Mode. Paul kann aber das aktuelle Programm (in Debug Mode) nicht sehen da das Programm wird nicht als Test übertragen.

Symptoms

Das Pattern ist anwendbar wenn:

Die Übertragung eines gemeinsamen Objects zu lange dauert. Es gibt sehr oft Änderungen auf gemeinsamen Daten, und den log Dateien zur diese Änderung ist ziemlich Kleine als die gemeinsamen Daten selbst. - Die Anwender einer kollaborative Anwendung sind mit der Bearbeitung Zeit der Anwendung nicht zufrieden. - Nicht alle Teile der Anwendung sind replizierbar.

Solution

Deshalb: Alle Methode-Aufruf die die Clients benutzen um Ihre Lokale Kopie zu manipulieren werden als COMMANDS (Gamma et al.. 1995) übernommen. Und danach wird diese COMMAND an alle Clients verteilt damit sie es zu Ihrer lokal Kopie wieder durchführen können.

Dynamics

Abbildung zeigt, wie die verschiedenen Client bei der Verwendung „Decentralized Updates“ zusammenarbeiten. Im ersten Schritt, der Client der den gemeinsamen Zustand modifiziert hat, holt die Änderung wieder zurück. Das wird realisiert wenn alle Zustandsänderung COMMAND über eine bestimmte Schnittstelle immer aufgerufen werden, durch die Verkapselung des gemeinsamen Objekts in einem WRAPPER (Gamma et al., 1995) der holt die aufgerufene COMMAND oder mit Hilfe von Aspekt Objekt Orientiert Programmierung Technik.


Nachdem der Zustandsänderung geholt ist, dieser Client führt eine COMMAND um zu wissen: - Welche Objekte sich geändert haben - Welche Methoden sind aufgerufen worden - Welche Argumente wurden verwendet, um den COMMAND auszuführen.

Der Client der seinen COMMAND zur anderen Client verteilt, behält natürlich der Kopie solange er den COMMAND lokal durchführt. Alle Client die den COMMAND bekommen benutzen die Informationen, die er gibt, um den Befehl an eigene lokale Kopie auszuführen.

Im einfachsten Fall, verwendet Man einer Programmiersprache der erlaubt die dynamische Ausführung von Befehlen lassen Sie in der Laufzeit wieder aufrufbar. Wenn es in der Programmierung nicht möglich ist, braucht man unbedingt ein API der die Ausführung in der Laufzeit von COMMAND ermöglicht. Damit das möglich ist, müssen alle COMMANDS die repliziert sollen identifiziert sein. Es gibt COMMANDS, die gemeinsamen Daten manipulieren oder die Aktionen auf gemeinsamen Daten durchführen, oder die für alle User in Kollaborative Session wichtig sind. Setter Methode auf gemeinsamen Objekt Attribute sind gute Beispiele für der erste Fall. Ein Beispiel für den zweiten Fall, kann das Durchspiel von PLAYBACK auf eine gemeinsame Audio Quelle.

Rationale

Da nur der Befehl Objekt in dieser Muster verteilt ist, und nicht die gesamte Objekt Zustand des gemeinsamen Objekts, ist die Menge des Netzwerk Verkehrs sich reduziert solange den Befehl Objekt kleiner ist als der gesamte gemeinsamen Objekten, die der Befehl betrifft. Die Clients haben es dann leicht bei der Messages Aktualisierung, da sie brauchen nicht mehr zu bestimmen welche Teile eines gemeinsamen Daten verändert wurden und welche nicht.

Check

Folgende Fragen sollten beantwortet werden, wenn dieses Pattern verwendet wird: - Wie werden die Befehle beschrieben? - Wie werden die Befehle übernommen? - Wie werden die Befehle wieder durchgeführt?


Danger Spots

Die Clients können parallel COMMANDS durchführen. Das sollte zur der Inkonsistenz von gemeinsamen Daten führen. Wenn man OPTIMISTIC CONCURRENCY CONTROL benutzt, das soll kein Problem sein. Weitere andere Mechanismus die Konsistenz gewährleisten können z.B. PESSIMISTIC LOCKING, CONFLICT DETECTION oder OPERATIONAL TRANSFORMATION beigefügt sein.


Es braucht immer lange lokal Befehl wiederdurchzuführen. Wenn Sie wissen das der Verteilung von Objekt Zustand schneller als die Wiederdurchführung von COMMAND, dann verteilen Sie lieber Objekt Zustände.


Bei der Verteilung von COMMANDS sie müssen sicher sein das jeder Client diese COMMAND durchführen kann. Das ist in alle Fälle nicht so, z.B. wenn die Durchführung von COMMAND mehr lokale Ressource brauchen als verfügbar braucht.


COMMANDS müssen immer was zurück geben. Beim erneuten Ausführen von COMMAND auf jedem Client entweder überspringen das Ergebnis oder, wenn das Ergebnis in der Benutzeroberfläche für eine konsistente Sicht auf jeden Client angezeigt werden muss, erlaubt der Benutzer-Schnittstelle den COMMAND und seinen Ergebnis unterzuschreiben. Man benutzt dafür Publisher-Subscriber (Buschmann et al., 1996).


COMMANDS können Arguments haben. Diese Argumente müssen entweder als Wert oder als Reference übertragen werden. Beim Übertragen von Argument als Reference ist es bei der Ausführung den COMMAND notwendig dass die Reference Argument den gleichen Zustand an jedem Standort haben. Andernfalls, kann die Ausführung von COMMAND zu Inkonsistenzen in gemeinsamen genutzten Daten führen.


COMMANDS können gemeinsamen genutzten Daten, die nicht durch ihre Argumente verwiesen wird. Um gemeinsamen Zustand Konsistenten zu halten, müssen alle verwendeten Daten den gleichen Zustand während der Ausführung des COMMAND haben. Dies kann erreicht werden wenn das System sicher stellt dass, sein COMMAND immer in der gleichen Reihenfolge ausgeführt werden, und dass sie nicht auf die lokale Benutzereingaben verlassen werden.


COMMANDS können andere COMMANDS die gemeinsamen Daten modifiziert aufrufen. Um konsistenten Zustand zu halten ist es notwendig sicherzustellen, dass jeder Client nur einmal den COMMANDS ausführt. (Mazouni et al., 1995b) sprechen von dem doppelten Aufruf Probleme. Sie stellen zwei Lösungen:

1. Post-filtering. Eine Website die Nachricht für COMMAND bekommt überprüft ob es bereits eine Nachricht für die gleiche Aktion bereits verteilt wurde oder nicht. Wenn ja, ignoriert er einfach die zusätzlichen COMMANDS. Obwohl das zum ungewünschten Wirkung führt, hat es keine Wirkung an dem Netzwerkverkehr. Pre-filtering. Nur eine besondere koordinierende Stelle verteilt eine Nachricht, wenn es notwendig ist. Diese Lösung vermeidet dass eine Website mehrerer Meldungen für die gleiche Command Aufnimmt.

Known Uses

Arjuna (Little et al., 1993) (Little and Shrivastava, 1994) Amoeba (Tanenbaum et al., 1991) (Wood, 1993) Multicast-RPC, DreamObjects (Lukosch, 2002) GARF (Mazouni et al., 1995a)

Related Patterns

MEDIATED UPDATES und DECENTRALIZED UPDATE können DISTRIBUTED COMMAND um die Konsistenz in dem gemeinsamen Objekt zu archivieren.

PESSIMISTIC LOCKING, CONFLICT DETECTION und OPERATION TRANSFORMATION können verwendet werden, um die Konsistenz der gemeinsamen Objekte zu gewährleisten.

COMMAND (Gamma et al., 1995) beschreibt, wie eine Zustandsänderung eingekapselt werden kann. Die DISTRIBUTED COMMAND muster verwendet die COMMAND Muster um die Methodenaufrufe die Clients benutzen für die Manipulation von REPLICATED OBJECT zu erfassen und erneut auszuführen.

DISTRIBUTED COMMAND (Brown et al., 1999) ist eine frühe Version dieses Muster, das sich hauptsächlich auf verteilte Komponente und Frameworks wie CORBA oder EJB konzentriert. Eine andere Version des DISTRIBUTED COMMAND Muster wurde durch al Zabir (2005) herausgegeben.

PUBLISHER-SUBSCRIBER (Buschmann et al., 1996) ermöglicht Clients ausgeführte oder erneute ausgeführte COMMANDS lokal auszuführen.

Realisierung auf der eStudy-Plattform

????

Data consistency support

Pessimistic Locking

Kai Krause

Intent

Bearbeiten mehrere Nutzer die identischen Daten, so darf zur selben Zeit nur ein Nutzer dessen Zustand dieser Daten ändern.

Context

Wenn mehrere Nutzer zur selben Zeit an identischen Daten arbeiten, muss verhindert werden, dass durch den zeitgleichen Zugriff inkonsistente Daten entstehen.

Problem

Auch wenn mehrere Nutzer ein identisches Objekt bearbeiten, muss muss gewährleistet sein, dass alle Änderungen an diesem Objekt übernommen werden.

Scenario

Also Beispiel kann man sich einen Spieleentwickler vorstellen, der den Code einer Spieleengine überarbeitet. Während er dies tut, bearbeiten jedoch seine Kollegen den Code. Hierdurch können seine Änderungen nicht einfach mit den Änderungen seiner Kollegen zusammengeführt werden. Eine Lösung für das Problem wäre die Kollegen davon abzuhalten Änderungen am Code vorzunehmen, indem er sie zum Pizza Essen einladet. Während die Kollegen Pizza essen, kann er den Code überarbeiten, ohne das ein Kollege gleichzeitig etwas am Code verändert.

Symptoms

Dieses Entwurfsmusster sollte in folgenden Fällen verwendet werden:

  • Die Rückgängigmachung von Inkonsistenten Änderungen ist schwierig oder unmöglich.
  • Das Fehlen eines Sozialen Protokolls gleichzeitige und konfligierende Änderungen verursacht.
  • Es müssen kritische Daten geteilt werden, in denen unter keinen Umständen Inkonsistenzen auftreten dürfen.

Solution

Eine Seite muss eine Sperre beantragen und auch erhalten, bevor sie den Zustand eines geteilten Objektes ändern darf. Eine Sperre kann von unterschiedlicher Granularität sein. Die Granularität legt fest wieviele Attribute des Objektes geändert werden dürfen nachdem die eine Seite die Sperre erhalten hat. Nachdem die Änderungen durchgeführt wurden sind, wird die Sperre wieder freigegeben, sodass andere Seiten einen Lock beantragen können um das Objekt zu verändern.

Dynamics

Um Änderungen an einem Objekt vorzunehmen, muss eine Seite zunächst ein Lock auf das Objekt beantragen. Dies kann beispielsweise durch einen zentrale Lockverwaltung geschehen. Diese gibt der Seite darauf hin Rechte das entsprechende Objekt für andere Seiten zu sperren. Nun kann die Seite Änderungen an dem Objekt vornehmen und diese Änderungen den anderen Seiten mitteilen. Nachdem Bearbeiten wird das Objekt durch die Seite wieder freigegeben. Will eine andere Seite das Objekt bearbeiten während dieses gesperrt ist, dann muss sie solange warten bis das Objekt wieder freigegeben ist. Es gibt viele Möglichkeiten das Sperren umzusetzen. Der verwendete Algorithmus beeinflusst die Nutzerschnittstelle, da Nutzer warten müssen. Dadurch steigt die Antwortzeit der Anwendung. Wenn die einzelnen Seiten über TPC/IP miteinander verbunden sind, kann ein Algorithmus der auf Token basiert die Anzahl der auszutauschenden Nachrichten reduzieren und damit die Antwortzeit der Anwendung verbessern. Wenn die einzelnen Seiten über ein Netzwerk verbunden sind, welches IP Multicasting unterstützt, dann sollte ein Algorithmus verwendet werden der auf Multicasting Nachrichten basiert.

Rationale

Durch das Sperrverfahren kann zur selben Zeit immer nur eine Seite Änderungen an einem Objekt vornehmnen. Hierdurch werden Inkonsistenzen vermieden.

Check

Folgende Fragen sollten beantwortet werden, wenn dieses Entwurfsmuster verwendet wird:

  • Welche Granularität wird die Sperre haben?
  • Welche Art von Sperre wird verwendet?
  • Wie werden Deadlocks vermieten, wenn verschiedene Sperren notwendig sind um den Zustand eines Objektes zu verändern?

Danger Spots

Das Sperrverfahren erhöht die Antwortzeit einer Anwendung. Es ist schwierig die Granularität festzulegen. Eine grobe Granularität mindert zwar die Anzahl der Sperranfragen, aber auch die Anzahl der möglichen gleichzeitigen Zugriffe. Eine feine Granularität der Sperren erhöht zwar die Anzahl der Sperren und damit den Netzwerktraffic, erhöht aber auch die Anzahl der gleichzeitigen Zugriffe auf ein Objekt. Wird mehr als eine Sperre benötigt um Änderungen vorzunehmen besteht die Gefahr eines Deadlocks. In diesem Fall müssen Strategien zur Vermeidung von Deadlocks angewandt werden. Havender rät hierbei alle Sperren mit einer ID zu versehen und alle Sperren anhand dieser ID zu sortieren. Es sollten dann nur Sperranfragen gemäß dieser Sortierung zugelassen werden.

Known Uses

DreamObjects

Unterstützung von zwei Verschieden großen Granularitäten. Pro geteiltem Objekt gibt es eine Sperre. Für mehr gleichzeitige Änderungen zu realisieren, können Entwickler eine Liste von Methoden angeben, die den wechselseitigen Ausschluss beachten müssen. Für jede Liste gibt es dann eine eigene Sperre.

DistView

Hierbei wird eine Anwendung in die Schnittstelle und die Andwendungsobjekte geteilt. Alle Zugriffe auf ein Objekt werden abgefangen und allen Clients mitgeteilt. Es gibt eine Sperre pro Anwendungsobjekt.

Related Patterns

Optimistic ConcurrencyControll (5.3.2)

Wenn es auf die Antwortzeiten der Anwendung ankommt, kann dieses Entwurfsmuster verwendet werden. Hierbei werden Änderungen in der optimistischen Art durchgeführt.

Operational Tranformation (5.3.4)

Beschreibt wieviele Nutzer zur gleichen einen geteilten Zustand ändern können ohne dafür Pessimistic Locking zu verwenden.

Floor Control (4.1.7)

Beschreibt wie der wechselseitiger Ausschluss von Aktionen auf Anwendungsebene oder auf der Ebene des Sozialen Protkolls sichergestellt werden kann.

Selective Locking (McKenney, 1996)

Eine Patternsprache für Sperrungen in parallelen Programmen

Permit Based Locking (Schütz 2001)

Ein Entwurfsmuster für das Anfragen und Erhalten von Sperren mit dem Ziel den Netzwerktraffic klein zu halten.

Coordinator (Jain 2003)

2-Phasen Commit Protokoll. Hierbei wird sichergestellt, dass alle Clients eine Änderung vornehmen könne.

Ressource Lifecycle Manager (Kirchner and Jain, 2004c)

Kontrolliert Rechte um geteilte Objekte zu verändern.

Realisierung auf der eStudy-Plattform

Nach aktuellem Kenntnisstand wird dieses Pattern im eStudy nicht verwendet. Eine denkbare Lösung wäre eine Collaborationsanwendung für Texte a la GoogleDocs.

Optimistic Concurrency Control

Kai Krause

Intent

Daten werden optimistisch geändert und bei konfligierenden werden Änderungen teilweise Rückgängig gemacht.

Context

Man erlaubt gleichzeitiges arbeiten an geteilten Objekten. Alle Zustandsänderungen werden an teilnehmenden Clients übermittelt. Es muss die Konsistenz sichergestellt werden.

Problem

Es soll Konsistenz sichergestellt werden, aber die Änderungen sollen möglichst schnell durchgeführt werden.

Scenario

Paul und Charley können mit ihrem Diagramm Editor auf gemeinsame Objekte zugreifen. Um konfligierende Änderungen zu vermeiden werden Sperren verwendet. Die Anwendung ist jedoch sehr langsam und Charley vermutet, dass die Sperren die Ursache dafür sind. Jedesmal wenn ein Objekt ausgewählt wird, muss eine Sperre angefordert und genehmigt werden.

Symptoms

Diese Entwurfsmuster sollte benutzt werden wenn:

  • Die Konsistenz sichergestellt ist, aber die Anwendung dadurch sehr langsam ist.
  • Das Anfordern von Sperren zu viel Zeit in Anspruch nimmt.
  • Die Anwendungsumgebung gleichzeitige Aktionen kontrollieren kann.

Solution

Lokale Änderungen werden sofort ausgeführt. Wenn ein Konflikt mit der Änderung eines anderen Clients erkannt wird, dann wird die Änderung rückgängig gemacht oder abgewandelt.

Dynamics

Ein Client ändert das lokale Objekt und informiert alle anderen Clients mit Hilfe der Decentralized Updates darüber. Der Client kann nun weiterarbeiten und erhält ein Zustimmung oder eine Ablehnung für seine letzte Änderung. Wenn seine Änderungen mit den Änderungen der anderen Clients konfligieren werden seine Änderungen rückgängig gemacht. Hierfür wird eine Konflikterkennung (Conflict Detection) benötigt. Um die Änderungen rückgängig zu machen, muss der alte Zustand gespeichert werden. Hierfür kann das Memento Pattern verwendet werden. Eine andere Möglichkeit besteht darin die Änderungen als Distributed Commands zu kapseln und für jede Anweisung eine Umgekehranweisung zu erstellen. Wird ein Konflikt erkannt, dann kann die Umkehranweisung dazu verwendet werden die Änderung rückgängig zu machen.

Neben dem Ablehnen und Rückgängigmachen von Änderungen können lokale Änderungen auch direkt ausgeführt werden. Im falle eines später erkannten Konfliktes können diese aufgeschlüsselt werden. Statt die Änderung rückgängig zu machen, wird sie abgeändert, sodass sie keinen Konflikt mehr verursacht. (Operational Transformation)

Rationale

Durch Verwendung des Optimistic Concurrency Control wird das warten von Clients in zwei Fällen vermieden.

  1. Vor dem durchführen einer Änderung
  2. Nach dem durchführen einer Änderung, dem Informieren der anderen Clients und dem Einholen deren Zustimmung.

Check

Wenn dieses Entwurfsmuster verwendet wird, sollten diese Fragen geklärt werden:

  • Wie werden Konflikte erkannt?
  • Werden alle unterschiedlichen Zustände eines Objektes gespeichert um bei Bedarf zum voherigen Zustand zurückzukehren?
  • Werden Umkehranweisungen erstellt um das Rückgängigmachen zu ermöglichen?

Danger Spots

  • Das plötzliche Rückgängigmachen einer Änderung kann den Nutzer verwirren.
  • Das Rückgängig machen ist sehr Speicherintensiv, wenn der Zustand einer Anwendung gespeichert werden soll.
  • Wenn viele Änderungen durchgeführt werden ist Speicherintensiv die vorherigen Zustände zu speichern. Hier sollten Umkehranweisungen verwendet werden.
  • Manchmal ist es nicht möglich eine Umkehranweisung zu verwenden. Ein Beispiel ist das ändern einer externen Quelle.
  • Das Ablehnen und Rückgängigmachen kann unter Umständen sehr viel Zeit in Anspruch nehmen, sodass die Anwendung unbenutzbar wird.
  • Es sollte darüber nachgedacht werden Operational Transformation anzuwenden. Auch die Restrukturierung der geteilten Informationen ist möglich siehe Lovely Bags.
  • Um die Anzahl der Rückgängigmachungen zu senken sollte das local lag paradigm verwendet werden. Hierbei werden lokale Änderungen solange herausgezögert bis sichergestellt ist, dass alle Clients die Änderung durchführen können.

Known Uses

COAST

Wenn der Client eine Änderung vornimmt, wird eine neue Transkation gestartet. Von einer Transaktionsverwaltung wird jeder Zugriff überwacht und in einem Transaktionslog gespeichert. Es wird ein Mediatorserver verwendet, der entscheidet ob Änderungen überleben oder nicht. Wenn die Änderung akzeptiert wurde ist nichts weiter zu tun. Andernfalls wird mit Hilfe des Transaktionslogs der alte Zustand wiederhergestellt.

DyCE

Benutzt einen zu COAST vergleichbaren Transaktionsmechanismus mit Optimistic Transaktions.

DOORS

Ein System ohne zentralen Server. Lokale Änderungen werden aufgezeichnet. Wenn sich ein Client verbindet, erhält dieser die Aufzeichnung und kann die Änderungen auch bei sich durchführen.

GINA

Die Vergangenheit eines Objektes wird als eine Art Anweisungsbaum verstanden. Dieser Baum wird UNDO/REDO Mechanismen, für Optimistic Concurrency Controll und für das Zusammenführen von Objekten verwendet.

Related Patterns

Conflict Detection (5.3.3)

Auch bei einem hohen Grad an Vertrauen, kann eine Gruppe Konflikte produzieren.

Lovely Bags (5.3.5)

Ein Beispiel wie man geteilte Objekte aufbaut, damit diese eine Vielzahl von gleichzeitigen Zugriffen zulassen.

Pessimistic Locking (5.3.1)

Es können Änderungen vorkommen, die nicht Rückgängig gemacht werden können. Hier sollten Sperren verwendet werden.

Operational Tranformation (5.3.4)

Beschreibt wieviele Nutzer zur gleichen einen geteilten Zustand ändern können ohne dafür Pessimistic Locking zu verwenden.

Optimistic Transaction (Hendrikxs et al., 2001)

Verwendet einen Änderungszähler durch den konfligierende Änderungen leichter erkannt werden können.

Rollback (Lea and Lea, 1999)

Der alte Zustand wird gespeichert um im Falle eines Konfliktest wieder zum ursprünglichen Konflikt zurückzukehren.

Community Of Trust (Coplien and Harrison, 2004)

Bearbeitet die gleiche Thematik wie Optimistic Concurrency Control, aber auf der Ebene eines Sozialen Prozesses.

Realisierung auf der eStudy-Plattform

Nach aktuellem Kenntnisstand wird dieses Pattern im eStudy nicht verwendet. Eine denkbare Lösung wäre eine Collaborationsanwendung für Texte a la GoogleDocs.

Conflict Detection

U13156

Intent

In Konflikt stehende Veränderungen erkennen.

Context

Zustandsänderungen können verteilt werden und man verwendet Optimistic Concurrency Controln. Es ist zu befürchten, das Veränderungen miteinander kollidieren können.

Problem

Ändern zwei oder mehre Benutzer zeitgleich ein und die selbe Daten, kann dies Auswirkungen auf die jeweiligen Änderungen haben. Dies kann zu inkonsistent Daten führen oder die Daten stimmen nicht mit den Absichten des Benutzers überein. Sollte dies den Benutzern nicht bewusst sein, kann dies die Zusammenarbeit beeinträchtigen.

Scenario

Susan und James arbeiten beide an der Quelldatei der Spracherkennungsengine. Beide haben sich die Datei von einem Shared File Repository kopiert und lokal gespeichert. James ändert den Algorithmus der Fourieranalyse. Er lädt die veränderte Datei hoch und sendet sie wieder an das Shared File Repository. Auch Susan ändert zwischenzeitlich etwas an dem Algorithmus. Sie lädt ihre Version hoch und sendet sie an das Shared File Repository, mit dem Effekt, dass die Änderungen von James überschrieben wurde.

Symptoms

Man sollte sich entscheiden den Pattern zu implementieren, wenn...

  • Benutzer parallel Dateien ändern, die zu inkonsistentn Daten führen können.
  • das Sozialprotokoll keine Konsistenz gewährleistet.
  • jeder Benutzer arbeitet an einer lokalen und nicht synchronen Version der gemeinsamen Dateien. Dies führt dazu, dass sich die Benutzer konzeptionell nicht einig sind.

Solution

Jeder Client behält alle lokalen Änderungen, die noch nicht von den anderen Clients angewendet werden. Wenn etwas von einem anderen Client geändert wird, überprüft man ob die Änderung die selbe Datei betrifft und ob es bisher noch nicht verwendet wurde. Erzeugen die Änderungen einen Konflikt, dann soll die Änderung rückgängig gemacht oder so umgewandelt werden, dass alle Clients einen konsistenten Zustand haben.

Dynamics

Jeder Client der fähig ist Datenkonflikte zu erkennen, muss alle seine Änderungen die er gemacht hat in einem Änderungsverlauf protokollieren. Zusätzlich muss für jede Änderung notiert werden, ob diese einen andern Client betrifft. Verwenden andere Clients die Änderung, kann es im Änderungsverlauf gelöscht werden, weil keine Konflikte aufgetreten sind.
Clients führen die Änderungen zunächst lokal durch und benutzen Decentrailized Updates direkt nach dem die Änderung verwendet wurde. Die Clients, die die Updates empfangen, überprüfen ihren Lokale Änderungsverlauf auf unbemerkte Änderungen der gleichen Datei.
Gleichzeitige Änderungen an einer Datei können für Konflikte sorgen. Der einfachste Weg um zu entscheiden ob ein Konflikt auftritt ist, das alle Änderungen an der gleichen Datei ein Änderungskonflikt ist. Im Allgemeinen kann man zwei Änderungen als Konflikt bezeichnen, falls diese einen unterschiedlichen Programmstatus haben der in einer unterschiedlichen Reihenfolge aufgerufen wurde.
Das bedeutet, dass die Änderungen nicht kommutativ sind. Um so detaillierte der Test für Kommutativität ist, desto größer ist die Anzahl der erlaubten gleichzeitigen Änderungen. Um zu prüfen ob zwei Änderungen kommutativ sind, wird der gebräuchliche Test von Lamport (1978) verwendet, der eine gleichzeitige Prüfung erlaubt. Dieser basiert auf der Verwendung der Logischen Uhr und Zeitstempel. Jeder Client pflegt eine lokale Logische Uhr. Wenn der aktive Client eine lokale Änderung vornimmt, fügt es einen Zeitstempel zu der Änderungen hinzu und aktualisiert die Logische Uhr. Ist die logische Uhr beispielsweise als ein Zähler implementiert erhöht sich dies um eins, wenn die logische Uhr aktualisiert wird. Das Verwenden von Zeitstempeln ermöglicht es Abläufe zu ordnen. Die logischen Uhren aller Clients werden nicht synchronisiert und jede lokale logische Uhr wird erst aktualisiert, wenn eine externe Änderung mit einem höheren Zeitstempel eingefügt wird oder bei einer lokalen Änderung. Somit ist es möglich, dass die Änderungen von unterschiedlichen Clients den selben Zeitstempel haben. Es wird davon ausgegangen das diese Änderungen nicht kommutativ sind.
Betrachtet man beispielsweise eine verkettete Liste für ein geteiltes Objekt, so könnte ein Client in Erwägung ziehen, dass das Hinzufügen von Daten (addFirst, addLast) zu dieser Liste ein Änderungskonflikt ist. Ein andere Client könnte definieren, dass addFirst and addLast paarweise kommutativ sind. Da ein addFirst Operator nicht von der Position des hinzugefügten Elements des addLast Operators betroffen ist. Anderseits sind zwei addLast Operatoren niemals kommutativ, da beide das Ende der Liste beeinflussen.
In der Endphase entscheidet der Client ob er den User über die Änderungskonflikte informiert und die Änderungen zurücksetzt (RollBack) oder umsetzt (Optimistic Concurrency Control oder Operational Transformation. In manchen Fällen ist Verwerfen oder Umsetzen der Änderungen ein kostspieliger Vorgang und kleine Ungereimtheiten werden akzeptiert. Allerdings ist es wichtig, dass jeder Client das gleiche tut.

Rationale

Der Änderungsverlauf ermöglicht jedem Client herauszufinden, ob sich konfligierende Änderungen auf das gleiche Artefakt beziehen.

Check

Beim Anwenden diese Pattern, sollten folgende Fragen beantwortet werden:

  • Wie werden die Änderungen auf Kommutativität getestet? Verwenden Sie die logische Uhr (Lamport, 1978)?
  • Sollen die Änderungen rückgängig gemacht oder umgesetzt werden? Wie wollen Sie es umsetzten?

Danger Spots

Der Prozess des Zurücksetzens und Umsetzten ist oft kompliziert. Man muss sicher gehen, das all diese Änderungen von dem Änderungsverlauf gelöscht werden und von allen Clients verwendet wird. Um festzustellen um welche Änderungen es sich handelt, kann ein Client Änderungsinformationen hinzufügen. Um so aktueller die Liste der verwendet Änderungen ist, desto weniger steht im Änderungsverlauf. Dies führt zu einer kürzeren Abwicklungszeiten für das Aufspüren von Konflikten und zu weniger Konflikten. Durch das Regeln des Änderungsverlaufes kann ein großer Engpass im System entstehen, wenn die Anzahl der Clients zu hoch ist. Man sollte sicherstellen, dass keine zusätzlichen Änderungen an dem Objekt angewendet wurde bevor dem Annullieren oder Umsetzten eines Änderungskonflikts. Andererseits führt die Operation zu einem inkonsistenter Zustand.

Known Uses

COAST

Erkennt Änderungskonflikte als Vermittler (Mediator) und als Client. Der Vermittler (Mediated Updates erkennt einen Änderungskonflikt, wenn ein Client eine Änderung an einer Datei vornimmt, die in dieser Zeit bereits von einem anderen Client geändert wurde. In diesem Fall ignoriert der Vermittler Änderungen an der veralteten Datei, sodass der andere Client nicht über den Änderungskonflikt informiert wird. Der Client der die veraltete Datei bearbeitet hat bekommt eine Information, dass die Änderung an einer veralteten Datei vorgenommen wurde. Daher muss der Client all seine Änderungen an der lokalen Datei auf den letzten gültigen Stand zurücksetzen.
Da jeder Client nur Änderungen seiner lokalen Anwendung und gültige Änderungen vom Vermittler aufspüren muss, muss das Zustandsmanagement nur zwei Beteiligte beachten. Dies macht es leicht und schnell.

Related Patterns

Lovely Bags

Kann verwendet werden um die Wahrscheinlichkeit einer konfligierenden Änderung einzuschränken, durch Modellierung der Daten auf eine weiße, die geeignet ist um gleichzeitig Änderungen vorzunehmen.

Operational Transormation

Beschreibt wie widersprüchliche Änderungen bei allen Mitwirkenden umgewandelt werden können, damit der geteilte Zustand bei allen Beteiligen gleich ist.

Optimistic Concurrency Control

Beschreibt wie Änderungen die im Konflikt mit einander stehen zurücksetzt werden können.

Recoverable Distributor (Islam and Davarakonda, 1996)

Kombiniert Conflict Detection mit Mediated Updates. Eine Diskussion darüber wie Recoverable Disrubitor sich auf Conflict Detection bezieht ist im im Kapitel Mediated Upates vorgesehen

. Change Indicator

Verringert das Risiko auf konfligierende Änderungen durch das sofortige sichtbar machen der Benutzer-Änderung.

Realisierung auf der eStudy-Plattform

Nein, es wurde bisher nicht realisiert.

Operational Transformation

U13156

Intent

Werden entfernte Änderungen ausgeführt müssen diese umgewandelt werden, um lokalen Änderungen berücksichtigen zu können. Damit beide in einem konsistenten Zustand sind.

Context

Clients ändern gleichzeitig etwas an Replicated Objects

Problem

Die Anzahl an konfligierenden Änderungen ist gestiegen, da viele Benutzer Änderungen an einer Kopie des Dokuments vornehmen. Es dauert zu lange, irritiert den User und macht die Applikation untauglich, wenn die Änderungen die miteinander im Konflikt stehen aussortiert oder zurückgesetzt werden müssen.

Scenario

Paul und Charley treffen sich in einer Collaborative um an einem Verschlüsselungs-Algorithmus zu arbeiten. Sie nutzen einen synchronisierenden Texteditor, der es Ihnen ermöglicht zur gleichen Zeit an dem Quelltext zu arbeiten. So können Sie die Änderungen des Partner sehen. Wollen Paul und Charley parallel daran arbeiten, wird das meiste Ihrer Änderungen nicht übernommen da es einen Konflikt bei gleichzeitigem Zugriff gibt.

Symptoms

Man sollte den Pattern implementieren wenn...

  • synchrones arbeiten zu vielen Konflikten führt und die Antwortzeit für die Applikation entscheidend ist.
  • Benutzer ihre Änderungen unregelmäßig veröffentlichen, wodurch die Wahrscheinlichkeit steigt, dass Konflikte auftreten.
  • Benutzer Konflikte nicht manuell beheben können.

Solution

Jede Seite kann Zugriffsänderungen die miteinander im Konflikt stehen umwandeln, sodass die transformierte Änderungen zu einem Status führt der konsistent zu dem Status aller anderen Seiten ist.

Dynamics

Die Unterschiedliche Clients eines Groupware-Systems arbeiten an einem gemeinsamen Objekt, wie im Pattern Distributed Command beschrieben: werden Kopien des Shared Objekts vom Client zwischengespeichert (Replicated Objects). Wenn ein Benutzer ein Befehl ausführt, wird dieser sofort auf die lokale Kopie angewendet. Danach wird es zu den anderen Clients gesendet. Dies geschieht entweder über Mediated Updteas oder Decentralized Updates. Diese Änderung wird von den anderen Clients auf ihre Kopie des Objekts angewendet. Die Strategie wird durch die folgenden zwei Prozesse erweitert, um Konsistenz zu berreichen:
1. Jeder Client verfolgt einen Änderungsverlaufs-Vektor für jedes geteilte Objekt. Dieser Vektor enthält alle Objektbefehle die auf die geteilten Objekte angewendet wurden. Dieser Änderungsverlauf-Vektor verteilt die neue erstellen Befehle. Dies erlaubt Remote Clients den Status von ihrer lokalen Kopie mit der Kopie der initiierten Clients zu vergleichen.
2. Bevor ein Distributed Command auf einer Seite ausgeführt wird, ist die "execution histroy" der empfangenden Befehle mit dem Änderungsverlauf der Lokalen Kopie zu vergleichen. Es können drei unterschiedliche Fälle auftretten:

  • Passt der Änderungsverlauf, wird der Distributed Command ausgeführt und von anderen Seiten zu dem Änderungsverlauf hinzugefügt.
  • Falls der Änderungsverlauf der Distributed Command zusätzliche Befehle enthält, wird der Befehl zwischengespeichert bis der fehlende Befehl ausgeführt werden kann.
  • Falls der lokale Änderungsverlauf zusätzliche Befehle enthält, wird der Distributed Command umgesetzt bevor der fehlende Befehl bereitgestellt werden kann.

Wie es umgesetzt wird, hängt im hohen Maße von dem Befehl und der Datenmodellierungsstruktur ab. Eine beliebte Strategie ist für jede Modellklasse eine Matrix zu erstellen, die für jeden möglichen Befehl einen passenden übereinstimmenden Befehl enthält. Jeder spezielle Eintrag enthält einen transformierten Befehl. Zum Beispiel, für die Befehle c_i, c_j mit i > j, definieren die Matrix die Transformation T(c_i,c_j) = c'_i diese angewendet auf c_i verhält sich als ob c_j vorher angewendet worden ist.

Diese Transformation muss korrekt sein:

1. c_i ◦T(c_j , c_i ) ist das gleiche wie c_j ◦T(c_i , c_j ), wohin c_i ◦c_j meint, dass der Befehl c_i wird nach c_j ausgeführt.
2. T(c_k , c_i ◦T(c_j , c_i )) ist da gleiche T(c_k , c_j ◦T(c_i , c_j )) mit i < j < k (cf. (Sun and Ellis, 1998b)).

Der erste Zustand beschreibt, dass eine unterschiedliche Reihenfolge der Programmbefehle zu dem gleichen Ergebnis führt. Der zweite Zustand beschreibt, dass die Reihenfolge der Transformationen nicht das Endergebnis beeinflusst.
Als Beispiel könnte man eine geteilte Textdatei betrachten. Diese enthält eine Liste mit geordneten Zeichen. Mögliche Befehle für diese Textdatei sind insert und delete. Imine (2003) erarbeitet und definierte anhand dieses Beispiels das folgende Interface für geteilte Objekte:

String insert (Number position, Number initialPosition, Character c);

String delete (Number position);

Die erste Methode fügt ein Zeichen c an eine bestehende Position ein. Der Parameter initialPosition dient dazu sich die Anfangsposition des Zeichen zu merken, nachdem der Befehl transformiert wurde. Der delete Befehl entfernt die Zeichen an der bestehenden Position. Diese beiden Befehle können nun in einer 2 x 2 Matrix angeordnet werden, sodass übereinstimmende Transformationsfunktion erfunden werden können:

insert (p1, ip1 , c1) delete(p1)
insert (p2, ip2 , c2) tInsIns (p1, ip1 , c1 , p2, ip2 , c2) tDelIns(p1, p2, ip2 , c2)
delete(p2) tInsDel (( p1, ip1 , c1 , p2) tDelDel((p1, p2)

Die Transformationsfunktion sieht dann laut Imine (2003) wie folgt aus:

String tInsIns  (Number p_1,Number ip_1,Character c_1,Number p_2,
                Number ip_2, Character c_2)
{
// insert the character based on the difference in the insertion index
    if (p_1 < p_2)
        return insert(p_1,ip_1,c_1);
    if (p_1 > p_2)
        return insert(p_1+1,ip_1,c_1);
// same position (p 1 == p 2)
// try to detect differences in the initial index
    if (ip_1 < ip_2)
        return insert(p_1,ip_1,c_1)
    if (ip_1 > ip_2)
        return insert(p_1+1,ip_1,c_1);
// also same initial position (ip 1 == ip 2)
// create an order that is consistent between sites
    if code(c_1) < code(c_2))
        return insert(p_1,ip_1,c_1);
    if code(c_1) > code(c_2))
        return insert(p_1+1,ip_1,c_1);
// also same character
    return id();
}

String tInsDel(Number p_1, Number ip_1, Character c_1, Number p_2)
{
    if (p_1 > p_2)
        return insert(p_1-1,ip_1,c_1);
    else
        return insert(p_1,ip_1,c_1);
}

String tDelDel(Number p_1, Number p_2)
{
    if (p_1 < p_2)
        return delete(p_1);
    if (p_1 > p_2)
        return delete(p_1-1);
    else
        return id();
}

String tDelIns(Number p_1, Number p_2, Number ip_2, Character c_2)
{
    if (p_1 < p_2)
        return delete(p_1);
    else
        return delete(p_1+1);
}

Rationale

Ist dieses Entwurfsmuster implementiert, können alle Änderungen direkt angewendet werden. Somit kann die Groupware Applikation schnell auf Benutzereingaben reagieren. Sollten Konflikte auftreten, werden diese automatisch behoben. Damit die Benutzer einen konsistenten Zustand haben.

Check

Bei einer Implementierung des Entwurfsmusters, sollten Sie folgende Fragen beantworten: - Was sind Ihre konfligierende Befehle? Was sind die übereinstimmenden Transformationsfunktionen? - Wie wollen Sie lokale ausführende Befehle beobachten? Wollen Sie diese Befehle für jedes geteilte Objekt abspeichern oder ziehen Sie einen globalen Zustand in Erwägung.

Danger Spots

Der schwierigste Teil an diesem Entwurfsmusters ist das Entwickeln eines korrekten Set von Transformationsfunktionen. Untersuchungen haben ergeben, dass selbst für einfache Datentypen wie Zeichenketten der Prozess des Erstellen und Testen von Transformationsfunktionen sehr fehleranfällig ist (Imine, 2003). Daher ist dieses Entwurfsmuster nicht für alle Datentypen geeignet: Transformationen sollen nur verwendet werden, wenn alle anderen bei gleichzeitigem Zugriff einen Fehler erzeugen.
Der Änderungsverlauf kann sehr groß werden. Eine Seite kann überprüfen ob alle anderen einen bestimmten Befehl c_i ausführen. Dies ist der Fall, wenn eine Seite die Befehlshistory für ein neuen Befehl c_j(j >i) empfängt, das auch c_i enthält. Ist dies der Fall, kann man sicher gehen, dass keine zukünftigen Befehle mit c_i im Konflikt stehen und c_i kann von der Befehlshistroy entfernt werden. Auf die gleiche Art, kann man den Handlungsspielraum des Änderungsverlaufes erweitern. Anstatt für jedes geteilte Objekt, kann man auch einen globalen Änderungsverlauf verwenden. Dies führt, in Kombination mit der automatischen Verringerung der Länger des Änderungsverlaufs zu einem kleinen Änderungsverlauf für Groupware Anwendungen.
Schlussendlich und am wichtigste ist, dass Benutzer gegebenenfalls von transformierenden Befehlen gestört werden. Ein Beispiel dafür ist das Verwenden von transformierten Befehlen in einer geteilten Textdatei. Das verwenden von Operational Transformation sichert, dass die Benutzer zur gleichen Zeit an einem Wort arbeiten und trotzdem den gleichen konsistenten Status erreichen. Die Semantik dieses Ergebnisses, wird womöglich nicht Ihre Absichten widerspiegeln. Z.B.: Charley und Susan verwenden einen Editor der auf perational transformations basiert. Susan möchte eine Variable umbenennen die anfangs von count auf pagecount umbenannt wurde. Zur gleichen Zeit, möchte charley den Namen auf documentcount ändern. Susan beginnt zu tippen "pa" und Charly tippt "do". Das Ergebnis ist eine Vierschachtelung beider Änderungen, zum Beispiel: dpacount. Operational transformation sichert, dass Susan und Carly dpacount sehen. Allerdings ist das Ergebnis bedeutungslos und der Konflikt muss bei einem Gespräch zwischen Susan und Carley gelöst werden.

Known Uses

LibreSource (Molli, 2003)

entwickelt ein Shared File Repository und organisiert die unterschiedlichen Versionen der enthaltenen Datei. Abhängig von dem Typ der Datei, werden unterschiedliche Transformationsfunktionen verwendet um gleiche Befehle zu transformieren und auflösen von vermischten Konflikten.
Der zugrunde liegende Algorithmus (S06 genannt) basiert auf dem Algorithmus der im Dynamics Absatzes diese Pattern beschrieben wurde. Anstatt es auf Zeichenketten anzuwenden kann es auf Dateioperationen angewendet werden, einfügen von Zeilen und entfernen von Textdateien oder Baumelemente in einem XML Dokuemnt. In Textdateien überprüft der Algorithmus ob in einer überlappenden Zeile etwas eingefügt oder entfernt wurde.


GROOVE (Ellis and Gibbs, 1989)

ist das früheste Beispiel für eine Anwendung von Operational Transformations. Es war ein tructured synchronous Texteditor, der von einer einfachen Transformationsfunktionen gebraucht macht: dOPT (distributed Operational Transformation). Obwohl sich herausstellte das die Transformationsfunktionen nicht korrekt war (Cormack, 1995a,b). Die Basis Struktur des handling remote commands wurde in späteren Implementierungen nicht geändert. Sun and Ellis (1998b) sammelten und diskutieren andere Beispiele von Texteditoren die von Operational Transformation Gebrauch machen.

Related Patterns

Lovely Bags

ist eine andere Möglichkeit um Nebenhäufigkeiten zu erhöhen.

Conflict Detection

behandelt wie Konflikt behaftete Aktivitäten gefunden werden können.

Change Log (Anderson, 2000)

speichert unterschiedliche Stadien eines Objektes oder Objektattributs mit zusätzlichen Information über die Ungleichmäßigkeit der Änderung. Es ist Kompatibel zum Änderungsverlaufes die für Operational Transformation erforderlich ist.

Realisierung auf der eStudy-Plattform

Nein, es wurde bisher nicht realisiert.

Lovely Bags

Julian Faupel

Intent

Man sollte Bags nutzen um Objekte in einem Container zu speichern. Sie liefern die beste Möglichkeit für Nebenläufigkeiten.

Context

Man nutzt mit Conflict Detection(5.3.3) einen Mechanismus um Konflikte zu entdecken. Nun sollte man darüber nachdenken wie man die Anzahl der konfligierenden Änderungen verringern kann.

Problem

Mehrere Operationen greifen auf einen gemeinsamen Container zu und ändern den Content des Containers indem sie Elemente hinzufügen oder entfernen. In Bezug auf Nebenläufigkeit sind die meisten Operationen ziemlich schlecht. Dies führt oft dazu das es so aussieht als sei die synchrone Zusammenarbeit in Containerobjekten unmöglich.

Scenario

Als Beispiel kann man sich ein Chatprogramm vorstellen über das kommuniziert werden soll. Das Chatprogramm wurde mittels replizierbaren Objekten implementiert. Der Chat gibt oft Meldungen aus das konfligierende Änderungen vorliegen und weisst Zugriffe zurück. Das Problem das vorliegt ist das jeder Beitrag im Chat in dem gemeinsamen Objekt abgebildet wird. Dort wird der Beitrag jeweils an einen langen String angehangen. Für die Nebenläufigkeit ist dies ein Problem, da das anfügen das gemeinsame Objekt verändert. Dies führt zu unterschiedlichen Strings je nachdem in welcher Reihenfolge das Hinzufügen durchgeführt wird.

Symptoms

Zugriffe auf das Containerobjekt werden oft zurückgewiesen, weil zwei konfligierende Änderungen nicht in unterschiedlicher Reihenfolge ablaufen können.

Solution

Modelliere das Container-Objekt als Bag, sofern ein hoher Grad an Nebenläufigkeit benötigt wird. Sofern eine Ordnung der Elemente nötig ist, versuche diese anhand eines Ordnungskriteriums innerhalb der einzelnen Objekte lokal wiederherzustellen, aber nutze für das gemeinsam genutzte Datenobjekt nach wie vor ein Bag.

Dynamics

Der wichtigste Beiteiligte ist der Bag. Der Bag ist ein gemeinsam genutztes Container Objekt das Referenzen auf andere Objekte enthält. Der Bag erlaubt Duplikate und es ist egal in welcher Reihenfolge die Elemente im Bag vorhanden sind. Aus mathematischer Sicht werden die Bags oft als Multisets betrachtet. Nutzer bearbeiten Operationen des Bags gleichzeitig. In den meisten Fällen sind diese Operationen, wegen ihrer unabhängigen Reihenfolge und den erlaubten Duplikaten, kommutativ. In den Fällen in denen der Bag nur wächst, muss man nicht mehr auf Konsistenz prüfen, solange nur Operationen genutzt werden die kommutativ sind. In den Fällen in denen auch Elemente aus dem Bag gelöscht werden muss man sicherstellen das die Nutzer Mechanismen zur Conflict Detection(5.3.3) nutzen. Wenn zum iterieren über die lokale Collection eine Reihenfolge notwenig ist, muss die Collection vor dem iterieren geordnet werden. Diese Vertauschung setzt vorraus das die benötigten Elemente ein oder mehrere Atrribute liefern die als Sortierkrieterien genutzt werden können.

Rationale

Die einfache Erklärung warum dieses Pattern funktioniert liegt in dem "lovely" des Bags:

Ein Bag interessiert sich nicht für die Reihenfolge und ordnet Elemente genau so an wie es auch andere Container tun. Im Gegensatz zu geordneten Containerobjekten wo die Einfügeoperation an eine bestimmte Einfügeposition gebunden ist, wie Arrays oder Listen, produzieren Bags das gleiche Resultat wenn die Elemente in zwei verschiedenen Reihenfolgen hinzugefügt werden.

Im Gegensatz zu Containerobjekten wo die Einfügeoperation auf einer bestimmten Position des hinzugefügten Objektes basiert, wie Sets oder Dictionaries, produzieren Bags das selbe Resultat wenn das Element bereits im Bag vorhanden ist und zwei Clients gleichzeitig eine Einfüge und Löschoperation ausführen.

Concurrent accesses bags.png

[1]

Dies illustriert die obige Abbildung. Auf der linken Seite arbeiten zwei Nutzer gleichzeitig an einer Liste. Eine Liste hat einen Ausgangswert von abc. Dann fügt "User1" ein "d" hinzu während "User2" ein "e" hinzufügt. Nachdem beide Nutzer die Operation ausgeführt haben, führen sie Decentralized Updates(5.2.6) durch. Aber wenn sich der Status von "User1" von dem Status von "User2" unterschiedet, nach dem sie die Updates ausgeführt haben, muss eine Operation rückgängig gemacht werden.

Nun betrachten wir die rechte Seite der Abbildung. Wieder führen die User die Änderungen durch und führen Decentralized Updates(5.2.6) durch. Aber jetzt können die Einfügeoperationen ausgeführt werden, solange das Hinzufügen nicht von dem Objektstatus oder der (nicht vorhandenen) Reihenfolge der Element abhängt. Nun erreichen beide User einen konsistenten Status nach der Akutalisierung.

In fällen in denen eine Reihenfolge notwendig ist, ist es oft möglich die Reihenfolge wiederherzustellen. Schauen wir uns eine sortierte Collection an: Dieser Klassentyp stellt sicher das die Elemente nach ihrer Sortierreihenfolge gespeichert werden(oder das über sie nach der Sortierreihenfolge iteriert wird). Der Hauptgrund eine sortierte Datenstruktur zu benutzen ist der Performancegewinn beim iterieren über die Elemente in der Reihenfolge. Wenn man über einen Bag in einer Reihenfolge iterieren will, muss man ihn vorher lokal in eine sortierte Collection konvertieren, und anschließen über die lokale Kopie iterieren. Die Reihenfolge, welche die Möglichkeiten von gleichzeitigen Operationen drastisch reduziert, ist also lokal wiederhergestellt worden wo sie gebraucht wird. Dies macht den Zugriff zu der geordnetetn Collection langsamer, und setzt voraus das jeder Client die Elemente sortiert, aber es macht die Datenstruktur auch robuster für gleichzeitige Manipulationen.

Ein anderer Grund Objekte in einer geordneten Collection zu speichern, ist die Notwendigkeit es über einen Index ansprechen zu wollen. Dies wird oft genutzt um die Iteration zu beschleunigen. Zum Beispiel in dem man einen Zähler benutzt für den Index, während man über ein Array in Java iteriert. Mit einem geordneten Zugriff, ist die Iterationsgeschwindigkeit weniger kritisch als das geringere Maß an Nebenläufigkeit. Wenn das Containerobjekt regelmäßig iteriert werden muss, kann man die Iteration auf lokalen Kopien des duplizierten Objektes durchführen, welches solange gültig ist bis das duplizierte Objekt geändert wird.

Check

Um dieses Pattern zu Nutzen sollte man vorher diese 3 Fragen beantworten:

  • Liefern die Objekte eine natürliche Reihenfolge? Wenn ja, welche Attribute könnte man für die Reihenfolge nutzen? Wenn nicht, könnte man ein Attribut hinzufügen das eine natürlich Reihenfolge ermöglicht? Beispiel: Kombination aus Client ID und Zeitsptempel der Erstellung.
  • Wofür braucht man die Reihenfolge? Kann man sie ignorieren?
  • Ist es möglich die Objekte direkt zu sortieren, oder braucht man einen Cache in welchem der Bag geordnet und aktualisiert wird wenn ein Element geändert wird?

Danger Spots

Ein Lovely Bag ist gefährdet bei Löschoperationen. Falls ein Element zur selben Zeit gelöscht und hinzugefügt wird und der Bag das Element nicht zuerst hinzugefügt hat, erhält man einen falschen Status im Bag anhand der falschen Anordnung der Operationen. Eine Möglichkeit dies zu verhindern, ist Löschoperationen zu unterbinden.

In manchen Bereichen können Arrays die bessere Wahl sein: Wenn die Anzahl der Elemente sich nicht oft ändert und ein Eintrag im Array über seinen Index angesprochen wird ohne das er eine Beziehung zu den anderen Elmenten hat, ist dies konkurrierend zu allen Änderungen an anderen Arraypositionen. Wenn das Array seine größe ändern soll, oder einen geteilten Index als aktuellen Index hat, könnten diese Attribute die Möglichkeit gleichzeitigen Änderungen auf das Array verringern.

Lange Sets zu sortieren kann viel Zeit in Anspruch nehmen. In Fällen in denen Einfügeoperationen zu lokalen Daten hinzugefügt werden müssen, kann man eine gecachete sortierte Abbildung verwenden und neue Elemente über eine sortierte Einfügeoperation hinzufügen.

Wenn mehrere Nutzer ein gemeinsames Objekt verändern besteht eine Chance auf Konflikte wenn der Versionenbaum upgedatet wird. Um dies zu umgehen sollte man Lovely Bags für die Knoten des Versionenbaums nutzen.

Known Uses

  • Chat in FUB
FUB (Haake und Schümmer, 2003) ist ein System das auf COAST basiert und welches Brainstorming in einer gemeinsamen Lernumgebung unterstützt. Seine Nutzer bekommen zwei unterschiedliche Arten von Chats: ein Brainstormingchat und einen Diskussionschat in dem Konzepte besprochen werden. Während der Brainstormingchat keine Reihenfolge benötigt und somit direkt die Modellierung mit einem Bag unterstützt, braucht der Diskussionschat eine genau festgelegte Reihenfolge in der die Chateinträge angezeigt werden. Der Diskussionschat ist deshalb als Set von Chateinträgen modelliert. Jeder Eintrag hat einen Zeitstempel welcher die synchronisierte Zeit repräsentiert in der der Eintrag vom jeweiligen Nutzer hinzugefügt wurde. Für die Ansicht des Chatlogs werden alle Einträge primär nach dem Zeitstempel und sekundär nach dem Nachrichtentext sortiert. Dies stellt sicher das alle Nachrichten bei jedem Nutzer in der selben Reihenfolge angezeigt werden.
  • Anordnung der Nachrichten im Usenet
Usenet Newsgroups repräsentieren Bäume von Nachrichten welche die Abhängigkeit zwischen den Nachrichten darstellen. Jeder Eintrag hat eine einzigartige ID. Der Eintrag kann einem Vaterelement zugeordnet werden ohne das dies geändert werden muss oder etwas von einem Kindelement weiss. Alle Einträge sind in einer unspezifischen Collection vom Server gespeichert. Der wichtige Punkt ist dass, das Protokoll keine Reihenfolge für die Einträge braucht. Wenn eine chronologisch sortierte Reihenfolge der Nachrichten angefordert wird, kann eine Liste anhand der Zeitstempel der Nachrichten generiert werden.

Related Patterns

Wenn das Programm einen geordneten Bag benötigt, muss ein Overhead zum Programm hinzugefügt werden, weil das sortieren Zeit kostet. Dies verlangsamt die Reaktionszeit des Programms. Wenn das Sortieren mehr Zeit verbraucht als den Lock zu bekommen, wie es im Pattern Pessimistic Locking beschrieben wird, dann sollte man lieber Sperrmechanismen einsetzen.
Bei der Nutzung von Lovely Bags kann Inkosistenz entstehen. Das Pattern Conflict Detection(5.3.3) erlaubt es die Inkonsistenz zu erkennen.
Beschreibt einen anderen Ansatz um den Anstieg von gleichzeitigen Änderungen gering zu halten.

Realisierung auf der eStudy-Plattform

Wird zur Zeit noch nicht genutzt im eStudy.

Immutable Versions

Julian Faupel

Intent

Speichere unterschiedliche Versionen eines gemeinsam genutzten Objektes wie einen Versionenbaum.

Context

Nutzer arbeiten an gemeinsam genutzen Objekten.

Problem

Die Ausführung einer komplexen Änderung auf einem geteilten Objekt braucht meistens Zeit und benötigt kognitiven Aufwand auf Seiten des Nutzers. Wenn Nutzer auf dem gemeinsam geteilten Objekt agieren, steigt die Möglichkeit von konfligierenden Änderungen. Eine der beiden gleichzeitigen Änderungen zu verwerfen ist unangemessen, wenn sein Verursacher großen Aufwand in die Erstellung der Änderung investiert hat.

Scenario

Charley und Susan haben ein freies Wochenende und wollen beide die Verschlüsselungsumgebung der Game Engine sicherer machen. Susan hat die Idee eine elliptic curve Krypthografie zu benutzen. Sie ändert ein Set von zehn Klassen checkt ihre Klassen am Montag als sie ins Büro kommt ein. Charly hatte vor ein ElGamal Verschlüsselungsschema auf Basis eines diskreten Algorithmus zu verwenden. Er ändert sieben Klassen und wollte sie Montag Mittag commiten. Leider gab es Konflikte bei drei Klassen, aber da Charley sich nicht um die elliptic curves kümmert, ignorierte er Susans Änderungen und commted seine Klassen. Die Komplette Version war kaputt, während Teile von Susans Code weiterhin im System waren.

Symptoms

Man sollte das Pattern benutzen wenn:

  • Nutzer auf gemeinsam genutzte Objekte gleichzeitig zugreifen.
  • Nutzer ändern lokale Kopien von gemeinsam genutzten Objekten.
  • Nutzer überschreiben die Änderungen von anderen.
  • Nutzer an der Historie von gemeinsam genutzten Objekten interessiert sind.

Solution

Alle gemeinsam genutzten Objekte in einem Versionenbaum speichern. Man muss dafür sorgen das die einzelnen Versionen der Versionenbäume im nachhinein unveränderbar sind. Alle Änderungen an dem gemeinsam genutzen Objekt müssen als Versionen gespeichert werden. Der Nutzer muss gefragt werden ob parralele Versionen im Versionenbaum hinzugefügt werden sollen, außer der Nutzer sagt explizit das ein neuer Ast angelegt werden soll.

Dynamics

Alle Versionen von gemeinsamen Objekten werden in einem Versionenbaum gespeichert. Der Versionenbaum erlaubt es sowohl die aktuelle Version, also auch eine spezifische Version, des Objektes anzusprechen. Jedesmal wenn eine neue Version erstellt wird, wird ein neuer Knoten zum Versionenbaum hinzugefügt. Dieses wird als Kindelement der vorherigen Version angefügt.

Die Knoten des Versionenbaums können ausserdem eine Kopie des gemeinsamen Objektes in seiner jeweiligen Version enthalten. Sie können ausserdem die Änderungen die mit der jeweiligen Version zusammen hängen und die Unterschiede der jeweiligen Version zur Vorgängerversion enthalten. In allen Fällen ist es wichtig zu entscheiden wann eine neue Version erstellt werden sollte. Dies kann vom System automatisch gemacht werden wenn eine Änderung durchgeführt wurde, oder nur dann wenn ein Nutzer explizit eine Änderung commited.

Version tree.png

[2]

Die obige Abbildung zeigt eine typische Entwicklung eines Versionenbaums für gemeinsame Objekte. Unter Punkt (a) ändert ein Nutzer die Version V1 des gemeinsamen Objektes, welche in Version V2 mündet. In Abschnitt (b) wird die Version V3 erstellt und in Abschnitt (c) erstellt ein anderer Nutzer Version V4. Version V3 und V4 haben mit der Version V2 den gleichen Vorgänger. Dies deutet darauf hin das zwei Nutzer eine neue Version mit dem Ausgangspunkt Version 2 erstellt haben. Also sind V3 und V4 parallele Versionen. Unter Abschnitt (d) wird eine weitere parallele Version V5 erstellt.

In Abschnitt (d) haben nun V3, V4 und V5 mit V2 die selbe Vorgängerversion. Diese Versionen existieren Parallel. Je nach Kollaborationsprozess gibt es verschieden Wegen diese parallelen Version zu handhaben:

  • Wenn es nicht notwendig ist eine explizite aktuelle Version zu haben, kann man die verschiedenen Versionen parallel beibehalten.
  • Wenn es wichtig ist eine einzige aktuelle Version zu haben, müssen die parallelen Versionen zusammengeführt werden. Dies kann zum einen getan werden indem man die Nutzer auffordert die Versionen manuell zusammen zu fügen oder man verwendet Operational Transformation.

Rationale

Wenn alle Versionen von gemeinsamen Objekten im Versionenbaum gespeichert sind, können die Nutzer ihre lokalen Kopien des gemeinsamen Objektes gleichzeitig ändern ohne die Änderungen der anderen Nutzer zu überschreiben. Darüber hinaus erlaubt ein Versionenbaum die aktuelle Version des gemeinsamen Objektes abzurufen, genau so wie eine bestimmte Version des Objekts es ihm erlaubt die Historie des gemeinsamen Objektes nachzuverfolgen.

Check

Wenn man sich für dieses Pattern entscheidet sollte man vorher folgende Fragen beantworten:

  • Soll der Versionenbaum als Centralized Object oder als Replicated Object verwaltet werden?
  • Will man die Änderungen der neuen Version, die Unterschiede zwischen zwei Versionen oder die Versionen selbst speichern?
  • Wann erstellt man eine neue Version? Immer wenn Nutzer lokale Abbildungen ändern oder nur wenn explizit eine neue Version angelegt werden soll?
  • Soll ein User Interface bereit gestellt werden, in dem die Nutzer die verschiedenen Versionen auswählen und anschauen können?

Danger Spots

Abhängig von der Größe des gemeinsamen Objekts, kann es viel Speicherplatz belegen alle unterschiedlichen Versionen des Objektes zu speichern. Wenn der Speicherplatz knapp ist sollte man nur die Änderungen die von einer Version zur nächsten Version gemacht wurden, oder die Unterschiede der jeweiligen Versionen speichern.

Das Zusammenführen von verschiedenen Versionen kann schwierig und zeitintensiv sein. Wenn die Nutzer oft Versionen zusammenfügen müssen, sollte man Werkzeuge bereitstellen die das Zusammenfügen unterstützen. Zum Beispiel in dem man die Unterschiede der beiden Version hervorhebt.

Verschieden Versionen eines Objektes in einem Baum zu speichern erhöht die Zugriffszeit. Wenn die Änderungen zwischen den Versionen anstatt die Version selbst gespeichert werden, steigt die Zugriffszeit noch weiter.

Known Uses

  • Concurrent Versions System (CVS)
ist ein Versionen Kontrollsystem das alle Änderungen in einer Umgebung speichert. Üblicherweise wird es bei der Implementation von Softwareprojekten genutzt und erlaubt es mehreren Benutzer gleichzeitig zusammen zu arbeiten. Die Dateien werden auf speziellen Servern gespeichert die es erlauben neue Versionen von einer Datei zu commiten. Außerdem kann man die aktuelle oder eine bestimmte Version einer Datei erhalten oder einen neuen Versionszweig einer Datei erstellen. Zur Realisierung speichert der Server alle Änderungen die von einer Version zur anderen gemacht werden.
  • CURE
eine webbasierte kollaborative Lernplattform (Haake et al. 2004c) die es Nutzern erlaubt Wikiseiten und Dokumente zu tauschen und zu editiren. CURE und seine Erweiterung offlineCURE (Lukosch et ak., 2006) nutzen Immutable Versions um die verschiedenen Versionen der Artefakte zu speichern. Bei konfligierenden Versionen fordert CURE die Nutzer auf die Koflikte manuell selbst zu lösen.
  • GINA
ist ein Framework das die Groupwareentwicklung (Berlage and Genau, 1993) untestützt und ermöglicht synchrone Kollaboration in dem es replizierbare Objekte nutzt. GINA versteht die Geschichte der replizierbaren Objekte als einen Operationsbaum. Diese Bäume speichern die Operationen die nötig sind um von einer Version zur nächsten zu kommen. GINA benutzt den Baum für Rückgängig und Wiederherstellungs Mechanismen, optimistische Nebenläufigkeitskontrolle, um verschiedene Objektversionen anzusprechen und um Objekte zusammenzufügen.

Related Patterns

erlaubt gleichzeitige Änderung der Knoten wenn sie für die Implementation des Versionenbaums genutzt werden.
kann mittels Immutable Versions implementiert werden um gleichzeitige Änderungen zu erlauben.
erlaubt gemeinsame Objekte optimistisch zu ändern und setzt konfligierende Änderungen zurück anstatt alle Versionen des gemeinsamen Objektes zu speichern.
  • Private Versioning(Coplien and Harrison 2004)
hebt heraus das Nutzer Versionen von geänderten Artefakten privat lassen sollen bis die Qualität des Artefakts einen Status erreicht hat der dem Qualitätsstandard der Gruppe entspricht.
  • Edition(Anderson, 2000)
spricht ein vergleichbares Problem an das besagt, das jede Änderung an einem Objekt das in eine neue Version resultiert, Edition genannt werden sollte. Die Edition nimmt zusätzlich das Objekt oder die Aktivität die aus der Änderung des Objekts entstanden ist auf.

Realisierung auf der eStudy-Plattform

Wird zur Zeit noch nicht genutzt im eStudy.

Einzelnachweise

  1. Till Schummer, Stephan Lukosch: Patterns for Computer-Mediated Interaction, 2007. Wiley, ISBN 978-0470025611. S. 492
  2. Till Schummer, Stephan Lukosch: Patterns for Computer-Mediated Interaction, 2007. Wiley, ISBN 978-0470025611. S. 496