Joint Editing / Application Sharing

Präsentation zum Thema: "Joint Editing / Application Sharing"—  Präsentation transkript:

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

2 Übersicht Grundkonzept Architekturen Konsistenzsicherung
asynchrones gemeinsames Editieren

3 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

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

5 Besonderheiten Konsistenzsicherung Antwortzeiten Eingabekoordination
Awareness

6 Was wird gemeinsam genutzt?
Telepointer Cursor Scrollbar

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

8 Eingabekontrolle

9 Eingabekontrolle

10 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

11 Single User Anwendung file model view display

12 Shared State file model view view display display

13 Synchronized State file file model model view view display display

14 Hybrider Ansatz file model view view display display

15 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

16 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)

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

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

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

20 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

21 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?

22 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

23 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

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

25 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

26 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

27 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.

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

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

30 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

31 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.

32 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.

33 Beispiel Site 0 Site 1 Site 2 O1 O2 O3 O4

34 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.

35 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.

36 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.

37 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.

38 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

39 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.

40 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].

41 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.

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

43 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

44 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.

45 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.

46 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

47 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.

48 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

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

50 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

51 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.

52 Ä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

53 Literatur