Applications of XML and Customizable Components in Building Virtual Places on the Web

Lukasz Beca
CollabWorx

Abstract

The demand for the systems that facilitate human interactions over the World Wide Web is growing. Shared Place is a technology for building collaboration environments tightly integrated with the Web and customized for specific user needs. XML-based Shared Place Definition Language, designed to describe collaboration functionality of the configurable components, can be merged with ordinary Web page content to create specifications of virtual places. This paper discusses basic concepts of the Shared Place technology, the model developed to describe functionality of virtual places, Shared Place documents and the architecture of the system. The discussion is illustrated with the examples of the applications.

1. Introduction

In recent years, the demand for Web-based collaboration environments is growing. Currently, on-line presentations, distance learning, and customer support are beginning to offer interactive applications on the Web. However, many aspects of personal interactions in this environment are awkward and primitive - the most often used collaboration tool is still a chat and sets of static HTML pages. In spite of the enormous potential for building media rich, interactive experiences on the Web, the frameworks that would enable such solution are not widely used. One of the reasons is that HTML was not designed and is not well suited for describing collaboration functionality. It is sufficient for description of the appearance of a Web page but does not address such issues as, for instance, synchronization policy of collaborative applications.

Fortunately, the progress in Web technologies may change this in near future. Important standards such as XML [16] emerged, which enable creating collaboration-oriented languages. Also, of great importance are advances in browser technology. Browser products - Internet Explorer 5.0 and Mozilla currently support XML, Document Object Model (DOM) [15], and other features such as dynamic changes in the structure of the Web page content. Development of component architectures for major programming languages: ActiveX [4] for C++ and Java Beans [13] for Java is another factor. Those advances together create platform for new developments in area of collaboration on the Web.

To explore those opportunities, we launched new research program called Shared Place on the Web. The main assumption we make is that collaboration functionality should be treated as any other Web page content. In this way the Web content can be combined with the collaboration components in order to create new functionality. We believe this approach will enable implementation of efficient Web-based shippable places described in [11] as the next generation of the Web content - the places that can be shipped over the Internet. In our work on Shared Place we build on the experience gained during development of the TANGO Interactive framework [1] and component-based solutions employed in this system for creating collaborative applications [2]. Currently, TANGO Interactive Virtual Classroom [14] is actively used by Syracuse University to deliver online courses.

2. Shared Place overview

A place consists of two important components: a shared space and a social context. Multiple aspects of place metaphor application in development of collaboration systems are described in [12]. We are convinced that both social and spatial aspects are important for successful collaboration and our solution tries to support both factors equally.

Shared Place does not offer collaboration functionality per se, rather it supports construction of virtual places on the Web where people can interact and work together. Users of such virtual places can use content and tools that are present at the place for collaborative work. They can bring their own content and share it with others. They can possibly create new content and take it with them to another virtual place or store it in a personal repository for off-line work. From the user’s point of view, the Shared Place application is an ordinary Web page with added collaboration functionality. Let's imagine a place for stock traders. Such place would contain relevant information in HTML or XML form: stock prices, news updates, and latest data about financial state of various companies. It would also contain collaboration tools such as audio conferencing tools for communication, shared spreadsheets for financial calculations, shared whiteboards for analyzing economic trends, and voting tools for making buy/sell decisions. Such a place could be an efficient work environment and could be created by merging HTML content with collaboration components. Countless other places can be imagined, such as the place for discussing results of experiments for scientists or a place for distance learning.

Shared Place offers significant advantages to software developers and Web site builders. It provides mechanisms that allow separation of software components development from process of building virtual places. Software developers can concentrate on creating various types of collaboration tools using Shared Place API. Whereas content developers can use available collaboration components, Web resources, and Shared Place Definition Language (SPDL) to develop virtual places on the Web. Content developers do not have to deal with complexities of the collaboration component implementation. Hence, people without programming background can create interactive virtual places according to their needs.

3. Model

Collaborative applications must usually satisfy a large set of requirements. It would be convenient to have a model that allows specification of those requirements in abstract terms relevant to the collaboration functionality. Our model is a tool for making the transition from the domain of high-level software requirements to more structured specification of the virtual place. The model is designed in such a way that the description of the application in terms of model entities can be easily transformed to an SPDL document, which in turn is used by the Shared Place framework to create a virtual place with desired functionality. The model is a result of analysis of needs of various collaboration applications (such as distance learning and virtual meeting tools) and is influenced by especially successful MUD and MOO approaches [6].

