NCSA work towards an Object-Oriented Web

Daniel LaLiberte (liberte@ncsa.uiuc.edu)

Last modified: Fri Mar 8 13:07:43 CST 1996

---

To reduce the complexity of adding features to web clients and servers, we are building in various extensibility features. CCI and CGI are examples from the past. In the future, we will make available our Java-based framework for synchronous collaboration, and our redesigned modular server or Repository.

Our synchronous collaboration framework provides the common tools necessary for many types of real-time collaborations, from white boards to video conferencing, from slave browsers to "neighborhoods" of documents. The framework provides an object-oriented abstraction for routing and sequencing of events as well as a few concrete implementations. Experience has shown that with this framework, it is very easy to turn existing Java applications into collaborative applications. The hope is that others will start using and extending the same framework rather than developing new ones.

The Repository project is building a new HTTP server from the ground up with modularity and extensibility in mind. Each of the major functionalities (such as security, meta data management, retrieval, searching, and annotation services) is given its own API, specified by object interfaces. Simple implementations of these APIs will be provided by us, but anyone may write new implementations to the same APIs and extend them by subclassing.

Repository modules will communicate with each other (for example, to request additional authentication) via ILU or other CORBA technology, and as they become available, CORBA clients may communicate directly with these Repository modules. The HTTP server may, in the interim, become merely a gateway between web-based clients and CORBA-based repositories of objects.

To facilitate this migration, we are investigating alternative ways to extend HTTP to allow a greater range of methods to be applied to objects. The Protocol Extension Protocol (PEP) is the most well developed such technology. But once we can send new methods, we will need ways to make requests on the client side and to process requests on the server side. On the server side, we are developing a general Method Handler Interface for translating to and from HTTP method requests and the designated object-oriented methods of the Repository modules.

On the client side, several things need to be done. Most simply, we need a way to package up method requests (e.g. in HTML documents), together with the object reference (a URI), and all the appropriate parameters. Clients need to be generalized to invoke the appropriate requests from these packages. Furthermore, the result of such a request needs to be identified for the purpose of caching, so we propose a package in the form of a new URI scheme named "call". E.g. call:SEARCH;author='Fielding';subject='URN';http://www.w3.org/

The addressing mechanism for web objects or resources is the URI. Each URI scheme corresponds to a different protocol for interacting with a set of objects. To facilitate deployment of new URI schemes, including URN schemes and distributed object schemes, we need to encourage development of client-side generic protocol handlers. Furthermore, to allow greater flexibility and generality in how URI schemes and portions of their identifier space are resolved, we should develop a standard mapping service, from URI-patterns to other URIs.

All of these efforts are moving the web closer to a full distributed object system. It seems inevitible that we will get there somehow, but by which path is far from certain. NCSA research is scouting out some of these alternatives.