Design of Distributed Collaborative Application through Service Aggregation Andrew Roczniak...

Design of Distributed Collaborative Application

through Service Aggregation

Andrew Roczniak

Multimedia Communications Research Lab

University of Ottawa, Ottawa, Canadahttp://www.mcrlab.uottawa.ca

http://www.mcrlab.uottawa.ca/

http://www.mcrlab.uottawa.ca/

Tuesday, October 03, 2006 © MCRLabhttp://www.mcrlab.uottawa.ca

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


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


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


5

General Architecture

Application

Functionality A Functionality B Functionality C

Service State Support

Service A Service B Service Z

Service Interaction Interface


6

Required Functionalities

Collaborative Authoring requires Group Communication

Group notification (event notification) Bulk transfer (large files)

Document consistency


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

Gateway

Jabber Client

Jabber Server Jabber Server

Jabber Client

Peer

Jabber Client

Yahoo!


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.


9

Matching Functionalities with Technologies

Group Notification

Bulk transfer

Data consistency

HTTP Jabber JXTA

Group notification + presence information + distributed lock mechanism


10

Implementation

Collaborative Authoring Application

BulkTransfer

GroupNotification

DataConsistency

ExtendedCMS

RendezvousPeerWeb Server Presence

JabberServer

Locks

Client/ServerClient/Server Peer-to-Peer

Jabber ProtocolsHTTP JXTA

JabberHTTP JXTA


11

Implementation

Collaborative Authoring Application

BulkTransfer

GroupNotification

DataConsistency

ExtendedCMS

RendezvousPeerWeb Server Presence

JabberServer

Locks

Client/ServerClient/Server Peer-to-Peer

Jabber ProtocolsHTTP JXTA

JabberHTTP JXTA


12

Implementation (and rest of the presentation)

ExtendedCMS

Locks

Distributed lock mechanism based on group notification and presence information

Improves performance in certain circumstances


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


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


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


16

Clock Synchronization Algorithms

Centralized Algorithms Cristian’s Algorithm Berkeley Algorithm

Decentralized Algorithms Averaging Algorithms (e.g. NTP) Multiple External Time Sources


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


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


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


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


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


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


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


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


25

Jabber Setup


26

Results


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.


28

JXTA Setup

Fast Peers

Slow Peers

Ethernet Ethernet

Ethernet

JXTA Client

JXTA Client

JXTA ClientJXTA Client

JXTA Client

JXTA Client

SourceRV Peer

JXTA Client


29

Bulk Transfer – JXTA+CMS


30

Bulk Transfer - eCMS


31

Bulk Transfer


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.


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


34

Future work

Controlled environment Comparison with WS implementations Questions?

THANK YOU!

Design of Distributed Collaborative Application through Service Aggregation Andrew Roczniak...

Documents

Transcript of Design of Distributed Collaborative Application through Service Aggregation Andrew Roczniak...