3.1. Model entities

Shared Place model distinguishes several basic entities:

A Place corresponds to a physical place in the real world. It provides boundaries where the intended interactions occur. Places 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. Places are persistent; its content is preserved when all Visitors leave. They can also provide Gates to other Places. In this way the groups of interconnected Places can be defined. Figure 1 illustrates the Place with Place Artifacts, Visitors, a Gate, and a Tool used by Visitors to work on the Artifact.

Figure 1. Model entities

A Place possesses a number of customizable properties. First, it is possible to specify Visitors that are allowed to enter the Place and assign them to Visitor groups. The Place also contains description of the place policy specified as a set of behavior rules. Policies impose various restrictions on the model entities depending on the desired functionality (see [8] for detailed discussion of policies in collaborative applications). For example, a description of the Place can include allowed and disallowed types of Artifacts and Tools. A description of a Tool can specify the level of control that a Visitor can exercise over the Tool, the level of synchronization that the specific Tool provides, mechanism used for initial state distribution, user interface presented to Visitors, and type of floor control transfer. Rules for Artifacts can describe Visitor’s rights to create, store, copy, or delete Artifacts.

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

A Tool provides means of interaction between Artifacts and Visitors, as well as between Visitors. Whenever the Visitor wants to change state of the Artifact, the Visitor must use a Tool. Tools can be used to perform various tasks such as: providing awareness information, artifact management, communication, collaborative work, or modification of artifacts. Some Places need Tools that implement all these tasks, others will manage to provide required functionality with a subset. 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. Tools can present different interfaces to the Visitors with different roles. Their behavior is defined by the place policy rules. They can be associated with a given Place or brought to a Place by a Visitor.

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 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 basic modes - as a Personal or a Place Artifact. A Personal Artifact belongs to a Visitor. A Visitor can possess arbitrary number of Personal Artifacts. Personal Artifacts are Place independent and can be carried from one Place to another. Place Artifacts are part of the Place content. They can be visible to the Visitors present at the Place if appropriate Tool for managing Artifacts is provided. The Visitors can change the mode of an Artifact by moving it from the Personal pool to the Place space or from the Place space to the Personal pool if appropriate Tools are present.

Artifacts have a number of properties such as type, expiration date, author information, date of modification, and pointer to a Tool that can be used to access the content. The Tool indicated by the information associated with an Artifact is activated when the Place does not have a specific Tool assigned to this type of the Artifact.

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

A Gate is an entity that enables Visitors to move from one Place to another. It is similar to 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.

3.2. User's view of the Place

A user perceives a place through a view. The view can be very different, depending on the purpose and the functionality of the place. The same entities of the model can be presented to the user in different manner in different places. Another factor that influences the view of the place is the role assigned to the user in the place. A user having the role of an administrator has access to more functionality than a user accessing the place as an ordinary customer. The view may also depend on the used device. For example, a view presented on a palmtop should be simpler than the view presented on a desktop machine.

A view is composed of Tools, Gates, Agents and HTML content. Information about Artifacts and other Visitors present at the place is not shown directly in the place view but it can be displayed by dedicated Tools. For example, a Tool can display a list of Personal or Place Artifacts or show Visitors as icons. The user may see all or certain subset of the place entities. If the designer of the place decides that it should be used only for synchronous communication, Artifacts and Agents may not be necessary.

3.3. Example of place description

In this section we describe a fairly complex collaboration system, a customer support place, using concepts introduced by the Shared Place model. We begin with a view seen by a support person. Such a person enters the place as a Visitor with 'Support' role assigned. Necessary Tools for communication with customers include a chat Tool or an audio Tool and a demonstration area. The chat or the audio Tool (whichever is available in the place) has the ability to create logs of conversations in the form of Place text or audio Artifacts. The demonstration area has the ability to retrieve Place Artifacts with the examples of the offered products and provides whiteboard functionality.

Figure 2. Customized place - support person

Two more tools are essential: a Place Artifact manager and a customer presence Tool. The Place Artifact manager enables control over the demonstration Artifacts and the Artifacts created using communication Tools. The customer presence Tool informs the support person that a customer has entered the place and seeks assistance. The support person does not need to have access to his or her Personal Artifacts because all Artifacts necessary to provide the service are available as the Place Artifacts. No Agents or Gates are necessary for the support person.

