Webwork
An Application Portal Vision

Technologies

Behind the Webwork Portal vision lie significant technologies in areas such as distributed computing and data management that can be implemented more reliably and economically on portal-based platforms than on loosely connected personal systems. The Webwork Study Group conducted a survey of the technologies that would be required for successful implementation of the Webwork platform. The full results of that survey are reported in a companion document, the Webwork Technology Survey.

We divide the Webwork Portal technologies into five categories, shown in the following diagram. Each category in this diagram rests on the functionality provided by the categories below it.

Figure 1. Webwork technologies.

Data Storage and Management

The foundation of Webwork Portal is reliable, accessible, secure and centrally administered Data Storage and Management. Data center and database technology are mature in many areas including high throughput, transactional protection during concurrent access, backup, recovery, scalability and protection against loss through media deterioration or natural disaster. In addition to these fundamental storage capabilities, scalable support for secure, independent access by multiple people requires security mechanisms including user information, identification, authorization, verification, encryption and access control. The Webwork data repository also allows users to retrieve prior versions of documents.

Although the data are “centralized” from the user’s perspective, they may in fact be replicated and distributed among a set of physical machines. Such distribution allows scalable and efficient access to users. When data are manipulated collaboratively by multiple users, care must be taken to maintain consistency among the data’s replicas. Solutions to these problems have been implemented within several distributed database and distributed shared memory systems.

Application Serving

Application Serving is another foundational component of Webwork Portal. Application Serving provides users with centrally maintained and administered software for accessing and manipulating their centralized data. A range of architectures can be used to provide this capability, from full server-side to full client-side execution. Tradeoffs between these two extremes have critical implications for the usefulness of the portal.

Server-side processing demands less of client devices, and enables global access to application state; on the other hand, frequent client-server traffic loads the network and gives rise to latency delays that limit application responsiveness. Client-side processing demands more of the client device, but guarantees responsiveness, loads the network only for downloads and saving data, and permits disconnected operation. Between these canonical extremes are hybrid architectures with different points of separation between the application processing and display. A promising approach for the Webwork Portal combines client-side processing with reliable transactional operations to update server-side data (document and application state). For constantly connected devices, this approach keeps the responsiveness and network fault tolerance of client-side processing while maintaining the application state on the server for quick recovery. This approach allows use of intermittently connected, mobile devices which can update server-side state when a connection is established.

Asynchronous Collaboration

Asynchronous Collaboration supports sharing information among users who may interact with it at different times. Exchanging e-mail is one example of asynchronous collaboration. Currently, users often share documents by sending copies to each other via e-mail attachments. This has several problems: recipients need to have installed the correct version of software to access the document, copies can become inconsistent, collaborators cannot see changes made by each other, and changes need to be merged into the master copy (often by hand).

In contrast, asynchronous collaboration on Webwork Portal takes advantage of capabilities provided by centrally located software and data. Rather than sending copies of shared data to collaborators, portal users send a reference to the centrally located data. To prevent conflicting simultaneous access, the platform uses a flexible lock management system in conjunction with access control.

Synchronous Collaboration

Synchronous Collaboration consists of technologies that allow multiple users to work together at the same time. Synchronous and asynchronous can be considered subcategories of collaboration but the technologies used to support each are different, so we consider them separately. Although the technologies are separate, synchronous collaboration is facilitated by some amount of asynchronous communication for forming groups and coordinating schedules to set up synchronous activity. For example, in the Webwork Portal scenario, Sarah transitions from accessing a document that was e-mailed asynchronously to a synchronous collaboration with a person who had already opened the document.

The Webwork platform includes several proposed services to support synchronous collaboration. Realtime information about users’ activities is accessible via active interface widgets in the Contact Neighborhood and People Neighborhood and embedded in applications where appropriate. Development of collaborative applications is facilitated by a publish-subscribe communication abstraction. An application’s support for collaboration can lie in a range from simple screen sharing, where only one user at a time can control the application, to full support, where multiple users with independent views of the document can manipulate the application simultaneously. Conflicting operations are managed using a concurrency-control framework that provides a range of mechanisms from pessimistic locking to optimistic transaction serialization. Finally, a set of multi-user interface widgets is available that allow collaborators to accomplish more fine-grained interactions together.

Context Processing

Beyond the advantages afforded by current indexing mechanisms, the Webwork Neighborhood associates people and their activities with documents. We refer to the technologies used to construct the Neighborhood as Context Processing, which involves detecting, filtering, and recording user activity in order to support the ability to create the Neighborhood contexts.

