Meeting rooms A typical automated face to face meeting room consists of a conference .... Most commercially available computer systems support a mailing.
DISTRIBUTED SYSTEMS SUPPORT FOR COMPUTER SUPPORTED COOPERATIVE WORK Tom Rodden and Gordon S. Blair Computing Department, Lancaster University , Lancaster LA1 4YR , U.K. E-mail: [tam, gordon]@comp.lancs.ac.uk
Abstract Distributed systems have traditionally tackled the problems associated with the inter-connection of a number of computer systems. Until recently the focus of this research has been on the development of solutions to the technological problems involved. The emergence of Computer Supported Cooperative Working (CSCW) has challenged this technological perspective by focusing on the group-working of a number of users. This paper briefly introduces the state of the art in CSCW and relates the general characteristics of existing CSCW systems to a variety of trends in distributed computing. It is argued a reasonable correspondence exists between CSCW and distributed systems in terms of their geographical nature and style of interaction. However, a disparity appears when we examine how cooperation is represented and controlled in both CSCW and distributed systems. Strict distribution transparency is highlighted as the most significant manifestation of this disparity, often discouraging users from influencing control decisions. It is suggested a CSCW support layer is required to allow cooperating users to have greater involvement in deciding how control is achieved.
1. Introduction Distributed systems have been one of the major growth areas in computing over the past decade. Products such as Ethernet [Shoch 82] and Mach [Jones 86] are available in the market place and standards to provide open communications are generally agreed [Zimmermann 80]. It is often argued that distributed systems are entering a period of consolidation with techniques for implementing distributed systems relatively well understood, and that emphasis should be placed on issues such as promotion of standards, large scale experiments, and gaining of experience. However, a major problem in distributed systems is a lack of existing applications of the technology leading to technological solutions to technological problems. Until recently, this feature of distributed computing has not posed many problems. However, the emergence of Computer support for cooperative working (CSCW) has led to more sophisticated demands on the underlying technology. CSCW encompasses a range of distributed applications and places particular requirements on distributed systems infrastructures. The aim of this paper is to evaluate distributed systems technology in light of CSCW. In more detail, our objectives are:i) to highlight the challenges of CSCW for distributed systems designers and developers ,
ii) to examine existing distributed systems support for CSCW, and iii) to consider the specific requirements of CSCW applications, iv) to make recommendations on future developments for distributed architectures to meet the challenges of CSCW. Section 2 discusses the emergence of CSCW and describes the main developments to date. Two major characteristics of CSCW are introduced in section 3, namely support for cooperation and geographic dispersion. These characteristics provide the basis for our initial examination of distributed system support for CSCW (section 4). This examination is enlarged in section 5 by considering the nature of control in both CSCW and distributed systems. Section 6 offers some general observations on the comparison and suggests the need for a CSCW support layer. Finally, section 7 presents some concluding remarks.
2. The Emergence of CSCW The term CSCW was coined by Grief and Cashman in 1986 [Greif 88] as a shorthand way of referring to the interests of a number of researchers involved in the use of computers to support user groups. The area has evolved over the last five years to combine the understanding of the nature of group working with the enabling technologies of computer networking, systems support and applications. As [Bannon 91] argues, CSCW is inherently a multi-disciplinary research topic and requires the application of a number of disciplines including, sociology, organisational science, psychology and computer science. Interested readers are refered to [Greif 88; Ellis 91; Goldberg 91] for more detailed examinations of CSCW. Four general classes of cooperative system have emerged : Message systems Message systems are descendants of early electronic mail programs which allowed a user using a central machine, to send textual messages to other users on the same machine. As wide area networks designed to support computer communication became more widespread [Mortensen 85], electronic mail systems increased in complexity and functionality [Kerr 82]. This development resulted in the formation of a Message Handling System (MHS) model described in the CCITT X400 series of standards documents [CCITT 87]. Each message system makes use of a particular message format to transfer information (a message format is often defined as a part of most message standards). Structured message systems are based on the principle of extending the amount of machine processible semantic information available by adding structure to the existing message formats. Systems of this class include the COSMOS [Wilbur 88] and AMIGO [Danielson 86] projects and the Object Lens [Malone 88], Strudel [Shepard 90] and ISM [Rodden 89] systems. Computer Conferencing Computer conferencing systems are also a development of the original electronic mail programs. However, structure is imposed in terms of how messages are grouped. A typical computer conferencing system consists of a number of groups called conferences, each of which has a set of members and a sequence of messages. Conferences are often arranged so that they individually address a single topic. A user subscribes to those conferences which are of interest. Usually, the system stores information about how far each conference member has read . This information is normally held along with conference messages in one central database rather than the individual mailbox
2
approach used in messaging systems. Examples of this class of systems include Notepad [Pullinger 86] and COM [ Palme 84] The development of reliable high speed communications has lead to the emergence of new real-time conferencing systems such as RTCAL [Sarin 85] which allow conference members to communicate in real-time. In addition, modern workstations have led to the development of desktop conferencing systems [Ellis 91] which merge real-time conferencing capabilities with modern windowing environments allowing shared windows across a number of workstations [Lauwers 90]. Multimedia conferencing systems such as Rapport [Ahuja 88] and the MERMAID Conferencing system [Watabe 90] represent the introduction of multimedia technology into conferencing systems. Such systems integrate many forms of media including audio, text and video. Meeting rooms A typical automated face to face meeting room consists of a conference room furnished with a large screen projector, a computer (or network of computers), a number of individual input/voting terminals, and a control terminal. The computer system supporting the meeting often makes use of multi-user software based on some form of analytical decision technique [Kraemer 88]. Software for graphics and vote tally and display also form part of the normal meeting facility. Examples of meetings rooms include the CoLab [Stefik 87a], Project Nick [Cook 87] and the Planning Laboratory at the University of Arizona [Applegate 86]. Co-Authoring and Argumentation Systems Co-Authoring and argumentation systems are a general class of system which aim to support and represent the negotiation and argumentation involved in group working. The cooperative authoring of documents is demonstrative of this class of cooperation where the final generation of a document represents the product of a process of negotiation between authors. This class of systems is characterised by their widespread use of hypertext technology. Argumentations systems include gIBIS [Conklin 87b] and SIBYL [Lee 90] while coAuthoring systems include Quilt [Fish 88] and CoAuthor [Hahn 89].
3. Dimensions of CSCW The wide variety of CSCW systems highlighted in section 2 reflect the many different views of cooperation. The nature of cooperation has been an on-going debate within the CSCW community [Schmidt 89] and two principal characteristics have emerged from this debate:i) The form of cooperation ii) The geographical nature We shall use these characteristics as the basis for examining both CSCW systems and the underlying support provided by distributed systems. This provides a basis for an examination of the interaction between these two areas. 3.1 The Form of cooperation CSCW systems are primarily concerned with supporting a number of users cooperating to address a particular problem, or range of problems. The nature of this cooperation can be distinguished by the way in which the group members interact. People can either interact and cooperate synchronously or asynchronously. Synchronous interaction requires the presence of all cooperating users while asynchronous cooperation occurs over a longer time period and does not require the simultaneous interaction of all users. 3
Figure 1 shows how the classes of CSCW systems identified in section 2 fit into this division.
Meeting Rooms
Message Systems Co-Authoring and Argumentation
Synchronous Systems
Conferencing Systems
Asynchronous Systems
Figure 1 Forms of cooperation in CSCW systems From this analysis, three general classes of CSCW system can be highlighted. i) Purely synchronous systems Purely synchronous systems need the simultaneous presence of all users. This general class of system is used for investigative and creative problems. Systems which typify this approach include real-time conferencing systems [Lauwers 90] using shared screen techniques [Stefik 87b] and the brainstorming tools found in meeting rooms. ii) Purely Asynchronous systems Asynchronous systems are designed to facilitate cooperation without the simultaneous presence of all group members. Often the cooperation takes place over a much greater time-scale. Asynchronous cooperative systems are often used to tackle structured prescriptive tasks. Cooperative message systems are a primary example of this type of system where users take on independent roles which produce and consume messages. Similarly, traditional conferencing systems developed from the work of Hiltz and Turoff [Hiltz 78] (for example EIES or CONfer) assume an asynchronous mode of cooperation with users reading and adding articles to conferences independently of other users. iii) Mixed Systems Mixed systems contain elements of support for both synchronous and asynchronous cooperation. They allow real-time synchronous cooperation to take place within the same framework as time-independent asynchronous working. The primary examples of this type of systems are in computer conferencing and co-authoring and argumentation systems. Modern computer conferencing systems provide a central asynchronous conferencing systems often augmented with facilities such as real-time conferencing systems. Co-authoring and argumentation systems are often asynchronous in nature for the larger part of the their use. However these systems rely on the establishment of cooperation roles which are the followed through the rest of the work. As a result these systems often provide mechanisms for real-time synchronous working.
4
3.2. Geographical Nature CSCW has traditionally considered the case of geographically distributed groups. More recent research [Stefik 87] has complemented this emphasis by considering the support of face to face (or colocated) meetings. As a result cooperative systems are often considered as being either remote or co-located giving our second classification mechanism. In this classification the division between remote and co-located is as much a logical concept as a physical measure and is concerned with the accessibility of users to each other rather than their physical proximity. The classes of CSCW system described in section 2 are divided in terms of their geographical nature in figure 2. Message Systems
Meeting Rooms Co-Authoring and Argumentation
Conferencing Systems
Co-Located Systems
Virtually Co-Located
Locally Remote
Remote Systems
Figure 2 Geographical nature in CSCW systems This analysis highlights four general divisions of CSCW systems based on their geographical nature. i). Co-Located. Purely co-located system require the local presence of all users. This class of system normally takes the form of a purpose built meeting room with a large projected computer screen and a number of personal computer linked by a local area network. A variety of software is used to augment the meeting room process by providing automated support for facilities such as minute taking and agenda planning. Argumentation and co-authoring systems also tend to have co-located variants which represent the merging of this class of system with meeting support systems. ii) Virtually co-located Systems which are virtually co-located are similar to co-located systems but do not have the requirement that the systems needs to be in one room in order to function. This is often achieved by the use of Multimedia technology, allowing real-time audio and video links to be maintained. Systems in this class include real-time Multimedia conferencing systems such as those been developed for MMConf [Crowley 90] and the less structured video linkage facilities such as the Cruiser [Root 88] system at Bell Labs. iii) Locally Remote Locally remote systems are those systems which provide high-bandwidth real time accessibility between users often using shared screen techniques. The general assumption is that users are within the one building and as a result the cost of direct access to another user is low. Argumentation and co5
authoring systems such as quilt or gIBIS and real-time conferencing facilities such as RTCAL [Sarin 85] can be considered in this way. iv) Remote Remote cooperative systems are those that assume the existence of only minimal accessibility between users. These include message systems which assume only the simplest of communication systems and computer conferencing systems which assume only rudimentary “dial-in” mechanisms.
4. CSCW and Distributed Systems To complete our initial analysis this section reviews the ability of existing distributed system technologies to support the wide range of CSCW applications. To do so our analysis uses the framework established in section 3 with distributed computing examined under the corresponding headings of:i) The form of cooperation ii) The geographical nature This tactic allows a direct comparison to be made between the requirements of CSCW and the support mechanisms provided by existing distributed systems technologies. 4.1. The Form of cooperation Distributed systems have traditionally being viewed in terms of support for cooperation between a number of computers connected by a network. It is important to note that the term cooperation is used in this context to refer to how closely related the computers within the distributed systems are to each other, rather than the more general application of the term in section 3. This interpretation is used throughout this section. The nature of support for cooperation varies greatly from system to system. A traditional problem with cooperation in distributed systems is the need to recognise autonomy of individual sites in a network. Indeed, full cooperation and full autonomy are actually two extremes in a spectrum of possibilities with most practical systems found between these two extremes. Increasing the autonomy of a system inevitably decreases the support for cooperation and vice-versa. Much of the research in distributed systems has been concerned with resolving this design tension and establishing a compromise between the two extremes. A number of distinct classes of system, each taking a particular approach to this issue, have been developed:i) autonomous systems with mailing capabilities This is an important class of system where personal computer environments are interconnected by electronic mail allowing users to interact asynchronously via (usually) text based messages. ii) resource sharing systems Resource sharing systems allow resources to be accessed whether they are local or remote to a workstation. The motivation for resource sharing systems is that many resources are expensive and hence it is economical to share such resources across a network. The key characteristic of this class of system is the retention of autonomy of individual nodes. The user always has a home site which provides a basic computing environment.
6
iii) distributed operating systems Distributed operating systems are operating systems which manage resources across a distributed environment [Tanenbaum 85; Goscinski 91]. They provide global management of such resources with the consequent loss of node autonomy. Most distributed operating systems are based on the clientserver model of interaction with clients requesting remote operations from servers on other nodes. More recent distributed operating systems have also tended to provide more sophisticated support for interaction. For example, several systems have developed protocols to provide general group interaction (e.g. ISIS [Birman 89] and psync [Petersen 89]]) as opposed to the one to one patterns encouraged by the traditional client-server model. Another important trend is the introduction of experimental distributed virtual memory mechanisms where memory can be managed on a global basis providing a new model for sharing and interaction [Johnston 89]. The need to support autonomy has proved to be more important than the support for cooperation. Most commercially available computer systems support a mailing capability and this has become accepted as a standard means of cooperation in a distributed system and provides adequate support for the development of asynchronous cooperative systems. Systems with resource sharing capabilities provide access to networked resources such as printers and remote files. More sophisticated resource sharing systems will provide the user with a global file system accessible from anywhere in the network. Most Unix environment now provides a range of facilities to access remote resources. In addition, Unix supplemented by NFS provides a sophisticated network filing system [Sun 87]. Resource sharing systems provide an ideal platform for developing mixed cooperative systems with asynchronous cooperative working as the norm and rudimentary synchronous support being provided as an expensive shared resource. There has been much less commercial interest/ exploitation of distributed operating systems. Distributed operating systems have been an area of intense research activity [Cheriton 84, Walker 83, Mullender 86]; however, this has yet to be mapped on to a real demand for the technology. Recently a number of products have emerged [Herrmann 88, Jones 86] although such systems are not yet in widespread use. Distributed operating systems represent the maximum support available for cooperation. They support reasonably sophisticated modes of interaction and often mask out the problems of distribution (e.g. locating objects and handling failure). However, most distributed operating systems allow some recognition of the autonomy of individual nodes and the cooperative end of the spectrum has not been explored fully. There are a few notable exceptions , for example, the work of the ISIS project on group interaction could be viewed as supporting more sophisticated levels of cooperation. A number of projects are also considering approaches based on distributed shared spaces. For example, the Linda project at Yale University is looking at an interesting metaphor for interaction based on the concept of shared tuple spaces [Gelernter 85].
7
In summary, research in distributed computing has produced a number of categories of system varying in the degree of support for cooperation. This spectrum is illustrated in figure 3. resource sharing systems distributed operating systems
e-mail systems
COOPERATION
AUTONOMY UNIX
ANSA Chorus Mach
Linda ISIS
Figure 3 Spectrum of Distributed Systems This spectrum corresponds quite closely to the forms of cooperation described in section 4.1. Synchronous systems require highly cooperative distributed systems while asynchronous systems tend to be much more autonomous in nature. Basic asynchronous cooperative systems need only the facilities provided by electronic mail systems, the most autonomous of distributed systems. Fully synchronous systems test the facilities provided by the most cooperative of distributed operating systems. Most distributed systems are found at the lower end of the spectrum, i.e. supporting a high degree of autonomy. This may account for the lack of highly interactive synchronous cooperative systems. The two views of a cooperative system are shown together in figure 4
Required Service
Available Service
Asynchronous systems
e-mail systems
Mixed systems
resource sharing systems
Synchronous systems
Increased User Cooperation
Increased Machine Cooperation
distributed operating systems
Figure 4 Comparison of Models of Cooperation A strong correspondence can be seen between the two categories in figure 4. However, there appears to be a gap when considering more sophisticated forms of synchronous working. It is not clear how best to support highly synchronous cooperative systems such as meeting rooms and real time multimedia conferencing with existing distributed technology. 4.2. Geographical Nature As discussed in section 3.2, the geographic nature of CSCW systems is concerned with the logical concept of co-location. In contrast, distributed computing has been solely concerned with the physical transmission and processing of specialised, computer-oriented, media such as numerical and textual data. Most
8
distributed computing environments have been connected by a range of local or wide area networks providing a reasonable handling of such media types. The characteristics of each type of network is summarised in figure 5. Network
Throughput
Classification
Ethernet
10 Mbits/Sec
Local Area Network
1Base5 CSMA/CD
1 Mbits/Sec
Local Area Network
PSS (UK)
64 KBits/Sec
Wide Area Network
Arpanet (USA)
64 KBits/Sec
Wide Area Network
Figure 5 Local vs Wide Area Networks The performance characteristics listed above have proved sufficient to support a range of distributed computing environments. The table also highlights the quantitative difference that currently exists between local and wide area technologies. Local area networks have been used to implement the full range of systems described in section 4.1 including distributed operating systems supporting varying degrees of cooperation. Wide area networks have generally been restricted to mailing systems and, occasionally, resource sharing systems. Recently, there has been great interest in high speed networks and, in particular, their capability to handle a greater variety of media types. In the local area, high speed networks such as FDDI [McCool 87] and the fast Cambridge Ring have emerged [Hopper 88]. Such networks are capable of supporting bandwidths in excess of 100 Mbit/s and are thus capable of supporting media types such as voice, audio, image, slow scan video and to a certain extent full motion video. In addition, forthcoming developments in compression technology will greatly increase this multimedia capability. Similar rapid advances are taking place in wide area technology with systems such as ISDN [Stallings 88] now becoming available. Such systems provide communications channels of up to 2 Mbits/Sec over large distances (155 MBits/Sec in the case of forthcoming broadband ISDN networks [Byrne 89]). A further category of system has emerged, called metropolitan area networks. Such networks are a compromise between local and wide area networks and support multimedia capabilities within a single community (such as a small town). For example, Berlin recently established an experimental metropolitan area network across the city [Popescu-Zeletin 89]. The capabilities of multimedia networks are summarised in figure 6. Network
Throughput
Classification
FDDI
100 Mbits/Sec
Local Area Network
DQDB
up to 100 Mbits/Sec
Metropolitan Area Network
Basic Rate ISDN
64 KBits/Sec
Wide Area Network
Primary Rate ISDN
2 MBits/Sec
Wide Area Network
Broadband ISDN
155 MBits/Sec
Wide Area Network
Figure 6 High Performance Networks
9
Networking technology is increasing at a rapid rate but there is still a long way to go before such networks can provide support for sophisticated forms of multimedia cooperation. The problems are most acute when considering the group interactions demanded by CSCW. Considerable research is also required in issues such as synchronisation of different multimedia channels [Shepherd 90] and the integration of high performance protocols into multimedia workstations [Hopper 90]. There is also very little work in integrating multimedia information into existing distributed system technologies [Blair 91]. To summarise, a spectrum of communications technologies exists as shown in figure 7. Existing WANs
ARPANET
High Speed Networks
Existing LANs
ETHERNET
DQDB
FDDI
Increasing Throughput
Figure 7 Spectrum of communications technologies As in the previous section, the support provided by distributed systems technologies can be compared directly with the requirements of CSCW systems (see figure 8) Required Throughput Remote
Available Throughput
Existing WANs
Locally Remote
Existing LANs
Virtually Co-located
High Speed Networks
Increasing Co-Location Increasing Throughput
Figure 8 Geographic Dispersion Comparison As in the case of cooperation distributed systems seem to provide good support for asynchronous cooperative systems. However, there are limitations with existing technology in supporting more synchronous styles of work. This is particularly true in CSCW applications supporting a high degree of co-location. Communication networks simply cannot cope with the logical 'bandwidth' demanded by this class of application. It is likely that high performance multimedia networks will have some impact on CSCW systems. The extent of this impact will depend on the development of protocols suitable for CSCW systems.
5. The Nature of Control The previous sections have examined the styles of interaction and the geographical nature of CSCW and distributed systems in turn. However, a fundamental element is still missing from our discussion. CSCW systems can be distinguishing for our distributed applications by their approach to representing and controlling users' cooperation. This section, examines the issues surrounding control in more depth. We begin by examining the differing styles of control adopted by different CSCW systems These various control techniques allow us to highlight an initial set of control requirements for CSCW systems. The section concludes by
10
examining how these requirements correspond to existing approaches to control found in distributed systems. 5.1 Styles of control in CSCW People work together to solve a wide variety of problems using varying forms of cooperation for different classes of problem. Cooperative problems can be though of as existing at some point on a spectrum ranging from unstructured problems at one end to prescriptive tasks at the other. Unstructured problems are those requiring creative input from a number of users which often cannot be detailed or described in advance; software design is a good example of such an activity. Prescriptive tasks, on the other hand, represent the routine procedural cooperative mechanisms used to solve problems which have existing group solutions, for example the invoicing procedures used in large organisations. Prescriptive tasks respond well to detailed control of cooperation while unstructured problems require a significant degree of freedom to be exercised by the cooperative system. A simple classification of the representation and control of cooperation in CSCW systems forms five classes of system based on the formality and nature of control exhibited by each. i) Speech act or conversation based systems Speech act systems apply a linguistic approach to computer supported cooperation based on speech act theory. Speech act theory considers language as a series of actions. Speech Act theory has been primarily applied by Winograd and Flores to form the basis for several computer systems including the Coordinator system [Winograd 87] and the CHAOS project [De Cindio 86]. Cooperation is represented and controlled within this class of system using some form of network structure detailing the patterns of message exchange ii) Office procedure systems Office procedures attempt to describe tasks performed within an office in terms of the combined effect of a number of small sub-tasks or procedures. Examples of procedures range from the well defined and understood (invoicing, for example) to less well defined tasks such as the generation and approval of an office budget. The research has concentrated on finding a unifying language which allows the specification of office procedures and a description of their interaction. More recently, systems such as POLYMER [Croft 88] have started to utilise AI technology and AI based planners to execute actions and coordinate interaction often handling exceptions and uncertainty. This class of system is characterised by the use of some form of procedural language to describe and control the cooperation by defining roles and activities.Similar approaches are found in the AMIGO [Danielson 86] and COSMOS [Wilbur 88] projects. iii) Semi-formal active Message systems Semi-formal or active message systems follow a philosophy of semiautomation; automating those parts of the system which are most amenable to it while leaving other parts of the system manual in nature. Systems of this form provide mechanisms for automatic message handling and more recently support the concepts of roles and autonomous agents. Systems of this form include the Object Lens [Malone 88], the Strudel project [Sheperd 90], and the ISM system [Rodden 89]
11
iv) Conferencing systems Conferencing systems provide basic control mechanisms which are minimal and fixed into applications. In traditional conferencing systems this takes the form of conference moderators who define conference topics and control the addition of information to these topics. In more modern real time conferencing systems the control centres around the floor control mechanism imbedded in the conferencing application and controlling who has access to some shared space at any given time [Lauwers 90] . v) Peer- group meeting or Control free systems Our final control category represents the class of systems which impose the least control on users. Peer meeting systems such as the Colab system [Stefik 87a] deliberately do not provide any control mechanisms and rely on the meeting participants to formulate their own meeting protocols. All users have equal status and may amend and use the systems freely. In turn the systems keeps no track of the nature or form of group work being undertaken and provide limited support for these work processes. The amount of control provided by cooperative systems is significant in that it highlights the level of automation each cooperative system provides. In particular, the approaches above can be characterised as either exhibiting explicit or implicit control. In systems which provide explicit control users may both view and tailor group interaction and cooperation. In contrast, systems exhibiting implicit control provide no techniques for representing or coordinating group interaction. These systems dictate cooperation by the styles of interaction they allow. The first three classes listed above are all examples of systems which exhibit explicit control allowing the representation and editing of control information. In contrast, conferencing and control free systems are implicit control systems which contain no representation of control. This distinction is important when considering the role of the underlying system infrastructure in supporting CSCW and will be revisited later. 5.2 Control requirements for CSCW One general conclusion to be taken from the above list is that CSCW encompasses a wide range of control techniques. In many ways this is to be expected; CSCW is essentially about supporting the rich patterns of inter-personal cooperation. This has two major repercussions: i) this richness should be reflected in the provision of control within CSCW systems, and ii) underlying technology should support rather than constrain this process. The latter point highlights the importance of the relationship between CSCW and distributed systems design. It is difficult to derive precise requirement from the list of control techniques presented above. However, some important observations can be made:
12
• The organisational context of the work needs to be captured. • The many different forms of cooperation need to co-exist. • The structure and organisation of groups need to be explicitly recognised. • Groups work in dynamic and unexpected ways. • Groups are themselves dynamic. • Control should be enabling rather than constraining Collectively these issues demand a user-centred approach to the control of cooperation within CSCW systems. This poses fairly fundamental questions for distributed system designers and highlights significant deficiencies in existing technology. 5.3 Supporting Control in Distributed Systems Traditionally, distributed systems have taken a systems-oriented approach to control. They view control as dealing with the problems of distribution and masking such problems from applications (distribution transparency). Unfortunately this focus on transparency has tended to re-enforced the bottom-up development of distributed systems. For example, consider the problem of shared access to resources. In most distributed systems this is dealt with by masking out the existence of other users. Hence sharing is transparent with each user unaware of the activity of others. This clearly contradicts the requirements of CSCW. In addition, a set prescriptive techniques have had to be developed to enforce transparency. Again this prescription contradicts the nature of CSCW control. Recent work on distributed systems has clarified the meaning of the term distribution transparency [ANSA 89] . Distribution transparency is now seen as a collective name for the masking out of various features of a distributed computation. In effect, there are a number of individual transparencies corresponding to each of these features (figure 9). Transparency
Central Issue
Result of Transparency
Location
The location of an object in a distributed environment The method of access to objects in a distributed system The re-location of an object in a distributed environment Shared access to objects in a distributed environment Maintaining copies of an object in a distributed environment Partial failure in a distributed environment
User unaware of the location of services All objects are accessed in the same way Objects may move without the user being aware Users do not have to deal with problems of concurrent access System deals with the consistency of copies of data Problems of failure are masked from the user
Access Migration Concurrency Replication Failure
Figure 9 The Various Forms of Transparency in Distributed Systems The prevalent view in distributed computing is to implement each of these transparencies in order to mask out all the problems of a distributed system. This is particularly true in the distributed operating system community which has developed
13
techniques to mask location (naming servers), access (remote procedure call protocols), migration (load balancing strategies), replication (multiple copy update algorithms and finally concurrency and failure (distributed atomic transaction mechanisms). The problem with this approach is that presumed control decisions are embedded into the system and hence cannot be avoided or tailored for specific classes of application, i.e. the solutions are prescriptive. This is the root of the problem in supporting CSCW. Because of the dynamic requirements of CSCW applications, it is very unlikely that such prescribed solutions will be suitable. It is therefore important to consider alternatives to this form of distribution transparency. Distributed system designers are aware of the problems that can be caused by full distribution transparency. Consequentially, a number of alternative approaches have been explored: i) Non-transparency In non-transparent systems, all the features of distribution are visible to the programmer. They must therefore deal directly with issues such as failure and migration. This allows more flexibility since individual applications can deal with the management of objects in a distributed environment. Applications can exploit information on the nature of cooperation supported by the application in making management decisions However, the handling of distribution can become an intolerable burden on the programmer. ii) Selective Transparency Selective transparency allows the user to opt for transparency or nontransparency for each of the issues in distributed computing (see figure 9). It is therefore possible to have location and access transparency, for example, but request non-transparency for the other issues. This approach was recently proposed in the ANSA project [ANSA 89] and provides some of the flexibility required for CSCW applications. The various approaches described above do not provide complete solutions to the problem of controlling CSCW applications. The option of transparent control is too prescriptive for the needs of CSCW applications. However, the alternative of non-transparency imposes too high a burden on application developers. Selective transparency does appear more promising but does not address the fundamental issue of the nature of control in cooperative working. It seems therefore that CSCW demands a fresh approach to control, i.e. an approach specifically tailored for cooperative working scenarios. There has been very little work in this area. However, it is possible to identify a number of features of such an approach:i) Clean separation of mechanisms and policies The first requirement for control in CSCW applications is that there should be a clean separation between the mechanisms required for distribution management and the policies which govern the use of these mechanisms. To appreciate this distinction, consider the case of migration. There is a clear distinction between the ability to move an object (the mechanism) and the decisions about when the object should be moved and to which site (the policy). Distributed systems can provide the mechanisms required to manage distribution leaving higher level authorities to impose the policy. This separation of concerns is implicit in both non-transparency and selective transparency.
14
ii) Tailored Mechanisms Current mechanisms have been developed in the classical bottom-up tradition of distributed systems. Such mechanisms may not be suitable for the particular semantics of CSCW applications. It is therefore important to consider existing mechanisms for the various transparencies and whether they are suitable for the demands of CSCW. Returning to the discussion of section 4.1 mechanisms delimit the implicit control exhibited by CSCW systems. A single set of mechanisms is unlikely to be suitable for all manifestations of implicit control in CSCW applications and the co-existence of a range of mechanisms needs to be considered. A impact of CSCW of different system mechanisms is reviewed in [Ellis 91]. iii) Tailored Policies Distribution policies provide the representation necessary for explicit control in CSCW systems. It is important that these policies meet the control requirements identified in 4.2. It is equally important that policies can be tailored to allow support across the range of explicit control techniques identified in section 4.1. The provision of the policies will require input from all areas of CSCW. It is important to avoid these policies overly inhibiting the cooperation of users. As described in [Armstrong 90] when considering good practice in management science: “Policies are both restrictive and permissive at once. They spell out the limits to actions, but at the same time they give freedom to act within the limits specified”. CSCW demands a richer approach to the issue of distribution . It is important to avoid prescriptive and often unsuitable solutions to issues such as migration, concurrency and failure. Rather, a more flexible and dynamic view of system management with the option existing between transparency and non-transparency is required . Similarly, both the mechanisms and policies of distribution management should be tailored more closely to the demands of group working. This raises some fundamental and, as yet, unresolved questions:i) what are the most suitable mechanisms to support group working, and ii) what are the appropriate management policies for a co-operative environment? A solution to the problem will require a detailed understanding of both the behaviour of distributed systems and the behaviour of interacting user groups. This problem therefore illustrates the inherently cross-disciplinary nature of CSCW research.
6. Evaluation 6.1 General Remarks The provision of appropriate facilities for supporting CSCW will almost certainly require a careful re-examination of underlying systems architectures. This paper has highlighted a number of problems with existing distributed systems technologies. In particular, the following specific problems can be identified:i) poor support for real-time group interaction Distributed systems do not provide good support for highly interactive group activities. The notion of a group simultaneously accessing shared data is generally not well catered for. In addition, systems do not provide the necessary real time responses for this class of application.
15
ii) lack of support for multimedia cooperation Research in dealing with multimedia information in distributed systems is still in its infancy and major issues remain before the problems of handling multimedia can be solved. This is particularly the case in group working where several users require access to multimedia information sources. iii) problems of distribution transparency The common approach of providing full distribution transparency may be misguided for CSCW applications. The problem with transparency is that decisions are made by the system on behalf of the application. The particular demands of CSCW require a greater level of control over the policies of managing the distributed system. Section 4.3 concluded by suggesting this represent the largest area of disparity between CSCW and distributed systems. The most significant mismatch between the needs of cooperative systems and the facilities provided by distributed systems appears when we consider the handling of control. Existing control mechanisms in distributed systems are not well-suited to the rich variety of control structures required in CSCW. As an added subtlety, systems should support both explicit and implicit control by both providing appropriate representation techniques and access to suitable mechanisms. The problem of providing support for CSCW is compounded by the observation that existing distributed systems already provide adequate support for a range of applications and this support has evolved over many years to meet the requirements of these applications. It is important that distributed systems continue to support these applications and mechanisms for supporting CSCW systems need to smoothly integrate with existing distributed applications. 6.2 A CSCW Support Layer Given the nature of the mismatch highlighted above, a CSCW support layer sitting between CSCW applications and distribution technology is the one approach which will allow effective development of CSCW systems (figure 10). The CSCW support layer act as a adaptation layer sitting between the requirements of CSCW and the facilities offered by more general distributed systems technologies such as distributed operating systems and OSI services.
USERS
Explicit Control Policies Cooperative Applications Implicit Control Policies CSCW Support Layer Distribution Technology Mechanisms Distribution Technology
16
Figure 10 The CSCW layer provides a clear separation between the mechanisms and policies required by cooperative systems. Suitable mechanisms should be provided by the distribution technology. In addition, the CSCW support layer will provide facilities for articulating policy decisions. Given the demands of CSCW it is important that these decisions are clearly and distinctly recorded by the support layer. In the case of implicit control systems these policies will be prescribed by developers using the CSCW layer. In contrast, systems with explicit control will allow users to view and tailor policies to meet the groups current needs. This accessibility of control is highlighted in figure 10 with users having access to explicit control policies while implicit control is visible only at the application level. It is beyond the scope of this paper to address the detailed design of an effective CSCW support layer. The development of such a layer raises some fundamental and, as yet, unresolved questions:• what are the most suitable mechanisms to support group working, • what are the appropriate control policies for CSCW, and • how are cooperation and control represented in CSCW systems? A solution to these problems will require a detailed understanding of both the behaviour of distributed systems and the behaviour of interacting user groups, illustrating the inherently cross-disciplinary nature of CSCW research. The CSCW research centre at Lancaster university is currently addressing this topic.
7. Concluding Remarks CSCW has emerged as a novel and exciting area of opportunity for distributed computing. The topic provides a variety of applications which demonstrate the possibilities of high performance distributed computing. However, to merely consider CSCW as another application domain for distributed computing could prove to be a missed opportunity for the developers of distributed systems. CSCW demands rigourous performance and high design standards of distributed systems. More significantly, CSCW asks searching questions about the nature of distributed computing and the assumptions embedded within the technology. This paper has highlighted some of these questions by examining the nature of distributed systems in light of the needs of existing CSCW applications. Existing distribution technology currently has shortfalls in supporting CSCW systems, both in terms of the cooperation between users and the geographic nature of these users. However, it is possible to see how these shortfalls can be overcome by current developments in distributed systems. More seriously, it is difficult to foresee how distributed systems can provide the highly flexible and tailorable facilities needed to represent the process of cooperation within CSCW applications. The provision of these facilities will almost certainly require a careful re-examination of distributed systems architectures and the provision of control within these architectures.This paper recommends the development of a specific CSCW support layer to bridge the gap between user communities and distributed systems technology.
17
8. References [Ahuja 88]
[ANSA 89]
[Applegate 86]
[Armstrong 90]
[Bannon 91]
[Birman 89]
[Blair 91]
[Brobst 86]
[Byrne 89]
[CCITT 87] [Cheriton 84]
[Cook 87]
[Croft 88]
Ahuja S.R.,Ensor J.R.,Horn D.N.' The Rapport Mulimedia Conferencing system', in Allen R.B.(ed) COIS88 Proceeding conference on Office Information Systems, March2325,1988, Palo Alto, California,. ANSA. 'ANSA: An Engineer's Introduction', Release TR.03.02, Architecture Projects Management Limited. November 1989. Applegate L., Knonsynski, Nunamaker J.F. ' A Group Decision Support System for Idea Generation and Issue analysis in Organisational Planning', in proceedings of CSCW 86, Austin , Texas, December 1986. Armstrong, M., “Management Processes and Functions”, in Management Studies Series, Armstrong, M., Farnham, D. (eds), ISBN 0 85292 438 0. Bannon L., Schmidt K.’ CSCW: Four Characters in Search on context’ in J.M. Bowers and S.D. Benford (eds): Studies in Computer Supported Cooperative Work. Theory, Practice and Design, North-Holland, Amsterdam, 1991. Birman, K., and K. Marzullo. 'ISIS and the META Project.' Sun Technology Sun Technology No.: Summer, Pages: 90104. Blair, G.S., Coulson, G., Davies, N., Williams, N., “Incorporating Multimedia in Distributed Open Systems ”, Proc. EUUG Spring ‘91 Conference on Distributed Open Systems in Perspective, Tromso, Norway, May 1991. Brobst S. A., MaloneT., et al. 'Toward intelligent message routing systems' In:, R Uhlig (Ed.), Computer Message systems -85. Proc. of the 2nd International Symposium on Computer Message Systems. North Holland, Amsterdam, 1986. Byrne, W.R., Kilm, T.A., Nelson, B.L., Soneru, M.D., “Broadband ISDN Technology and Architecture”, IEEE Network, pp 23-28, Jan 1989. CCITT (1987) ' Draft Recommendation on Message Handling Systems, X 400, Version 5' , November 1987. Cheriton, D.R. 'The V Kernel: A Software Base for Distributed Systems.' IEEE Transactions on Software Engineering IEEE Trans. on Soft. Eng. Vol: 1 No.: 2, April, Pages: 19-42. Cook P., Ellis C., Graf M., et al ' Project NICK: Meetings Augmentation and Analysis', ACM trans. on Ofiice Information Systems, Vol 5, No 2, Aprill 1987,pp 132-147. Croft W.B, Lefkowitz L.S. ' Using a Planner to support office work' in Allen R.B.(ed) COIS88 Proceeding conference on Office Information Systems, March 2325,1988, Palo Alto, California.
18
[Crowley 90]
[Danielson 88]
[De Cindio 86]
[Ellis 91] [Ellis 91]
[Fish 88]
[Gelernter 85]
[Goscinski 91] [Greenberg 91] [Grief 88]
[Hahn 89]
[Herrmann 88]
[Hiltz 78]
[Hopper 88]
Crowley T., Milazzo P., Baker E., Forsdick H., Tomlinson R. ' MMConf: An infrastructure for building shared multimedia applications', in proceedings of CSCW 90, Los Angeles, CA, October 7-10 1990, ACM press , ISBN 089791-402-3. Danielson T., Panoke-Babatz U. ' The AMIGO Activity Model ', in R. Speth(ed) EUTECO 88: Research into Networks and Distributed Applications, Vienna, Austria, April 20-22,1988. De Cindio F., De Michelis G.,et al ' CHAOS as a Coordinating Technology', in proceedings of CSCW 86, Austin, Texas, December 1986. Ellis C.A., Gibbs S.J., Rein G.L. ‘ Groupware some issues and experiences’, Comm ACM Vol 34, No 1, January 1991. Ellis, C.A., S.J. Gibbs, and G.L. Rein. ‘Groupware: Some issues and experiences.’ Communications of the ACM Vol: 34 No.: 1, January, Pages: 38-58. Fish R.S., Kraut R.E., Leland M.D., Cohen M. ' Quilt: A colloborative tool for cooperative writing', in Allen R.B.(ed) COIS88 Proceeding conference on Office Information Systems, March23-25,1988, Palo Alto, California,. Gelernter, D. 'Generative Communication in Linda.' ACM Transactions on Programming Languages and Systems Vol: 7 No.: 1, January 1985, Pages: 80-112. Goscinski A. ‘ Distributed Operating Systems. The logical design’, Addison Wesley, Sydney, 1991. Greenberg, S.(ed) ‘ Computer supported cooperative work and groupware’. Academic Press, London. Grief I.(Ed) 'Computer Supported Cooperative Work: A Book of Readings', Morgan Kaufmann Publishers, San Mateo CA., 1988, ISBN 0-934613-57-5. Hahn U., Jarke M., Kreplin K.et al. ‘ CoAuthor: A hypermedia Group Authoring Environment’ In Proceeding of EC-CSCW, the 1st European Conference on CSCW, Gatwick Hilton September 13th-15th 1989. Herrmann, F., F. Armand, M. Rozier, M. Gien, V. Abrossimov, I. Boule, M. Guillemont, P. Leonard, S. Langlois, and W. Neuhauser. 'CHORUS, A New Technology for Building UNIX Systems.' Proc. EUUG Autumn Conference, Cascais, Portugal, October 1988. Pages: 1-18. Hiltz S.R and Turoff M. 'TheNetwork Nation: Human Communication via Computer', Addison Wesley, New York,1978, ISBN 0-201-03141-8. Hopper, A., Needham, R.M., “The Cambridge Fast Ring Networking System”, IEE Trans on Computers, Vol. 37, No. 10, pp 1212-1223, Oct 1988.
19
[Hopper 90]
[Johnston 89]
[Jones 86]
[Jones 86]
[Kerr 82]
[Kraemer 88]
[Lauwers 90]
[Lee 90]
[Malone 88]
[McCool 87] [Mullender 86]
[Palme 84]
Hopper, A., “Pandora - An Experimental System for Multimedia Applications”, ACM Operating Systems Review, Vol. 24, No. 2, April 1990. Johnston, G.M., and R.H. Campbell. 'An Object-Oriented Implementation of Distributed Virtual Memory', Internal Report University of Illinois at Urbana-Champaign. 1989. Jones, M.B., and R.F. Rashid. 'Mach and Matchmaker: Kernel and Language Support for Object-Oriented Distributed Systems.' Proceedings of the Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA '86), Portland, Oregon, 1986. Editor: N. Meyrowitz, Special Issue of ACM SIGPLAN Notices, Vol: 21, Pages: 67-77. Jones, M.B., and R.F. Rashid. 'Mach and Matchmaker: Kernel and Language Support for Object-Oriented Distributed Systems.' Proceedings of the Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA '86), Portland, Oregon, 1986. Editor: N. Meyrowitz, Special Issue of ACM SIGPLAN Notices, Vol: 21, Pages: 67-77. Kerr E.B., Hiltz S.R. ‘ Computer Mediated Communication Systems - Status and Evaluation ‘, Academic Press, New York , 1982. Kraemer K L, Kling J L ' Computer based systems for cooperative work and group decision making', ACM Computing Surveys, Vol 20, No 2, June 1988. Lauwers J.C., Lantz K.A. ‘ Collaboration awareness in support of collaboration transparaency: Requirements for the next generation of shared window systems’ Proceedings of CHI ‘90 Seattle, Washington April1-5, 1990, ACM press, ISBN-0-201-50932-6. Lee J ' SIBYL: A tool for managing group decision rationale', in proceedings of CSCW 90, Los Angeles, CA, October 7-10 1990, ACM press , ISBN 0-89791-402-3. Malone T W, Lai K, ' Object Lens: A Spreadsheet for Cooperative Work', in proceedings of CSCW88, Portland, Oregon, September 1988. McCool, J.F., “The Emerging FDDI Standard”, Proc. Systems Design and Integration Conference, Feb. 1987. Mullender, S.J., and A.S. Tanenbaum. 'The Design of a Capability-Based Distributed Operating System.' The Computer Journal Vol: 29 No.: 4, pp 289-299. Palme, J., 'COM/PortaCOM conference system Design goals and principles', INTERACT '84, B. Shackel (Ed.), IFIP 1985
20
[Petersen 89]
Petersen, L.L., Bucholz, N.C., Schlichting, R.D., “Preserving and Using Context Information in Interprocess Communication”, ACM Trans on Computer Systems, Vol. 7, No. 3, pp 217-246, Aug 1989. [Popescu-Zeletin 89] Popescu-Zeletin, R. 'From Broadband ISDN to Multimedia Computer Networks.' Computer Networks and ISDN Systems No.: 18, Pages: 47-54. [Pullinger 86] Pullinger D.J. ' Chit-Chat to Electronic Journals: Computer Conferencing Supports Scientific Communication', IEEE trans. on Professional Communications, Vol PC 29, No 1, pp23-29, March 1986 [Rodden 89] Rooden T., Sommerville I.. ‘Building conversations using Mailtrays’ In Proceeding of EC-CSCW, the 1st European Conference on CSCW, Gatwick Hilton September 13th-15th 1989. [Root 88] Root R. W., ' Design of a Multimedia Vehicle for Social Browsing', in proceedings of CSCW88, Portland, Oregon, September 1988. [Sarin 85] Sarin S., Grief I.: 'Computer-Based Real time Conferencing Systems', IEEE Computer October 1985, pp 33- 45. [Schmidt 89] Schmidt, K., “Cooperative Work: A Conceptual Framework”, FCI Publication #89-1, The Informatics Centre of the Danish Trade Union Movement, June 1989, ISBN 8789369-00-9. [Sheperd 90] Sheperd A, Mayer N., Kuchinsky A., ‘ Strudel- An extensible elctronic conversation toolkit’, in proceedings of CSCW 90, Los Angeles, CA, October 7-10 1990, ACM press , ISBN 0-89791-402-3. [Shepherd 90] Shepherd, D., Salmony, M., “Extending OSI to Support Synchronization Required by Multimedia Applications”, Computer Communications, Vol. 13, No. 7, pp 399-406, Sept 1990. [Shoch 82] Shoch, J.F., Y.K. Dalal, D.D. Redell, and R.C. Crane. 'Evolution of the Ethernet Local Computer Network.' IEEE Computer, August 1982. Pages: 10-26. [Stallings 88] Stallings, W., “Tutorial: Integrated Services Digital Networks (ISDN)”, IEEE Computer Society Press, 1988. [Stefik 87a] Stefik M., Foster G., et al 'Beyond the chalkboard: computer support for collaboration and problem solving in Meetings', Comm ACM Vol 30, No 1, January 1987. [Stefik 87b] Stefik M., Bobrow D.G., et al 'WYSIWIS Revised: Early experiences with Multiuser Interfaces', ACM trans. on Ofiice Information Systems, Vol 5, No 2, Aprill 1987, pp 147-168. [Sun 87] Sun Microsystems, 'Sun Network File System (NFS) Reference Manual', available from Sun Microsystems, Mountain View, California, 1987.
21
[Tanenbaum 85]
[Walker 83]
[Watabe 90]
[Wilbur 88]
[Winograd 87]
[Zimmermann 80]
Tanenbaum, A.S., and R.V. Renesse. 'Distributed Operating Systems.' ACM Computer Surveys Vol: 17 No.: 4, December 1985, Pages: 419-470. Walker, B., G. Popek, R. English, C. Kline, and G. Thiel. 'The LOCUS Distributed Operating System.' Proceedings of the Ninth Symposium on Operating Systems Principles, October 1983. Pages: 49-70. Watabe K., Sakata S, Maeno K et al ‘ Distributed Multiparty Desktop Conferencing System: MERMAID’, in proceedings of CSCW 90, Los Angeles, CA, October 7-10 1990, ACM press , ISBN 0-89791-402-3. Wilbur S.B., Young R.E. 'The COSMOS Project : A MultiDisciplinary Approach to Design fo Computer Supported Group Working', in R. Speth(ed) EUTECO 88: Research into Networks and Distributed Applications, Vienna, Austria, April 20-22,1988. Winograd T. 'A language/action perspective on the design of cooperative work', Stanford University Department of Computer Science Technical Report , STAN-CS-87-1158. Zimmermann, H., ‘The ISO Model of Architecture for Open Systems Interconnection’, IEEE Trans on Communications”, Vol. 28, No. 4, April 1980.
22
