Joint Editing / Application Sharing Dr. Wolfgang Prinz GMD-FIT

Übersicht Grundkonzept Architekturen Konsistenzsicherung asynchrones gemeinsames Editieren

Begriffe Joint Editing: zwei oder mehrere Benutzer bearbeiten gemeinsam ein Dokument - synchron oder asynchron. Application Sharing ermöglicht zwei oder mehreren Benutzern die synchrone Benutzung einer beliebigen Anwendung. Session: eine Periode der synchronen Interaktion unterstützt durch ein Groupware System

Anwendungsszenarien Face-to-face Sitzungen verteilte Sitzungen ... verteilte Sitzungen gemischte Sitzungen: face-to-face und verteilt

Besonderheiten Konsistenzsicherung Antwortzeiten Eingabekoordination Awareness

Was wird gemeinsam genutzt? Telepointer Cursor Scrollbar

Eingabekontrolle - Spektrum single multiple Cursor Jeder darf alles Kontrolle über “Floor” Eingabekontrolle Aspekte: Freiheit <-> Kontrolle Konsistenzsicherung: explizit <-> implizit

Eingabekontrolle

Eingabekontrolle

Referenz Modelle Patterson’s Taxonomy “the primary challenge for synchronous groupware applications is to maintain shared state” (Patterson, 1995) 4 Zustandsebenen Display-Zustand: realisiert in der Video Hardware View-Zustand: logische, visuelle Representation der unterliegenden Daten Model-Zustand: die unterliegenden Daten File-Zustand: die persistente Repräsentation des Models

Single User Anwendung file model view display

Shared State file model view view display display

Synchronized State file file model model view view display display

Hybrider Ansatz file model view view display display

Verteilungsarchitekturen Interlace Framework (Phillips, 1999) physical input devices connected to an input process, which transforms input into logical interface events a chain of more update processes, which transform interface events into updates on state a chain of one or more view processes, which collectively compute an interactive view from the state elements a rendering process, which represents the view to the user on physical output devices

Interlace Architekturelemente Shared State (s) Consistence Maintenance Process (cm) Lautsprecher Monitor Rendering Process (r) Tastatur Maus Input Process (i) Update Process (u) View Process (v) Private state (p) Lautsprecher Monitor Rendering Process (r) Tastatur Maus Input Process (i) Update Process (u) View Process (v) Private state (p)

Zentralisierte Verteilungsarchitektur Anwendung residiert auf einem Server Displaydienste sind verteilt Kommunikation über Interface-level Events X-Window events Varianten Collaboration transparent Collaboration aware

Zentralisierte Verteilungsarchitektur Vorteile Einfachheit Unterstützung von Nachzüglern Nachteile hohes Kommunikationsaufkommen Anfällig bei unterschiedlicher Connectivity Scalability Beispiele: XTV, Netmeeting

Replizierte Verteilungsarchitektur Vollständige Replikation aller Komponenten Varianten collaboration transparent Synchronisation der Eingabe collaboration aware Synchronisation des Zustands relaxed WYSIWIS

Replizierte Verteilungsarchitektur Vorteile evt. geringerer Bandbreitenbedarf (Input vs. Output) verbesserte Antwortzeiten Nachteile Verfügbarkeit der Anwendung bei allen Teilnehmern Konsistenzproblematik Unterstützung von Nachzüglern was wird ausgetauscht? Beispiele: DreamTeam, GINA, COAST

Zentral koordinierte Verteilungsarchitektur ahnlich der vollständig replizierten Architektur jedoch mit zentraler Koordination Varianten collaboration transparent Synchronisation der Eingabe collaboration aware Synchronisation des Updates Synchronisation des Zustands?

Zentral koordinierte Verteilungsarchitektur Vorteile ähnlich der vollständig verteilten Arch. Zentraler Konsistenzalgorithmus vs. verteilter Nachteile zentrale Koordination als Flaschenhals für Performanz und Verfügbarkeit Beispiele: COAST, Habanero

Konsistenzsicherung optimistische Ansätze Responsivität The aim of concurreny control mechanisms is to allow for maximum concurrency while trying to restrict the system from becoming inconsistent or irrecoverable pessimistische Ansätze Vorhersagbarkeit Konsistenz

Designaspekte Locking Transaktionen Turn-Taking Protokolle zentralisierte Kontrolle Abhängigkeits-Erkennung Reversible Ausführung Operations-Transformation

