1. Leveraging Operational Transformation in Collaborative Object Groups
G. Henri ter Hofte
Telematica Instituut, The Netherlands

2. It takes 100 ms ...
for humans to react, or for humans to perceive a response is not immediate
for 40 million clock cycles to run on a 400 MHz Pentium II
for 15,5 Mb of data to be sent on an ATM link
… for 1 bit of that data to reach its destination on an international link
(for light to travel about 3/4 around the world)
latency: it won’t go away!

3. What if … Latency > 100 ms and you need “immediate” response?
replication!
for performance of groupware (despite high latency)
You want to work together while disconnected?
for availability in nomadic computing (i.e. despite disconnection)
A computer crashes and you need the functionality?
for fault-tolerance in critical applications (i.e. despite partial faults)

4. Collaborative zipper Legend: file status edit status uncoupled status
view control status
coupled status
(centralized)
user interface
control status
coupled status
(synchronization)

5. Replication complexities
consistency management
due to ordering anomalies
waiting on “the other side(s)” is expensive
e.g. don’t lock unless really necessary!
latecomers & earlyleavers
how to handle without disrupting service?

6. Remote Method Invocation
Java Virtual
Machine 1
Java Virtual Machine 2 A B
Java RMI

7. Multicast RMI ?
JVM3
JVM1
JVM2 A B1 B2
Multicast RMI (MRMI)

8. Object group invocation
(server)
(client)

9. Object group invocation
request(s)
collation
multicast
collation
multicast
response(s)
object group
(server)
object group
(client)

10. Proposed solution: GroupRMI
replicated object groups
programmers can treat them as normal (non-replicated) objects
replication transparency
adhere to Java RMI, works for arbitrary remote objects
“programmers that know how to RMI, know how to GroupRMI”
shallow learning curve
default policies + allow for policy plug-ins
to allow advanced programmers to deal with special cases
to allow various (optimistic) consistency policies
coupling/uncoupling, operational transformation, merging
selective replication transparency

11. One level Legend: uncoupled status coupled status (centralized)
(synchronization)

12. One level Legend: uncoupled status coupled status (centralized)
(synchronization)

13. One object group Legend: uncoupled status coupled status (centralized)
(synchronization)

14. One object group Legend: uncoupled status coupled status (centralized)
(synchronization)

15. One object group member

16. One object group member
Local done queue
(outbound queue (aggregation), optimistically performed actions, undo/redo & latecomer log)
Java object
Outbound Coupler
(presence aggregation filter)
multicast channel
Concurrency Control:
Exclusive Access and/or Ordering
Inbound Coupler (awareness aggregation filter)
Local to-do queue
(pessimistically delayed local actions, & inbound queue (aggregation))
total order token
Local to-do queue
(pessimistically delayed local actions)
Acccess Control

17. lookup (“rmi://h1/nm”)
Java RMI scenario
client JVM
Registry
server JVM (“h1”)
bind(“nm”)
lookup(“nm”)
lookup (“rmi://h1/nm”)
stub for B
skeleton for B
“nm”
Naming
bind(“nm”)
Naming B A
myCall()
myCall()
stub for B
myCall

18. newInstance (“CB”,“nm”)
GroupRMI scenario
JVM
session1
JVM
newInstance (“CB”,“nm”)
newInstance
(“CB”,“nm”) A B
“nm” B’
“nm” A’
myCall()

19. Operational transformation matrix: two operations
commutative: do nothing special
masking: delete one from history buffer
memoryless: masking all, empty buffer
conflicting: specify transformation function
application specific
fork history (parallel versions) is an option followed by version merging tools

20. Use of operational transformation
State transfer = intentional latency
Group undo/redo = “ delayed” undo
Version merging = human-assisted form of operational transformation

21. Issues terminology find better quality criteria performance studies
e.g. from serializability to consistency causality, intention preservation
performance studies
e.g. impact of latency, use of IP multicast, algorithms
simulation of network
usability tests
what DO users expect, what IS their intention
build application-specify transformation matrices

22. Issues (cont’d) share algorithms common experimentation platform
with pluggable policies
+ simulation

23. That’s all folks!
Questions? Comments?