Building Collaborative Problem-Solving Environments as Shared Places

Lukasz Beca

CollabWorx

Abstract

1. Introduction

The problem-solving environments (PSE) field is developing rapidly. Many diverse products are available, for example, Extensible Computational Chemistry Environment [15] provides support in the domain of computational chemistry and AutoCAD [3] offers tools for the industry design. This trend is driven by steady progress in many branches of computer industry. Advanced distributed data storage and retrieval systems are available for archiving results of experiments or domain specific information necessary to solve complex problems. Computing facilities such as specialized hardware, mainframes or computers organized into clusters are used to provide significant computational power. Large suites of advanced, domain-oriented software modules are available. They encapsulate the algorithms relevant for a specific class of problems (for example, PELLPACK [11] offers comprehensive support for solving partial differential equations). Finally, visualization tools such as AVS [1] [17] are used to analyze and present complex data. All those developments enhance problem-solving capabilities of current software systems.

As far as collaborative PSEs are concerned, the research is still in progress. Such environments should provide the functionality of a PSE and, in addition, allow system users to work as a team in a manner independent of their location and the time they access the PSE resources. However, the problem is still far from being solved. The main reason for such a situation is the difficulty of building efficient collaboration environments in general, and merging them with problem-solving environments in particular. A collaborative application always has a form of a distributed system, which is not trivial to build. Also, in spite of significant research progress, social issues that arise in virtual groups are not addressed properly by the currently available collaborative environments. As a result, most of the on-line collaboration systems are difficult to use and offer limited functionality. Therefore, it is understandable that the designers of most PSEs concentrate on the problem-solving functionality, postponing implementation of the collaboration functionality till the mentioned difficulties are resolved.

Many of enumerated problems could be solved by applying available Web technologies and resources. Several systems such as Collaborative Research Environment (CORE) [18] and TANGO Interactive [5] make steps in this direction. As the Web infrastructure becomes more mature, as the browser platforms become more sophisticated, and as new Internet standards such as XML [20] emerge, new collaboration solutions become possible. XML offers standardized approach to data description, ability to create compact documents, and wide availability of software tools for creating and processing documents. Component technologies such as JavaBeans [19] and ActiveX [8] allow easy creation of Web-based collaboration tools, fast transfer over networks, and interoperability. Web browser platforms provide ability of dynamic generation and modification of Web page content, and execution of components fetched over the network. We propose a framework that is based on these technologies and enables construction of customized Web-based collaboration environments integrated with Internet resources.

Our solution, Shared Place, is composed of two parts. Shared Place framework provides necessary services for building variety of the collaboration components that allow synchronous and asynchronous teamwork on the Web. Shared Place Definition Language (SPDL), an XML-based language, describes properties of a virtual place: Place appearance, behavior of collaboration components present in the Place, and access to the Place resources. By combining these two parts we want to create a platform for building virtual places on the Web, which are conceptually similar to the shippable places introduced in [14]. In our work we apply experience gained during construction of Web-based collaboration frameworks (TANGO Interactive), and from building environments for distance learning and the virtual meetings.

A part of the material presented in this paper was introduced in [4]. It is included here to provide self-contained presentation and it is discussed in the context of building CPSEs.

2. Requirements for Collaboration Layer of CPSE

A collaboration framework must satisfy certain set of requirements in order to become an efficient collaboration layer of a CPSE. Under the notion of a collaboration framework we understand software architecture that (1) implements collaboration services and (2) allows for development of collaboration-enabled tools that use those services.

2.1. General Requirements

The following list of features must be supported by every Web-based collaboration framework:

Communication services. Communication services enable distribution of changes in the collaborative application state among instances operated by different users. Also, they enable interaction among tools operated by the same user.

Synchronization mechanisms. Execution of many tasks in a distributed environment requires ability to synchronize actions performed by users of the system. Such mechanisms are used for controlling access to system resources and enforcing consistency of distributed state.

Persistence. The collaboration framework must provide mechanisms that enable storage and retrieval of the results of the collaborative work. Such functionality can be implemented as archiving the state of a collaboration tool or recording of the entire process that led to the final result.

Access to awareness information. Awareness information includes the state of resources used in collaboration, availability of the users, and information about activities performed by the users. This information can be employed by collaborative tools to help a user of the system to relate his/her actions to the actions executed by other users.

Session management mechanisms. Collaborative session groups users who employ tools and other shared resources to solve a specific problem together. The session management mechanisms are used for setup and termination of collaborative sessions.

