A synchronized protocol for distributed collaborative modeling

1. A synchronized protocol for distributed collaborative modeling Dov Dori, Dizza Beimel and Lior Galanti dori@ie dizza@tx sgalanti@t2 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 • The formal entity being shared • Modifier • 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 • Participant • 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 • Session Controller • 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. idle send {Register} wait receive {Initialize} receive {publish} ready send {modify} [modifierId=x] receive {publishorreject}[modifierId=x] blocked receive {publish} [modifierId!=x] Editor interaction, continued 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.