Each element of Context Processing carries technical requirements. Detection involves providing mechanisms for portal- and non-portal-based systems to report a user’s activity at a meaningful level. Filtering activity involves determining when to create a new context record, as well as making associations with existing context records. Recreating context involves restoring all of the processes involved in a context to the appropriate state.

While Context Processing is potentially compute intensive, storing data on reliable and powerful servers allows more processing than is typically feasible on a personal, but comparatively low-powered, machine. Thus, the application portal provider can amortize this cost over the large number of users that it would be serving.

Issues

Throughout the Webwork investigation, we have kept an eye on the viability of the concepts and the feasibility of their implementation. The fundamental conclusion of our survey is that much of the required technology is well understood. The one unproven area is Context Processing. To our knowledge, no previous system has provided a capability similar to the Webwork Neighborhood. As an initial step, we have outlined a conceptual architecture for capturing and recording activity and associating it with related documents and people.

The remaining technologies required for Webwork have been tried and tested in previous systems. For the most part, implementation is clearly conceptually possible, though many important issues must be considered in the design of the Webwork Portal architecture. We identify significant issues throughout the detailed technical discussion found in the Webwork Technology Survey.

Even though the technologies have been proven in separate systems, integrating them into a globally accessible system that supports millions of simultaneous users presents significant challenges. In addition to the independent issues that need to be addressed within each technology category, the interdependencies among the technologies complicate how each is designed. Full details are provided in the Webwork Technology Survey and are briefly described here.

Security

Although portal-based computing has only recently become available, there is already a growing concern for the security of server-based data. Server-based data allows access at anytime, from anywhere, but hopefully not by anyone. In addition to such general concerns for security on server-based computing, Webwork presents capabilities that potentially raise new concerns. Webwork Portal users will need to be able to control access to the data they own. In addition to granting access, they will need to be able to rescind previously granted authorization. A complicating factor is that access control must not be overly difficult to understand. If it is, users will not properly protect their data.

Technologies exist to address these issues. In the past, many systems have treated security as an add-on, often retrofitted as an afterthought. This complicates the already difficult integration of system-wide security. The Webwork Portal architecture should be designed from the start to include solutions to security concerns that are comprehensive and consistent throughout the system.

 

User Information

Webwork Portal includes convenient and ubiquitous access to people along with realtime display of their activity. This involves two types of information about the user: static contact information and dynamic activity information. Static contact information is often collected in a Directory Service. A directory service would seem to be a natural place for dynamic user information as well; however, conventional directory services are optimized for low frequency updates. Dynamic changes in awareness activity must be updated at a high enough rate to be useful to coworkers. Additionally, notification of state changes to interested processes is non-existent or rudimentary in existing directory servers.

 

Application Sharing

Basic application sharing is implemented by capturing the graphical output of the shared application and distributing it to the displays of all collaborators. The ease of capturing the graphics depends on the point of separation between the application’s process and graphics. The simplest Application Serving architecture on which to implement this approach would be under server-side execution where the application image can be captured as it is sent to the client; however, the need for application responsiveness indicates that some amount of client-side execution is beneficial. The Application Sharing component, therefore, should most likely intercept application graphics at the client end.

 

Data Modification Transactions

The hybrid Application Serving architecture we describe uses transactional operations to update the server-side data. Another use of transactions is to support synchronous collaboration through transaction serialization. Serializability for synchronous collaboration requires that the transactions conform to a set of properties (idempotent, invertible, or composable) not required of traditional database transactions. The specification of the transaction model within Data Storage and Management must allow this non-traditional use of transactions.

 

Lock Management

A locking mechanism should be used to prevent potentially conflicting simultaneous access of a shared document. Typically a lock is held by one person at a time. On Webwork Portal, a lock owner must be able to expand the access to multiple people, as when Sam shares access with Sarah to the budget he has opened. To support this, the access control mechanism within Data Storage and Management must allow the transition from individually to multiply owned locks.

 

Activity Detection

Webwork Portal applications must expose user activity for the portal to construct and dynamically update the Neighborhood. The Webwork platform can provide specifications within a component architecture (e.g., DCOM, JavaBeans, Bonobo) through which third-party application developers announce user activity information. The difficulty here is that developers may be reluctant to devote extra effort to use the mechanism correctly. We can encourage conformance by designing a simplified activity-notification framework and providing a toolkit of reusable modules that keeps the extra development effort low.

The companion document, Webwork Technology Survey, discusses in greater detail these technologies, their issues and interdependencies.

  Options