Support for various collaboration policies. Different applications need different collaboration policies. For example, two scenarios are possible during scientific collaboration. The scientists first set up parameters for computations and later they deliver presentation of the results to a larger group of spectators. In the former case the scientists can work in peer-to-peer fashion. They can freely discuss the parameters of the computing process and gradually they arrive to the most optimal solution. In the latter case, one scientist should be distinguished as a master user and have exclusive control over the presentation tools in order to deliver the presentation of the results in the most efficient manner without unsolicited interruptions. The collaboration framework should be sufficiently flexible to adapt to the required policy.

Integration with the Web infrastructure. World Wide Web became a standard way of providing access to resources and services. It enables easy publication of documents and data, and straightforward implementation of interfaces to computing services. Therefore, extensible collaboration framework must provide mechanisms for accessing the Web infrastructure. Integration with the Web infrastructure can be supported on many levels. For example, Web repositories can be used as a source of data for the collaboration tools. The collaboration framework may also support building collaboration tools as Web services.

Application Programming Interfaces (API). APIs must be defined to provide access to all described above services. Also, the guidelines for the application development such as design patterns must be offered to collaboration environment developers.

2.2. CPSE-specific Requirements

CPSEs impose a number of requirements on the collaboration framework that are determined by the needs of problem-solving applications:

Integration of synchronous and asynchronous collaboration. Collaborative problem-solving activities, especially those that are carried out over extended periods of time, involve utilization of synchronous (communication, synchronization, awareness) and asynchronous (persistence) collaboration services. The synchronous services are used to support virtual meetings, presentations, or shared access to the resources. The asynchronous services maintain the state of the collaborative work over multiple synchronous sessions and enable access to the data repositories.

Support for multiple platforms. The scientific and problem-solving environments are built for various platforms, therefore, the collaboration framework for a CPSE should operate on as many platforms as possible.

Customizability. The collaboration layer of a CPSE should be configurable for wide array of problems, so that it can adapt to needs of various tasks supported by a CPSE and various models of group work. It should be also reusable, so that it can form a base for multiple CPSEs.

Conformance to standards. Conformance to standards ensures that the environments constructed using collaboration framework will be able to reuse solutions developed by others.

Support for communities. A group of the users working on the same problem in natural manner forms tightly integrated community. Since the collaboration layer of a CPSE is supposed to directly support group activities, it should provide means for mapping this social concept onto virtual domain.

Security. The collaboration layer of a CPSE should provide mechanisms for authentication, authorization, and secure communication in the boundaries of the community. These services should be implemented in such a way that unnecessary overhead to the CPSE users is not introduced.

Interfaces to the legacy resources. Many applications that have already been used for some time can also be useful in new settings; therefore the collaboration layer should be flexible and accommodate such resources.

Integration with other layers of a CPSE. The collaboration layer of a CPSE must present a consistent interface to other layers that directly support problem solving functionality, communicate with data repositories, or with scientific instruments.

In the next sections, we will show how the Shared Place technology addresses the requirements enumerated above.

3. Shared Place Concepts

This section introduces concepts essential for understanding of the Shared Place technology. As the name indicates, the main purpose of this technology is to provide a platform for creation of Places on the Web—virtual spaces where people can meet and interact. Shared Place model distinguishes concepts of Place, Visitor, Tool, Gate, Agent, and Artifact.

A Place corresponds to a physical place in the real world. It provides boundaries within which the intended interactions occur. A Place can contain Artifacts, Visitors, Agents, Tools, and Gates. Visitors present at the Place can interact directly with Agents, Tools, and Gates gathered here. Visitors interact indirectly (by using Tools) with Artifacts and other Visitors. The Place is persistent; its content is preserved when all Visitors leave. The Place can also provide Gates to other Places, so that groups of interconnected Places can be defined.

A Place has a number of customizable properties. It is possible to specify names of Visitors that are allowed to enter the Place and assign them to the Visitor groups. Another element of the place description is a set of behavior rules that form a place policy. Policies impose various restrictions on the model entities depending on the desired Place functionality. For example, a description of a Place may specify allowed and disallowed types of Artifacts and Tools.

