INTRODUCTION

Over the last decade, many CSCW(Computer-Supported Cooperative Work) systems have been built. However, in traditional systems, the coordination policies, such as those for access control and concurrency control, are often hard-coded into the system together with the user interfaces. Coordination policies are usually sensitive to the work style and organizational structure of individual groups. Not only do different groups have different needs, but the same group may require different policies in different phases of their collaboration. Therefore, it is important for system support to be flexible and adaptable. But in general, traditional CSCW systems are complex to build and do not easily accommodate changes.

We proposed a novel approach called COCA [16] to model and support collaborations over the Internet. Our approach is different from traditional CSCW systems in the following ways. First, we separate coordination policies from user interfaces in building collaboration systems. Second, we provide an executable specification language to describe coordination policies. Those policies are enforced at runtime by the COCA virtual machine (cocavm), a copy of which runs at each participant site. Third, at runtime participants in the same collaboration take on roles(e.g. the professor and student roles in distance learning). Different roles are each controlled by a different set of rules. As a result, the design and implementation of collaboration tools are greatly simplified. Tools are both easy to build from scratch[17] and to adapt from legacy tools[18]. The same set of tools can be reused in many different scenarios with different policies and without changes to the tools. Moreover, the coordination policies are explicitly and collectively specified instead of being scattered in all the involved components of the system. Systems thus built are more tractable to manage and evolve than those developed in traditional ways.

The notions of role and collaboration are well-accepted in object-oriented systems design and analysis, e.g. [34], [33], and [13]. However, their uses of those two concepts are different from ours, as was concisely illucidated by the following excerpt [27]:

In the CSCW literature, Intermezzo[8], QUILT[14], etc. used the concept of role. In Intermezzo and many other systems, roles are used only for access control. We use role as a unit to specify a wide range of coordination policies including access control, concurrency control, session control, etc. As a result, the language in Intermezzo is much simpler and limited in expressive power, as compared with the language in COCA. QUILT built three roles into the group editor: reader, commentator, and co-author, each with different privileges. In COCA, the users are free to specify as many roles as the application requires.

An important difference between groupware and traditional software is the critical need for an efficient and scalable group communication model. Early collaborative systems were generally built based on grouping of multiple point-to-point communications. This approach incurs tremendous overhead on both the message senders and the communication paths, and latency increases with the size of the receiver population. Deering[6] proposed IP multicast as a better solution to this problem. It has been well-accepted in the networking literature (e.g.[10,23]) that IP multicast is an efficient model for group communication, both for delivery of time-critical media streams and for non-realtime messages. We adopt IP multicast as the group communication model of COCA.

Major novelties of our specification language include the following. It uses roles as a unit to specify a wide range of policies including access control, concurrency control, session control, etc. It provides logic-based language constructs for efficient and flexible group communication. The simple syntax leads to concise and easily understood specifications. It is potentially possible to develop tools to mechanically verify and validate the specifications, to derive test cases, to detect deadlock situations, to reason about role behavior, etc.

Over the past one year, considerable experience with COCA has been accumulated and the system extended to improve the usefulness of COCA in practice. The runtime support system has been running since February 1998. Since the summer of 1998, we have been exploring application domains and building systems. Specifically, COCA has been proved applicable in the following domains: electronic meeting systems[17], online auction systems[18], and so forth. Today over 40,000 lines of code are running, including the core language runtime and applications. The performance has been good despite the fact that the prototype is done in pure JAVA.

The remainder of this paper is organized as follows. We first briefly overview the collaboration model of COCA in the next section. In section 3, we try to give the readers an initial feel of the language with a simple example. Section 4 describes our specification language. A more complete design example is discussed in section 5. Some important implementation issues are discussed in section 6. A more detailed comparison with related work is left to section 7. We conclude this paper in section 8 with some directions for future research and development.