Evaluating Collaborative Infrastructure for CSCW Apps Grid/Web Services

1. Evaluating Collaborative Infrastructure for CSCW AppsGrid/Web Services COMP 790, Fall 2006 Collaborative Systems

2. References • CoFrame: A framework for CSCW Applications based on Grid and Web Services • Jinlei Jiang et al, Proceedings of IEEE International Conference on Web Services (ICWS 2005) • Developing Collaborative Editing Applications using Web Services • Muhammad Younas, Rahat Iqbal, Coventry University, Coventry, UK • Improving Network Efficiency in Real-Time Groupware with General Message Compression • Carl Gutwin et al CSCW 2006 • A Collaborative Infrastructure for Aerospace Design • http://ic.arc.nasa.gov/people/filman/text/darwin/ace.pdf • A Collaborative Infrastructure for IM applications • http://www.imlogic.com/ • A Collaborative Infrastructure for Scalable and Robust News Delivery • http://doi.ieeecomputersociety.org/10.1109/ICDCSW.2002.1030843

3. Collaborative Infrastructure • CSCW Applications and Infrastructure • Are they the same ? • What is a CSCW Application: • N-user software • Example: Chat Tool

4. CSCW Infrastructure • Higher Level of abstraction that provides application developers a framework to build CSCW applications. • Example: • We have already used one: • “Sync”: A Java based framework for developing collaborative applications

5. Evaluating Criteria

6. Features Supported / Flexibility • NewsWire collaborative content delivery system • Deals with real-time delivery of news items • Reduces Compute/Network load • DARWIN • Collab Infrastructure for AeroSpace Design • Issues such as: wind tunnel testing data • Focus: • Storing/Indexing data • Manage visualizations for stored/derived data • IMLogic • IM Application development infrastructure • Drawbacks • Specific to one application. • Deal with some core issues but not all • Alternatives: • Sync (Framework for Collaborative Applications) • Web Services and Grid Computing

7. Features supported – Grid/Web • Provide Core Services and additional services • Core Services: • Communication • Cooperative Message Bus (CMB) • RMI (Sync Equivalent) • SOAP (Simple Object Access Protocol) • Additional Services: • Process Management Service • Awareness Support Service • Interaction-Aided Service • Directory Service • UDDI (Universal, Description, Discovery and Integration) • Central Registry (similar to UDDI) • RMI registry (Sync) • Persistence Visual Cooperation space facility • Easier to add new functionality as it gets added as another service in the framework

8. Programming Model (Environment) • Grid Computing • Use existing infrastructure to manage data, resources and to collaborate to solve a large scale problem. • Use multiple computer (resources) to build a Virtual computer architecture • Open unlike Sync (closed)

9. Programming Model (Environment) • Scalability • Firewalls • Description of Services: • CoFrame: WSDL (Web Services Description Language) • Sync: Java • Coding Language • CoFrame • Sync • Globus Toolkit 3 • OpenSource • Industry Standard

10. Programming Cost (Transparency) • Developers need to only concern themselves with services being offered and not how the services are implemented. • CoFrame Architecture: • Grid layer separates Application layer from Resource layer • Younas/Iqbal doesn’t provide such an abstraction. • Sync (Integrated RMI)

11. Consistency of Data • Younis/Iqbal propose a transaction based model similar to ACID concepts • ACID (Atomic, Consistent, Isolated, Durable) • SACReD • CoFrame doesn’t mention Consistency of data but the SACReD approach can be implemented in the CMB part of the framework

12. Fault Tolerance • Central server easier to secure (one point of failure) • Grid Architecture (Distributed) • CoFrame provides for: • Single Sign On Service

13. Resource Optimization • Bottleneck : Network Bandwidth and Latency • Effects: • Deterioration of user experience • Example: • Video Chat with video frame updating every two seconds • How to Fix this: • Improve resources • Better network layout • Optimize current resources • Message Compression • Resource Replication Policy

14. Resource Optimization:“Message Compression” • Why Needed ? • Collaborative applications share a lot of data. • Inter-collaborative application messages • Example: • Dragging a window across screen • Updates need to be sent consistently to all connected clients • Use of XML • Message must include: • Sender id, message id, application id, timestamp, message type, fieldnames and data values corresponding to each field • Send messages less frequently ? • Encoding before sending, decoding on receiving • Gutwin proposes a mix of Ziv-lempel algorithm, Huffman Coding and building a dictionary of sequences with short lookup codes.

15. Message Compression • Sources of Inefficiency in Groupware messages • Repetition Within a single message • Repetition between messages • Inefficient Coding • Encoding of numbers. • Field widths for numeric data types.

16. Message Compression - Algorithm • Within-Message Issues: • Use standard zlib algorithm • Helpful when sending large messages • Between-messages Compression • Treat one message as template • Compare subsequent against that template, to determine repeated sequences • Replace repeated sequences by codes in a dictionary • Create new templates if messages not similar

17. Resource Replication • Replication of resource • Backup of Data • More optimized – can serve from best source • Centralization of resource • Easier to implement • Grids are distributed in nature • Replication model proposed by CoFrame

18. Resource Replication • Resources stored independent of working nodes • Provider publishes to one server • Broadcast message using CMB to store metadata

19. Heterogeneous Systems • CSCW Application built for different resources • Example: Two collaborators (A & B) connected using two different devices • A has good Network (Cable/DSL) while B is on a relatively poor network (Dialup) • Both on a Video Chat or using a 3D graphics application • Compression of data • Lower bit-rate

20. Conclusion