A Peer-to-Peer Middleware for Mobile TeamWork

by Carlo Ghezzi, Gianpaolo Cugola, and Gian Pietro Picco

The advantages of a peer-to-peer architecture go well beyond the realm of Internet file sharing, becoming crucial in supporting business processes and especially collaborative work involving mobile users. To support this view, we designed and experimented with PEERWARE, a core communication middleware for TeamWork applications.

Collaborative work is intrinsically peer-to-peer in nature. Members of a team typically interact directly with each other, each responsible for a given set of documents and carrying with them the subset relevant for discussion. On the other hand, most of the currently available tools supporting collaboration exploit a rigid client-server architecture.

This results in an 'architectural mismatch' between the external view provided by the application and its internal software architecture. The effect of this mismatch is a lack of flexibility in carrying out the interactions, which must all be funneled through the server. This limitation is even more evident when mobility becomes part of the picture. People need to communicate and collaborate even while in movement, and independently of their location. However, in similar situations, server access is often prevented by technical or administrative barriers.

We argue that a peer-to-peer approach holds significant advantages over traditional client-server architectures. When a peer-to-peer architecture is adopted, data and services are no longer gathered in a single point of accumulation. Instead, they are spread across all the nodes of the distributed system. Users may directly host the resources they want to share with others, with no need to publish them on a particular server.

Interestingly, these features are relevant not only in mobile scenarios but also in fixed ones, where the decentralized nature of a peer-to-peer architecture naturally encompasses the case of multisite or multicompany projects, whose cooperation infrastructure must span administrative boundaries, and is subject to security concerns.

Unfortunately, most of the peer-to-peer applications developed in recent years started from premises that are rather different from those outlined thus far. They target the Internet and aim at providing peer-to-peer computing over millions of nodes, with file sharing as their main application concern. The difference in perspective from the domain of collaborative work is made evident by their search capabilities, which typically do not guarantee to capture information about all matching files. In most cases they do not take into consideration features like security or the ability to support reactive interactions, which are crucial in cooperative business applications. Moreover, they bring peer-to-peer to an extreme, where the logical network of peers is totally fluid, and none can be assumed to be fixed and contributing to the definition of a permanent infrastructure. This radical view prevents access to resources exported by non-connected peers, which is unacceptable in the business world, where critical data is often required to be always available, independently of its owner.

PEERWARE
On the basis of the above considerations, we have developed PEERWARE: a peer-to-peer middleware for teamwork support specifically geared towards the enterprise domain.
PEERWARE is both a model and an incarnation of this model in a middleware. In developing both, our first concerns were minimality and flexibility.

The Model
The PEERWARE coordination model exploits the notion of a global virtual data structure (GVDS), which is a generalization of the LIME coordination model. Coordination among units is enabled through a data space that is transiently shared and dynamically built out of the data spaces provided by each accessible unit.
The data structure managed by PEERWARE is a hierarchy of nodes containing documents, where a document may actually be accessible from multiple nodes, as shown in Figure 1. This structure resembles a standard file system, where directories play the role of nodes, files are the documents, and Unix-like hard links are allowed only on documents.

Figure 1: The data structure provided by PEERWARE.

When a peer is isolated, it is only given access to its own tree (stored locally) of items (ie, nodes and documents). However, when connectivity with other peers is established, the peer has access to the virtual tree constructed by superimposing the trees contributed by all the peers in the system, as illustrated by Figure 2.

Figure 2: Building the GVDS in PEERWARE.

In search of minimality, PEERWARE provides only three main operations to operate on the GVDS:

• the execute operation allows peers to execute an arbitrary piece of code on a selected set of items held by connected peers. The results are collected and returned to the caller
• the subscribe operation allows peers to subscribe to events occurring on a selected set of items, while
• the publish operation allows peers to notify the occurrence of events.

By exploiting these primitives, peers can query the GVDS and also subscribe to events and receive the corresponding notifications. The hierarchical structure of the GVDS provides a natural scoping mechanism, thus leading to an efficient implementation of searches.

The Middleware
Currently, the PEERWARE model has been implemented in two middleware: one, developed in Java, has been used as the core of the MOTION platform, the other, developed in C# under the Microsoft .Net infrastructure, is the core of the PeerVerSy configuration management tool.

Both implementations are tailored to the business domain and distinguish between a set of permanently available backbone peers, and a fringe of mobile peers, which are allowed to connect and disconnect as required. To optimize routing, these peers are connected to form an acyclic graph in which the mobile peers represent the leaves, as shown in Figure 3.

Figure 3: The PEERWARE run-time architecture.

Access control and security are critical issues in the domain we target and they are addressed by two separate modules. One provides mechanisms to establish encrypted channels among peers and to manage the security information necessary to authenticate a peer. The other embeds the actual security policy that determines the capabilities of a given peer.

To increase flexibility, the functionalities provided by the security modules and also by the repositories holding local documents are sharply decoupled from the specific implementation provided for these functionalities. Thus, the security protocols, as well as the format of the security information used to perform authentication, and the repository effectively used can be changed easily, eg, to adapt them to the common practice of a specific business environment.

Conclusions
Collaboration defines a scenario where interaction is intrinsically peer-to-peer. We exploited this idea by developing PEERWARE, a peer-to-peer middleware explicitly tailored for collaboration. The model of collaboration adopted by PEERWARE is minimal but expressive enough to support complex collaboration schemes, including both reactive and proactive interactions. Current incarnations of this model in a middleware have been tailored to the domain of enterprise-wide collaboration. We are now working on a different implementation oriented toward more dynamic scenarios, including ad-hoc networks.

Links:
PEERWARE: http://peerware.sourceforge.net
PeerVerSy website: http://sourceforge.net/projects/peerversy/

Please contact:
Gianpaolo Cugola, Politecnico di Milano, Italy
Tel.: +39 022 399 3493
E-mail: cugola@elet.polimi.it