http://www.soc.staffs.ac.uk/~cmtajd/topics/webarch

The rapid growth in world-wide communications has enabled cooperative users to collaborate and access shared resources when they are distributed remotely. Due to its ubiquitous nature and platform independent interface, the web provides an attractive infrastructure for implementing collaborative applications. It already offers global access to web pages and in some respect those can be regarded as a kind of shared artefact. However, there are some problems associated with using the web as a groupware environment.

Because the web has an inherently distributed nature, it does not support symmetric access to the artefacts. Updates take place where the pages are stored and remote readers are only allowed to view the pages. However, synchronous cooperative applications, such as BSCW [1] need to provide equal access to the shared artefact upon which the group members are working. A further problem inherent within the web context is the fact that awareness is not extensively supported [4]. Changes to normal web pages are only noticed when the relevant page is visited. Implicit notification services are generally absent as the web has largely stateless servers. Some web-based applications do however provide explicit forms of notification by sending emails to users when updates take place. Another form of awareness that is not easy to manage, especially when using the web as an asynchronous environment, is how changes happen. Some traditional groupware with shared workspaces record who has made the updates and when. However, such temporal information is hard to reconstruct at a distributed level. Even synchronous web interaction will suffer from a similar problem in the event of delays over the communication channel.

The emergence of web-based collaborative work has increased the importance of temporal properties of interaction. The very nature of cooperative work introduces delays, as users have to wait for the feedback from their own actions and that of the actions of others (feedthrough). The unreliability of timely responses from group members can have a serious impact on the task being carried out. Moreover, with the web, there are further delays and lags that are implicit in the network. Remote site failures can lead to frustration and errors and the task can eventually get so complicated that it may be abandoned, thus giving rise to a complete breakdown in cooperative work.

The development of the web exposes concerns regarding data storage and control issues. Data storage (in the form of web pages) may be separate from control (such as indexing). It is common for web applications to use Java applets to download the code and execute it locally at the user end. Therefore code and data can have a permanent storage location but they can execute at an ephemeral location. This analysis [6] was previously applied to discuss web-based CSCW architectures. Although rapid user interface feedback is promoted by running the code at the local end, local data updates may conflict with the needs of feedthrough. Thus the provision of rapid feedback and feedthrough becomes more problematic on the web.

Current web-based collaborative applications often weakly support feedthrough even though feedthrough is essential in maintaining fluid collaboration [3]. The standard web protocol offers poor feedthrough besides server push which was one of the earliest technique designed in the web to perform continuous update of users’ screen. There is therefore a need for notification mechanisms to support feedthrough of other users actions and hence maintain awareness. Notification servers provide a notable mechanism for maintaining shared state information of any synchronous or asynchronous groupware system. In a previous paper [7] the design space for notification servers was presented by applying the general model of status change discovery from status-event analysis.

A fundamental aspect of notification servers is the rate of notification and this is often driven by the pace of interaction [2]. In addition, collaborative users often have to work with a large number of shared objects and it is not often possible to maintain an appropriate pace of feedthrough for each object, even over fast networks. In effect, if a maximum rate of feedthrough is provided for each shared object, further network congestion will arise. The extra computational load would imply delays for all the objects including the ones of higher interests to the users. The solution is to use impedance matching to provide effective user-level behaviour.

Impedance matching basically involves matching the rate between the clients performing changes on the shared objects and those viewing the updates. Impedance matching can be achieved by simply reducing the rate at which the updates are broadcast. Such changes are however of a global nature and will consequently affect the clients viewing the changes. The latter must therefore filter the stream of updates at the expense of additional network bandwidth and computational effort. Instead notification servers can be used to adjust the pace of feedthrough between the clients.

The notification server can act as an intermediary between the clients and mediate the rate of updates. The server does not have to forward the updates at the same rate that it receives them. As a result, the clients will have to negotiate with the notification server to maintain the right pace and the right granularity of the changes. In addition to the frequency of updates (pace impedance) the volume of data sent to users (volume impedance) can be adjusted to make it more manageable.

There are a number of issues to consider before implementing impedance matching. In general, the clients must communicate the information about achieving an appropriate user-level feedthrough to the notification server. The user can either control the frequency of updates or it may be inbuilt within the client application. In the latter case, the client needs to use some form of protocol to inform the notification server of the required pace. The desired behaviour of the server is to delay feedthrough to the clients, hence the need for event queues before updates are broadcast. This does however lay an extra storage load on the server.

