3. Architectural Styles 10
Components including code that directly supports collaboration are called collaboration
aware; those without such code are collaboration transparent. The model allows either type
of component to appear at any location in the hierarchy.
2.4 Discussion
Seeheim, Arch, and Dewan’s generic architecture all model systems as a series of layers
going from concrete at the physical interface to abstract at the functional core. In Arch
and Seeheim there are three main layers concerned with physical interaction, the control
of dialogue, and semantic aspects of the application’s data structures. The adapter layers
simplify the main layers and permit them to be constructed in relative isolation. In Dewan’s
model an arbitrary number of layers is permitted.
These models support the well-accepted software engineering principles of modularity
and separation of concerns. Allocating the functions of a given layer to a pre-existing com-
ponent promotes reuse. Judicious use of the models is expected to reduce total application
complexity and lifecycle cost; while there are no empirical studies demonstrating the truth
of this conjecture for these models in particular, there is some evidence that it does hold for
layered architectures in general [120].
Some groupware development efforts have been guided by the principles enshrined in
these models [33, 104]. Arch has been used as the basis for a study of single-user interactive
systems [72] and Dewan has characterized the architectures of a number of groupware
systems using his generic model [40].
Patterson’s taxonomy usefully clarifies the patterns of state sharing and replication
found in groupware systems but ignores distributed computation aspects. In section 4.1
we introduce a new framework to permit exploration of these issues.
All of these reference models propose structures or ways of looking at entire applica-
tions in a relatively coarse-grained fashion. In the next section we look at architectural
styles, which provide patterns for application development at a much finer level of detail.
3 Architectural Styles
An architectural style suggests a vocabulary of component and connector types, a topology
of interconnection, and a control flow strategy. Ideally, an architectural style will provide
the developer with a clear mental model for the system under development, will provoke
appropriate questions at an early stage in the development process, and will provide direct
operational answers to those questions [21]. For groupware the key question centers around
how to build systems which allow multiple users to concurrently interact with each other
and with shared data.
In this section we present a selection of architectural styles for groupware which strive
to answer this question. There have been a wide range of such styles proposed, practically
one for every groupware application, system, toolkit or programming language. Here we
include those styles which are influential and widely known as well as a limited number of
more recently proposed styles.
Most architectural styles for groupware are based on the same separation of user inter-
face and application seen in the Seeheim model (section 2.1). However, where Seeheim