HTTP-ICE: An HTTP-Based Distributed Application Framework For Interactive Collaborative Environments*

Eiman Elnahrawy
Department of Computer Science, Rutgers University
Piscataway, NJ 08854, USA
 eiman@paul.rutgers.edu

William C. Cheng
TeleGIF
Marina del Rey, CA, USA
 bill.cheng@acm.org

Leana Golubchik
Department of Computer Science, IMSC, and ISI, University of Southern California
Los Angeles, CA 90089, USA
leana@cs.usc.edu

ABSTRACT 

In this paper, we propose HTTP-ICE: an HTTP-Based Distributed Application Framework For Interactive Collaborative Environments. HTTP-ICE is an alternative framework for the exchange of information between collaboration applications that does not conflict with imposed firewall constraints. Therefore, HTTP-ICE enables users located behind firewalls to utilize such useful technology.

Keywords

Web-based collaboration, Firewalls, HTTP streaming, Synchronous collaboration applications, Interactive applications.

1. INTRODUCTION

Over the past few years the Internet has grown in popularity and in capabilities. Currently, the Internet is used not only for storing and exchanging of information, but also for several forms of collaboration between heterogeneous users. There are currently several collaboration tools available on the Internet to support collaboration such as chat tools, audio and video tools, voting tools, etc. Several tools are also combined in one application framework to form a collaboration application. These applications have facilitated numerous real life tasks such as distance learning, collaborative medical diagnosis, distributed authoring, and so on. However, the malicious intrusions have also grown with the growth of the Internet. This caused the emergence of firewalls as an essential need that safeguards both personal computers and corporate networks from hostile intrusions. Unfortunately, firewalls and collaboration applications have conflicting goals since existing collaborative environment frameworks are based on a heavy use of TCP and UDP ports for exchanging information [1,2]. These ports are likely to be blocked by firewall administrators since they are considered potential threats that carry viruses or possible attacks [3]. This has limited the use of collaboration applications and deprived the Internet users from utilizing such useful technology. This problem is not trivial since there are several administrative domains at each user's side; which results in more complicated constraints that vary from user to user. With the exception of a few chat tool implementations, another key issue that limits the spread of collaboration applications is the lack of a standard for the exchange of information between different implementations. This restricts the collaboration to only instances of the same application. We introduce the HTTP-ICE framework. The proposed framework consists of a communication model and a collaboration protocol. The communication model utilizes the HTTP protocol in order to solve the conflict between collaborative environments and firewalls. The proposed collaboration protocol is a novel protocol for the exchange of information between users in a collaborative environment. This protocol is not tied to a specific implementation of collaboration tools. Therefore, unlike existing frameworks, our framework would enable several collaboration tools of the same type to communicate with each other independently of their implementation details. We discuss the communication model, the collaboration protocol, and the overall architecture of HTTP-ICE in Sections 2, 3, 4, respectively. Section 5 gives an overview of our prototype implementation. Finally, Section 6 concludes this paper.

2. COMMUNICATION MODEL

Our proposed communication model utilizes the reliable HTTP streaming technology where the MIME message formats are used for sending several blocks of data to the client in response to a single HTTP request. It is based on the client-server model. The central server is an HTTP/HTTPS server and all communication between the clients and the server is performed via HTTP. The data blocks routed in the environment are encoded as messages. There are two types of messages used in the communication between the client application instances and the central server: control messages and event messages. The central server uses “HTTP streaming” to push any new message to every client in the environment while the clients communicate with the server using “individual HTTP Post requests”. Each individual request corresponds to one message, and the content-type header field of the request corresponds to the type of the message. Experimental MIME content types are used to define a content-type for each type of the messages. The content-type information is used by the client application and the central server to interpret the messages. Standard structures for the data encapsulated in any message is also defined based on the content-type of the message. These standards enable several client implementations, not necessarily equivalent, to exchange information about collaboration tools independently of their implementation details.

3. COLLABORATION PROTOCOL

