As a motivation for the concept of a collaboration bus, consider two conferencing scenarios:
Scenario 1: Suppose four geographically separated users, A, B, C, and D, wish to collaboratively discuss and annotate a mission plan document.
Each one of them is using a text editing facility to compose notes and annotations for the document. Collaborators A and B use a specialized multiuser editor that allows them to couple their text buffers without coupling their scrollbars, lock
examined. Users C and D are unwilling to learn this editor, and prefer instead to use shared window systems, which allow them to share existing single-user editors. Each of them, however, prefers a different shared window system. User C wishes to use ODU's XTV shared window system while user C wishes to use HP's Shared X. Both shared window systems provide capabilities to completely couple
but differ in the
concurrency control, and session management they support.
Scenario 2: Consider now an architectural VE built for visualizing new ship designs; it allows an individual to construct a 3-D model of a new ship and to "walk through" the ship, experiencing the design from a ship-dweller's perspective. Consider also a second VE built to simulate a group conference; it allows a collection of individuals physically remote from one another to experience a face-to-face meeting in a virtual 3-D environment. Could we not combine these two systems
so they interoperate, allowing a group of physically separated people to virtually walk through a ship "together," communicating as a group?
The services offered by a variety of single-user and collaborative systems are being used above to facilitate two distributed, real-time collaborations. Without this integration, the collaborations may not have taken place. In the first case, the different users may not have been able to agree to use a specific window system and text editor. In general, formation of work groups is dynamic, usually in response to an identified need, and brings together people with different training, different skills, and different work habits. Therefore it is crucial to support scenarios such as the first one. In the second case, the alternative to integration of the two systems is a new system that supports the capabilities of these systems. However, the expense and time required to build new collaborative systems makes the integration approach far more attractive.
These scenarios are currently far from possible since current collaboration tools have not been designed to work with other tools and several complex issues must be resolved before these tools can be made to interoperate with each other. This problem is not peculiar to collaboration systems and specific solutions have been addressed for heterogeneous programming languages, operating systems, database systems, and software engineering. This project will explore the instance of this problem that has arisen in the area of collaboration. It is our hypothesis that it is possible to develop a new abstraction, called the collaboration bus, that interconnects existing single-user applications and collaboration systems and facilitates new, useful kinds of collaborations at far less expense than existing abstractions. This abstraction, like interconnecting technologies in other domains, can be expected to be an effective solution to the heterogeneity problem
to a bus abstraction is far cheaper than writing a cross-translation module for every different pair of tools that might want to interoperate.