Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "© Dr. Wolfgang Prinz Joint Editing / Application Sharing Dr. Wolfgang Prinz GMD-FIT."—  Präsentation transkript:

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

2 © Dr. Wolfgang Prinz Übersicht Grundkonzept Architekturen Konsistenzsicherung asynchrones gemeinsames Editieren

3 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz Anwendungsszenarien Face-to-face Sitzungen +... verteilte Sitzungen +... gemischte Sitzungen: face-to-face und verteilt +...

5 © Dr. Wolfgang Prinz Besonderheiten Konsistenzsicherung Antwortzeiten Eingabekoordination Awareness

6 © Dr. Wolfgang Prinz Was wird gemeinsam genutzt? Scrollbar Cursor Telepointer

7 © Dr. Wolfgang Prinz Eingabekontrolle - Spektrum Jeder darf alles Kontrolle über Floor Aspekte: Freiheit Kontrolle Konsistenzsicherung: explizit implizit single multiple Cursor Eingabekontrolle

8 © Dr. Wolfgang Prinz Eingabekontrolle

9 © Dr. Wolfgang Prinz Eingabekontrolle

10 © Dr. Wolfgang Prinz Referenz Modelle Pattersons 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 © Dr. Wolfgang Prinz Single User Anwendung file model view display

12 © Dr. Wolfgang Prinz Shared State file model view display view display

13 © Dr. Wolfgang Prinz Synchronized State file model view display file model view display

14 © Dr. Wolfgang Prinz Hybrider Ansatz file model view display view display

15 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz Interlace Architekturelemente Lautsprecher Monitor Rendering Process (r) Tastatur Maus Input Process (i) Update Process (u) View Process (v) Private state (p) 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)

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

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

19 © Dr. Wolfgang Prinz Replizierte Verteilungsarchitektur Vollständige Replikation aller Komponenten Varianten +collaboration transparent –Synchronisation der Eingabe +collaboration aware –Synchronisation des Zustands –relaxed WYSIWIS

20 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz pessimistische Ansätze optimistische Ansätze Konsistenzsicherung Responsivität VorhersagbarkeitKonsistenz The aim of concurreny control mechanisms is to allow for maximum concurrency while trying to restrict the system from becoming inconsistent or irrecoverable

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

25 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz Transaktionen Transaktionsablauf: +ö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 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz Turn-Taking Protokolle Floor Control +mechanische –FIFO –priorisiert –moderiert +soziale Einsatzmöglichkeit abhängig von der Anwendung +editing +voting

29 © Dr. Wolfgang Prinz Zentrale Kontrolle Zentraler Server empfängt und verteilt alle Benutzereingaben Vorteil: +einfache zentrale Konsistenzsicherung Probleme: +Ausfallproblematik +Flaschenhals +Antwortzeiten –Eingabe -> Server -> Anzeige

30 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz Beispiel Site 0Site 1Site 2 O1O2 O3O4

34 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz Total ordering Definition: Total ordering relation => Given two operations Oa and Ob, generated at sites i and j and timestamped by SV Oa and SV Ob, respectivly, then Oa => Ob, iff: 1. sum(SV Oa ) < sum (SV Ob ), or 2. i < j when sum (SV Oa ) = sum (SV Ob ), where sum(SV) = i=0 N-1 SV[i].

41 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz Interoperabilität file model view display view display file model view display file model view display ?

43 © Dr. Wolfgang Prinz Interoperabilität (Dewan 1999) file model view display view display file model view display file model view display file model view display view display Interoperation Module

44 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz Floor Control als Master Floor Control System User 1User 2Dummy 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 © Dr. Wolfgang Prinz Erweiterte Lösung 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. Floor Control System User 1User 2Dummy User 3 LockControlSystem User 4 User 5 User 6 Floor Listener

47 © Dr. Wolfgang Prinz Lock Control als Master Lock Control System User 1User 2Dummy 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 © Dr. Wolfgang Prinz Erweiterte Lösung Lock Control System User 1User 2Dummy 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 Lock Listener

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

50 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz 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 © Dr. Wolfgang Prinz Ä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 © Dr. Wolfgang Prinz Literatur


Herunterladen ppt "© Dr. Wolfgang Prinz Joint Editing / Application Sharing Dr. Wolfgang Prinz GMD-FIT."

Ähnliche Präsentationen


Google-Anzeigen