1. A synchronized protocol for distributed collaborative modeling
Dov Dori, Dizza Beimel and Lior Galanti
Technion, Israel Institute of Technology, Haifa, Israel.
5 June 2005
Lior Galanti. Technion, Israel Institute Of Technology.

2. Synchronous collaborative protocols: Requirements
Participants should be able to continuously and asynchronously propose modifications
Modifiers must be applied synchronously
The document’s validity must be maintained at all times
Lior Galanti. Technion, Israel Institute Of Technology.

3. Traditional collaboration
Synchronous
Restricts the participants to editing the document one at a time
Uses single lock mechanisms
Lior Galanti. Technion, Israel Institute Of Technology.

4. Single lock mechanisms
Synchronous collaboration revolves around dynamically allocating access permissions, called “floors”
Can be extended with moderation
Floors control semantics is derived from concurrency control methodology
Floor holder is granted mutually exclusive access rights
Lior Galanti. Technion, Israel Institute Of Technology.

5. A new approach: Synchronized collaborative protocol
Relaxing the floor control requirement
Lior Galanti. Technion, Israel Institute Of Technology.

6. Requirements
Participants can edit the document continuously without obtaining the floor
Modifications are applied synchronously for all participants
The document’s validity is maintained at all times
Lior Galanti. Technion, Israel Institute Of Technology.

7. Assumptions about underlying transport protocol
message delivery is:
Reliable
FIFO
Persistent
Lior Galanti. Technion, Israel Institute Of Technology.

8. Data structures Document Modifier The formal entity being shared
Sufficient instructions to perform modifications to a document
Transforms a document into another
Lior Galanti. Technion, Israel Institute Of Technology.

9. Messages Register Initialize Modify Publish Reject
Lior Galanti. Technion, Israel Institute Of Technology.

10. The Participant super role
Can validate a modifier to a document
Can apply a modifier to a document
Step number is increased by one every time a modifier is applied
Domain specific functionality
Lior Galanti. Technion, Israel Institute Of Technology.

11. The Session Controller role
Single in a session
Executes methods in atomic transactions
Generates the order relation for the modifiers
Synchronizes the session
Validates published modifiers for their corresponding published step
Performs weak validation
Lior Galanti. Technion, Israel Institute Of Technology.

12. The Editor role Editor Handles user requests
Applies published modifiers from the session controller
Validates user modifiers before they are sent to the session controller
Tags modifiers with the step they were validated for
Lior Galanti. Technion, Israel Institute Of Technology.

13. Editor/Session Controller interaction
Lior Galanti. Technion, Israel Institute Of Technology.

14. Weak validation Requires O(1) operations
Always rejects invalid modifiers
May reject valid modifiers as well
Always accepts if the document’s step is identical to the modifier’s step
Lior Galanti. Technion, Israel Institute Of Technology.

15. Session Controller message handlers
Replies to Register messages with an Initialize message containing the current known document
Replies to Modify messages with a multicast Publish message if the modifier weakly validates or a Reject message if weak validation fails
Lior Galanti. Technion, Israel Institute Of Technology.

16. Editor interaction
Sends a Register message at boot and waits for the Initialize message from the session controller
Applies published modifiers to the persistent document when they arrive
After sending a modify message blocks until modifier status is resolved, either published or rejected
Lior Galanti. Technion, Israel Institute Of Technology.

17. Editor interaction, continued
idle
wait
send {Register}
ready
receive {Initialize}
receive {publish}
send {modify}
[modifierId=x]
blocked
[modifierId!=x]
receive {publish or reject} [modifierId=x]
Lior Galanti. Technion, Israel Institute Of Technology.

18. Persistent and secondary document
Published modifiers are applied to the persistent document
User generates modifiers on the secondary copy
May be simulated using a history stack
Modifiers are validated against the persistent document before they are requested
Lior Galanti. Technion, Israel Institute Of Technology.

19. Persistent and secondary document, continued
Returning from blocked to ready due to modifier being published results in replacing the secondary copy with the persistent document
Returning due to rejection allows revalidation of the rejected modifier
Due to FIFO policy the step at which the modifier was rejected should be available
Lior Galanti. Technion, Israel Institute Of Technology.

20. Weak validation in the OPM domain
Weak validation is domain specific
Refining permissions in conjunction with refinement/abstraction mechanisms can be used for efficient weak validation
A modifier can be weakly validated if it does not concern zones changed by modifiers it was not aware of
Lior Galanti. Technion, Israel Institute Of Technology.

21. Special thanks To Prof. Dov Dori and Ms. Dizza Beimel
for their insightful comments and ongoing support.
To Ms. Hamutal Shamash and my brother, Mr. Gil Galanti,
for so many proof readings and for being there.
Lior Galanti. Technion, Israel Institute Of Technology.