A Collaboration Architecture and Toolkit
Jeff Kurtz
The MITRE Corporation
202 Burlington Rd
Bedford, MA 01730 USA
+1 781-271-2291
jkurtz@linus.mitre.org
ABSTRACT
This demonstration presents the Joint Collaboration Services (JCS), an architecture and a toolkit for the construction of tailored collaborative environments. A team at The MITRE Corporation has been developing a flexible architecture that supports several key requirements for collaborative environments: the coordination of activities around a theme, easy integration of existing collaborative tools, the distribution of resources for efficiency, software support on multiple platforms, and rapidly configurable client interfaces. From the architecture a toolkit has been implemented using Java and CORBA that gives developers easy access to a suite of collaboration services. This simplifies collaborative tool integration and client software development. The demonstration will show how the toolkit was used to implement a variety of collaboration environments that can be used to coordinate activities, manage user workspaces, integrate applications, and distribute computing resources.
Keywords
Architecture, toolkit, collaborative environment, integration, coordination, distributed services, workspace management.
INTRODUCTION
The Joint Collaboration Services (JCS) is both an architecture and a toolkit. The architecture was developed to meet several important requirements for collaborative environment development. Collaborative environments bring people and resources together so that information can be shared. These environments require
The toolkit is an implementation of these components and ancillary components using Java and CORBA. It provides directory services and factories that help the developer manage and distribute environment resources.
The contribution of this work is an architecture that provides spanning abstractions for collaborative systems and a toolkit for implementation of tailored collaborative systems supporting a wide variety of policy and user experiences.
The demonstration will present the toolkit and three collaborative environments built using it. The clients are distinguished by their collaboration policy and their user interfaces.
CONTEXTS, PARTICIPANTS, ROLES, CONFERENCES
Contexts are abstract metaphor-neutral collections of participants, conversations, and things that serve to factor the total collaborative activity of the system into useful, comprehensible parts. This concept is a generalization of place-based systems that factor collaboration based on space. Contexts are gathering places for collaborations and can be bound to many different representations, metaphors, and purposes; for example, plan objectives, functions, units, common skills, geographic regions of interest, and so on. Contexts are persistent—that is, the context and the documents, tools, and so on gathered there are continuously available—they do not go away when any or all of their users disconnect from the system.
Participants represent users (human or software agents) of the environment. They track the contexts a user is participating in and the conferences being used in those contexts. Each participant may have one or more roles—much as in the workplace, a single employee may work on more than one project and may even have different kinds of duties and different levels of responsibility associated with each project. JCS roles are social cues that indicate a participant’s responsibilities. For example, a participant in the environment may join one context as simply a committee member who needs to participate in discussions, and another context as the person with authority to sign off on logistic plans.
A conference is a shared, multi-participant session under a single point of control, either unimodal or multimodal. It is used by participants to communicate with each other within the virtual environment, and for applications to share data. Examples of kinds of conferences supported in the toolkit include text conferences, in which users communicate using basic "chat" capabilities; multicast conferences, in which participants can use audio and video media; and conferences that allow participants to share and collaborate on documents, data, and objects. Participants may be active in several conferences at once; for instance, participants collaborating on a logistics plan might be sharing data via one conference, and talking about that data via another.
Together these four components can be combined to present users with a collaborative environment. Context consists of participants and conferences. Participants wanting to access a context present their role. They are permitted to join if the roles associated with the context permit. As a member of a context a participant can communicate with other participants using the conferencing tools.
Figure 1: Contexts and their contents

Figure 1 shows a situation in which there are two contexts representing two collaborative activities. Each has a set of participants. Participants P1 and P2 are in both contexts; P3 is only in Context B. In Context A, P1 and P2 both subscribe to the same conferences. In Context B, all three participants communicate via the Text Conference, but only P1 and P3 communicate using the Audio Conference. Every context has a Text Conference, and when a participant joins a context they are automatically placed into that conference. The other conferences have role-based access control.
The toolkit implements these components and provides directory and factory services for them. It also provides a document repository facility so that both contexts and users have documents associated with them.
BENEFIT FOR THE DEVELOPER
Building collaborative environments around the four components offers developers support for coordinating user activities, managing user workspaces, for integrating applications and to distribute system resources. A system implementation using the toolkit is a set of services and clients on the services. Wherever possible mechanism is implemented in the server and policy implemented in the client.
Developers can define a set of contexts that best corresponds to the preferred mechanism for coordinating activities. For example, contexts could be created to match an organization’s structure, the layout of a building, or the phases of a process.
Developers can manage user workspaces by associating tools with certain contexts. When participants switch their focus from one context to the next a different tool set may be presented. Switching to a meeting context might present all the users with an anonymous voting tool. Switching to a development context could present users with a shared object modeling tool.
Integration of applications into the environment is simplified using the conference component. Any application collaborative or non-collaborative can be represented as a conference; this means that any application can be launched from a context. Developers can use the toolkit’s data conference to share information between applications.
The toolkit directory services are machine independent and can be run wherever the resources are available to operate them. On top of that factories can be used to create components on any machine that will run the component. This becomes useful when you have a widely distributed group using the collaboration environment. Consider a group distributed across two sites, say Boston and San Diego. It is likely that there will be contexts only used by the Boston group and others only used by the San Diego group. In that case, contexts used primarily by Boston personnel will be instantiated in Boston. All the resources for that context, then, would be more easily accessed. The same would go for the contexts used primarily by the San Diego group.
These features together give developers a powerful toolkit for rapidly configuring collaborative environments.
DEMONSTRATION AND CONFIGURATION
The demonstration will present the architecture in more detail and show how the toolkit was used to develop a collaborative environment for the planning system.
Figure 2 shows one of the prototype clients we have implemented
while testing the toolkit. In this client there is a focal context, called
Strategy Development, that is occupying the user’s attention. Four peripheral
contexts are present but the user is not active in those contexts. Activity
in peripheral contexts is signaled using a red icon next to the context's
selection tab (not shown here). The focal context has three conferences,
VIC, VAT, and a text conference. VIC is selected so that application has
been launched. Participants in the focal context are shown on the right.
At the bottom of the interface is the folder structure associated with
this context. This and other interfaces will be shown as part of the demonstration.
Figure 2: Sample client implementation

The key concepts to be presented in the demonstration are
PRESENTER INFORMATION
Jeff Kurtz and another member of the design and development team will conduct the demonstration.
ACKNOWLEDGMENTS
This work was funded in part by DARPA ISO under contract DAAB07-97-C-E601.
Scott Budzowski, Jay Carlson, Sasha Caskey, Tari Fanderclai, Rod Holland, Michael Krutsch, and John Ramsdell are active in the design, development and reporting of this work.