GENERIC ARCHITECTURE

  
Figure 9.2: Generic architecture.

Figure 9.2 shows a generic collaboration architecture for implementing the model described above. It is a generalization of the architecture Patterson proposed at the CSCW'94 workshop on ``distributed systems, multimedia and infrastructure support in CSCW'' [Dew94] that makes fewer assumptions about collaborative applications. As we shall see later, this architecture can be instantiated to multiple specific architectures.

The architecture assumes that a user's input/output is processed by a hierarchy of layers. A lower-level layer (that is, a layer closer to the user) manages objects that are interactors of objects in the immediately higher-level layer. We will refer to the latter as abstractions of the former. An interactor of an abstraction creates a presentation of the abstraction, which contains a transformation of the information in the abstraction (e.g. a text field representing an integer, or a bitmap representing a text field ) plus some additional information serving as ``syntactic sugar'' (e.g. a label field or a window scrollbar). Thus, perceptible renderings of abstractions are created by applying the presentation operator successively to their interactors, and the interactors of these interactors, and so on. An abstraction can have a variable number of interactors, which may change dynamically as users create or delete renderings of the abstraction.

The layers communicate with each other using events. Often, this term implies that the communication is sent asynchronously by the sender to the receiver. However, we will use it here in a more general sense and allow the information to be retrieved synchronously from the sender by the receiver. We divide events of a collaboration application into interaction events and collaboration events based on whether they support single-user or collaboration semantics. An interaction event may be an output event or an input event depending on whether it is sent to a lower or upper-level layer.

Abstractions send output events to their interactors and receive input events from the latter. Output events received by objects from their abstractions may be transformed into lower-level events before they are sent to their interactors. Conversely, input events received by objects from their interactors may be transformed into higher-level events before they are sent to their abstractions. Not all input events received by interactors need to be sent to their abstractions - in particular, events that request manipulation of local syntactic sugar. Moreover, not all output events transmitted down by interactors are triggered by output events received from their abstractions. These include not only those events that change local syntactic sugar but also those that generate local echo/feedback in response to requests for changing the higher-level state in the abstraction.

A collaboration event may be a copy or extension of an interaction event or it may be an entirely new kind of event. It may be sent not only to a lower-level and upper-level layer but also a cross layer, that is a layer in an another branch, as shown in the figure.

Some levels in this architecture are shared while others are versioned or replicated. A shared level is associated with a single, shared layer that processes the input/output of multiple users of the application, while a versioned or replicated level is associated with a private layer for each user of the application, which processes the input/output of only that user and collaboration events concerning the user. An object in a private layer is private while an object in a shared layer is shared by multiple users. We refer to the collection of all private objects of a user and the shared objects accessible to the user as the interaction state of that user. All levels below a private level are constrained to be private levels and all levels above a shared level are constrained to be shared levels. Thus, the architecture defines a tree of layers rather than a general graph. We refer to this tree as a protocol tree in analogy with the related networking concept of a protocol stack. We refer to the lowest shared layer as the base, the highest versioned layers as branch points, the base and all layers above it as the stem, and a branch point and all the layers below it as a branch of the architecture. Moreover, we refer to all private layers at a certain level as peers or replicas of each other.

An abstraction may have interactors in zero or more replicated layers. We refer to the different interactors of an abstraction as replicas, peers, or versions. In general, they can create different logical presentations of the abstraction. However, in most current collaboration architectures, they create different physical replicas (for different users) of the same logical presentation. It is for this reason, we have used the term ``replica'' for a peer interactor and layer, though strictly speaking, the term ``version'' is more general. In the rest of the discussion, we will use these terms interchangeably. It is important to note that an interactor in a layer may not have a peer interactor in a peer layer, since not every layer creates an interactor for an abstraction in the layer above.

Abstractions and interactors may not only transform interaction events but also control the interaction by checking access rights, consistency, and other constraints. Unlike the Smalltalk Model-View-Controller paradigm [KP88] but like the abstraction-view paradigms supported by InterViews [LVC89], Rendezvous [HBR94], PAC [Cou87], and several other frameworks, we do not treat the transformation and control components as separate objects. Similarly, unlike the Clover model [Sal95], we do not differentiate among the different collaboration functions implemented by an abstraction or interactor, clubbing them all in one multi-function object. Furthermore, unlike the PAC model, we do not capture the structure of a hierarchical abstraction or interactor, modelling it as a single unit. We do not assume that an abstraction or interactor is actually implemented as a programming language object. Similarly, we do not assume that an architectural event is actually implemented as a programming event. It may be sent in response to the evaluation of a programming constraint or some other higher-level computation that is not explicitly aware of events. Programming issues are beyond the scope of this discussion since we are focusing here only on architectural issues.

The bottom-most layers in this architecture are the workstation (operating system and hardware) layers managing the screen and input devices attached to a workstation. The workstation layers are usually replicated to allow the collaborators to use different workstations. A notable exception is MMM [BF91], which allows a single workstation layer to be shared by multiple users concurrently manipulating the same screen using different input devices.

We refer to the topmost layer in the architecture as the semantic layer and the abstractions in this layer as semantic objects. Unlike a lower-level object, a semantic object is not itself an interactor for another object. However, like an interactor, a semantic object in a replicated layer may have peers or replicas in peer layers. Peer semantic objects are (the highest-level) computer representations of the same user-level abstract object.

Not all application modules are layered in the protocol tree shown in the figure. We refer to such modules as external modules. The layers and modules in a collaboration architecture include both application components implemented by the application programmer, and system components provided by an infrastructure or tool. When characterizing the ``architecture'' of a collaboration tool, we will, in fact, be characterizing those aspects of the architectures of clients of the tool that are defined by the tool. An individual client may refine this architecture by adding further layers and modules.