A Visitor represents a user in a Place and is similar in some aspects to the concept of an avatar in Multi-User Virtual Environments (MUVE) [12]. All actions that a user executes on the content of a Place are performed by the Visitor. Visitors can enter and leave the Place using Gates. A Visitor can interact with the Place Artifacts using Tools and carry his/her own Personal Artifacts. Visitors can interact with Agents. They can also communicate with each other using Tools. One user can be represented by several Visitors remaining in different Places at the same time. Usually, a Visitor has some role assigned in the Place. A role is used to determine how other Shared Place entities react to the Visitor's actions. A Visitor cannot assume several roles in the same Place.

A Tool provides means of interaction between Artifacts and Visitors, as well as among the Visitors themselves. Tools can be used to perform various tasks such as providing awareness information, Artifact management, communication, collaborative work, or modification of Artifacts. Tools may behave in different way depending on the type and mode of the Artifact they operate on, and the role of the Visitor that uses them. Their behavior is defined by the Place policy rules. Tools can be associated with a given Place or brought to a Place by a Visitor.

A Gate is an entity that enables Visitors to move from one Place to another. It is similar to an HTML hypertext link but a Gate can also perform more complicated tasks such as authentication or providing information about the Place that the Visitor is about to enter.

An Artifact represents content of an arbitrary type that can be created and accessed by a Visitor using Tools. It is essentially a data container such as a Web page, a document, an image, a stream of data, an entry point to information stored in a database, or a set of links to other Artifacts. Artifacts can be moved from one Place to another by Visitors. However, some Places may put limitations on types of imported and exported Artifacts. An Artifact can exist in one of two modes—as a Personal or as a Public Artifact. A Personal Artifact belongs to a Visitor. A Visitor can possess an arbitrary number of Personal Artifacts. Personal Artifacts are Place independent and can be carried from one Place to another. Public Artifacts are a part of the Place content. They are visible to the user accessing the Place if a Tool appropriate for displaying Artifacts is provided. Artifacts have a number of properties such as a type, an expiration date, information about author, a date of modification, and a pointer to a Tool that can be used to access the content. The Shared Place framework activates the Tool indicated by information associated with an Artifact when the Place does not have a specific Tool assigned to this type of Artifact.

An Agent may perform actions on Public Artifacts on behalf of a Visitor while he or she is not present in the Place. Those might be administrative tasks—removal of expired Artifacts or update of time-sensitive content of the Artifact. Agents can also act without any authorization from a specific Visitor. Moreover, Agents may have social tasks to perform such as greeting Visitors, or offering instructions on how to use certain Tools.

Tools, Gates and Agents are software components (referred to as collaboration components in the following sections of this paper) that can be implemented by the developers who have access to the Shared Place API. The functionality of these components depends on the tasks to be solved. A Tool might be a chat, whiteboard, data visualization application etc. A Gate must provide the basic functionality of transfer to the next Place but can offer additional features such as authentication of a user. Agents do not have any default tasks assigned. They have access to the state of a Place, but they do not have to offer any collaboration functionality. We are still working on the API for Agents. Current design assumes that an Agent is composed of two components, one is present at the Shared Place server and can execute tasks even when the Place is not being accessed by any user. Another component is responsible for presenting a graphical interface to the Place users and is activated whenever a Visitor representing a user enters the Place. The part present at the Shared Place server can be downloaded and executed by the server. This approach is similar to the solution adopted by the JINI technology [2] developed by Sun. We also envision the possibility of an Agent being an active party in the communication with the Shared Place server. In that case the Agent can contact the Shared Place server and, if allowed to enter, it can download its server-side component and start execution. In this way the Agent can move from one Shared Place server to another.

More detailed discussion of the Shared Place model and its applications in designing virtual places is included in [4].

4. Shared Place Framework

4.1. Architecture

Figure 1. Shared Place architecture

Shared Place employs currently available technologies such as Web infrastructure, Web browser platforms, and component architectures (see Figure 1). Shared Place Definition Documents are stored on Web servers and can be downloaded as any other Web resource. The collaboration components (Tools, Gates, and Agents) are stored on a Web server together with the SPDL documents that describe their configurable properties. Artifact repository functionality is provided by an HTTP or FTP server. The repository server must be configured in such a way that makes the updates of Artifacts possible. An Artifact may also provide an interface to more complex forms of storage such as database repositories, media streams, or scientific instrument input and output. In addition, Personal Artifacts may be stored on a local machine to allow off-line access. The collaboration services are provided by the Shared Place server, which is implemented as a Java application.

