Appeared in Object Magazine, February 1997
Column: Objects & The Web
The average person thinks of the Web as anything that can be delivered into their browser. Although I dont completely agree with this broad definition, it does cause me to think about system architectures that enable gta such capability. The Web is not a specific technology, but a amorphous collection of protocols and data formats that are served by a multitude of different servers. The rapid evolution of Web-based systems has expanded the set of protocols commonly supported by Web clients, and the ease of information access enabled by the Web has virtually exploded the number of content types. The successful future and application of Web-based systems may depend on object technologies as a means to downloads provide flexible, extensible architectures.
In a hybrid Web-Object system, every object becomes a type of content, and conversely, every type of content can be managed as an object. Both clients and servers must be easily extensible to support new object, while inheriting common behavior from the framework. An object-oriented component architecture can help to achieve this goal in both the Web client programs and in the servers. Ill examine some specific architectural design choices in future columns, but this month I will review the basic issues that must be addressed and some broad alternatives. Not surprisingly, I see the future dominated by Java!
The original release of NCSA Mosaic helped the Web to become a multifaceted network of protocols and content types. For the first time, Internet access was unified into a single, friendly. No longer did you have to run separate programs for ftp and smf, gopher, and http access, since one program brought them all together. However, as the current browser wars attest to, the once thin client is becoming much fatter and more error prone. As the number of protocols and contents types expands, this combination threatens to become an unwieldy burden for web browser developers and system designers.
We often take the multi-protocol capability of our favorite Web client for granted. Every URL specifies the protocol as its first symbol, e.g. http:, ftp:, file:, etc. Even though the HTTP protocol is used in most URLs to communicate with a Web server, the flexibility of this specification has helped to spawn a whole new set of protocols that soon will be accessible through any general purpose Web client. For example, ldap: will directly communicate to a directory server in its standard, native protocol, instead of wrapping these queries in a http/cgi query. Its proposed that the rmi: protocol will be used by a Java applet to invoke remote Java objects, and the iiop: protocol will invoke remote CORBA compliant objects. However, with current designs, each additional protocol must be embedded in the browser program by its developer. If any application developer could easily incorporate his or her own application specific protocols, e.g. manufacturing control or EDI protocols, then the goal of a general purpose client program might truly be realized. More on this topic later.
The protocol is only half the story. The Web client must also know how to display or process the content received the URL destination via the specified protocol. The browser must render HTML according to its format specifications, display a GIF or JPEG formatted image, play sound files of various formats, and so on. Its clear that the problem of support for content types is far worse than multi-protocol support. Consequently, the Mosaic browser had native support for a few formats (primarily HTML and GIF) and provided a "helper application" configuration that allowed user extensibility and customizability. Netscape took this capability further with its plug-in architecture that those extensions to be run as child panes within Netscapes window. However, the plug-in architecture is still rather onerous and begs a better solution (probably because I find anything not object-oriented to be awkward!).
A third problem area is the inability of a Web servers common gateway interface (CGI) to scale to high-volume or functionality. This has been widely reported, so I wont belabor the point here. Replacement of CGI is probably the most dominant problem and gets the corresponding lions share of discussion for object-oriented solutions. Even if the multi-protocol/content problem doesnt deserve quite equal footing with CGI, I hope to elevate awareness of all these issues as opportunities for object technologists.
Java applets are probably the first thing to come to mind when contemplating use of objects in a system. Although the current generation of these applets provide very useful benefits for raising the level of interactivity on Web pages, most have not addressed the aforementioned problems. I suggest that the next generation of Java development should emphasize resolution of these architectural problems, and place less emphasis on animation that can often be better implemented with other approaches.
With Java applets, you can provide custom functionality for both protocols and content. Ive written an that supports the lightweight directory access protocol (LDAP) and displays the entries returned by the directory server (either X.500 or stand-alone LDAP servers). When the applet is downloaded into any Java-enabled browser, that browser appears to be extended to support directory protocols and content, but only within the applet context. This is a very weak extension because the applet merely sits within the browser window and has little to affect the browser environment. The Web browser is only a delivery vehicle for what is otherwise a stand-alone application. The user cannot type an ldap:// URL into the location field and cause the browser to load my applet, nor can the browser load my applet whenever the server returns a directory MIME type response.
What we need is a fully extensible object-oriented Web browser. The HotJava browser developed by Sun comes closest to this objective. HotJava is completely developed in the Java language and provides a general facility for extending both protocol handlers and content handlers. When using HotJava, the necessary handler classes can be downloaded on an as-needed basis. Ideally, these classes would be downloaded from the same server providing a way to dynamically support any custom or proprietary formats. This is still the ideal case, because current security restrictions in Java limit flexibility, or expose the user to security risks. The Java JDK 1.1 should resolve this issue with applet authentication. At this point, you can download a pre-beta version of HotJava from http://java.sun.com, but it appears that the commercial version of this browser will be folded into a larger offering called HotJava Views.
Extensible Web servers are also under development. The World Wide Web Consortium (W3C) is building a next-generation Web server, called Jigsaw, that is completely implemented using Java (for access to a full-source distribution, see http://www.w3.org/pub/WWW/Jigsaw/). Jigsaw uses a very general object-oriented design that supports both minor and major extensions implemented as subclasses to its library, or more radical class replacements that implement specified interfaces. By creating new resource classes, developers can implement customized processing for any content types processed by the server. These resource objects completely replace use of CGI scripts and programs in the current generation of Web servers. With Jigsaw, the server becomes a very flexible, extensible platform for responding to HTTP protocol requests.
The most fundamental proposal for incorporating object technologies into Web-based architectures is centered around replacing HTTP with the Internet Inter-ORB Protocol (IIOP). This is mostly manifested as Java-IDL bindings that enable Java applets to act as CORBA clients, directly participating in distributed object applications. In effect, any object accessible via IIOP becomes a form of content delivered to the client application. With this approach, the Java applet completely bypasses the Web server, other than to act as a source for downloading the Java applet itself. Is this still a "Web application?" Such a radical shift underscores my opening statement that what we now refer to as the Web is morphing into a very general Internet-based platform. For a interesting example of IIOP capability, see the OMG sponsored CORBAnet testbed (http://corbanet.dstc.edu.au/).
The HTTP vs. IIOP topic has been reported in prior issues of this magazine, including the OMGs contest for the best IIOP applications runnable from a Web client (see http://www.omg.org/pr96/contest.htm). The OMG contest guidelines specifically state that using a Web server CGI to access the ORB does not qualify. The application must demonstrate the power and potential for replacing HTTP. The contest results should be announced shortly before you read this column.
In my next several columns, I will analyze specific technology choices in greater detail. Ill share some insights gained from developing my LDAP Java applet for directory servers, plus take a more detailed look at the Jigsaw architecture. In general, I prefer to keep my architectural analyses independent of particular vendor implementations. A system requirement should be addressed by selecting and integrating standards-based components, then selecting vendor implementations of those standards as a final step in architectural design.