A customer enters the place as a Visitor with 'Customer' role assigned. The customer has access to the same communication tools as the support person; they are necessary for asking questions and receiving responses, but their functionality is slightly different. They enable archiving of interaction results in the form of Personal Artifacts that the customer will be able to store and consult later. The demonstration area should offer similar functionality. As a result, a Personal Artifact manager is needed to control created Artifacts. The customer support place can also have a Gate to another place where customers can gather and exchange experiences with other customers who bought the same product. An Agent may greet entering customers and offer some forms of assistance. Finally, the place view is complemented with the context content: HTML with company specific widgets or ads of the latest products.

Figures 2 and 3 demonstrate the view of the customer support place as seen by the support person and the customer respectively. The screenshots show the prototype implementation of DirecTouch - the customer support system developed by CollabWorx using the Shared Place framework. The functionality of the customer's interface presented in Figure 3 is not as rich as described in the example above but it is sufficient for basic communication. It is important to notice that the support person has access to more place resources than the customer does. More Tools are available; apart from a chat and a whiteboard, a list of Place Artifacts and a list of present Visitors are provided. Moreover, the chat and the whiteboard Tools operated by the support person have additional controls that allow saving chat and whiteboard content in form of Place Artifacts. Other controls are used for erasing and synchronizing Tool content. In this prototype, integration of the HTML content with collaboration components allowed to create customized appearance of the place.

Figure 3. Customized place - customer

4. Shared Place documents

Shared Place documents have crucial role for the Shared Place concept. Most of the content of the documents is specified in Shared Place Definition Language (SPDL) - the XML-based language providing syntax for describing the collaboration functionality of the virtual place. The Shared Place framework recognizes several types of documents. The most important is the document that describes the place itself. It is composed of two parts. The SPDL part defines collaboration functionality of the place. It has ability to define multiple properties such as users allowed to enter the place, roles assigned to specific users, behavior of collaboration tools, or policies regarding persistence of objects created during collaborative work. It contains entries that describe properties of model entities: the place itself, the users, user groups and their roles, artifacts, tools, visitors, agents, and gates to other places. The place policy is specified in SPDL as a set of behavior rules, which are associated with user roles, tools, artifacts and agents to create complete definition of the place policy.

Figure 4. A fragment of place description in SPDL

Figure 4 presents the fragment of the SPDL part of the place description. It declares two roles - the 'Support' role is assigned to the person that enters the place as John, the 'Customer' role is assigned to any other user that enters the place through gate without authentication. Two behavior rules are declared, later associated with user roles to determine behavior of a chat tool. Information about tool contains URL of the tool description document that contains declaration of collaboration properties supported by the chat and a pointer to the actual implementation of the tool.

The HTML part of the place definition document describes the appearance of the virtual place, and can be different for each user role. In this part a developer can utilize all the resources used in building regular Web page. Entities described using SPDL are embedded in the HTML part of the document by using special tags. HTML is not the only choice here. Other applications of XML such as XHTML can be used.

Shared Place also relies on other documents, specified entirely in SPDL. They describe properties that tools, artifacts, agents, and gates expose for customization. This information is used to check validity of the place definition document. The last type of document used by Shared Place provides identity information about a user. It corresponds to a business card presented whenever user accesses specific place. It contains such data as user name, e-mail address, home Web page or place, and a public key used for data encryption.

5. Architecture

Shared Place merges several technologies such as Web infrastructure, Web browser platforms, and component technologies (see Figure 5). Shared Place documents are stored on Web servers and can be downloaded as any other Web resources. The places are accessed using the components implementing gate functionality. Such a component can be embedded in a regular Web page or it can be a part of a virtual place. When activated by the user, it has the ability to fetch a Shared Place document, translate it into a document with embedded collaboration and Shared Place framework components understandable by a standard Web browser, and display the result as a virtual place in a browser window. The collaboration components are visible to the user, whereas the framework components, which implement the collaboration services and expose them to the collaboration components of virtual place, remain hidden. The collaboration services include user authentication, establishing channels of communication, synchronization, access to place properties, access to policy settings, notifications about changes in the state of the place, and management of persistent artifacts. The services implemented by Shared Places framework are available through the set of Application Programming Interfaces (API). The framework components communicate with the Shared Place server that implements most of the services.

