Yet Another Framework for Supporting Mobile and ... - CiteSeerX

Yet Another Framework for Supporting Mobile and Collaborative Work Mauro Caporuscio and Paola Inverardi Department of Computer Science University of L’Aquila L’Aquila, Italy 67100 E-mail: caporusc, inverard @di.univaq.it


Abstract

In this paper we describe the design of a framework that offers services for supporting mobile collaborative work based on a publish subscribe system. The purpose of YACO (Yet Another Framework for Collaborative Work) is to exploit capabilities of the SIENA publish/subscribe system with support for mobile users for providing services to support collaborative work. SIENA has been designed for achieving scalability [6] and, since it has not native services for managing mobility of its clients, we enhance it by using M OBI K IT, a support service for mobile publish/subscribe applications [4]. The paper is organized as follows. Section 2 discusses related work on CSCW. Section 3 briefly introduces publish/subscribe systems detailing on SIENA and M OBI K IT. Section 4 presents services offered by YACO and its main features. Section 5 reports design details such as architectural decision and implementation choices. Section 6 discusses differences between YACO and MOTION. Finally in Section 7 we summarize our experience and discuss future work.

This paper presents the design of YACO (Yet Another framework for Collaborative work), a framework for supporting mobile collaborative work. Mobile collaborative work has been increasing in popularity in business domain. Coworkers cooperate and share expertise across sites and domains, employees may move from a location to another carrying devices (such as PDAs and laptops) in which they store documents. The YACO framework that we have designed aims at exploiting the capabilities provided by an event-based system with support for mobile application in order to offer services to users that collaborate each other in a corporate domain.

1 Introduction Computer Supported Collaborative Work (CSCW) has been defined as the study of how people work together using computer technology either in small groups or in large organizations. In this context new requirements have been posed by the technology evolution. In fact both the increasing performance of the wireless network and the shrinking size of devices push users to be mobile. For example, employees of a distributed organization may want to continue their work while moving from a location to another. Hence, CSCW is being pervasive and ubiquitous. That is, network connectivity is going to be a basic feature of CSCW facility and users have the ability of utilizing network services independently of their physical location. Publish/subscribe systems are considered good candidate in integrating loosely-coupled components in mobile computing [11]. Moreover, the publish/subscribe paradigm is increasing its popularity and there are many systems available on both market and academia. Notable examples are: CORBA Notification Service [10], Elvin [19], Java Message Service [20], JEDI [12], and SIENA [7].

2 Related Approaches on CSCW In this section we briefly mention existing tools developed to support collaborative work. For space reasons we cannot provide a more comprehensive survey. We have chosen these particular systems in order to point out that different architectural design have been used and experimented. Computer Supported Collaborative Work (CSCW) has been increasing its popularity and many systems have been proposed for providing CSCW services. They differ each other in the offered services and in the architectural design. For example, Khronika [18] is a centralized system implementing a client-server architecture; the Mocca [1] system proposes an architecture composed of a set of loosely connected components (called managers) which provide appropriate portions of cooperative support. MOTION [17] is oriented to manage user’s mobility and is based on an peer-to1

string Title System specification int Project substring(CWS) string Author M. Caporuscio string Title System specification int Project Yet another CWS

peer architecture. Since it is the closest to the system proposed in this paper, we will discuss the differences between YACO and MOTION in Section 6.

3 A Publish/Subscribe System with Mobility Services

Figure 2. A SIENA Filter and a SIENA Notification

A publish/subscribe system is a middleware communication service built on the idea of content-based networking [8]. That is, message delivering is driven by the message content rather than by explicit addresses specified by senders. A sender publishes messages, while receivers subscribe for messages that are of interest to them; the system is responsible for delivering published messages to matching subscribers. In the following sections we briefly introduce both SIENA and M OBI K IT. For a complete description of them, please refer to the citations reported below.

the model is a set of typed attributes. Each individual attribute has a type, a name, and a value, but the notification as a whole is purely a structural value derived from its attributes. There is a set of operators that are used in the filters provided by subscribers to specify a set of constraints over the attributes. Figure 2 shows a) a filter and b) a notification matching the filter.

3.2

3.1 SIENA: Scalable Internet Event Notification Architectures

