Overview of the Web

The Web was originally intended to be a powerful tool for supporting ‘active’ forms of collaboration between collaborators in remote sites through the sharing of ideas surrounding a common project (Berners-Lee et al., 1994). However, over the years the development of Web browsers, servers and protocols have largely concentrated on more ‘passive’ forms of information browsing and the initial concept of an ‘active’ form of collaboration was set aside (Bentley et al., 1997b).

This section first considers the Web architecture, followed by its limitations as a development platform for collaborative applications and finally looks at some of the ways in which the Web functionalities can be improved to facilitate the construction of collaborative applications.

5.1.1 Architecture

The Web is based on a simple client-server architecture. Web browsers run at the client- end and interact with a central server component (figure 5.1). A browser identifies the information required by using the standard Uniform Resource Location (URL) naming scheme and requests information from the server through the standard HyperText Transfer Protocol (HTTP) (Fielding et al., 1997). The host server then sends an HTTP response back to the client.

HTTP requests HTTP responses standard Web client standard Web server

Figure 5.1 Web client-server architecture

The response consists of a header, which identifies the data type (MIME) and allows the browser to handle the format correctly, and a body, which contains the requested information. The client browser uses the header information to display the information in the right format, for instance in text or graphics form, by launching an external ‘helper’ application such as Microsoft Word to display a Word document or a browser plug-in such as QuickTime to view video files.

HTTP is a generic, stateless object-oriented protocol, based on a simple request-response model. The client browser uses the GET ‘request’ method to ask the host server for a specific service, like an HTML page or a video clip, and the POST ‘response’ method to

transmit HTML data to the server. A stateless protocol implies that no state is associated with a network connection. This has several advantages. Firstly, it increases the robustness and the efficiency of the connection, as a dropped connection will only affect a single request and a connection state does not have to be established each time a connection is created. Secondly, a stateless protocol eliminates the need for a resynchronisation operation to recover a connection state following an interruption. Finally, servers can process requests from client browsers independently without affecting any previous requests, thus enabling the development of lightweight server components.

State information is typically preserved by the client and is then passed on to the server as part of the HTTP request. The HTTP protocol is independent of the format of the data transmitted. The clients and servers are responsible for handling new data formats usually through some extension. Client browsers can handle different types of data by using helper applications whereas the functionality of Web servers can be extended through Application Programming Interfaces (API). Helper applications usually function like many database client-server applications and they can be in the form of additional protocols running independently or in parallel with the current Web protocol.

The Common Gateway Interface (CGI) 5 _{is the de-facto standard for interfacing external} applications with information servers such as HTTP or Web servers. Unlike an HTML document, which is static in nature, a CGI program is executed in real-time and produces dynamic information. The CGI approach is independent of any particular server architecture and allows rapid development. In CGI scripts, the interface and the application sit on the server side to produce dynamic pages and the Web browser is used as the presentation manager at the client-end. Dynamic pages allow changing information to be displayed, but this can often cause server-end overload.

5.1.2 Limitations

The Web already offers global access to Web pages, which in some ways can be regarded as a kind of shared artefact. Although the Web allows users to search, browse, retrieve and publish information fairly easily, it does not currently offer features for sharing information in a more cooperative fashion, such as facilitating authors to produce a joint document (Bentley et al., 1997b). The main difficulties with supporting shared activities stem from the Web architecture itself, the existing protocols and browser limitations.

5.1.2.1 Asymmetric nature

The Web is asymmetric in nature due to its intrinsic distributed features. As a result, it cannot support symmetric access to the shared artefacts. Updates only occur where the pages are stored and readers are simply allowed to view the pages. Equal access to the shared artefact is an essential requirement for enhancing collaboration (Section 4.1.5).

5.1.2.2 Lack of awareness

Awareness is another important requirement for assisting and promoting collaborative work (Section 4.1.4). However, awareness mechanisms are practically absent within the Web context. Changes to normal Web pages are only noticed when the page is visited. Despite their advantages, stateless servers answer for the lack of implicit notification services on the Web and thus render the HTTP protocol unsuitable for sending notification messages (Trevor et al., 1997), (Dix, 1997). Some Web-based applications do however provide explicit forms of notification, for instance they send emails to users when updates take place. Even then, the absence of any client-server notification increases the likelihood of the interface becoming inconsistent with the information held on the central server, unless users reload the page frequently.

5.1.2.3 Restrictive architectural arrangement

The Web does not fully support collaborative arrangements such as direct server-client, client-client or replication across servers (Section 4.2). This is essential for applications where the server need to play a more active role, such as notifying users for changes or maintaining consistency across several servers. Some applications do poll Web servers periodically to check for updates, but if the pages rarely change polling will generate unnecessary network traffic.

5.1.2.4 Feedback delays

The CGI approach for generating dynamic information on the Web is based on a request- response model. This increases feedback delays, as the server has to be contacted after each user input. Such delays may be acceptable when for example a document is requested, but less so during simple requests that only involve a change in the state of the interface. In addition, simple computations, such as checking whether a user has filled in all the fields in a form, should be performed at the client-end to reduce unnecessary network traffic, high server load and slow user feedback.