Locking Sperrung von edititierten Bereichen Visuelle Anzeige des gesperrten Bereichs Probleme Overhead: Anforderung und Freigabe explizit implizit Granularität Lock-Typen Simple locks explizite Anforderung / Freigabe Tickle locks idle Zeit bestimmt Lockfreigabe Soft locks überschreibbare locks

Transaktionen Transaktionsablauf: Problem öffnen & sperren ändern commit & freigeben sichtbar für andere Problem verteilte Transaktionen sind schwierig zu implementieren Granularität: Absatz: langsame Antwortzeiten behindern die Interaktion Zeichen: schnelle Antwortzeiten aber teure Realisierung

Transaktionen und der philosophische Unterschied “philosophischer” Unterschied zwischen Datenbanken und Groupware Systemen Datenbank: multi-user System, das ein single- user System simuliert Groupware:multi-user System, das die anderen Benutzer sichtbar macht.

Turn-Taking Protokolle Floor Control mechanische FIFO priorisiert moderiert soziale Einsatzmöglichkeit abhängig von der Anwendung editing voting

Zentrale Kontrolle Zentraler Server empfängt und verteilt alle Benutzereingaben Vorteil: einfache zentrale Konsistenzsicherung Probleme: Ausfallproblematik Flaschenhals Antwortzeiten Eingabe -> Server -> Anzeige

Abhängigkeits-Erkennung sofortige lokale Ausführung von Eingaben Markierung der Eingaben per Zeitstempel erkannte Konflikte werden signalisiert und gekennzeichnet Konfliktauflösung ist Aufgabe der Benutzer Vorteil: schnelle Antwortzeiten wg. lokaler Ausführung Problem: Verlagerung der Konsistenzsicherung auf den Benutzer

Reversible Ausführung sofortige lokale Ausführung von Eingaben Markierung der Eingaben per Zeitstempel Eingaben werden gespeichert und bei einem Konflikt erfolgt eine automatische Konfliktauflösung Problem: Irritation des Benutzers durch nachträgliche automatische Textänderungen.

Operationstransformation sofortige lokale Ausführung von Eingaben Markierung der Eingaben per Zustandsvektor Verteilung der Eingabe an alle inkl. des eigenen und der anderen Zustandsvektoren Transformation der Eingabe abhängig vom lokalen und empfangenen Zustandsvektor.

Beispiel Site 0 Site 1 Site 2 O1 O2 O3 O4

Konsistenzmodell (Lamport, 1978) Definition: Causal ordering relation “->” Given two operations Oa and Ob, generated at sites i and j, then Oa -> Ob, iff: 1. i = j and the generation of Oa happened before the generation of Ob, or 2. i  j and the execution of Oa at site j happened before the generation of Ob, or 3. there exists an operation Ox, such that Oa -> Ox and Ox -> Ob.

Konsistenzmodell (Lamport, 1978) Definition: Dependent and independent operations Given any two operations Oa and Ob. 1. Ob is said to be dependent on Oa iff Oa -> Ob. 2. Oa and Ob are said to be independent ( or concurrent) iff neither Oa -> Ob, nor Ob -> Oa, which is expressed Oa || Ob.

Konsistenzmodell (Lamport, 1978) Definition: Intention of an operation Given an operation O, the intention of O is the execution effect which could be achieved by applying O on the document state from which O was generated. Intention kann nicht erreicht werden, wenn der Dokumentzustand zwischen Generierung und Ausführung geändert wird.

Konsistenzmodell (Lamport, 1978) Definition: A consistency model A cooperative editing system is said to be consistent if it always maintains the following properties: 1. Convergence: when all sites have executed the same set of operations, the copies of the shared document at all sites are identical 2. Causality-preservation: for any pair of operations Oa and Ob, of Oa -> Ob, the Oa is executed before Ob at all sites. 3. Intention-preservation: for any operation O, (a) both the local and remote execution effects of O equal to the intention of O, and (b) if there exists an operation Ox such that Ox || O, then the execution effect of Ox does not interfere with the execution effect, and vice versa.

State Vector (Ellis, 1991) N = Anzahl der kooperierenden Sites Jede Site verwaltet einen State Vector (SV) mit N Komponenten. Initiierung: SV[i]=0 für alle i  {0, ..., N-1} Nach Ausführung (execution) einer Operation, die von der Site i generiert wurde, gilt: SV[i] := SV[i] + 1

Causality-preservation Definition: Conditions for executing remote operations Let O be an operation generated at site s and timestamped by SVo. O is causally-ready for execution at site D (d  s) with a state vector SVd only if the following conditions are satisfied: 1. SVo[s] = SVd[s] + 1, and 2. SVo[i]  SVd[i], for all i  {o,1, ..., N-1} and i  s.

