Chapter 5 Why, What, Where, When: An analysis of Collaborative
5.8 Impact on research
The analytic framework discussed in this chapter has raised a number of behavioural, architectural, placement and mobility issues that arise with cooperative systems and the Web. The aim of this research is to develop an architectural framework that exhibits appropriate temporal properties, particularly for collaborative applications that execute on the Web. This section will highlight the main behavioural considerations of this research and examine their influence on the resulting architectural framework.
5.8.1 Behavioural considerations
A number of behavioural issues were explored in Section 5.3, but this research will focus on the provision of feedthrough. Although both feedback and feedthrough are major temporal properties, the demands for feedthrough are more important in cooperative systems for maintaining effective collaboration between group users and promoting awareness. The provision of feedthrough is more challenging in a distributed collaborative environment, as both the issues of pace of interaction between participants and network-related delays have to be taken into account. Besides, there is very little support for feedthrough on the Web.
Collaborative users often work with a large number of shared objects and it may not always be possible to maintain an appropriate rate of feedthrough for each object, even over fast networks. However, the requirements of feedthrough tend to be more flexible than feedback (Section 4.1.3). Because some objects are more significant for obtaining a sense of engagement, the concepts of quality-of-service (Rada, 1995) can be applied to give different levels of feedthrough on shared objects within a groupware architecture. For example, the sharedness of some objects like shared cursors, can be relaxed by reducing their feedthrough, but group pointers, which is a form of virtual finger used during electronic conferencing, need to have almost instantaneous feedthrough to be effective.
5.8.2 Influence on architecture
The rate of feedback and feedthrough provided to the users is driven by decisions taken at the architectural level. The need for rapid feedback points towards the use of some form of caching or replication (Section 5.5.1).
On the Web, rapid user interface feedback can be promoted by running code locally as downloaded Java applets (Section 5.6.2), but the code must execute where the data is used (Section 5.7). This opens up the possibility for the data to migrate locally and local data updates will conflict with the needs of feedthrough. Consequently, there is an important trade-off between feedback and feedthrough that needs to be addressed at the architectural level.
The standard Web protocol offers poor notification besides server push for promoting awareness. The server push technology was one of the earlier techniques designed to perform continuous update of users’ screen. The server continuously runs the application program, which generates dynamic pages and sends new copies of those pages to the browser. Although this mechanism allows constant information update, it causes excessive server overhead and introduces delays. Furthermore, if several browsers attempt to access the pushed pages simultaneously, a separate copy of the dynamic page application program has to be executed for each request, consequently delaying updates further.
A more robust notification mechanism is therefore required to support feedthrough − by informing the users of any changes to the data in a timely fashion, and to enhance awareness
locking (Section 5.5.2). If no notification service is provided then an ad hoc mechanism is necessary; for instance, individual clients may poll one another for changes. Alternatively, a notification service may be incorporated within the data-management infrastructure; for example, Lotus NSTP (Patterson et al., 1996) offers a generic data storage and notification server. Finally, a stand-alone notification server can be used. The various design alternatives for notification services are explored in details in the next chapter.
5.9 Summary
This chapter first examined the functionalities of the Web as a development platform for collaborative applications. The Web offers a ubiquitous infrastructure and a platform independent interface that can be easily integrated with existing user environments. A brief overview of the Web architecture was presented, followed by a critique on its limitations in supporting cooperative tasks, based on its architecture, existing protocols and browser restrictions. Although the Web is unsuitable for developing systems that require highly interactive user interfaces with a high degree of synchronous interaction, the constraints of its basic architecture can be removed to meet the requirements of cooperative systems.
The focus of this chapter was on the analytic framework for constructing collaborative applications on the Web. This was based upon a systematic investigation of why certain behavioural issues are essential for collaborative work, what architectural components are necessary, where should the components be placed in a distributed architecture and finally,
when should the components be moved to improve performance.
The analysis of behavioural issues identified the key architectural components of cooperative systems. The placement decisions revealed the conflicting needs of feedback and consistency on the Web. This is commonly dealt with by using either caching or replication to bring the shared data ‘closer’ to the user. Web applications use dynamically downloaded code of which applets are the most common. This allows both code and data to be stored in a permanent location while having an ephemeral location where they are executed or used. The mobility issues associated with data and code generated a storage/use matrix for data and a storage/execution matrix for code, which facilitated the analysis of placement options.
Although there appears to be many possible combinations of data and code placement, a close examination of their interaction within distributed environments in general and the Web in particular, limits this to only 2 ‘real’ Web options. However, due to the security limitations of Java, applets cannot enter into peer-to-peer communication, thus eliminating the option of having Java applets operating with locally held replicas. This effectively leaves only one truly Web-based option of using Java applets with caching. This option favours rapid feedback, as the real data is located centrally, but it does conflict with the needs of feedthrough.
The behavioural and component analysis in this chapter narrows down the focus of this research on facilitating an important behavioural requirement − feedthrough, which is also a significant temporal property of collaborative work. Feedthrough is crucial for maintaining
collaboration and promoting awareness, but it is an intrinsic limitation in distributed systems in general and even more so in Web-based collaborative applications. Because the requirements for feedthrough challenge the needs for feedback on the Web, a solution to this problem can be found at the architectural level. A suitable notification mechanism is therefore required to manage the rate of feedthrough and optimise on the temporal performance. The next chapter deals with the issues surrounding the design options for notification services.