The architecture of a software application characterises the components of the application, the function implemented by each component, and the interaction among these components [SG96,KBAW94]. It is an important issue in the design of the application since it influences the performance, ease of modification, and other properties desired by users and programmers of the application. It is also a difficult issue to resolve since decomposing a large problem into smaller parts is a challenging task: There are a number of different ways in which this decomposition can be done, and the consequences of choosing different decompositions are not always apparent.
For these reasons, a new discipline of computer science has emerged to help programmers choose architectures for software applications [SG96]. The architectural techniques developed so far either apply to general software applications or are tied to specific functionality such as database management [SG96] and user-interface support [SG96,Bas93]. We address here the domain of collaborative applications by describing the influence of collaboration support on the architecture of an application.
We consider five kinds of components of a collaborative application: modules, layers, threads, processes, and replicas. These components occur in both collaborative and non-collaborative applications but the collaboration domain introduces special techniques for decomposing an application into these components. We do not identify the exact functionality of these components, since it depends on application semantics. Instead, we simply classify them according to whether or not they implement collaboration-specific functionality. Similarly, we do not identify the exact events communicated among these components. Instead, we distinguish among them based only on whether or not they carry collaboration-specific information.
We characterise the design space of collaboration architectures by presenting a generic architecture that captures properties common to the points in this design space, and a set of dimensions that represent the differences among these points. We identify different choices along each of these dimensions and evaluate these choices by discussing their influence on properties desired by programmers/users. We consider several generic properties such as ease-of-modification and performance that have been identified by previous work on software architectures. In addition, we consider the special case of reuse of existing single-user code, an important goal in the design of collaborative applications.
To better explain the scope of this work, it would be useful to identify what we are not addressing here. We are not considering the functionality of a collaborative system, which is covered in [DCS94,OMKO93] and the accompanying discussion on shared editors by Prakash. Moreover, we are not describing tools/infrastructures for implementing collaborative applications, some of which are surveyed in the accompanying discussion on toolkits by Greenberg and infrastructures by Dourish. We envision the process of developing a collaborative application to consist of three main steps: (1) design the functionality, (2) decompose the application into components, and (3) use tools for implementing the components. We are looking at only step (2) of this process. Naturally, these steps are not independent. For instance, the choice of the architecture may depend on the functionality desired, and a tool is typically tied to a particular architecture. We will look at these relationships but will not examine in-depth the functionality and tools issues, per se. A preliminary discussion of these concepts was presented at a conference [Dew95].
The remainder of this discussion is organized as follows. We first present a model of collaboration that defines the kind of collaborative applications we consider here. Next we describe the generic collaboration architecture for implementing these applications. We then present the various dimensions along which collaboration architectures differ and discuss the tradeoffs to be made in choosing different points along these dimensions. We use these dimensions to classify architectures supported by several existing collaboration tools, and distill our discussion about the tradeoffs by giving a set of architectural design rules that should be followed when implementing collaborative applications, which are in the spirit of those given in [SG96] for user-interface support. Finally, we present conclusions and directions for future work.