Building Collaborative Web Browsing and Chat into Standard Web Pages

Master Thesis Proposal

 

Patricia Ferrao

September 28, 2003

 

 

 

 

 

 

Committee Members and Signatures:

   Approved by                                           Date
 
   __________________________________                    _____________
   Advisor: Dr. Edward Chow                        
 
   __________________________________                    _____________
   Committee member: Dr. Xiaobo Zhou
 
   __________________________________                    _____________
   Committee member:

 

1.   Introduction

Web collaboration is a hot topic in the Internet world today. It is also a broad topic, including applications such as multi-media chat [5][7][18], white-boarding [10][8][4], application sharing [5][7][6], corporate conferencing [6][7], slide-show presentation [6][7], web browsing [7][2][10], clipboard [8], and collaborative games [18]. Most applications available today are designed for corporate use and are not in the public domain [5][6][7]. They involve heavy-weight protocols such as H.323 and T.120 [7][6]. Some application vendors use their own proprietary protocols, which makes interoperability among different vendors very difficult [19]. Expensive, vendor specific SDK packages are required for any necessary customization [6][10]. Most applications are designed by server vendors who customize for their particular servers [5][18][19]. This leads to high capital expenditure for corporations, and takes the personal user out of the picture completely. The web collaborative applications that are available in the public domain include MSN messenger [18], AOL instant messaging [19] and Yahoo messenger [20]. For the most part, they use their own proprietary protocols, are platform specific, and do not interoperate with each other. Furthermore, they do not work well across firewalls, require application downloads or browser plug-ins, and do not allow users to enhance, customize or build applications around them.

 

I propose to implement a web-based application that allows the casual user to chat and browse the web with a group of friends. My application will be HTTP based, require no pre-registration, and no extra downloads. The user can login to the system from anywhere and immediately start collaborating.  All he needs is access to the Internet, a web browser, and a session login and password.  My application will use only light-weight, open source technology such as Tomcat J2EE server [21], Java servlets, Java pushlets [1][22], Javascript and Dynamic HTML. It will work across firewalls, since most firewalls allow HTTP to be enabled. Furthermore, it will set the groundwork for web designers to implement similar collaborative applications that can easily be integrated into standard web pages.

 

2.   Collaborative Web Application

2.1 Architecture

 

Figure 1: System Architecture

 

My application will be based on the architecture shown in Figure 1. There will be a directory server that will make use of a database, a backbone server that will also make use of a database, two client servers (although there can be many), and a few clients. The clients will initially communicate with the directory server through a URL such as “cs.uccs.edu/~pferrao/webbrowsing.html”. The directory server will redirect the client to a client server with available resources to serve the new user.  The client server will then present the user with a “Welcome Page”, and prompt him for a group id, group password, and user name. The group id and password will have to be pre-determined by the group members through other means, such as by email or telephone. The user name will be used to identify the user to others in the group. The client server will give the group id and password to the backbone server for authentication. If the backbone server does not know about the group id, it will create an entry for it in its database.

 

Once a user gets by the login page, he will be presented with a collaboration page made up of four frames: a control and status frame, a web browsing frame, a chat frame, and a hidden frame providing the communication with the client server. The control and status frame will allow the user to become master of the browsing session. The master is the only one allowed to affect the browsing view. When the master types a URL or clicks on a link, everyone in the group will browse to the new page. The control and status frame will display the login names of all group members, and indicate who is the master. Everyone can use the chat frame to discuss the browsed content, or argue over who should get control of the session next. The hidden frame will maintain a HTTP connection with the client server application. The client server will use the persistent connections to push status, text messages and URL information to the clients, one connection per client. The server will hold the connection to a client for as long as the client remains in the session. This will allow the server to push new content to the client as required. The client’s hidden frame will receive the server updates and send text messages to the chat frame, status information to the status frame, and URL information to the collaborative browsing frame. The collaborative browsing frame will use the URL to fetch the new page.  The chat text, status, and URL information is sent from client to server using HTTP Get (postlets).

 

The architecture will be a scalable one that will allow multiple servers to interact with each other and serve a common group. There will be a directory server, a backbone server, and multiple client servers. The directory server will hold information about all client servers and the backbone server. All client servers wanting to join the collaborative browsing and chat network will have to register with the directory server. The directory server will offer registration and de-registration for all client servers wanting to be part of the network. The directory server will store this client server information in its database. The client servers will maintain connections with users, and the backbone server will be responsible for the client server-to-client server communication. This will create a hierarchical architecture, allowing multiple front-end servers to serve clients.  It will offset the limitation of having every client hold-up a socket resource for the entire session. The directory server will make backbone server information available to client servers. This will allow the client servers and backbone to communicate directly. The client servers will inform the directory and backbone servers of every client joining and leaving a session. This will permit the directory server to keep track of load statistics on a per client server basis, and the backbone server to keep track of which client server is serving which session. When a user types a chat message or a session master clicks on a new URL, the information is sent to the user’s local client server. The client server will update all of its local clients belonging to the group and the backbone server. The backbone server will update all client servers who are currently serving users that belong to the group. The client servers can then update their local clients. 

 

2.2 Technology

Figure 2: System Technology

 

Server Side:

The directory server, client server, and backbone server software will consist of the Jakarta Tomcat J2EE web server and Java servlet software specific to this application.

The client server’s servlet software will be built around Just van den Broecke’s pushlet software [1]. The directory and backbone servers will make use of MySql databases and JDBC connection software.

 