We define an event-driven collaboration protocol. The protocol is based on exchanging the minimum amount of information about any update in the collaborative environment, between the clients, in the form of messages. Each client extracts the information included in these messages and interprets it in order to perform the necessary updates. There are two types of messages used in the communication between the client application instances and the central server: control messages and event messages. Control messages are used for controlling the environment, e.g., a join-session message. Client-to-server control messages are processed by the central server, while server-to-client messages are processed by the client application instance. Event messages do not play any role in controlling the environment. They are used for distributing updates in the collaborative environment to all participating users, e.g., a chat message. They contain two kinds of information: the content of the message and the content-type of the message. The content of the message is the description of the tool update. The content-type of the message determines which tool should perform that update. Event messages are initiated by the client applications and not by the central server. The central server does not perform any processing of the content of event messages. It is only responsible for routing these messages, using the same content and content-type of the message, between the participating users. This collaboration protocol can accommodate any synchronous collaboration tool such as a chat tool, a web presentation tool, a whiteboard tool, a file transfer tool, audio and video tools, voting tool, etc. Many types of collaborative environments can be completely constructed using only some of these tools; for example, a distance learning environment, a chat environment, an auction room, and so on.

4. FRAMEWORK ARCHITECTURE

The proposed framework consists of two major elements: the central server and the client application. The central server is responsible for: (1) storing all the information about the collaborative environment in a database, (2) routing event messages between the clients, and (3) logging all the activities. The framework can be fairly easily extended to the case of multiple distributed servers. The client application can be further divided into two elements: the core element and the local collaboration tools. The core element is responsible for managing the two way communication between the collaboration tools and the central server. The core element itself consists of the Sender, which is responsible for sending the messages in the form of HTTP requests to the central server, and the Receiver, which is responsible for listening to all incoming messages from the central server via the HTTP stream, and for processing them appropriately based on their type. The local tools are responsible for: (1) parsing messages delivered by the core element to extract the update information and performing the appropriate action accordingly, (2) encapsulating any update in the tool, performed by the user, in an event message, and then delivering the message to the core element, in order to be sent to the central server. Figure 1 illustrates the elements of the framework. The dashed line represents the communication between the client and the server using individual HTTP requests. The solid line represents an HTTP stream, used by the server to communicate with the client.

Figure1: HTTP-ICE Framework Elements

 

5. PROTOTYPE IMPLEMENTATION

We have built an implementation of our proposed framework entirely in the Java programming language. In particular, the client and the server sides were developed using Java 2 Software Development Kit JDK1.3.1. Java Web Server JSDK 2.1 offered by Sun Microsystems as a stand-alone servlet engine was used for running the server prototype. Our prototype supports the following tools: a chat tool, a web browser, an audio and video tools, and a file transfer tool. Each client implementation also displays a list of the current participating users. Figure 2 demonstrates the use of our prototype in a typical distance learning environment.

Figure 2: Distance Learning Session

 

6. CONCLUSIONS

We presented an HTTP-based framework for collaboration applications and discussed its advantages over existing frameworks. We discussed the communication model and the collaboration protocol of the proposed framework. We also presented the framework architecture. Finally, we gave an overview of the prototype implementation and demonstrated it using a distance learning application.

7. ACKNOWLEDGEMENTS

This work was supported in part by the NSF ANI-0070016 grant.

8. REFERENCES

1. A. Chabert, E. Grossman, L. Jackson, and S. Pietrovicz.  NCSA Habanero- Synchronous Collaborative Framework and Environment.  http://havefun.ncsa.uiuc.edu/habanero/whitepapers/ecscwhabanero.html.
2. Microsoft Corporation, Windows NetMeeting home page. http://www.microsoft.com/windows/NetMeeting/.
3. W. Cheswick and S. Bellovin. Firewalls and Internet Security: Repelling the Wily Hacker. Addison Wesley, April 1994.

 

 

* This work was done while Eiman was at the Department of Computer Science at the University of Maryland, College Park. This work was partly done while William Cheng and Leana Golubchik were with the Department of Computer Science and UMIACS at the University of Maryland, College Park.