A web of inter-referencing objects is a powerful data structure which is used by a diverse set of applications. The World Wide Web affords an opportunity to form a common understanding of how to distribute a web data structure across a network so that it can be interpreted by both human and computer agents. Unfortunately, this opportunity will be lost, if the market rushes to standardize on only one mechanism for implementing the WWW.
Traditionally, the purpose of an interface is expose an object's functionality while hiding its implementation. Experience with WWW and CORBA shows that hiding the implementation works fine on LANs, because the system properties of LANs are well understood, generally stable, and resources are plentiful. But, in wide-area environment's system properties are more dynamic and hostile. In order, for a distributed application to work over the wide area, the usage patterns, QoS requirements, and underlying resources must be dealt with. Unfortunately these features are precisely the ones being hid by the functional interface.
The functional interface to web data structures is essentially the same across applications, but it is unlikely that a single mechanism can be found to satisfy all applications' system requirements. Instead a federation of specialized mechanisms could extend the WWW to cover performance, reliability, security, and legacy issues. This would allow the WWW to evolve as stable substrate for building applications.
This page argues that a single implementation for the WWW will not meet all the system requirements for applications which migrate to the Internet. To illustrate this point, we present some observations about wide-area collaborative planning applications whose subsystems all use a distributed web data structure. The functional interface to three subsystems is described along with their system requirements. Radically different mechanisms are needed meet the system requirements, even though the functional interface to the web is same. Likewise, if the WWW does not address these system issues, it will ultimately fail or it will serve only a small niche, such as hypertext documents.
BBN is working on several collaborative planning applications [2] which use the web data structure to share information between programs distributed across wide area network. Objects are implemented using CORBA for computer-to-computer exchanges. "Browsers" translate the CORBA representation into human representations and allow planners to collaborated over several time scales. This family of applications gives a glimpse of future knowledge-flow systems and is in operation today.
Filter, Copy, Edit, Merge: A subset of a web is copied and edited by an application. The results are merged back into the web to be shared by other applications. Many sub-functions support this basic operation, such as browsing, version control, and web walking.
Replicate: The heart of collaboration is informing other applications when a web node or link has changed so that it can update its internal representation, such as a user display. Replication is used to move a copy of a web "close" to consumers to improve performance, but adds complexity in keeping the replicas up to date.
Project: Creates a new web that summarizes an existing web. For example, taking a plan and creating a geographic map overlay representing the location of objects or a pert chart representing dependency between objects. But when the original web changes the projections must be updated. Likewise editing the projection can edit the original web.
Plan Server: The data needed to form a plan is stored in several terabyte legacy databases replicated around the world. A typical plan will project a gigabyte of records into web-objects, edit them, analyze them, and merge the results back into the global database. Any one analyst is responsible for a small part of the whole plan, but their results depend on the contents of plan as a whole. So many iteration, backtracks, and speculations are performed as the plan is refined, but the plan must always be ready to use.
The system properties of the plan server are dominated by the size and location of the database. The database changes slowly, (once a week) and the replicas separated by extremely low quality communications. Communications can be down for days and when up may only be in tens of kilobits per second range. Several planning operations may be in progress concurrently and competing for the same objects. The merge operation must help detect and resolve conflicts.
The web implementation for a Plan Server must tolerate out-of-date and inconsistent information. Multiple version of the web may be present at the same time with some divergent versions. The web implementation must merge these versions into a reasonable view to allow planning.
Map Server: The map server projects a plan onto a geographic map overlay. For example, the current location of a shipment may be represented as an icon with links back to the base object and context. Overlays are shared between planners and can be used to browse and edit the underlying plan.
The system properties of the map server are dominated by keeping the map objects up to date for an ever changing group of clients. The complicated interaction between planning objects must be constantly evaluated and reprojected to map overlays. For example, a shortage of fuel may result in a delayed flight which will result in a missing shipment. When one operator changes the fuel icon, it results in a cascade of updates which might result in changing in the shipment icon on a different operators screen.
A classic client sever implementation is appropriate for the map server, i.e. a global object which notifies its list of client when its state changes. Since the time requirement for the notification is in the seconds range, several operation between the client and sever can be tolerated in order to maintain a consistent view among all the clients.
Whiteboard Server: Planners can collaborate over maps in real time. Besides the map overlays being dynamically update, planners can annotate screens in a whiteboard style. The screen gestures and annotations are not just bitmaps, but a web of objects which are linked back to map and plan objects.
The system properties of a distributed whiteboard are dominated by the difficult real time constraints for keeping a fixed number of clients updated. For example, only the current state of an object is important, intermediate changes can be drop so long all screens match after a second of idle time.
A decentralized implementation is appropriate for a shared whiteboard. Each client has a local replica and exchange updates with all other replicas. Multiple interactions with a global object can not be tolerated and specialized resources can be exploited, such as multicast communication channels.
Note: The previous examples showed that the same functional interface had several different implementations. The choice of the appropriate implementation depends on how the client uses the object, the requirements for Quality of Services, and the underlying resources.
The QuO project builds a framework for CORBA-based application to adapt to different system properties. QuO integrates and summarizes system information from client, object, and resources. QuO also gives run-time support for dispatching to different implementations based on this summary. The QuO concepts could also be applied to the WWW.
1. Note that the author[John Zinky] is a member of a large multi-company team which is building collaborative planning applications . Many people helped form and are still debating these ideas. The author takes no credit in originating the ideas, but hopes they will help improve the dialog in the Fourth International Conference on the World Wide Web
2. Special issue on ARPA-ROME Planning Initiative, IEEE Expert, Feb 1995.