The ABC framework supports long-term pervasive collaboration by providing support for asynchronous and synchronous activity sharing. By modeling human activities as first-class computational entities in the architecture and the user interface, we have enabled activity-based collaboration where;
An important issue in the design of a collaborative system is its architecture, which determines the nature of the components of the system and the placement of these components on the computers of the various users participating in a collaborative session. Archetypical architectural patterns are the centralized, the replicated, the client-server, and the peer-to-peer architectures.
The ABC collaborative features are enabled using two different strategies, depending on the environment surrounding the client. Either a hybrid collaborative architecture, utilizing a central server for state events are used, if the client has access to a server.
This architecture builds on a basic differentiation between what we have termed accountable and ephemeral events. In replicated collaborative architectures – which the ABC environment is an incarnation of – concurrency control between events on distributed clients is absolutely central in order to maintain correct behavior of the collaborative systems. We use the term ‘accountable’ for this kind of distributed events, because the system needs to be accountable for the correctness and timing of these events in order to function as a well-behaved collaborative system.
There are, however, a range of other kinds of events which are not subject to the same kind of accountability. Such events are typically absolute values, independent of previous and subsequent events, and may even be missing or dismissed without adverse effects. We call these events ‘ephemeral’ because they are short-lived and transient.
We use the differentiating of events to route accountable traffic which comprises very little of the overall traffic through a server, while ephemeral traffic (the vast majority) is multicasted directly between clients.
If there is no server in the environment, collaboration is enabled using a pure peer-to-peer architecture, thereby enabling a collaborative session anytime and anywhere.
The Peer-to-Peer architecture builds on the concept of peer-to-peer distributed shared Object. These objects are physical distributed objects, e.i., instead of viewing a distributed object as an entity running on a single host with others accessing it remotely, we physically distribute a copy of the object to all hosts using this object in an application. Hence, applications access and use objects as local objects which ensures fast responsiveness. Objects are distributed on creation (remote instantiation) and removed from the local address space on deletion (distributed garbage collection).
The state of the distributed shared object is kept synchronized in real time, if possible. Hence, state changes are propagated to all object replicas. State synchronization is handled by the underlying infrastructure, but the objects themselves are involved in potential conflict resolution, using domain specific conflict resolution algorithms.
Physically distributed objects rely on a peer-to-peer – or object to object – synchronization strategy. Hence, no central entities like an object broker or an object registry are involved in object registration or lookup. Each object is responsible for looking up and synchronizing with its replicas. This principle makes distributed programming simple from the developers point of view since there are no configuration overhead associated with the development and deployment of a distributed application.
We have built several collaboration widgets, including tele-pointers and voice-links, which can be readily integrated into front-end implementations in the UI layer. Also, implementing new widgets are easily done by extending a base widget class, defining the input- and output channels, which types of traffic they consume/produce, and any visible user-interface elements.
Asides from the widgets the user-interface exhibits the zoom and radar views which supports a peripheral spatial awareness by allowing a user to overview a greater area of desktop-space than is available to see on the screen. Both the zoom and the radar functionality only manipulate the local viewport, which means that two (or more) users collaborating in the same activity can partition the virtual canvas of the activity, work in different applications and maintain a peripheral awareness of what the other users are working on.
