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

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


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!


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.


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


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


A

B

C

D

Lock

Lock

Lock

Lock

HTTP

Upload

Unlock

Unlock

Unlock

Unlock

Download

Download

Download


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


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.


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


SetupSetup


ResultsResults


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.


Future workFuture work

Controlled environmentControlled environment

Comparison with WS implementationsComparison with WS implementations

Questions?Questions?

THANK YOU!


Electing a Leader


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


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


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


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


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


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)


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.


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.


PeerOutside Acquire Leader

You can relinquish Leader role only by leaving

Superstates


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


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


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

Documents

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