M OBI K IT [4] has been designed to support the movement of clients between access points of a distributed publish/subscribe system. Moreover, M OBI K IT has been explicitly designed to be portable to different publish/subscribe platforms. Thus it can be adapted to the specific characteristics of the given publish/subscribe system.

SIENA [6, 7] is a publish/subscribe event notification service. As depicted in Figure 1, in the SIENA architecture two main entities may be distinguished: clients and servers. The servers are interconnected as a distributed network in order to achieve a scale suitable for large numbers of communicants and high volumes of notifications. Servers provide clients with access points offering an extended publish/subscribe interface. This interconnection of the servers represent the event-service. Servers that have no clients Publish/Subscribe System

P

Publish/Subscribe System

Message Routers

R R R

R

R

R

P

R

P

R R Clients

R P

P

Service Proxies

Message Routers

R R

Figure 3. Mobility Proxy Objects

R R

M OBI K IT: a Support Service for Mobile Publish/Subscribe Applications

R

R R R

R Clients

M OBI K IT supports mobility of publish/subscribe applications by managing subscriptions and publications on behalf of a client application, both while the client is disconnected and during the switch-over phase. The mobility service is implemented by using stationary components (called mobility proxy objects) that run at the access points of the publish/subscribe system (see Figure 3).

R

Figure 1. SIENA Architecture other than other servers act as pure routers. The clients are of two kinds: publishers, and subscribers. Publishers use the access points to publish the notifications and subscribers use the access points to subscribe for notifications of interest by supplying a predicate, called filter. A filter is applied to the content of notifications and it allows subscribers to select the events they are interested in. SIENA is responsible for selecting the notifications that are of interest to subscribers and then for delivering those notifications to the subscribers via the access points. Underlying SIENA’s interface is a notification data model that drives the semantics of the service. A notification in

message

message router

message

Proxy

client client interface

Figure 4. Disconnected Client States When a client decides to detach, it calls a move-out function from its local mobility interface. The move-out function transfers the stored subscriptions to its mobility proxy. 2

