soa-based collaborative authoring andrew roczniak multimedia research lab university of ottawa
TRANSCRIPT
SOA-based SOA-based Collaborative AuthoringCollaborative Authoring
Andrew RoczniakAndrew Roczniak
Multimedia Research LabMultimedia Research Lab
University of OttawaUniversity of Ottawa
22May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
IntroIntro
Our intent is to develop a framework for Our intent is to develop a framework for fast design of collaborative applicationsfast design of collaborative applicationsFor that purpose we have looked at For that purpose we have looked at Jabber, originally designed with instant Jabber, originally designed with instant messaging applications in mind, with the messaging applications in mind, with the goal on building on top of itgoal on building on top of itVery quickly it became apparent that some Very quickly it became apparent that some functionalities required by collaborative functionalities required by collaborative applications are missingapplications are missing
33May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
JabberJabber
Jabber is a set of streaming XML protocols and technologies that Jabber is a set of streaming XML protocols and technologies that enable any two entities on the Internet to exchange messages, enable any two entities on the Internet to exchange messages, presence, and other structured information in close to real time presence, and other structured information in close to real time No specific network architecture requiredNo specific network architecture required
Usually implemented in a client-server architecture over TCPUsually 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
Gateway
Jabber Client
Jabber Server Jabber Server
Jabber Client
Peer
Jabber Client
Yahoo!
44May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
JabberJabber
The Jabber Software Foundation (JSF) contributed the base The Jabber Software Foundation (JSF) contributed the base protocols to the Internet Engineering Task Force (IETF) under the protocols to the Internet Engineering Task Force (IETF) under the name Extensible Messaging and Presence Protocol (XMPP)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 RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core. The core XML streaming functionality that powers Jabber applications, including core XML streaming functionality that powers Jabber applications, including advanced security and internationalization supportadvanced security and internationalization supportRFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. Basic IM and presence functionality, including Messaging and Presence. Basic IM and presence functionality, including contact lists, presence subscriptions, and whitelisting/blacklisting 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 RFC 3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) A mapping of (XMPP) to Common Presence and Instant Messaging (CPIM) A mapping of XMPP to the IETF's abstract syntax for IM and presence XMPP to the IETF's abstract syntax for IM and presence RFC 3923: End-to-End Signing and Object Encryption for the Extensible RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) An extension for interoperable, Messaging and Presence Protocol (XMPP) An extension for interoperable, end-to-end security end-to-end security
Various XMPP extensions are defined in the JSF's Jabber Various XMPP extensions are defined in the JSF's Jabber Enhancement Proposals (JEPs) series.Enhancement Proposals (JEPs) series.
55May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
Required FunctionalitiesRequired Functionalities
Group CommunicationGroup Communication Group notification (event notification) Group notification (event notification) Bulk transfer (large files) Bulk transfer (large files)
Document consistency Document consistency Group notification + presence information + Group notification + presence information +
distributed lock mechanismdistributed lock mechanism
66May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
T = 1 T = 2A
B
C
D
C requests lockA requests lock
C requests lockA requests lock
OK OK
OKOK
B: OKB: OK
D: OKD: OK
DenyT=1 < T=2 OK T=1 < T=2
C: OK A: DenyLock
Lock
Lock
Lock
77May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
A
B
C
D
Lock
Lock
Lock
Lock
HTTP
Upload
Unlock
Unlock
Unlock
Unlock
Download
Download
Download
88May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
Approximate time synchronization is required Approximate time synchronization is required Cooperative, not competitive environmentCooperative, not competitive environment
The leader will periodically send a series of The leader will periodically send a series of “timestamps”, based on System.nanoTime().“timestamps”, based on System.nanoTime().All users (leader included) will, upon receiving All users (leader included) will, upon receiving such timestamp, take note of the difference such timestamp, take note of the difference between the timestamp and their own value of between the timestamp and their own value of System.nanoTime(). System.nanoTime(). Whenever a timestamp needs to be created for Whenever a timestamp needs to be created for a new request, it will be based on the current a new request, it will be based on the current System.nanoTime() + the difference with the System.nanoTime() + the difference with the LeaderLeader
Getting the time rightGetting the time right
99May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
Leader ElectionLeader Election
When a user joins an empty room, it When a user joins an empty room, it becomes the leader.becomes the leader.
When a user joins a non-empty room, it When a user joins a non-empty room, it waits for a special message from the waits for a special message from the leader.leader.
When the leader leaves the room, the When the leader leaves the room, the users elect a new one using highest JID users elect a new one using highest JID hash.hash.
1010May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
ExperimentsExperiments
Ran test scripts that randomly attempt to Ran test scripts that randomly attempt to lock editable areas of the shared lock editable areas of the shared document at randomly spaced intervals of document at randomly spaced intervals of timetimeIf a lock is achieved, then an image is If a lock is achieved, then an image is added and the area is unlockedadded and the area is unlocked A separate script randomly executes A separate script randomly executes login, log off and simulates system login, log off and simulates system crashescrashes
1111May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
SetupSetup
1212May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
ResultsResults
1313May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
ResultsResultsNot sent: requests that were Not sent: requests that were canceled either because the canceled either because the area was already locked, or area was already locked, or because the activities were because the activities were paused in order to let a user paused in order to let a user join the collaboration room. join the collaboration room. Canceled: requests that Canceled: requests that were retracted when another were retracted when another user was logging in. user was logging in. Timeout: requests for which Timeout: requests for which not all accept messages not all accept messages were received within 5 were received within 5 seconds; those were re-seconds; those were re-issued. issued. Denied: those that were Denied: those that were withdrawn because another withdrawn because another peer attempted to lock the peer attempted to lock the same area a moment same area a moment before. before. Successful: those that Successful: those that completed successfully.completed successfully.
1414May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
Future workFuture work
Controlled environmentControlled environment
Comparison with WS implementationsComparison with WS implementations
Questions?Questions?
THANK YOU!
1515May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
Electing a Leader
1616May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
locked?NoYes
Cancel
Sending a request
LockList
Pending
Send Lock Request
This must be completed in active state (no pause)
Read
Write
Action
Lock area
Wait for Replies
1717May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
Wait for Replies
Yes
No
No
Yes
Issue lockconfirm Upload Issue
unlock
Matchesrequest?
No
YesDeny?
All votes?
Processing request replies
Read Pending
Write
VoteList
Write
Delete
Done
WriteDelete
This must be completed in uploading state (no pause)
Can be preempted by pause
Lock accept/deny message
Timeout ActionLock area
1818May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
VoteList
Wait for Replies
Requestreceived
Issue lockconfirm
Interaction between active objects
This can be killed only if the vote list is incomplete
These can be killed at any time
1919May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
Yes
No
No
Yes
Receiving a request
Yes
Yes
No
No
YesNo
Yes
No
ActionLock request message
Done
Locked?
My request?
Pending? My time greater?My time lower? My hash higher?
IssueAccept
IssueDeny
Write
Pending WriteDelete
Pending
Read
LockList Read
VoteList
Can be preempted by pause
2020May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
Leader?
Pending Locks?
Set to DENYIgnore replies
Specific to that request
Yes
My Locks > 0
No
Upload andIssue Unlock
Message
Yes
Done
NoYes
Locks > 0
Wait
YesNo
Issue LeaderDeclaration Message
The new user will send a start message afterDownloading the DOM.
Otherwise the leader tells participants to start
if(lockManager.lock_list.size()==0) {…} elsenew 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-RestartAssumes there is a leader
Assumes nobody crashed and all unlock messages are received
2121May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
How many peers?
1 N
Not Leader
NoYes
Leader election – when Leader leaves (gracefully or crashed)
Leader Calculate hash of unique IDsfor 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.
Atom
ic(w
henever leader left message is received)
2222May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
How many peers?
1 N
Not Leader
Leader election – at the beginning
Leader
Get list of participantsfrom 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.
2323May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
Was it the leader?
No Yes
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.
2424May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
PeerOutside Acquire Leader
You can relinquish Leader role only by leaving
Superstates
2525May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 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
2626May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
Area (active peer)
Messages receivedMessages sentActions
Unlocked Locked
Lock confirm
Unlock
Pending
Lock request
DenyCancel
Lock requestAccept - or -Deny
Accept
Business logic based on timestampLock request
AcceptDenyLock confirmUnlock
2727May 19th, 2006May 19th, 2006 Andrew Roczniak MCRLab 2006Andrew Roczniak MCRLab 2006
Area (passive peer)
Messages receivedMessages sentActions
Unlocked Locked
Lock confirm
Lock requestAccept
Improvement
This information could be used to minimize conflicts if this peer decides to lock this area
Unlock User left - RemoveDeny is never sent since
this peer is not trying to lock this area as well
Lock requestAcceptDenyLock confirmUnlock