Generation of a Place for a specific user has several steps and requires interaction among a number of entities of the Shared Place architecture (see Figure 2). When the user decides to move from one Place to another, he or she must provide a name and a password to the Place component that implements Gate functionality. When authentication data is submitted, the Gate retrieves the SPDL file that defines the target Place associated with the Gate (step 1 in Figure 3).

Figure 2. Steps in virtual place generation

Using information from the SPDL document, the Gate connects to the Shared Place server that supports the target Place (step 2). Subsequently, the Gate submits the user name and the password to the Shared Place server, which confirms or rejects user's right to enter the Place. If the server does not have the SPDL document describing the Place, the collaboration functionality description part of the document is sent to the server by the Gate component. Next, the Gate component dynamically generates an HTML page from the SPDL document taking into account user's identity and his o her role in the new Place (step 3). The references to the collaboration components in the layout part of the document are replaced by valid HTML tags.

After the generation is completed, the page is interpreted by the browser, which renders the content and downloads the collaboration and framework components from indicated locations (step 4). The collaboration components are visible to the user, whereas the framework components, which implement the collaboration services, remain hidden. Next, the components embedded in the page are initialized and the framework component contacts the Shared Place server (step 5). The framework component retrieves the collaboration functionality description of the Place from the server and parses it. Finally, the collaboration components access relevant behavior properties and initialize accordingly. They also access the collaboration services provided by the framework component. When this step is completed, the Place is ready for interaction with the user.

The Place generation process, although complex, is entirely handled by the Shared Place framework and is transparent to the Place users and the Place developers. It offers significant benefits in the form of easy setup and simplified configuration of the architecture components. With the current approach it is enough to publish SPDL documents on an HTTP server, and start the Shared Place server and the Artifact repository (FTP or HTTP) servers to obtain fully functional Shared Place infrastructure. As the Shared Place technology is based to a large degree on Web architecture, it offers scalable service as far as the access to SPDL documents, collaboration components, and Artifacts is concerned. Performance of the collaboration services is dependent on the computing resources available to the Shared Place server.

4.2. Services

The Shared Place framework offers services that can be used by the developers of collaboration components to construct configurable applications with desired collaboration and problem-solving functionality.

4.2.1. Collaboration Services. The Shared Place framework provides complete set of collaboration services. The design is influenced by the solutions adopted in Java Shared Data Toolkit (JSDT) [7]—a framework offering a set of generic mechanisms that can be used to build collaboration tools. Shared Place offers similar mechanisms in the Web settings and combines them with other services, not implemented by JSDT. For the communication between collaboration components operated by different users or between different collaboration components operated by the same user communication channels can be employed. A communication channel is a transmission medium for events and data. In order to transmit an event, the collaboration component must send it to the channel. In order to receive an event, the tool must subscribe to a channel notification service. The tool is notified whenever new events or data are available in the channel. Channels can be created and destroyed dynamically by the collaboration components. Information about channels is maintained by the Shared Place server, which also takes care of event distribution.

Another service implemented by the Shared Place framework is synchronization. The collaboration components can create tokens and access them in shared or exclusive modes. The collaboration components can also subscribe to the notifications about changes of the token state. Tokens provide straightforward and sufficient mechanisms for implementation of various collaboration models such as mentor/student or peer-to-peer. The state of tokens is maintained and controlled by the Shared Place server.

The Shared Place framework also offers access to properties. A property is a shared variable that is stored by a Shared Place server. It can be of arbitrary type and can be dynamically created and destroyed by collaboration components. After being created, the property can be accessed by any collaboration component that knows the name of the property. It is also possible to subscribe to a notification service that informs about changes of the property value. The Shared Place framework maintains a number of special properties that hold information about the state of a Place. The state data include such information as the name of the Place, the names of Visitors, Tools, Artifacts, Agents, and Gates present at the Place. The collaboration components, by accessing the state data, gain awareness information, which they can display in arbitrary manner. For example, Visitors present at a Place can be represented by a set of icons with associated names.

4.2.2. Access to the Place Description Data. In addition to the collaboration services, the Shared Place framework offers access to the configuration data extracted from the SPDL document that describes a Place. This information is divided into two parts: the Place specific data and the user specific data. The Place specific data is inherently related to the description of the Place and is the same for all users. Such information includes data about Artifacts or Visitors allowed at the Place. The user specific data is related to the behavior of Tools, Agents, Artifacts, and Gates when the user accesses them. Access to the configuration data is provided by the property mechanism described in the previous section.

