Design of Distributed Collaborative Application through Service Aggregation Andrew Roczniak Multimedia Communications Research Lab University of Ottawa, Ottawa, Canada

Tuesday, October 03, 2006© MCRLab 2 Context Trend Growing levels of digitalization and broadband access Drives extremely fast progress in multimedia and networking technologies Results in consumers creating requirements at an accelerating rate

Tuesday, October 03, 2006© MCRLab 3 Motivation The problem is in matching the time necessary to develop an application to the rate of change of users’ requirements A solution is to empower users to create applications that best meet their expectations The Service Oriented Architecture (SOA) is used to support loosely-coupled integration of existing applications We are investigating the possibility of creating entirely new applications based on SOA

Tuesday, October 03, 2006© MCRLab 4 Proposed Approach To show that SOA-based collaborative applications can be quickly designed and deployed: A case study for a collaborative authoring application Targeting groups of around five users collaborating over the Internet Highlight the basic requirements of the application Show how these can be fulfilled by utilizing certain services Accessed through standard HTTP, Jabber and JXTA set of protocols Off-the-shelf techniques Measure the performance of the application in a heterogeneous environment Provide details of an alternate service fulfilling the application’s requirement

Tuesday, October 03, 2006© MCRLab 5 General Architecture Application Functionality AFunctionality BFunctionality C Service State Support Service AService BService Z Service Interaction Interface

Tuesday, October 03, 2006© MCRLab 6 Required Functionalities Collaborative Authoring requires Group Communication Group notification (event notification) Bulk transfer (large files) Document consistency

Tuesday, October 03, 2006© MCRLab 7 Jabber – 1/2 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 Servers also communicate with each other over TCP connections

Tuesday, October 03, 2006© MCRLab 8 Jabber – 2/2 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) RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core. The core XML streaming functionality RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. Basic IM and presence functionality 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.

Tuesday, October 03, 2006© MCRLab 9 Matching Functionalities with Technologies Group Notification Bulk transfer Data consistency HTTP Jabber JXTA  Group notification + presence information + distributed lock mechanism

Tuesday, October 03, 2006© MCRLab 10 Implementation Collaborative Authoring Application Bulk Transfer Group Notification Data Consistency Extended CMS Rendezvous Peer Web ServerPresence Jabber Server Locks Client/Server Peer-to-Peer Jabber ProtocolsHTTPJXTA JabberHTTPJXTA

Tuesday, October 03, 2006© MCRLab 11 Implementation Collaborative Authoring Application Bulk Transfer Group Notification Data Consistency Extended CMS Rendezvous Peer Web ServerPresence Jabber Server Locks Client/Server Peer-to-Peer Jabber ProtocolsHTTPJXTA JabberHTTPJXTA

Tuesday, October 03, 2006© MCRLab 12 Implementation (and rest of the presentation) Extended CMS Locks Distributed lock mechanism based on group notification and presence information Improves performance in certain circumstances

Tuesday, October 03, 2006© MCRLab 13 Data Consistency: Concurrency Control Pessimistic Ensure no conflicts occur Lock-based concurrency control Two-phase locking (acquire, release) Deadlocks Optimistic Assume no conflicts occur Detect conflicts at commit time and abort conflicting transactions Wasted effort

Tuesday, October 03, 2006© MCRLab 14 Data Consistency: Implementation (pessimistic) Centralized Easy to implement, but one peer is responsible Distributed Many messages Group membership management Failures Tokens Less messages Token recovery More complicated implementation

Tuesday, October 03, 2006© MCRLab 15 Granting of Locks Who gets the lock depends who made the request first, and the order can be based on: Time Synchronization Logical Clocks

Tuesday, October 03, 2006© MCRLab 16 Clock Synchronization Algorithms Centralized Algorithms Cristian’s Algorithm Berkeley Algorithm Decentralized Algorithms Averaging Algorithms (e.g. NTP) Multiple External Time Sources

Tuesday, October 03, 2006© MCRLab 17 Cristian's Algorithm Assume one peer has the “right” time and all other peers synchronize with it Every  seconds, each peer sends a message to the time server asking for the current time. Time server responds with message containing current time T Delay from the server to client can be significant and there may be jitter - estimate delay d If d is above a threshold, ignore the measurement Use shortest recorded delay

