Zyklische Ortung mit dem Medaillon GMD-11 DAKS Release 7 HiPath DAKS V3 R0 Stand: 27. März 2008.
© Dr. Wolfgang Prinz Joint Editing / Application Sharing Dr. Wolfgang Prinz GMD-FIT.
-
Upload
malwine-wentz -
Category
Documents
-
view
115 -
download
1
Transcript of © Dr. Wolfgang Prinz Joint Editing / Application Sharing Dr. Wolfgang Prinz GMD-FIT.
© Dr. Wolfgang Prinz
Joint Editing / Application Sharing
Dr. Wolfgang Prinz
GMD-FIT
© Dr. Wolfgang Prinz
Übersicht
• Grundkonzept
• Architekturen
• Konsistenzsicherung
• asynchrones gemeinsames Editieren
© 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
© Dr. Wolfgang Prinz
Anwendungsszenarien
• Face-to-face Sitzungen+ ...
• verteilte Sitzungen+ ...
• gemischte Sitzungen: face-to-face und verteilt+ ...
© Dr. Wolfgang Prinz
Besonderheiten
• Konsistenzsicherung
• Antwortzeiten
• Eingabekoordination
• Awareness
© Dr. Wolfgang Prinz
Was wird gemeinsam genutzt?
ScrollbarCursor
Telepointer
© Dr. Wolfgang Prinz
Eingabekontrolle - Spektrum
Jeder darf alles Kontrolle über “Floor”
Aspekte:• Freiheit <-> Kontrolle• Konsistenzsicherung: explizit <-> implizit
single
multiple
Cursor
Eingabekontrolle
© Dr. Wolfgang Prinz
Eingabekontrolle
single cursor multiplecursor
multiplefloor
single floor
© Dr. Wolfgang Prinz
Eingabekontrolle
single cursor multiplecursor
multiplefloor
"Cursor Wars" Konsistenz-problem
single floor restriktiveBenutzung
verschiedeneCursortypen
© Dr. Wolfgang Prinz
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
© Dr. Wolfgang Prinz
Single User Anwendung
file
model
view
display
© Dr. Wolfgang Prinz
Shared State
file
model
view
display
view
display
© Dr. Wolfgang Prinz
Synchronized State
file
model
view
display
file
model
view
display
© Dr. Wolfgang Prinz
Hybrider Ansatz
file
model
view
display
view
display
© 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
© Dr. Wolfgang Prinz
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)
© 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
© Dr. Wolfgang Prinz
Zentralisierte Verteilungsarchitektur
Vorteile
• Einfachheit
• Unterstützung von Nachzüglern
Nachteile
• hohes Kommunikationsaufkommen
• Anfällig bei unterschiedlicher Connectivity
• Scalability
Beispiele: XTV, Netmeeting
© Dr. Wolfgang Prinz
ReplizierteVerteilungsarchitektur
• Vollständige Replikation aller Komponenten
• Varianten+ collaboration transparent
– Synchronisation der Eingabe
+ collaboration aware
– Synchronisation des Zustands
– relaxed WYSIWIS
© Dr. Wolfgang Prinz
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
© Dr. Wolfgang Prinz
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?
© Dr. Wolfgang Prinz
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
© Dr. Wolfgang Prinz
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
© Dr. Wolfgang Prinz
Designaspekte
• Locking
• Transaktionen
• Turn-Taking Protokolle
• zentralisierte Kontrolle
• Abhängigkeits-Erkennung
• Reversible Ausführung
• Operations-Transformation
© 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
© 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
© 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.
© Dr. Wolfgang Prinz
Turn-Taking Protokolle
• Floor Control+ mechanische
– FIFO
– priorisiert
– moderiert
+ soziale
• Einsatzmöglichkeit abhängig von der Anwendung
+ editing
+ voting
© Dr. Wolfgang Prinz
Zentrale Kontrolle
• Zentraler Server empfängt und verteilt alle Benutzereingaben
• Vorteil:+ einfache zentrale Konsistenzsicherung
• Probleme:+ Ausfallproblematik
+ Flaschenhals
+ Antwortzeiten
– Eingabe -> Server -> Anzeige
© 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
© 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.
© 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.
© Dr. Wolfgang Prinz
Beispiel
Site 0 Site 1 Site 2
O1 O2
O3 O4
© 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 thatOa -> Ox and Ox -> Ob.
© 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.
© 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.
© 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.
© 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
© 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.
© Dr. Wolfgang Prinz
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].
© 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.
© Dr. Wolfgang Prinz
Interoperabilität
file
model
view
display
view
display
file
model
view
display
file
model
view
display
?
© 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
InteroperationModule
© 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.
© Dr. Wolfgang Prinz
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.
© 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 1 User 2 Dummy User 3
LockControlSystem
User 4 User 5 User 6
FloorListener
FloorListener
© Dr. Wolfgang Prinz
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.
© Dr. Wolfgang Prinz
Erweiterte Lösung
Lock Control System
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, wenneine Floor Anforderung vorliegt
LockListener
LockListener
© Dr. Wolfgang Prinz
Awareness in shared applications
• Telepointer
• Multi-User Scroll bars
• Miniaturansicht
• Radaranssicht
• What you see is what I do
• Teleport
© 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
© 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.
© 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
© Dr. Wolfgang Prinz
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.