5.1.2.5 Unreliable transmission

The HTTP protocol does not guarantee the transmission rates between servers and clients. Data transfer varies during a single transmission depending on the network and the server load. Continuous media like audio and video require a more reliable transfer mode, thus they use the alternative Real-Time Protocol (RTP).

5.1.2.6 Poor user interface

HTML is not a user interface design toolkit and it does not provide any support for common desktop features like drag and drop, multiple selection and semantic feedback. 5.1.3 Improving functionality

The above limitations restrict the scope of the Web as a development platform that is mainly suitable for asynchronous centralised applications and offer no support for synchronous notification, disconnected working and rich user interfaces. However, the Web has a significant advantage in that it is an accepted technology which is easily integrated with existing user environments and extensible through the server API. Also, users do not require additional client software to run on their machines. The following approaches have helped to remove some of the constraints of the basic architecture and make the Web more amenable as a development platform for collaborative systems.

5.1.3.1 Using CGI scripts

A simple and quick method for extending server functionality without modifying the protocols, browsers or servers is through CGI scripts. BSCW (Bentley et al., 1997b), (Bentley et al., 1997a) is an example system that provides a Web forms interface to a collaboration support system by integrating collaboration services with an extension of a standard Web server using the CGI programming interface. BSCW also provides HTTP upload and download support.

5.1.3.2 Implementing dedicated servers and clients

A special-purpose Web server can be implemented to improve performance, security and introduce new server functionality such as server-initiated notification. Unlike CGI scripting, this method is more flexible and secure for accessing existing Web applications. The BASIS WEBserver6 _{is an example of a specialised server approach that enables Web} access to the BASISplus document management system. In addition, a dedicated client can allow applications other than Web browsers to communicate with Web servers using HTTP. An example of a specialised client is the ‘coordinator’ clients in the WebFlow distributed workflow system (Grasso et al., 1997).

Servers and clients can also be customised to provide additional services. For example, in the Virtual Places system7_{, the Ubique client interacts with the Virtual Places server to} provide synchronous communication and allow users to be aware of the presence of other users.

5.1.3.3 Augmenting Web interface

The basic Web functionality can be augmented by replacing the client and server components to provide richer mechanisms for the user interface, synchronous notification, update propagation and information replication. Worlds (Fitzpatrick et al., 1995) is an example of such a system. However, the end product is likely to have specific hardware and software requirements and a lack of integration with existing user environments, thus limiting its accessibility and scope of use.

Some alternative solutions exist at the server and browser level that gives developers more flexibility. For instance, the Apache server allows certain aspects of the server functionality, which cannot normally be accessed through CGI scripts, to be modified (Thau, 1996). Netscape’s ‘Plug-in’ development kit and Microsoft’s ‘ActiveX’ environment simplifies the process of embedding other applications in standard Web browsers. They also allow Web browsers to handle different media types directly. These extended client server programming interfaces increase the possibility for developing much richer CSCW applications that can be fully integrated with desktop environments.

The use of ‘mobile code’ is another promising area on the Web (Bentley et al., 1997b). Mobile code allows a client browser to download application programs or Java applets and execute them locally. Applets produce much richer user interfaces than HTML and they can support special protocols like different media types, and various collaboration services, such as event notification, simple text chat and more. In addition, applets can provide users with faster response rates by moving computation closer to the clients, subsequently reducing network traffic, server load and feedback lags. There are however security concerns that arise when code is downloaded over the Internet and executed on a user’s desktop, but some progress have been made in this area.

5.1.3.4 Enhancing network protocol

The measures discussed so far mainly rely on using the standard HTTP network protocol. This protocol cannot by itself effectively meet the demands of highly interactive collaborative tasks like collaborative authoring (Whitehead and Y., 1999); therefore an enhanced network protocol is required. WEBDAV (Whitehead, 1997), (Goland et al., 1999) is an example distributed authoring protocol that supports interoperable remote collaborative authoring. It extends the HTTP network protocol to provide facilities for concurrency control − to prevent overwrite conflicts through locking, namespace operations − to copy and move Web resources and hierarchies, and property management − to create, remove and query information about Web pages. Users can collaboratively author their contents directly to an HTTP server through the WEBDAV protocol. This enhanced network protocol augments the Web functionality from a read-only mode for downloading information to a writeable collaborative medium.

This section has described the Web architecture and discussed its limitations as a platform for constructing collaborative applications. The Web does not meet some important requirements for collaborative work; for example, it does not provide equal access to the shared artefacts and it does not have any inbuilt awareness mechanisms. Also, there are not many possibilities for having different architectural arrangements on the Web to optimise

feedback delays. However, with the rapidly evolving Web technologies, some of which have been outlined above, the traditional role of the Web as a passive information repository can in fact be transformed to an active tool for cooperation and for developing CSCW applications.