1. Introduction 3
1 Introduction
1.1 Groupware
Synchronous groupware systems allow physically separated users to interact with one an-
other and with shared computational objects in real time. This contrasts with single-user
systems, where there is neither inter-user interaction nor object sharing; with asynchronous
groupware, where the interaction or object sharing is normally not immediate; and with
multi-user databases, where user interaction is a side-effect rather than a goal. Synchronous
groupware applications include shared virtual whiteboards, multi-user editors, distributed
brainstorming tools, and real time network games [51].
The users of a synchronous groupware system may be co-located, as in a meeting sup-
port system, or physically distributed, as in a distance education application. If co-located,
the users may be using a single computer system or several. In this paper we assume the
distributed, multiple-computer case as the default, although most of the presentation applies
equally to systems with co-located users.
Building synchronous groupware (which we will refer to simply as “groupware”) presents
a number of special challenges. First, groupware systems typically have significant user in-
terface components, and user interfaces are notoriously difficult to “get right” [58, 103].
Second, they are distributed systems, which means that issues of resource sharing, concur-
rency, scalability, fault tolerance and transparency must be addressed in their design [30].
Third, groupware user interfaces are themselves distributed and must support the actions of
multiple, concurrent users, which combines and exacerbates the first two difficulties [63,
88]. Further discussion of groupware issues can be found in a collection written and edited
by Baecker et al. [6], especially a contained paper by Ellis, Gibbs and Rein [51].
1.2 Architecture
The intrinsic difficulty of producing groupware applications has led to a wide range of de-
velopment approaches. Some of these are primarily architectural in nature: that is, they seek
to make groupware simpler to develop by proposing and codifying structures appropriate to
the problem domain [101]. These codified structures are called architectures. In this paper
we present some of the more widely recognized architectures for groupware, organizing
them into three distinct architectural views [8]:
Reference models. Reference models specify the complete structure of some class of sys-
tem at a relatively large granularity. This is typically done by creating a conceptual
structure consisting of a small number of named functional elements and well defined
data flow between those elements. One example is the classical model of a compiler
which breaks the system down into a series of phases, beginning with a lexical ana-
lyzer and ending with a code generator, supported by a symbol table manager and an
error handler [3]. A successful reference model will allow a wide range of existing
systems to be easily mapped onto it, and will provide useful insights into the prop-
erties of those systems. It may also suggest new approaches to system development
in its domain of application. In section 2 we present several reference models which
have been proposed for groupware.
