SOA-based Collaborative Authoring Andrew Roczniak Multimedia Research Lab University of Ottawa

2May 19th, 2006Andrew Roczniak MCRLab 2006 Intro Our intent is to develop a framework for fast design of collaborative applications For that purpose we have looked at Jabber, originally designed with instant messaging applications in mind, with the goal on building on top of it Very quickly it became apparent that some functionalities required by collaborative applications are missing

3May 19th, 2006Andrew Roczniak MCRLab 2006 Jabber Jabber is a set of streaming XML protocols and technologies that enable any two entities on the Internet to exchange messages, presence, and other structured information in close to real time No specific network architecture required Usually implemented in a client-server architecture over TCP Usually implemented in a client-server architecture over TCP Servers also communicate with each other over TCP connections Servers also communicate with each other over TCP connections

4May 19th, 2006Andrew Roczniak MCRLab 2006 Jabber The Jabber Software Foundation (JSF) contributed the base protocols to the Internet Engineering Task Force (IETF) under the name Extensible Messaging and Presence Protocol (XMPP) Base Protocols (XMPP RFCs) Base Protocols (XMPP RFCs) RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core. The core XML streaming functionality that powers Jabber applications, including advanced security and internationalization support RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. Basic IM and presence functionality, including contact lists, presence subscriptions, and whitelisting/blacklisting In addition, the XMPP Work Group developed the following two RFCs: In addition, the XMPP Work Group developed the following two RFCs: RFC 3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) A mapping of XMPP to the IETF's abstract syntax for IM and presence RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) An extension for interoperable, end-to-end security Various XMPP extensions are defined in the JSF's Jabber Enhancement Proposals (JEPs) series. Various XMPP extensions are defined in the JSF's Jabber Enhancement Proposals (JEPs) series.

5May 19th, 2006Andrew Roczniak MCRLab 2006 Required Functionalities Group Communication Group notification (event notification) Group notification (event notification) Bulk transfer (large files) Bulk transfer (large files) Document consistency Group notification + presence information + distributed lock mechanism Group notification + presence information + distributed lock mechanism

6May 19th, 2006Andrew Roczniak MCRLab 2006 T = 1T = 2 A B C D C requests lockA requests lock C requests lockA requests lock OK B: OK D: OK Deny T=1 < T=2 OK T=1 < T=2 C: OK A: Deny Lock

7May 19th, 2006Andrew Roczniak MCRLab 2006 A B C D Lock HTTP Upload Unlock Download

8May 19th, 2006Andrew Roczniak MCRLab 2006 Approximate time synchronization is required Cooperative, not competitive environment Cooperative, not competitive environment The leader will periodically send a series of “timestamps”, based on System.nanoTime(). All users (leader included) will, upon receiving such timestamp, take note of the difference between the timestamp and their own value of System.nanoTime(). Whenever a timestamp needs to be created for a new request, it will be based on the current System.nanoTime() + the difference with the Leader Getting the time right

9May 19th, 2006Andrew Roczniak MCRLab 2006 Leader Election When a user joins an empty room, it becomes the leader. When a user joins a non-empty room, it waits for a special message from the leader. When the leader leaves the room, the users elect a new one using highest JID hash.

10May 19th, 2006Andrew Roczniak MCRLab 2006 Experiments Ran test scripts that randomly attempt to lock editable areas of the shared document at randomly spaced intervals of time If a lock is achieved, then an image is added and the area is unlocked A separate script randomly executes login, log off and simulates system crashes A separate script randomly executes login, log off and simulates system crashes

11May 19th, 2006Andrew Roczniak MCRLab 2006 Setup

12May 19th, 2006Andrew Roczniak MCRLab 2006 Results

13May 19th, 2006Andrew Roczniak MCRLab 2006 Results Not sent: requests that were canceled either because the area was already locked, or because the activities were paused in order to let a user join the collaboration room. Canceled: requests that were retracted when another user was logging in. Timeout: requests for which not all accept messages were received within 5 seconds; those were re- issued. Denied: those that were withdrawn because another peer attempted to lock the same area a moment before. Successful: those that completed successfully.

14May 19th, 2006Andrew Roczniak MCRLab 2006 Future work Controlled environment Comparison with WS implementations Questions? THANK YOU!

15May 19th, 2006Andrew Roczniak MCRLab 2006 Electing a Leader

16May 19th, 2006Andrew Roczniak MCRLab 2006 locked? NoYes Cancel Sending a request Lock List Pending Send Lock Request This must be completed in active state (no pause) Read Write Action Lock area Wait for Replies