4.2.3. Storage Services. The storage service enables implementation of asynchronous collaboration. It offers ability to create and access Artifacts that are managed by the Shared Place framework. Artifacts can contain any type of data. The Shared Place framework does not interpret Artifact content. However, it maintains metadata about the Artifact content in a form of the Artifact Descriptor that accompanies the Artifact. The Shared Place framework offers mechanisms for creating and accessing both types of Artifacts: Public and Personal. In a CPSE, Artifacts can be used to store results of collaborative work, data obtained from instruments, or results of computations.

4.2.4. Authentication. Since the Shared Place technology supports Place appearance and behavior customization based on user's identity, authentication is one of the most important services. Authentication is implemented jointly by Gate components and the Shared Place server. Gate components provide interface that allows a user to enter the authentication data that are verified by the Shared Place server.

4.3. Security

Security is an essential part of any system that operates in the Internet environment. We work on the implementation of the secure Shared Place services. There is a number of issues that must be addressed in order to create a secure collaborative environment. Documents that describe the virtual places can be protected from malicious modifications by adding digital signatures to their content. The communication channels can be protected from eavesdropping by implementing communication over Secure Socket Layer (SSL). Authentication procedure prevents unauthorized entries. Collaboration components are signed before deploying in virtual place and must present developer's signature before executing potentially dangerous operations.

4.4. Application of Shared Place Services

The Shared Place services are available as an Application Programming Interface (API), currently implemented as a set of Java classes and interfaces. The next step will involve turning the Shared Place API into a component version using JavaBeans component architecture. In this process we will apply experience gained in the creation of the component based API for TANGO Interactive [6]. The Shared Place API can be used to develop a collaboration component that can be fetched over the network and executed by the browser.

Having introduced Shared Place services, we will describe how they can be used to create a simple tool for collaborative data visualization. We will start with the description of the tool functionality. A data viewer should have ability to present supplied data in a form of 3D or 2D graphs. Moreover, it should allow viewing data in various modes to help discover significant patterns and dependencies. As a collaboration tool, such a viewer must provide ability to communicate with viewers started by other users. It must maintain consistent state among distributed instances—the same view of the data should be presented to all users at all times. Another useful feature would be ability to draw on the presented graph, as well as saving and loading archived graphs. Finally, the tool should support various collaboration policies such as peer-to-peer work when all users have similar rights or presentation mode when one user entirely controls the tool and shows the results to on-line spectators.

To implement described collaboration functionality, various services are needed. Communication channels can be used to transmit changes in the data view and the drawings. Synchronization tokens can be used to impose constraints on the interaction with the tool to assure consistency of the data viewer distributed state. For example, only the user who holds the token should be allowed to change the parameters of the data view or draw on the graph. Artifacts can be used to provide access to the experiment data and to allow archiving of generated graphs. Other tools can complement viewer’s functionality, for example, they can access and display the information about Artifacts and Visitors present at the Place. Finally, the collaboration policy required at a specific Place can be defined in SPDL document that provides the configuration data for all Place tools.

After the development stage is finished, the component is turned into a distribution package and must be digitally signed. The tools for this purpose are available from vendors of the software development tools. The next stage is preparation of the component descriptor document in SPDL format. Such a descriptor provides information about features that the component exposes for customization. In this case it can be a standard view of data presented by the Tool just after initialization, accepted collaboration policies, or the amount of control that the user has over the Tool. Finally, the distribution package and the component descriptor must be deployed on the Web server. Whenever the Tool is requested in the process of dynamic Place construction, the Tool is downloaded, embedded in the Place and initialized with information from the Place Description Document.

5. Elements of Shared Place Definition Language (SPDL)

SPDL is a part of the Shared Place technology that enables description of the customized problem-specific collaboration environments. Its syntax is based on XML. The following sections present all types of SPDL documents and their elements. To make the concepts easier to understand we gradually develop the description of a virtual place using language constructs as they are introduced. As an example we use a Place that can be accessed by scientists for discussion of experiment results.

5.1. Place Definition Document

The first type of an SPDL document is a Place Definition Document. It is composed of two parts. The first part, collaboration functionality description, defines collaboration functionality of the Place. This part is expressed entirely in SPDL. The second part, layout description, defines the appearance of the Place—how the Place is displayed to the user. The template of a simplified Place Definition Document is presented below.