We will now discuss an experimental notification server we have constructed called ‘Getting to Know’ (GtK) to demonstrate some of these implementation issues. The server is built within a distributed agent architecture. The infrastructure of GtK is described briefly and this is followed by an outline of the main functions provided by notification server. We will then look at how impedance matching is implemented to provide effective temporal interactivity.

An asynchronous message protocol has been defined to give GtK a uniform generic location-independent data model. Although the implementation is in Java, we use our own ASCII protocol for message passing instead of Java's Remote Method Invocation (RMI). There are several reasons behind this decision. Firstly, at the time we started our development, Java RMI did not have solid foundations. Secondly, RMI is synchronous and has to be integrated with user interface code using threads. Thus interfaces end up using two models: event-based windowing code and RMI networking code. In contrast, asynchronous messages allow a uniform model between user events and remote events. Finally, the use of an ASCII based asynchronous messaging protocol makes it easier to add non-Java clients and servers.

The notification server provides three main functions:

• add interest – tells the server that a specific network object wants to know about specific events for a second network object
• remove interest – tells the server to cancel some or all of the interests for a given object
• tell all – asks the server to broadcast an event to all interested objects

GtK uses the same event model as the messaging infrastructure, but allows optional translation of event types. The above three functions, with a few housekeeping operations, allow the expression of a wide range of different application specific notification strategies. They are similar to the facilities offered by the Java AWT Observer/Observable classes and AWT 1.1 event listener model except that the Java events are limited to a single Java process.

GtK updates an interest table based on the functions ‘add interest’ and ‘remove interest’. When an object asks GtK to ‘tell all’, GtK matches the event type and objects with the interest table and passes on the event (with optional type translation) to all interested clients.

Figure 1 shows this in progress. In response to user input an object in an applet sends the message:

to a ‘transcript’ object at the server managing an online conference. The transcript object updates its internal state and asks the notification manager to ‘tell all’.

The notification manager then sends all interested client objects the message:

43:0:115:7:new line:bye

They then use this to update windows on each user’s machine.

Note that each message is of the form:

where both sender and recipient are of the form:

GtK requires that the data invokes the ‘tell all’ function to inform clients of any updates. Unlike NSTP [5], GtK is only loosely coupled to the data repository. GtK knows that data objects exist and that other objects are interested in them, but it has no other application knowledge. Similarly, the data objects have to inform GtK by using ‘tell all’, but they need not be aware of other remote or local interested objects. GtK thus achieves a separation of concerns between the notification server and the data repository.

In the example applications we have so far constructed, GtK resides in the same physical address space as the data store. However, the notification server functions can be invoked either locally via method calls or remotely using asynchronous messages and so GtK is capable of running in a separate address space or even a separate physical server.

GtK is being amended to incorporate impedance matching. An optional pace parameter has been added to the ‘add interest’ function and we will extend our examples to investigate the effect of this on user-level performance and network load.

One example is a web-based collaborative on-line conference application allowing several simultaneous conferences.

A two-level conference registration method is used:

• level 1 – the active conference
• level 2 – other conferences the user is 'interested in'

Users can only join one active conference (level 1) at a time. But they can add as many conferences as they wish to the level 2 conference list.

The client will request a high-pace interest on all updates to the level 1 conference, but only a low-pace interest in a subsidiary ‘has changed’ event for the level 2 conferences. Thus the user will see instant feedthrough when other participants enter text into the level 1 conference, but if another participant adds text to a level 2 conference, the user is only informed that the conference contribution has changed, for instance, by highlighting the name in the conference list. Furthermore, this may not necessarily happen straight away.

In this example the notification manager acts as an impedance matcher in both the temporal dimension, by restricting the pace of feedthrough and in terms of bandwidth by not sending all the information across simultaneously.

A crucial temporal interactive behaviour on collaborative web-based applications is to achieve an appropriate pace of feedthrough and awareness. The central mediating position of the notification server allows it to perform impedance matching and thus reduce network bandwidth and improve user-level notification. We have looked at how a notification server can provide impedance matching in order to achieve an appropriate pace of feedthrough for the users. The results of this analysis are being explored by using an experimental notification server GtK (Getting to Know).