The proxy subscribes using all the subscriptions passed by the client, and then it stores all the incoming messages in a dedicated buffer (as showed in Figure 4). When the client reaches its destination, it uses a move-in function to contact a local proxy (termed a “move-in proxy” passing it the address of the remote proxy from which it detached (termed a “move-out” proxy). At this point, the local move-in proxy and the remote move-out proxy engage in a protocol that results in the transfer of all the subscriptions and all the buffered messages from the remote site to the local site, and then onto the client library.

a user can search them into the repository of the other YACO users. Each artifact into a repository has its own description and access rights (see Section 4.2). When a user performs a search, only artifacts matching its search parameters and access permission will be showed out. After the user has received a list of available artifacts, it can decide which one is of interest and download it through the file transfer service.

4 Exploiting Publish/Subscribe Capabilities for Achieving Collaborative Work

User Discovery: Users might be contacted for expertise. That is, a user may ask questions to a competent user in order to solve a given problem. In this context every user that is using YACO, exports its own profile with knowledge and personal data.

File Transfer Service: This service enables YACO users to download artifacts from the local repository of other peers.

As mentioned in Section 3, publish/subscribe systems are considered a good architectural style for enabling mobile computing. Even if many publish/subscribe systems are available and M OBI K IT has been designed for working with all of them, in this work we decide to use SIENA because it is scalable, simple to use, and lightweight. Our choice is based on previous experiences, in which we have studied and evaluated the performance of SIENA’s clients running on limitedresource devices [2] and, in wireless environment [3]. SIENA also provides two useful packages. SXML [5] that is a tool that automates the use of XML data within the SIENA publish/subscribe service; and a fast forwarding algorithm [9] that optimizes messages routing through the network.

Mobile and Stationary Users: Users may be either mobile or stationary. While stationary users are always online and do not need special services, YACO also offers features specifically addressed to manage requirements posed by mobility (i.e persistence of both messages and artifacts queries). Additional Entities: Other entities such as Data-Bases (DBs) or Concurrent Versions Systems (CVS), can be easily added. In fact they can be viewed as a stationary user that accepts requests and automatically replies by receiving and sending special messages through the YACO framework.

4.1 Services offered by YACO

4.2 A XML Definition for Profiles

The use of a publish/subscribe system as communication protocol enables users to be location unaware [16]. That is, users can share artifacts, can send and receive messages and can interact each other with no knowledge of where they are located. In fact, in this context users refer each other by using user-ID instead of host addresses. This frees users from the constraint of having fixed network-addresses and it is a powerful feature for mobile users that usually moves from a domain to another one by getting temporary addresses (such as in using Dynamic Host Configuration Protocol [14]). YACO offers a set of standard services like other CSCW systems:

Every user in YACO has its own repository that is used for storing artifacts. In YACO each artifact is composed by two distinguished parts: (1) a document and (2) the related profile. Artifact’s profiles are accomplished by using an XML definition. When a user stores a new document into the local repository a new artifact’s profile has to be built by using the User-Profile and the Document-Profile (as showed in Figure 5). This information is needed for publishing artifacts. It will be used to generate filters and notification. User Profile User Profile is used for storing information about YACO’s users. It contains information such as first and last name, affiliation, position, group membership, knowledge, etc. . .

Messaging: Users can send and receive messages. They can use messages for exchanging information, call for group meeting, ask for help, etc. . . Messages can be sent either to a single user, to a group of users or to all users.

Document Profile Document Profile is used for storing information about documents shared between YACO’s users. It contains information such as title, first and last name of the authors, description, access permission, etc. . . Since profiles are edited by using the XML [21] language, it is possible to use XML Schema [22] in order to

Distributed Search of Artifacts: Users can share artifacts and expertise. In order to retrieve artifacts of interest, 3

Mauro Caporuscio Ph.D. In Computer Science ...

Mobile Peer

Stationary Peer

High−Level Application

High−Level Application

CWS API

User Profile

Repository Messaging

Document Profile

Assembler

Assembler

sXML Artifacts Sharing

Search

Document Profile

User Profile

Document Profile

Messaging

Document Profile

Search

ci_dmc03.ps Yet Another Framework for Supporting Mobile Collaborative Worki ...

CWS API

Repository

sXML

Artifacts Serching

Artifacts Sharing

Messaging

Artifacts Serching

Messaging

MobiKit

Figure 5. An example of YACO profile

Siena

create different XML document’s structure. Thus, it is possible to configure profiles in order to adapt their content to the specific domain they refer (i.e. user’s data in a business domain usually differ to user’s data in educational domain).

Figure 7. YACO: Software Architecture. have the same internal SA for accessing YACO standard services. (1) a YACO API that provides: access to a localrepository that is used for storing shared artifacts; a search module that allows for performing distributed searches, a messaging component that allows users to publish and receive messages. (2) Assembler component that assembles the information and passes it to the sXML module. (3) the sXML module that acts as interface interpreting back and forth the communication between YACO and SIENA. (4) the SIENA layer is the communication layer and it is used for both artifacts sharing, and message exchange. Furthermore, on the Mobile-Peer side of Figure 7 an additional component called M OBI K IT can be distinguished. It provides the mobility support to the mobile-peers.

5 Developing the YACO Framework In this section we describe how we have been designing YACO, by detailing on architectural and implementation choices. We start from a high level view of a generic YACO application. Mobile Users

Fixed Users

DBMS

 

 

 







Team Work Servers

CVS

 

 

 

5.2 Services Implementation 

 












Messaging: The User edits messages by using the API. In editing a message, the user has to specify who is the destination of this message: user-ID (for point-to-point messages), group-ID (for point-to-multipoint messages), all user (for broadcast messages). Once a message has been edited, it is passed to the Assembler. The Assembler builds a document by composing the message and a subset of the User-profile (such as personal data) and, sends it through the sXML to the SIENA layers. Since all messages are delivered in content-based mode, YACO needs to explicitly manage the point-to-point messaging. In order to provide this feature, the YACO framework subscribes special filters (specifically addressed to force point-to-point delivering) that will drive notification from a sender to the specified receiver.

Figure 6. YACO:A possible scenario In Figure 6 three main entities can be recognized: YACOservers, stationary users and mobile users. YACO-servers are disseminated through the company network and provide communication services to the users. They represent the access points of the publish/subscribe service (refer to Section 3.1). Stationary users are either users that reside on fixed workstations or special entities such as Data Bases, CVS, etc. . . Mobile users are applications that reside on laptops or PDAs and can move from a site to another by switching their access point.

5.1

YACO Software Architecture

In this section we describe the role of each component present into the framework. Figure 7 depicts the software architecture (SA) of YACO framework. YACO is composed by servers and peers. Servers provide the communication services by means of SIENA access points and M OBI K IT proxies. Peers can be either mobile or stationary. They

Distributed Search of Artifacts: The User sets search parameters by using the YACO API. The parameters to set up are: document title, document authors, document topic, document group membership, etc. . . These parameters are passed to the Assembler that composes a document by join4

ing search parameters and a subset of the User-profile (such as group membership, affiliation). This document will be delivered to all peers that store artifacts matching both search parameters and access permission. Peers that receive this notification will automatically reply by advising for artifacts availability.

the matching algorithm. Furthermore, using only one communication protocol makes clients lightweight and, then portable to devices with limited resources. MOTION coordinates its clients by using services offered by the Global Virtual Data Structure (GVDS) coordination model contained in PeerWare. In GVDS each peer shares a set of data with the other peers. This set is completely managed by the middleware. In other hands YACO does not provide any explicit service for coordination, but peers can coordinate themselves through messages exchanging. Thus the framework does not need to manage any persistent knowledge and coordination is completely dynamic.

File Transfer Service: Once a user (artifact-retriever) has been advised that an artifact is available, it can decide to download the document. Inside the received notification there is the user-ID of the artifact owner (artifact-provider). Once the artifact-retriever decides to download the document, the download-request will be automatically sent to the artifact-provider by using the point-to-point messaging mode. The artifact-provider replies sending a point-to-point message that contains the requested artifacts.

7 Conclusions and Future Work In this paper we presented the architecture of YACO. YACO aims at exploiting Publish/Subscribe capabilities in a framework for collaborative working of mobile users. The goal of this system is to provide a lightweight and portable tool for corporate collaborative working. We have been building this system by using ideas and tools we have been developing during our past and current researches. YACO is a good case study to investigate and validate the use of M OBI K IT together with SIENA in real world, distributed and mobile applications. The work we have presented although still preliminary let us draw some considerations: (1) The use of a publish/subscribe system (such as SIENA) for both messaging and artifact sharing services, enables clients to refer each others only using User-ID independently of the location (host address). (2) The use of the sXML package on top of SIENA allows a high degree of adaptability to different contexts, in fact by means of XSchema, User- and Documentprofiles may be easily adapted to specific domains. (3) The use of M OBI K IT on top of SIENA frees users from the constraint to be always online. The services provided by M O BI K IT allow clients to disconnect and reconnect to the system without losing interesting events. The use of a single communication protocol allows clients’ devices with limited capabilities at the price of a certain abuse of the communication protocol. We believe that the latter can result in acceptable network overload and communication performance in the application context we refer to. Of course, on this side, more experimentation and in the field evaluation must be carried on. YACO is still in progress and we have been implementing an early prototype. Next milestones in this direction are to build a complete prototype and test it in both a wired and a wireless network. A side result of this work can also result in adjusting the design and implementation of both SIENA, M OBI K IT and YACO.

User Discovery: When a new user connects to the YACO framework, the entire community is advised by publishing an event containing the User-Profile. Users that are interested in this event will receive a notification informing about the new user. Users can also set the search parameters in which they specify expertise of interest. The search process is performed as in the artifacts case.

6

YACO and MOTION

In this section we briefly describe the main differences between YACO and MOTION. MOTION [17] (MObile Teamwork Infrastructure for Organization Networking) has been developed with the intent to offer services for mobile collaboration. The MOTION system is composed of peers that communicate each other by using services offered by a middleware called PeerWare [13]. PeerWare offers basic communication services such as peer-to-peer file sharing and publish/subscribe mechanisms. Services offered by MOTION are: artifact storing in local repository, resource searching and sharing, messaging, system events subscribing. MOTION also offers a service for managing access rights on resources provided by using DUMAS [15], an access control component. As mentioned above MOTION is based on PeerWare. In PeerWare communication in achieved using both publish/subscribe and peer-to-peer architectures. MOTION uses publish/subscribe for messaging and peer-to-peer for artifacts sharing. Conversely, YACO uses a publish/subscribe system for providing both services. One can argue that this is a protocol abuse and the entire system may lack of performance. On the contrary we think that this choice does not heavily affect performances of the system. First we are in corporate domains thus with limited number of peers and servers and, large network bandwidth. Second, the files embedded into events are not considered by 5

Acknowledgment

[10] Notification Service, Aug. 1999.

The authors wish to thank Alexander L.Wolf and Antonio Carzaniga for their contribution to the work described in this paper. This work has been partially supported by progetto MIUR SAHARA.

[11] G. Cugola and E. Di Nitto. Using a publish/subscribe middleware to support mobile computing. In Proceedings of the Workshop on Middleware for Mobile Computing, in association with IFIP/ACM Middleware 2001 Conference, Heidelberg, Germany, Nov. 2001. [12] G. Cugola, E. Di Nitto, and A. Fuggetta. The JEDI event-based infrastructure and its application to the development of the OPSS WFMS. IEEE Transactions on Software Engineering, 27(9):827–850, sep 2001.

References [1] S. Benford, J. Mariani, L. Navarro, W. Prinz, and T. Rodden. MOCCA An Environment for CSCW Applications. Technical Report CSCW/14/92, Centre for Research in CSCW, Lancaster University, 1992.

[13] G. Cugola and G. Picco. PeerWare: Core Middleware Support for Peer-To-Peer and Mobile Systems. Technical report, Politecnico di Milano, May 2001. Submitted for Publication.

[2] M. Caporuscio. CoMETA - Mobility Support in the Siena Publish/Subscribe Middleware. Master’s thesis, Universit`a degli Studi dell’Aquila - Dipartimento di Informatica, L’Aquila, Italy, Mar. 2002.

[14] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, Mar. 1997. [15] P. Fenkam, H. Gall, G. Reif, and E. Kirda. A Dynamic and Customizable Access Control System for Distributed Applications. Technical report, Distributed System Group, Technical University of Vienna, Dec. 2001.

[3] M. Caporuscio, A. Carzaniga, and A. L. Wolf. An experience in evaluating publish/subscribe services in a wireless network. In Third International Workshop on Software and Performance, Rome, Italy, July 2002. [4] M. Caporuscio, A. Carzaniga, and A. L. Wolf. Design and evaluation of a support service for mobile, wireless publish/subscribe applications. Technical Report CU-CS-944-03, Department of Computer Science, University of Colorado, Jan. 2003. Available at http://www.di.univaq.it/ caporusc/mobikit. [5] A. Carzaniga and J. Giacomoni. http://www.cs.colorado.edu/serl/siena/sxml.

[16] P. Fenkam, E. Kirda, S. Dustdar, H. Gall, and G. Reif. Evaluation of a publish/subscribe system for collaborative and mobile working. In Proceedings of the Eleventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 02), 2002.

sXML.

[17] E. Kirda, P. Fenkam, G. Reif, and H. Gall. A service architecture for mobile teamwork. In Proceedings of the 14th international conference on Software engineering and knowledge engineering, Ischia, Italy, 2002.

[6] A. Carzaniga, D. S. Rosenblum, and A. L. Wolf. Achieving Scalability and Expressiveness in an Internet-Scale Event Notification Service. In Proceedings of the Nineteenth Annual ACM Symposium on Principles of Distributed Computing, pages 219–227, Portland, OR, July 2000.

[18] L. Lovstrand. Being selectively aware with the Khronika System. In Proceedings of the 6th European Conference on Computer Supported Cooperative Work - ECSCW’91, Sept. 1991.

[7] A. Carzaniga, D. S. Rosenblum, and A. L. Wolf. Design and Evaluation of a Wide-Area Event Notification Service. ACM Transactions on Computer Systems, 19(3):332–383, Aug. 2001.

[19] B. Segall and D. Arnold. Elvin has left the building: A publish/subscribe notification service with quenching. In Proceedings of AUUG97, pages 243–255, Brisbane, Australia, Sept. 3–5 1997.

[8] A. Carzaniga and A. L. Wolf. Content-based networking: A new communication infrastructure. In NSF Workshop on an Infrastructure for Mobile and Wireless Systems, Scottsdale, Arizona, Oct. 2001.

[20] Sun Microsystems, Inc., Mountain View, California. Java Message Service, Nov. 1999.

[9] A. Carzaniga and A. L. Wolf. Fast forwarding for content-based networking. Technical Report CU-CS922-01, Department of Computer Science, University of Colorado, Nov. 2001.

[22] World Wide Web Consortium. XML Schema. http://www.w3c.org/XML/Schema.

[21] World Wide Web Consortium. Extensible Markup Language (XML). http://www.w3c.org/XML.

6