17May 19th, 2006Andrew Roczniak MCRLab 2006 Wait for Replies Yes No Yes Issue lock confirm Upload Issue unlock Matches request? No Yes Deny? All votes? Processing request replies Read Pending Write Vote List Write Delete Done Write Delete This must be completed in uploading state (no pause) Can be preempted by pause Lock accept/deny message Timeout Action Lock area

18May 19th, 2006Andrew Roczniak MCRLab 2006 Vote List Wait for Replies Request received Issue lock confirm Interaction between active objects This can be killed only if the vote list is incomplete These can be killed at any time

19May 19th, 2006Andrew Roczniak MCRLab 2006 Yes No Yes Receiving a request Yes No YesNo Yes No Action Lock request message Done Locked? My request? Pending?My time greater?My time lower?My hash higher? Issue Accept Issue Deny Write Pending Write Delete Pending Read Lock List Read Vote List Can be preempted by pause

20May 19th, 2006Andrew Roczniak MCRLab 2006 Leader? Pending Locks? Set to DENY Ignore replies Specific to that request Yes My Locks > 0 No Upload and Issue Unlock Message Yes Done NoYes Locks > 0 Wait Yes No Issue Leader Declaration Message The new user will send a start message after Downloading the DOM. Otherwise the leader tells participants to start if(lockManager.lock_list.size()==0) {…} else new Timer().schedule(new TimerTask(){public void run(){tryToRestart();}},100); Local locks are taken care of by the protocol. Global number of locks must be 0 to finish. My Locks - - Locks - - For example: New user has joined My locks is not a structure, just used here to highlight ownership of locks. Those two algorithms are running concurrently Pause-and-Restart Assumes there is a leader Assumes nobody crashed and all unlock messages are received

21May 19th, 2006Andrew Roczniak MCRLab 2006 How many peers? 1N Not Leader NoYes Leader election – when Leader leaves (gracefully or crashed) Leader Calculate hash of unique IDs for all peers My hash == max{hash} Leader Assumes all get the same list of peers Could cause problems if leader leaves and a peer joins at the same time: some peers could get different lists from the server? Get internal list Of participants Two events happen: leader leaves and new user joins. The order of events is determined at the server. Since we use a centralized server, message order is the same for all peers, but these can be received at different times. List must be stored at each peer and updated when user leaves and after leader declaration message when user joins. Otherwise, a new user could wait for the declaration when it has been elected leader. Atomic (whenever leader left message is received)

22May 19th, 2006Andrew Roczniak MCRLab 2006 How many peers? 1N Not Leader Leader election – at the beginning Leader Get list of participants from server What if two users join the chat room at the same time? Both could retrieve a list of two participants and thus decide they are not leaders.

23May 19th, 2006Andrew Roczniak MCRLab 2006 Was it the leader? NoYes Participant leaves (gracefully or crashed) Done Elect Leader Assumes all get the same list of peers Could cause problems if leader leaves and a peer joins at the same time: some peers could get different lists from the server? Remove locks owned by the participant Two events happen: leader leaves and new user joins. The order of events is determined at the server. Since we use a centralized server, message order is the same for all peers, but these can be received at different times. List must be stored at each peer and updated when user leaves and after leader declaration message when user joins. Otherwise, a new user could wait for the declaration when it has been elected leader.

24May 19th, 2006Andrew Roczniak MCRLab 2006 PeerOutsideAcquireLeader You can relinquish Leader role only by leaving Superstates

25May 19th, 2006Andrew Roczniak MCRLab 2006 Pause Join, Leave Active Restart Join, Leave Peer After acquire, is the peer in active or pause state? Waiting Join, Leave Active Restart Join, Leave Leader After becoming a leader, is the peer in active or pause state? Waiting for replies Uploading

26May 19th, 2006Andrew Roczniak MCRLab 2006 Area (active peer) Messages received Messages sent Actions Unlocked Locked Lock confirm Unlock Pending Lock request Deny Cancel Lock request Accept - or - Deny Accept Business logic based on timestamp Lock request Accept Deny Lock confirm Unlock

27May 19th, 2006Andrew Roczniak MCRLab 2006 Area (passive peer) Messages received Messages sent Actions Unlocked Locked Lock confirm Lock request Accept Improvement This information could be used to minimize conflicts if this peer decides to lock this area Unlock User left - Remove Deny is never sent since this peer is not trying to lock this area as well Lock request Accept Deny Lock confirm Unlock