Total ordering Definition: Total ordering relation “=>” Given two operations Oa and Ob, generated at sites i and j and timestamped by SVOa and SVOb, respectivly, then Oa => Ob, iff: 1. sum(SVOa) < sum (SVOb), or 2. i < j when sum (SVOa) = sum (SVOb), where sum(SV) = i=0N-1 SV[i].

Algorithmus Algorithm: The undo/do/redo scheme When a new operation Onew is causally-ready, the following steps are executed: 1. Undo all operations in history buffer (HB) which totally follow Onew to restore the document to the state before their execution. 2. Do Onew and save it in HB. 3. Redo all operations that were undone from HB.

? Interoperabilität file file file model model model view view view display display display display

Interoperabilität (Dewan 1999) file file file file model model model model view view view view view view display display display display display display Interoperation Module

Problem Wie verheiratet man Systeme mit unterschiedlichen Methoden zur Konsistenzsicherung? Turn-taking Protokoll bzw. Floor Kontrolle, d.h. nur ein Benutzer kann die gesamte Objektmenge editieren Locking, d.h. Benutzer können Einzelobjekte sperren, die gesamte Objektmenge kann von mehreren Benutzern aber gleichzeitig bearbeitet werden.

Floor Control als Master Floor Control System User 1 User 2 Dummy User 3 LockControlSystem User 4 User 5 User 6 Jeder Lock fordert den Floor Bei einem Floor Queue können Lock User weiterhin Locks setzen: Lock User (4-6) sind damit im Vorteil, da jeder Lock die Anforderung in die Floor-Queue einreiht, während Floor User nur einen Request absetzen können.

Erweiterte Lösung Floor Control System User 1 User 2 Dummy User 3 Floor Listener User 1 User 2 Dummy User 3 LockControlSystem Wenn ein Floor Control User den Floor anfordert, werden alle Lock Anforderungen zurückgewiesen, d.h. es können über zusätzliche Locks keine zusätzlichen Floor Anforderungen in den Floor-Queue eingestellt werden. User 4 User 5 User 6

Lock Control als Master Lock Control System User 1 User 2 Dummy User 3 FloorControlSystem User 4 User 5 User 6 Jede Floor Anforderung führt zu einer Reservierung aller Locks im Master Jede Floor Freigabe führt zu einer Freigabe aller Locks im Master Problem: Ein Floor User kommt nicht zum Zuge, weil ständig neue Locks angefordert werden.

Erweiterte Lösung Lock Control System User 1 User 2 Dummy User 3 Lock Listener User 1 User 2 Dummy User 3 FloorControlSystem User 4 User 5 User 6 Lock Listener sorgt dafür, dass keine weiteren Locks gesetzt werden, wenn eine Floor Anforderung vorliegt

Awareness in shared applications Telepointer Multi-User Scroll bars Miniaturansicht Radaranssicht What you see is what I do Teleport

Asynchrones Joint-Editing Grundidee: Mehrere Personen editieren ein Dokument asynchron. Welche Eigenschaften sollte das Dokument haben: • Das Dokument ist zerlegbar • Teile des Dokumentes können einzelnen Bearbeitern zugeordnet werden • Änderungen sind leicht nachvollziehbar • Änderungen sind leicht revidierbar bzw. nachträglich zu verabschieden • Änderungshistorien. • Mechanismen zum Verteilen von Dokumenten

Probleme beim gemeinsamen Ändern von Texten Möglich sind Weglassen, Hinzufügen, Hervorheben, Modifizieren Man muss verstehen können, warum jemand Änderungen macht Problem: - Welche Änderungen werden dargestellt? - Wie werden sie dargestellt? - Layout- vs. Inhaltsänderung Die Antwort hängt ab: - von der Rolle der Bearbeiter - von den Zielen des gemeinsamen Erstellens von Dokumenten - von der Art der Aufgabe Wahrnehmungsproblem: Die Aufmerksamkeit muss ständig zwischen dem Inhalt und dem Nachvollziehen von Änderungen hin- und herschalten.

Änderungen beim Joint-Editing nachvollziehbar machen unterschiedliche Autoren • Streichungen und Einfügungen • wählbare Granularität bzgl. Bedeutung der Änderung, bzgl. des Umfangs etc. • Markierung am Rand • Vergleich von Dokumenten • Kommentare

Literatur