The ABC architecture is a replicated architecture, which is a hybrid between a client-server and a peer-to-peer architecture.
The architecture is replicated due to the need for fast local responsiveness [cscw_book:greenberg] and the need for supporting pervasive collaboration, i.e. that users can continue working if the network is reduced or disappears. Hence, we want to utilize the local resource and continue to support uses while disconnected.
The key motivation for the hybrid architecture is the aim of combining the strengths of the client-server and the peer-to-peer architectures. Client-server communication is used for state management since maintaining state synchronization and consistency is inherently easier when using a central server for concurrency control [cscw_book:prakash]. However, for large amount of data traffic, the peer-to-peer architecture scale much better since no single host need to relay all data. In the ABC architecture we hence rely on the activity server to synchronize accountable information about the state of the ongoing activity sharing session, and we rely on a peer-to-peer setup for distributing the ephemeral event data from the session.
An example of accountable event data in the ABC platform is state information on the size and location of windows, whereas voice and telepointer data are examples of ephemeral event data. Looking at a typical activity sharing session between 2 users working for half an hour we have recorded the total amount of data floating between the clients and the server, and between the clients. These figures show that the vast amount of data (99%) floats in the peer-to-peer connections. This is our main motivation for using the hybrid architecture - use a server for maintaining consistency amongst state data and use a peer-to-peer setup for the large amount of voice and other collaboration awareness data.
In addition, the server is used for centralized session management which simplifies controlling and notifying participating users, and it is used for an easy handling of late-comers to a collaborative session.
The ABC architecture for activity-based collaboration is illustrated in figure 1 and consists of an infrastructure layer, a client layer, and an UI layer.
The infrastructure layer is responsible for storing (the Activity Store) and runtime management of activities (the Activity Manager), for collaborative activity sharing (the Collaboration Manager), and for handling context-information (the Context Service).
The client/OS layer resides on each device participating in the ABC deployment. This layer is a middleware layer between the user-interface and the infrastructure layers. The core component is the Activity Controller, which is responsible for controlling activities on the client and for communicating with the Activity Manager in the infrastructure layer. The State Manager is responsible for handling activity state when an activity is resumed and suspended on various clients. The Collaboration Controller is responsible for handling the collaborative activity sharing session, including peer-to-peer communication.
The UI layer contains plugable user-interface components for accessing the ABC infrastructure. For example, in the Windows XP client the Activity Bar replaces the Windows Taskbar and allows the user to e.g. suspend and resume activities, create new activities, and to navigate within activities. These operations are also accessible via a speech interface component. Different user-interfaces exist for different types of devices, like a desktop client, a wall-based client, a wearable client, or a table-based client. The UI layer also implements different collaboration widgets, like support for telepointers and voice links between participants in a synchronous activity sharing.
An important part of the ABC infrastructure is the use of a stateless protocol both in client-server and peer-to-peer communication. The Activity-Based Computing Protocol (ABCP) is modeled like the HTTP protocol - a stateless, string-based, unicast socket protocol with URI and URL string syntax.
Basically, ABCP can be divided into three parts. The first part is used for activity management, i.e. to GET, POST, and DELETE activities using the activity manager. The second part is a general-purpose publish-subscribe event mechanism where clients can subscribe to events and are notified on subsequent changes. This latter part of the protocol is used for collaborative event propagation, i.e. sending state change information and events on session changes, like when a particiapnt joins or leaves an activity. The third part of ABCP is dedicated to handling (storing and receiving) general-purpose resource information tied to an activity and hence a collaborative session. One particular important set of resources are the multicast group ID used in the peer-to-peer communication of ephemeral events.
The syntax of an ABCP request is:
ABCP/1.0 <method> /<argument>?(<key>=<value>&)*
For example, to get the last (latest) activity of a given user, the ABCP request is:
ABCP/1.0 GET /last_activity?user=bardram
To subscribe to notification events, the ABCP request is:
ABCP/1.0 SUBSCRIBE /host?name=firkin.daimi.au.dk&port=12345&activity=432&scope=meta
where the scope parameter is used to scope the amount of events. This is done to let devices with limited resources (network or cpu) to participate in collaborative sessions, but with reduced collaboration support. State and event information for accountable events use the Activity Markup Language (AML) which is an XML model for activity-based computing.