The definition of collaboration functionality of the Place is contained in the PLACE element. Two types of layout, for role1 and for role2 are described by separate HTML elements. The user will see different layout depending on the role assigned in the Place.

5.1.1. Collaboration Functionality Description. The collaboration functionality description is composed of several parts that express various aspects of Place customization. It is contained in the PLACE element of the Place description.

General Place Information. This part of the SPDL document contains general information about the Place such as the Place name and description of its functionality. It also provides the data used to establish contact with the Shared Place server and the repository with Public Artifacts. The following fragment of SPDL specification contains general information about the example Place:

Successive elements contain data about the Place name, Place description, URL of the Shared Place server and URL of the Artifact repository server. As the example shows, the Shared Place server and the repository server can run on different machines.

Users. The users who can access the Place are organized into groups. Each group can contain arbitrary number of members. The following fragment of SPDL specification defines three groups:

We assume that the users working on the research project belong to groups alpha, beta, and gamma. The defined groups are used in further sections of the SPDL document to specify various properties of the virtual place.

Roles. It is possible to assign a specific role to an arbitrary Visitor or to a group of Visitors in the Place. A role is a key construct in the collaboration functionality and layout specification. The behavior of Place collaboration components (Tools, Gates, and Agents) and the Place appearance are determined by the role of the Visitor. Currently, Shared Place supports only static roles; the Visitors cannot switch from one role to another when they are present in the Place. The following fragment of SPDL specification presents an example of the role definition:

In this case, two roles are defined. Researchers from alpha group prepared the experiment, therefore the author role is assigned to the members of this group. The members of two other groups have the guest role.

Behavior. The behavior description part of the Place Definition Document allows definition of templates of behaviors for various Place components. The behavior of a component is defined by a set of properties that have a form of a name/value pair. Some properties have preprogrammed meaning and must be understood by all collaboration components of certain type. For example, all Tools must understand synchronization, floor control, and Artifact access properties. Other properties are component specific. The fragment of SPDL specification presented below describes two types of behavior: full control and limited control:

The full control behavior allows a user to access full functionality of a Tool. The floor control is assigned to the user on demand, and the tool asks for the permission before floor release. Reading from and writing to Artifacts is allowed. Moreover, a Tool displays full user interface. The limited control behavior imposes restrictions on Tool access. The floor control is assigned on demand but it can be taken back without request for approval. Artifacts can be accessed only for reading and the functionality of a user interface is limited.

Tools. Tools are described by the document elements that define unique name of a Tool, associate Visitor roles with Tool behavior rules, and provide information about the location of the Tool Descriptor. Also, additional properties, which are independent of the Visitor role, can be defined. The fragment of the SPDL document below presents example Tool definition element for data viewer:

The definition assigns full control over the Tool to the Visitors who assume role of an author and limited control over the Tool to guest Visitors. Moreover, the location of the Tool Descriptor, viewer.spdl, is provided as well as the style property, which defines overall look and feel of the data viewer.

The Shared Place framework does not implement any mechanisms for enforcing the behavior rules defined for the collaboration components (the Shared Place framework enforces only certain properties, which apply to the entire Place, for example user access). The values of all properties are available to the collaboration component and depend on the Visitor role. It is up to the collaboration component to interpret the behavior properties in meaningful manner. Such approach was taken on purpose. Even though it would be possible to define complete language for description of collaboration functionality, the creation of documents in such language would be time consuming and would lead to complex and difficult to understand specifications. Therefore we require the Tool to understand only limited number of generic properties and allow definition of arbitrary number of Tool-specific properties.

Gates. Gates are defined in similar manner as Tools. However, there is one important additional element in the Gate description: DESTINATION. The destination property points to the SPDL document, which describes the Place the gate leads to. The fragment of SPDL specification included below shows an example Gate description:

Presented Gate offers the same functionality to all users (no POLICY tag) and leads to the Place that enables setup of the experiment.

Artifacts. A Place Definition Document may contain information about embedded permanent Artifacts. Those artifacts cannot be deleted by Tools or Agents. In addition, the Place Definition Document must contain a section that associates Tools with specific types of Artifacts and a section that defines Place-wide access rights to the Public Artifacts.

Agents. A part of the document that describes an Agent follows the same pattern as the description of a Tool. It contains the description of the user interface component and, in addition, the information about the allowed actions of the server side component of the Agent. Also, the Place Definition Document must contain appropriate declaration that enumerates the types of Agents, which are allowed to enter the Place.

