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.

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.

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.

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.

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

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.

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

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.