Tuesday, October 03, 2006© MCRLab 18 Our Implementation The leader periodically or on membership change sends a series of its current time values All users (leader included) will, upon receiving timestamps, take note of the difference between the timestamp and their own time Delay can be estimated from the series Whenever a timestamp needs to be created for a new request, it will be based on the current local time + the difference with the leader

Tuesday, October 03, 2006© MCRLab 19 Alternative - Logical Clocks What is important is that all peers agree on the order in which requests occur Vector Clocks can be used even when: Rate of occurrence of events is high Execution time of events is small

Tuesday, October 03, 2006© MCRLab 20 Why not Logical Clocks? Humans usually establish precedence with the help of loosely synchronized clocks And we are trying to help humans collaborate not compete…. Loose synchronization should be sufficient Vector clocks are more complex to implement

Tuesday, October 03, 2006© MCRLab 21 Data Consistency: Mutual Exclusion We already have total ordering and reliable messaging A peer requesting a lock sends a message to all peers (including self) with Area ID (critical section), its name (Jabber ID) and Timestamp Upon receiving a request, each peer: If it does not currently hold the lock and it did not request the lock, it sends an OK message to the sender If it currently holds the lock, it sends a DENY message If it does not currently hold the lock but issued a request for it, it compares the timestamps of the requests. If it is its own request or if the received request has lower timestamp, it sends OK. It sends DENY otherwise

Tuesday, October 03, 2006© MCRLab 22 Data Consistency: Mutual Exclusion The peer waits for an OK from all the other peers. When all are received, it notifies all peers that it currently holds the lock After making modifications and uploading a new version of the document, it notifies other peers of the availability of the new document and releases the lock Variant of (Ricart and Agrawala) mutual exclusion algorithm – more messages, but no waiting

Tuesday, October 03, 2006© MCRLab 23 Leader Election The leader (time server) is a controller. If it fails, one and only one new controller must take its place 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 Jabber ID hash

Tuesday, October 03, 2006© MCRLab 24 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 peer crashes

Tuesday, October 03, 2006© MCRLab 25 Jabber Setup

Tuesday, October 03, 2006© MCRLab 26 Results

Tuesday, October 03, 2006© MCRLab 27 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.

Tuesday, October 03, 2006© MCRLab 28 JXTA Setup Fast Peers Slow Peers

Tuesday, October 03, 2006© MCRLab 29 Bulk Transfer – JXTA+CMS

Tuesday, October 03, 2006© MCRLab 30 Bulk Transfer - eCMS

Tuesday, October 03, 2006© MCRLab 31 Bulk Transfer

Tuesday, October 03, 2006© MCRLab 32 Bulk Transfer – Why not BitTorrent? Bit Torrent is designed to efficiently replicate a file between a large number of peers that do not necessarily know each other, and in most likelihood will not cooperate on downloading another file again. In contrast, during a multimedia authoring session the same peers might collaborate on transferring multiple files. Torrent file creation and distribution would thus impose unnecessary costs if not adapted to our application. The choking algorithm’s benefits - reciprocity and peer selection - will not be fully utilized. In our application peers are assumed to be fully cooperative and thus there is no need to implement incentives to trade pieces. Similarly, due to the limited number of participants, searching for a better peer could again impose unnecessary costs. The tracker provided services such as keeping a global view of the system, are not used in our case since they are designed to support interaction between a large number of peers.

Tuesday, October 03, 2006© MCRLab 33 Conclusions Assuming a pool of functionalities accessible through standard protocols and interfaces (Services), aggregate them in such a way as to fulfill some requirements (Application) If a Service does not directly support a requirement, use off-the-shelf techniques to do the mapping (Service State Support) Different Services can support the same requirement (using different standards: HTTP, JXTA) Depending on the Application and context, some services will be better adapted than others (CMS, eCMS) An Application thus created is very flexible and easily put together User is responsible for resulting QoS

Tuesday, October 03, 2006© MCRLab 34 Future work Controlled environment Comparison with WS implementations Questions? THANK YOU!