5.1.2. Layout Description. The layout can be described in an arbitrary markup language that conforms to the XML specification. In particular, it can be HTML. That gives Place developers the ability to reuse all the resources that are available for building Web pages in construction of virtual places. The layout description contains embedded fragments of the SPDL that refer to the entities defined in the collaboration functionality description. The Place Definition Document may contain specifications of several layouts, appropriate for various user roles. The fragment of SPDL specification included below provides greatly simplified layout description:

Two layouts: for users with the author role and for users with the guest role are defined. Each contains two Tools: a chat and a data viewer defined in the collaboration functionality description part of the document. In addition, the layout specification for authors contains a Gate to the experiment setup Place.

5.2. Shared Place Descriptors

Apart from the Place Definition Document, Shared Place uses other documents: collaboration component descriptors (Tool Descriptor, Agent Descriptor, and Gate Descriptor), Artifact Descriptors, and Visitor Descriptors.

Component descriptors are used to specify properties of Tools, Agents, and Gates. They characterize customizable properties recognized by the collaboration components. Each property is described by a unique name, a type and a set of allowed values. The descriptors of collaboration components contain information about the location of the component implementation.

An Artifact Descriptor is another type of SPDL document. It contains metadata about an Artifact: a location of the content, a content type, a name of the author, a date of the creation. The Artifact Descriptor can also provide information about special mechanisms that are required to access the content of the Artifact. The Artifact Descriptor contains a pointer to the descriptor of the default Tool that can be used to access content of the Artifact.

The last type of document used by Shared Place, Visitor Descriptor, provides identity information about a user represented by a Visitor. It corresponds to a business card presented whenever the user accesses a specific Place. It contains such data as the user name, the e-mail address, the home Web page or Place, and the public key used for data encryption.

6. Related Work

There are many other environments and systems that employ place metaphor: Multi User Dungeons (MUD and MOO) [9], Collaborative Virtual Workspace [13] or TeamRooms [16], but they are not integrated with Web environment and usually they do not allow for dynamic component customization. Artefact [10] is a Web-based framework for building collaborative applications that supports a room metaphor. Artefact rooms are built from a set of HTML frames that contain information about applications, objects and users. The system provides Artefact Definition Language (ADL) that allows building simple collaboration tools by composing HTML and Tcl constructs. Although the approach is similar, Shared Place differs in several aspects. Virtual environments built using Shared Place are not restricted to one type of layout; HTML documents with arbitrary structure can be used to define appearance of the Place. Moreover, Shared Place allows arbitrary collaboration components to be embedded in the document as interactive content to create integrated environment. In addition to collaboration tools, Shared Place supports construction of other specialized components such as Gates and Agents. Finally, Shared Place employs SPDL to describe the functionality of the individual collaboration components as well as the behavior and the appearance of the entire Place.

7. Implementation Status

The Shared Place technology is still a work in progress, however we believe that the main concepts are mature enough to be presented. The prototype versions of the Shared Place server, the framework components, and the SPDL processor are already implemented. Right now we experiment with various descriptions of virtual places to refine the design of the SPDL.

8. Conclusions

Shared Place offers generic platform for building synchronous and asynchronous collaboration environments. It provides services that enable creation of the sophisticated collaboration tools suitable for multiple tasks. It allows the developer to concentrate on problem-oriented functionality of the application.

The Shared Place technology is tightly integrated with the Web infrastructure. There are several benefits of this approach. As Web technologies develop, Shared Place also gains new features. In addition, collaboration components based on the Shared Place platform have access to the vast Web infrastructure of data and document storage. Also, by using only browser as the environment for component execution we gain platform independence. Finally, SPDL documents conform to the standard markup syntax, therefore they can be generated dynamically by Web server modules—servlets, JavaServer Pages, or CGI scripts using information about user preferences and tasks to be executed.

Virtual places created using Shared Place can be extensively customized because each Place is generated from a SPDL specification. However, this feature creates another challenge: how to make the application of Shared Place technology, in spite of the overall complexity of the collaboration environment building process, simple enough to allow users without programming experience to build their own Web Places. This issue is addressed by using intuitive, place-oriented model of collaboration, reuse of already existing Web resources, employment of a XML based markup language to describe properties of collaboration components, and byseparation of tool and Place development process. The last feature is very important because if allows users to create collaborative environments from available components according to their needs.

