Bill
Janssen [1] & Mike Spreitzer
[2]
Xerox Palo Alto
Research Center [3]
3333 Coyote Hill Road
Palo Alto, CA
94304
Abstract: The WWW can and should be analyzed to reveal its fundamental abstractions. These abstractions can be cast as programming interfaces. For maximum payoff, all these interfaces should be set in a distributed object system, such as CORBA [4] (in general) or ILU [5] (in particular). Distributed object systems are not as inappropriate as Cardelli claims [6], and can and should be made fully appropriate --- for the sake of the WWW as well as other applications. A preliminary analysis of the current WWW reveals at least five important abstractions (HTTP Server, HTTP Responder, WWW Client, WWW Document Viewer, and WWW URL) and some subsidiary ones. By architecting the WWW in terms of these kinds of distributed objects, we enable rapid, independent development of the WWW in many dimensions.
The WWW should be organized as a distributed object system, based on an object-oriented analysis of the current WWW. Object orientation is good because it decouples development of particular object implementations from development of the contexts that use those objects, yielding automatic integration of a great number of independent pieces of code. Distributed objects are much more useful than non-distributed ones, for all the reasons that make the whole of cyberspace more useful than any single computer.
Distributed object systems are not as inappropriate as Cardelli claims, and can and should be made fully appropriate. Cardelli raises two issues: (1) lack of referential integrity, and (2) explicit dealing with quality of service. It is not unusual for distributed object systems to explicitly address lack of referential integrity. CORBA, for example, has standard exceptions to express difficulties in communicating with a remote object. Explicit attention to quality of service is currently rare, but is a natural development for distributed object systems. And the WWW is not the only application for distributed objects that would benefit from such attention. Another example is Bayou [7], a replicated database system that asynchronously propagates information among servers; the strategy a server uses for choosing when to communicate with which peer could profitably be informed by quality of service information.
The Common Object Request Broker Architecture (CORBA) of the OMG [8] is an interesting example of a distributed object system design, because it provides a specification for building such a system agreed to by most of the computing world. This specification describes a language for documenting APIs, rules for expressing this API language in programming languages like C++ and Smalltalk, an abstract object type system, a standard RPC protocol that allows different implementations of the CORBA spec to interoperate, and a security architecture that protects the entire system. Among the 600 members of the OMG are Digital, IBM, Apple, Sun, SGI, Hewlett-Packard, Oracle, and Microsoft [9].
While CORBA seems to be the future of distributed objects, the current specification of CORBA has some missing or malformed pieces that make it less than well suited for the WWW. The ILU system at Xerox PARC has been developed as a prototype of what CORBA will look like when the omissions have been addressed, and the malformed pieces repaired. The set of technologies gathered in ILU seem to be appropriate for a DOO WWW; the World Wide Web Consortium is currently carrying out a study into the technical feasibility of augmenting the present HTTP/MIME-based WWW with one built on ILU [10].
The OO analysis of the WWW centers around two main loci, WWW clients and servers, and the cycle of dependencies among them. We begin the analysis at an HTTP Server. While HTTP servers are not the only kind of servers in the WWW, they are the most "in-play" --- the others serve older protocols, and are less subject to development by the WWW community.
An HTTP server exports two interfaces: the main request-response interface, and a configuration interface. Normally the former is exported over the network via HTTP, and the latter is manipulated with configuration files. While security concerns may have motivated past decisions to base configuration interfaces on files, these are less compelling as the WWW, and various object systems, get more serious about security.
An HTTP server processes a request with the following main steps. The client's athentication and authorization are checked. If those checks succeed, the requested URI is examined to determine which HTTP Responder should handle the request. Then the request is handed off to the responder to actually produce the response. The request is logged. Each of the above steps is controlled by rules set through the server's configuration interface.
We can observe several kinds of HTTP responder in current HTTP servers. First, there are file-based responders, which map the URI to a filename and read the named file. Another current responder launches and communicates with a separate program, using the CGI convention. There are existing local APIs for responders; Netscape's NSAPI, the Apache API, and Microsoft's ISAPI are examples that address both responders and server configuration. Digital Creations' ILU Requestor [11] is an example of a distributed-object-oriented interface for responders. This responder forwards the request as a message to an existing ILU object, which determines and returns the appropriate response.
The HTTP request was sent by, and the response is received by, a WWW Client, the second locus of WWW abstractions. Upon receipt of a response, the client takes one of several actions based on a result code (in HTTP/1.0) that indicates either (a) that the request was successful or (b) what went wrong. The most interesting case is success, upon which the client proceeds to consider the MIME type of the response.
More generally, the client's job is to organize the WWW interactions of a particular application. That application could be a generic WWW browser, or some other WWW-aware application. A generic browser is parameterized by a configuration interface; other applications may be more or less parameterized, depending on their semantics.
One of a browser's jobs is to take a given WWW document and display it. The browser currently does this by examining the document's MIME type, and invoking a particular WWW Document Viewer to actually do the display. The browser is a parameter of that invocation, for two reasons. The first reason is to give the document viewer a particular place (i.e., window real estate) in which to display the response. The second is to factor URL-following behavior out of the document viewer. The document viewer will display hyperlinks (e.g., `<A HREF="...">...</A>') and other WWW-specific document content. When a user clicks on a hyperlink, for example, it becomes the browser's job to handle that click. So one method of a browser is something like (in C++ syntax)
virtual void FollowHyperlink (URL url);
As another example, consider submitting a HTML form. A
forms-supporting client needs something like
typedef enum {fm_Get, fm_Post} FormMethod;
virtual void SubmitForm (URL url, FormMethod meth, AList vals);
The existing CCI is a simple network interface for a WWW Client.
The WWW Document Viewer's job is local rendering and interactions. Ideally this would be in window real estate provided by the WWW Client. Netscape, through DDE, and Microsoft's Internet Explorer, through OLE, offer current examples of such client/viewer interfaces. However, in some current browsers this is not so; instead a ``helper application'' is launched to display the document independently. Netscape supports such helper applications.
Some document types are hierarchical, and so would benefit from a pair of hierarchical Container and Component abstractions. This would work particularly smoothly if the WWW Client were a Container.
Some types of documents are in fact programs. This offers many exciting possibilities, one of which is the re-invigoration of the distributed programing interface. Currently, the WWW is one big user interface. As non-distributed programmers learned years ago, systems building requires well thought-out APIs, not just user interfaces. But the current WWW encourages user interfaces (e.g., HTML output), not programmer's interfaces, for services on the network. The ability to run a program in a WWW Client changes this. The program can take care of presenting the user interface, contacting an arbitrary server through an arbitrary distributed programming interface (supposing the security policy of the client allows such contact). PostModern's Black Widow [12] illustrates this, by making CORBA objects acessible to Java applets. This approach can actually make securing the client easier: because the applet's external communications are at a higher level of abstraction (CORBA objects instead of TCP streams), the client has more information on which to base security decisions.
The current WWW supports many different URL `schemes'. A URL object thus encapsulates certain behavior expected in certain uses. For example, consider a use of URL X in the hyperlink `<A HREF="X">...</A>'. For most URL schemes, following such a link entails using the scheme-specified protocol to fetch a WWW document and then causing the WWW Client to display it. This would involve a method like the following on a URL object:
virtual void FollowHyperlink (WWWClient c);
Forms submission would involve a URL method like:
virtual void SubmitForm (WWWClient c, FormMethod meth, AList vals);
After fetching (or fabricating) the appropriate WWW document, these
methods would then invoke the document display method of the WWW
Client, which might look something like this:
virtual void Display (ByteStream doc);
The WWW Client is responsible for binding a URL scheme name to the actual class that implements the appropriate URL behavior. This enables client-specific implementations of some URL schemes --- as is indeed seen in some current WWW browsers.
We have asserted that the WWW should be analyzed to reveal its fundamental abstractions, and that these abstractions can be cast as programming interfaces. Furthermore, we feel that these interfaces are best manipulated with a distributed object system, in particular ILU. A brief analysis of the current WWW has revealed at least five important abstractions (HTTP Server, HTTP Responder, WWW Client, WWW Document Viewer, and WWW URL). We feel that modularizing the WWW in terms of these abstractions, and allowing new ones to be clearly described and easily added, will enable rapid, independent development of the WWW in many dimensions.