Pushlet is a Java servlet application written by Just van den Broecke of Just Objects B.V, and is freely available from http://www.pushlets.com [1]. It allows the server to push information to a client over a HTTP connection. The server pushes Javascript objects to a client DHTML frame piecemeal, as the information becomes available. The frame then updates the client’s browser display. The server push is event-driven, allowing a client to receive information from the server as soon as an event occurs. Once a client establishes a HTTP connection with a pushlet application, the connection is held for the entire session. The pushlet application will release the connection when it tries to push the information to a client and discovers that the client has gone away. 

 

Postlet is a Java servlet application also written by Just van den Broecke [1]. It works in conjunction with a pushlet application. It allows a client browser to post an event to the server so that a pushlet application can publish it to clients. 

 

Client Side:

The client side consists of a single browser. The HTML service page is composed of the four frames already mentioned, and uses Cascading Style Sheets, Javascript and HTML. The hidden frame will communicate with the application server through pushlets and postlets. The other three frames will communicate with the hidden frame when events (new URL loaded, control/release master status, text chat message) need to be posted to the application server. The collaborative browsing frame will fetch its own pages, but will inform the hidden frame when a new page has just been loaded. The hidden frame will need to query the browsing frame for its URL so that it can post it to the server. The hidden frame is the one to obtain new information (status, text chat message, new URL) from the application server, since it maintains the persistent connection with the server. This frame will have to pass the information on to the appropriate frame for handling.

 

Limitations:

One limitation stems from the hidden frame having to query the browsing frame for its URL. Javascript has built in security that prevents one frame from obtaining the URL of another if they are not in the same domain. Signed Javascripts can be used to overcome this limitation. These are Javascript snippets signed by a service like VeriSign that require the user to accept the script before it can be applied. Not all browsers support this technology, and those that do don’t all support it the same way. This technology is browser specific, so I will restrict my application to a single browser such as Netscape or Mozilla. Internet Explorer does not support signed Javascripts.

 

Another limitation is security. I will not address the issue of security for this application, since it is intended for the casual user. The session login and password will make some attempt to ensure that all users who take part in a session are welcome, but no encryption will be used. It is possible to have this application work over HTTPS, but I will make no attempt to verify this.

 

A third limitation is the use of proxy servers. This application assumes that there are no proxy servers between clients and client servers. Proxy servers may be an issue for pushlets.

 

3.Tasks

3.1 Timeline

3.1.1 Already Complete - done during Fall 2002 and Spring 2003

3.1.2 In Progress - should finish October 2003

3.1.3 Future – Fall 2003 and Spring 2004

3.1.4 Future - complete during Summer 2004

3.1.5 Future - complete during Fall 2004

 

3.2 Deliverables

o       Test collaborative web browsing and chat with 1 backbone server, 1 directory server, 2 client servers, and 2 clients (one on each client server)

o       Test registration process for client servers

o       Test login process for clients

 

4. References

  1. Just van den Broecke, “ Pushlets Whitepaper ”, Just Objects B.V. 2002/08/05.
  2. Alan W. Esenther, “Instant Co-Browsing: Lightweight Real-Time Collaborative Web Browsing”, Mitsubishi Electric Research Labs, http://www2002.org/CDROM/poster/86/, 2002.
  3. Nishanth Menon, “ Collaborative Tools for the next millennium (and beyond) “.
  4. Microsoft, “Exchange 2000 Conferencing Server Downloadable documentation”, http://www.microsoft.com/exchange/techinfo/productdoc/2000/conferencedoc.asp , May 2001.
  5. Microsoft, “Microsoft Exchange Chat Service”, http://www.microsoft.com/exchange/en/55/help/documents/chat/coc01_3.htm, February 28, 2000.
  6. Lewis Ward, “ WebEx MediaTone: Delivering on the Promise of Rich Media Communications”, white paper,  “http://www.webex.com/technology_whitepapers.html”  , May 2002.
  7. First Virtual Communications, “Click To Meet”, http://www.fvc.com.
  8. Sun Microsystems, “Sun Forum”, http://www.sun.com/desktop/products/software/sunforum/”.
  9. John Fontana, “ Sun Launches IM server, integrates it with collaborative platform “, Network World, http://www.nwfusion.com/news/2003/0410sunim.html, 04/10/03.
  10. Cisco, “Cisco Collaboration Server”, http://www.cisco.com/warp/public/180/prod_plat/cust_cont/nam/collaboration.html.
  11. Linda Rosencrance, “Tech firms lobby for open IM standards”, http://www.computerworld.com/printthis/2000/0,4814,45662,00.html, June 08, 2000.
  12. Cathleen Moore, “XMPP rises to face Simple standard”, InfoWorld, April 18, 2003.
  13. Christopher Saunders, “A Lack of Simple Pleasures”, Instant Messaging Planet, Nov. 12, 2002.
  14. Jabber Software Foundation, “ Jabber Technology Overview”, http://www.jabber.org.
  15. Eidelshtein Ilya and Taubkin Victor, “IRC – Internet Relay Chat”, http://www2.rad.com/networks/1995/irc/irc.htm.
  16. Elizabeth Daly, “Distributed Slide Show Tool”, University of Dublin, September 16, 2002
  17. Ganesh Godavari , “SGFR : Secure Groupware for First Responders”, University of Colorado at Colorado Springs, http://cs.uccs.edu/~sgfr/, 2003.
  18. Microsoft Corp. “MSN Messenger”, http://messenger.msn.com/
  19. AOL Instant Messenger, http://www.aim.com/
  20. YAHOO Messenger, http://messenger.yahoo.com/
  21. The Apache Jakarta Project, http://jakarta.apache.org/tomcat/
  22. Patricia Ferrao, Event Application Using Pushlets, http://piglet.uccs.edu/~cs526/projF2002/pferrao/doc/Eventapplication.doc, December 6, 2002

 

Last Updated October 12, 2003