We demonstrated that Shared Place technology is a feasible platform for development of Collaborative Problem-Solving Environments. Some aspects of the system still require development effort (support for Agents, platform specific tools, synchronized recording of collaboration sessions), but most of the requirements for the collaboration layer of a CPSE identified by us are already satisfied. Also, an extensive library of problem-solving tools must be developed. It is important to understand that not only Shared Place does support design and implementation of specific collaboration tools, but enables building complete environments, which can operate in integrated fashion as well. Shared Place technology tries to realize this goal by merging synchronous and asynchronous collaboration services, component technology, customizability, support for the place metaphor, and reuse of Web resources.

10. References

[1] Advanced Visual Systems (AVS), http://www.avs.com

[2] Arnold, K., O'Sullivan, B., Scheifler, R. W., Waldo, J., and Wollrath, A., The Jini™ Specification, Addison-Wesley, 1999.

[3] Autodesk, AutoCAD, http://www.autodesk.com

[4] Beca, L., "Applications of XML and Customizable Components in Building Virtual Places on the Web", Proceedings of the Ninth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, June 2000, pp. 242-247

[5] Beca, L., Cheng, G., Fox, G. C., Jurga, T., Olszewski, K., Podgorny, M., Sokolowski, P., and Walczak, K., Java enabling collaborative education, health care, and computing, Concurrency: Practice and Experience, Vol. 9(6), June 1997, pp. 521-533.

[6] Beca, L., Fox, G. C., Podgorny, M., Component Architecture for Building Web-Based Synchronous Collaboration Systems, Proceedings of WETICE'99, June 1999, pp.108-113.

[7] Burridge, R., Java Shared Data Toolkit User Guide, Sun Microsystems, Inc.,

http://java.sun.com/products/java-media/jsdt/index.html

[8] Chappell D., Understanding ActiveX and OLE: A Guide for Developers & Managers, Microsoft Press, 1996.

[9] Curtis, P., Nichols, D.A., MUDs grow up: Social Virtual Reality in the Real World, Proceedings of the 1994 IEEE Computer Conference, 1994.

[10] Dobridge, T., Lin, J., Rajan, D., Roscoe, T., Brandenburg, J., Byerly, B., Artefact: A Framework for Low-Overhead Web-Based Collaborative Systems, Proceedings of the ACM CSCW'98, November 1998, Page 189 - 196.

[11] Houstis, E. N., Rice, J. R., Weerawarana, S., Catlin, A. C., Papachiou, P., Wang, K.-Y., Gaitatzes, M., PELLPACK: a problem-solving environment for PDE-based applications on multicomputer platforms; ACM Transactions on Mathematical Software, Vol. 24(1), March 1998, pp. 30-73.

[12] Kauppinen, K., Kivimäki, A., Era, T., Robinson, M., Producing identity in collaborative virtual environments, Proceedings of the ACM Symposium on Virtual reality software and technology, November 1998, pp. 35 - 42.

[13] Mosier, J. N., Deus, L. M., Carlson, J. A., Spellman, P. J., Collaborative Virtual Workspace; Proceedings of the International ACM SIGGROUP Conference on Supporting Group Work, November1997, pp. 197 - 203.

[14] Orfali, R., Harkey, D., Edwards, J., The Essential Client/Server Survival Guide, Second Edition, John Wiley and Sons. 1996.

[15] Pacific Northwest National Laboratory, Extensible Computational Chemistry Environment (Ecce), http://www.emsl.pnl.gov:2080/docs/ecce

[16] Roseman, M., Greenberg, S., TeamRooms: Network Places for Collaboration, Proceedings of the ACM CSCW'96, November 1996, pp. 325 - 333.

[17] Sanner,M. F., Duncan, B. S., Carrillo, C. J., and Olson, A. J., Integrating Computation and Visualization for Biomolecular Analysis: An example using Python and AVS, Proceedings of Pacific Symposium in Biocomputing `99. pp 401-412.

[18] Schur, A., Keating, K. A., Payne, D. A., Valdez, T., Yates, K. R., Myers, J. D., Collaborative suites for experiment-oriented scientific research, interactions, Vol. 5(3), May 1998, pp.40 - 47.

[19] Sun Microsystems, The JavaBeans 1.01 Specification, http://java.sun.com/beans.

[20] World Wide Web Consortium, Extensible Markup Language (XML) 1.0, W3C Recommendation http://www.w3.org/TR/REC-xml, February 98.