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

© Dr. Wolfgang Prinz

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

• gemischte Sitzungen: face-to-face und verteilt+ ...


Besonderheiten

• Konsistenzsicherung

• Antwortzeiten

• Eingabekoordination

• Awareness


Was wird gemeinsam genutzt?

ScrollbarCursor

Telepointer


Eingabekontrolle - Spektrum

Jeder darf alles Kontrolle über “Floor”

Aspekte:• Freiheit <-> Kontrolle• Konsistenzsicherung: explizit <-> implizit

single

multiple

Cursor

Eingabekontrolle


Eingabekontrolle

single cursor multiplecursor

multiplefloor

single floor


Eingabekontrolle

single cursor multiplecursor

multiplefloor

"Cursor Wars" Konsistenz-problem

single floor restriktiveBenutzung

verschiedeneCursortypen


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

display

view

display


Synchronized State

file

model

view

display

file

model

view

display


Hybrider Ansatz

file

model

view

display

view

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

Lautsprecher

Monitor

RenderingProcess (r)

Tastatur

Maus

InputProcess (i)

UpdateProcess (u)

ViewProcess (v)

Privatestate (p)

SharedState (s)

Consistence MaintenanceProcess (cm)

Lautsprecher

Monitor

RenderingProcess (r)

Tastatur

Maus

InputProcess (i)

UpdateProcess (u)

ViewProcess (v)

Privatestate (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


ReplizierteVerteilungsarchitektur

• Vollständige Replikation aller Komponenten

• Varianten+ collaboration transparent

– Synchronisation der Eingabe

+ collaboration aware

– Synchronisation des Zustands

– relaxed WYSIWIS


ReplizierteVerteilungsarchitektur

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 koordinierteVerteilungsarchitektur

• 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 koordinierteVerteilungsarchitektur

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


pessimistische Ansätze

optimistische Ansätze

Konsistenzsicherung

Responsivität

Vorhersagbarkeit Konsistenz

The aim of concurreny control mechanisms is to allow for maximumconcurrency while trying to restrict the system from becoming inconsistentor irrecoverable


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:+ ö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


• 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


• 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 thatOa -> Ox and Ox -> Ob.



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.



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.



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

model

view

display

view

display

file

model

view

display

file

model

view

display

?


Interoperabilität(Dewan 1999)

file

model

view

display

view

display

file

model

view

display

file

model

view

display

file

model

view

display

view

display

InteroperationModule


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 dieFloor-Queue einreiht, während Floor User nur einen Request absetzen können.


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


LockControlSystem


FloorListener

FloorListener


Lock Control als Master

Lock Control System


FloorControlSystem


• 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


FloorControlSystem


Lock Listener sorgt dafür, dass keine weiteren Locks gesetzt werden, wenneine Floor Anforderung vorliegt

LockListener

LockListener


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

Dewan, P. and A. Sharma, "An experiment in interoperating heterogeneous collaborative systems",in Proc. of ECSCW'99: Sixth Conference on Computer Supported Cooperative Work, S. Bødker, M.Kyng, and K. Schmidt eds., Copenhagen, Kluwer Academic Publishers, 1999, pp. 371-390.

Ellis, C.A., S.J. Gibbs and G.L. Rein, "Groupware: Some issues and experiences," Communicationsof the ACM, 1991, Vol. 34, No. 1, pp. 39-58.

Lamport, L., "Time, Clocks, and the orderung of events in a distributed system," Communications ofthe ACM, 1978, Vol. 21, No. 7, pp. 558-565.

Patterson, J.F., "A taxonomy of architectures for synchronous groupware applications," ACM SIGOISBulletin Special Issue: Papers of the CSCW'94 Workshops, 1995, Vol. 15, No. 3,

Phillips, W.G., Architecture for Synchronous Groupware, Queen's University, 1999-425, 6. May1999, 1999.

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

Documents

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