The collaboration components (tools, gates, and agents) are customizable pieces of software developed using available component technologies (for example Java Beans or ActiveX) and Shared Place API. They are stored on a Web server together with the SPDL documents that describe their configurable properties. When embedded in a place, they follow rules described in a place definition document and communicate with the Shared Place framework (through exposed API) to access available collaboration services. As a result, it is possible to create multiple places that look and behave in different manner by changing SPDL specifications or place layout while using the same set of the collaboration components.

Figure 5. Shared Place architecture

The HTTP or FTP servers are used as the artifact repositories. The servers must be set up in a way that makes updates of artifacts possible. An artifact may also provide an interface to more complex form of storage such as database repository, media streams or access to scientific instrument input and output. In addition, personal artifacts may be stored on a local machine to allow off-line access.

6. Related work

Significant research was conducted in the area of separating the computation and coordination mechanisms in collaborative applications. For example, Describing Collaborative Work Programming Language (DCWPL) [5] allows developers to specify multiple coordination rules for the same application. The execution of applications is controlled by external entity - Control Engine, which can interpret DCWPL programs and impose chosen collaboration policy. Shared Place framework is not so restrictive in controlling behavior of collaboration components. Collaboration components access policy settings during initialization procedure and act accordingly.

Artifact [7] is Web-based framework for building collaborative applications that supports a room metaphor. The rooms are built from set of HTML frames that contain information about applications, objects and users. The applications are launched as separate windows with exception of a chat tool, which is permanently built in the one of the room frames. Artifact provides Artifact Definition Language (ADL) that allows building simple collaboration tools by composing HTML and Tcl constructs. It also offers APIs in several programming languages. Our solution 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 (this approach is preferred over launching tools in separate windows). In addition to collaboration tools, other specialized components can be used such as gates and agents. Finally, SPDL can define the behavior of the individual component as well as the behavior of the whole place.

There are many other environments and systems that employ place metaphor such as Multi User Dungeons (MUD and MOO) [6], Collaborative Virtual Workspace [10] or TeamRooms [12] but they are not integrated with Web environment and usually they do not allow for component customization.

7. Implementation status

The early results of the work on Shared Place were presented at XML Developers' Conference in August'99 [3]. The prototype versions of the Shared Place server and the framework components are already implemented and were used to develop virtual places for customer support service.

8. Conclusions

Shared Place technology provides place functionality by merging customizable collaboration components and support for persistent artifacts with the Web content. The Shared Place Definition Language (SPDL), based on XML, allows description of collaboration functionality using conventional markup language. The conformance to the Web standards means that SPDL documents can be processed by widely available XML tools and can be integrated with other Web resources.

The level of customizability offered by Shared Place allows developers to create various environments, from social interaction to work and service oriented places. The process of building places is separated from the development of the collaboration tools. One of the advantages of this approach is the possibility of dynamic creation of the virtual places from the libraries of the components. The dynamic construction of the virtual place can be accomplished by generating Shared Place documents according to user preferences, tasks to be executed or available resources. Whenever necessary, the places can be interconnected to build complex Web communities.

Further work is still needed to include support for dynamic changes of users’ roles and directory services for finding users distributed among different places. Other important issues that must be addressed include security and privacy of the users accessing virtual places.

10. References

[1] 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.

[2] 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.

[3] Beca, L., Fox, G. C., Podgorny, M., Shared Places on the Web: XML for Web-based collaboration and Distance Education, Graphic Communications Association, XML Developers' Conference, August 1999, http://www.npac.syr.edu/users/gcf/montrealxmlaug99/.

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

[5] Cortés, M., Mishra, P., DCWPL: a programming language for describing collaborative work, Proceedings of CSCW'96, November 1996, pp. 21-29.

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

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

[8] Edwards, W. K., Policies and Roles in Collaborative Applications, Proceedings of CSCW' 96, November 1996, pp.11 - 20.

[9] 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.

[10] 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.

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

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

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

[14] CollabWorx, TANGO Interactive Virtual Classroom, http://www.collabworx.com/products/vclassroom.html.

[15] World Wide Web Consortium, Document Object Model (DOM) Level1 Specification: Version 1.0, W3C Recommendation, http://www.w3.org/TR/REC-DOM-Level-1, October 98.

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