This work makes several contributions. It motivates the need for studying software architectures of collaborative systems, describes a generic architecture that encapsulates architectural properties common to a wide range of collaborative systems, identifies a set of issues that a designer of a specific architecture must face, discusses and evaluates competing approaches to addressing these issues, classifies existing systems according to the approaches they have taken, and gives a set of architectural rules.
This work is related to the SAAM model for describing architectures of software systems [KBAW94]. This model advocates (i) a canonical decomposition of the functionality of the system, (ii) identification of the structure of the system, that is, the set of components of the system and the communication among these components, (iii) identification of the functions performed by each component, (iv) selection of a set of abstract properties for evaluating the architecture, (v) selection of a set of concrete tasks that have these properties, and (vi) evaluation of the extent to which the architecture supports the abstract properties and concrete tasks. Our work has applied several of these steps. In particular, it has applied step (i) by decomposing the functionality of a collaborative application into interaction functions and collaboration functions, (ii) by identifying the layers, threads, and processes of a collaborative system, (iii) by distinguishing between collaboration- aware and unaware layers, (iv) by selecting functionality, performance, programming effort, reusability, and modularity as evaluation properties, and (vi) by evaluating how well each of these abstract properties are satisfied by an architecture. It would be useful to extend this work by (a) identifying concrete tasks that have the evaluation properties and evaluating how well the architecture supports these tasks, (b) doing a finer structural decomposition that identifies the components of the layers and the external modules of the architecture, and (c) doing a finer task assignment that distinguishes among layers based not only on whether they perform interaction or collaboration functions but also on the set of collaboration functions they perform.
The framework and associated terminology can be used for understanding, comparing, and classifying existing collaboration systems. It can also be used to varying degrees to design new systems. One method would be to take the set of approaches supported in an existing system to develop a new system that addresses details not covered here differently. For instance, the set of approaches used in XTV can be used to develop a shared window system based on a different network single-user window system such as the Plan 9 window system [PPTT90]. A more novel use of the framework would be to choose a new combination of the set of the approaches described here. For instance, a new version of Suite can be developed that supports a fully replicated architecture.
This framework makes these tasks easier by telling the designers which questions they have to answer what choices are available, and what the consequences of these choices are.
This work can be extended in many other ways.
It would be useful to decompose a layer by structure, as in the PAC model, and function, as in the Clover model. A first-cut at combining this architecture with PAC and Clover has been published recently [CCN97]. It is also necessary to identify other assumptions, issues, approaches, and criteria for comparing architectures. In particular, it useful to relax the assumption that all levels above a central level are also centralized. In a single-workstation collaborative system such as MMM, it may be useful to create different branches for different users. Moreover, in such a system, it would be useful to capture, in the concurrency degree, the notion of assigning different devices to different threads. This architecture was developed based on experiences with implementing multiuser textual/graphical user-interfaces. It would be useful to test its applicability for multiuser audio/video and 3-D virtual reality user-interfaces. It may also be useful to relax the assumption that a layer is replicated/threaded/distributed as a whole, which does not apply to Shastra [AB93]. In Shastra, the semantic layer consists of two parts: one performs expensive computations while the other performs relatively inexpensive ones. The expensive part is centralized but the inexpensive one is replicated and distributed since computation costs dominate in one case and communication costs in the other. It would also be useful to consider migration and caching of centralized components of collaborative applications [GUN96,CD96] and their impact on performance.