There has recently been significant research in the area of collaboration systems, which has resulted in two kinds of systems: collaborative applications and collaborative tools. The former are special software systems that allow multiple users to share application-specific state. The latter are general purpose systems providing reusable implementations of various collaboration functions. They can be used to share existing, collaboration-transparent,
new collaboration-aware, collaborative applications. A large number of complex issues must be resolved in the design of collaborative tools and applications. As a result, (as shown in section III.E) despite the relative infancy of this area, a great variety of collaborative applications and tools have been developed, which resolve different sets of issues and make different tradeoffs. [ Ellis CACM ] [ Olson Trends ] [ Dewan Trends ]
Thus, we have two ways to support a collaboration infrastructure: i) develop a new collaboration infrastructure, or (ii) develop an integrating infrastructure, which we call the ``collaboration bus'', that is designed to combine the capabilities of existing collaborative tools and applications. So far, researchers in this area have taken the first approach. In particular, the researchers in our group have developed multiple collaboration infrastructures with different capabilities/implementations - the Suite effort has investigated support for distributed collaborative architectures, [ Dewan Framework Transactions ] flexible sharing, [ Dewan Coupling Proceedings ] collaborative undo/redo, [ Choudhary Dewan SERC Undo ] and protected I/O; [ shen dewan proceedings ] the XTV effort [ Wahab XTV ] has explored how existing X applications can be shared, and the ABC effort [ Jeffay Smith ] has explored how extendible shared window systems can be implemented modularly. These are ongoing research efforts and being carried out as parts of different projects.
We propose to instead investigate the second approach. This approach is attractive because it allows us to support scenarios of the kind given in sections II.D and III.B. It is possible to develop a new system from scratch that support these scenarios by reimplementing the capabilities of the individual systems, but a tool that allows reuse of the implementation of individual capabilities is a much more attractive option because of the complexity of implementing collaborative systems.
As mentioned before, there are are two important forms of interoperability: inter-service interoperability and intra-service interoperability. Inter-service interoperability allows independent services to be composed with each other. Figure 1 illustrates inter-service interoperability. It allows two applications supporting virtual environments user interfaces to be composed with an application providing coupling. The result is a new application supporting collaborative virtual environments. It allows the users of two VEs to couple with each other, where the coupling between the two users is determined by the coupling manager.
The previous section gives several examples of scenarios needing inter-service interoperability (e.g. scenarios 2, 5, 10, 11).
Intra-service interoperability allows multiple, competing instances of a service to be used for a single task. Figure 2 illustrates such interoperability.
The previous section gives several examples of intra-service interoperability (e.g. scenarios 1 and 3). In this example, the DistEdit and Suite collaborative editors are being used together to manipulate a single document, thereby allowing each set of users to use their favorite editor.
The notion of inter and intra - service interoperability requires an identification of services needed by a collaborative application. These services can be classified into two categories: function services and implementation services. Function services are high-level services that implement the various functions offered by the collaborative system to the user while the implementation services are low-level services used to implement the function services.
Our identification of functions services is based on on the research done as part of the Suite project and by Olson et al, [ Olson Trends ] which has investigated ways to decompose collaboration into independent functions or dimensions. Like a non-collaborative application, a collaborative application must perform semantic and user-interface functions. In addition, it must couple the state of different users to allow them to exchange information and events. Coupling, in term, can be decomposed into several subfunctions: session management, which allows a group of collaborating users to establish a joint session; sharing, which allows users to link the objects they are working on; concurrency and access control, which prevent users from entering inconsistent and unauthorized commands, respectively; and user awareness, which allows users to be aware of the activities of each other through video/audio/text channels. Figure 3 shows the functional decomposition of a collaborative application.
The main implementation service we shall focus on will be real-time support. This support will be used to ensure that all of the functions mentioned above (Figure 3), working together, can meet the real-time needs of the collaborators.
To explain the role of these services, consider a collaborative CAD application. The semantics of the application define the abstract object being designed, and the user-interface defines the actual user view seen by a user of the application. Session manament determines how the different users establish a joint session with the application. It may require an initiator or chairman to explicitly invite all other participants or it may automatically join all users in the same room in a virtual space into a session. Sharing determines how the semantics and user-interface objects created for different users are linked to each other. It may link only the semantic objects or both the semantic and user-interface objects. Moreover, it may synchronously transmit a user's changes to other users or buffer changes until the sender is ready to transmit them and the listener is willing to receive them. Concurrency control would disallow two users from concurrently manipulating the same part of an object in an inconsistent fashion. It may provide a coarse-grained lock for the whole object or
Access control would disallow users from manipulating objects they are not authorized to access. It may provide mandatory or control. User awareness would tell each user about the activities of other users. It may establish a video channel between the users allowing each user to observe the gestures of other users or provide special cursors to indicate gestures. Real-time support will allow real-time collaboration among the users of these services. Inter-service interoperability between, say a) real-time support and other services would ensure that all other services - in particular video and VE graphics - meet their real-time deadlines; and b) coupling and other services would ensure that sharing, access control, and concurrency control are provided for all objects - in particular both objects found in both traditional and VE applications. Intra-service interoperability would allow, for instance,
systems offering (a) explicit and implicit session management to coexist by mapping events from one policy to another and (b) coarse-grained and fine-grained concurrency control to coexist by choosing a compromise concurrency control (coarse-grained) that can be supported by both systems.
The challenge in providing inter-service interoperability is providing an abstract definition of a service in a bus that can be composed with abstract definitions of other services. So far, the research in collaboration systems has explored specific combinations of services rather in abstract service definitions. For instance, the work on coupling [ Dewan Coupling Transactions ] has considered text-based interfaces and developed a parameterized model of coupling that describes all known textual couplings known to us. However, it has not considered graphics, audio, or VE -based interfaces. It is not currently clear how these interfaces must be shared, what events trigger sharing, what it means for concurrent actions on these interfaces to be consistent, what should be the granularity of protection, when and how should users be made aware of the activities of others, what kind of user-interfaces should be provided to specify the protection, consistency, sharing, and awareness parameters, and so on.
Similarly, to date our work on real-time support has has primarily focused on the problem of supporting videoconferencing with digital audio and video. The results of our research have been a number of basic operating system and communication protocol mechanisms for (i) ameliorating the effects of contention for resources in the end- systems and in the network, and (ii) for realizing application-level quality of service requirements. For example, we are presently involved in a collaboration with the Intel Corporation to incorporate the result of this research into a research prototype of the videoconferencing subsystem of Intel's ProShare conferencing product.
However, it is not currently clear what kind of operating and network support should be provided for immersive collaborative virtual environments. We believe that the data generated in a collaborative virtual environment: graphics display lists, object definitions, object position and tracking data, etc. represents a new class of continuous media. Like digital audio and video, these data streams will have delay and loss requirements that will greatly stress operating systems and communication protocols. However, the the magnitude of, and variability in these requirements requires a fundamental rethinking of the problems of management of real-time data in a distributed system. The challenge here is to design small, generic, media adaptations that can sense congestion (possibly with the help of feedback from the receiver) and adapt accordingly. Our current hypothesis is that one can design generic, effective adaptations that scale the media streams (increase or decrease some aspect of the stream) in both the bit-rate and message-rate dimensions.
The challenge in providing intera-service interoperability for a particular service is identifying the design space of the service, and finding a way to translate between systems supporting different parts of this design space. The translation problem is particularly difficult when events in one implementation of the service have no corresponding event in another implementation of it. For instance, a request for a fine-grained lock may have no analogue in a system supporting coarse-grained floor control, an event describing a change to a semantic object may have no analogue in a system that does not distinguish between semantic objects and their views, and an access specification provided by a system supporting discretionary access control may have not be allowed by a system supporting mandatory control.
It is not possible to develop a bus that allows arbitrary applications to interoperate with each other. However, it is our hypothesis that it is possible to develop one that allows a significant fraction if not most of the ``typical'' collaborative applications to be interfaced with each other. In general, integrating two collaborative systems will require that each be made ``bus aware'', that is, modified to communicate with the collaboration bus. Once these systems have been modified, however, other systems can be integrated with them without requiring additional changes to these two systems. Thus, the bus, like previous heterogeneous tools such as IDL, would require n translations rather than n square translations if n systems need to be integrated with each other. Often, it is not desirable or possible to change an interfacing client. Therefore, we intend to explore methods for interfacing with the bus that do not require changes to collaborative systems and explore the kind of integration methods that can be supported by these techniques.
While the bus is a central logical structure, it must not be allowed to become a central physical bottleneck. There has been significant work in process replication [ MMConf ] and migration [ Emerald ] and we propose to apply it to the concept of the bus. We propose to determine which parts of the bus must be replicated, which must be centralized, which of the centralized objects should be migrated, and what kind of mechanisms and policies should be provided for supporting migration. We will consider migration/replication of not only the parts of the bus but also its clients. For instance, the bus may automatically replicate a VE client on the host of each user wishing to enter a joint session with it. Figure 4 illustrates migration and replication of the bus and its clients. The VE client and the real-time services are replicated while the lock object is a migrating centralized object.
mechanisms must be developed to secure the bus. These mechanisms will complement the access control provided to protect the operations on the clients interfacing to the bus. Bus access control will protect the operations on the bus, which may indirectly affect the interfacing clients. For instance, it will protect unauthorized users from adding new coupling managers for connecting two VE interfaces (Figure 1).