Appeared in Object Magazine, May 1997
Column: Objects & The Web

Object-Oriented Web Servers

Dave Carlson
Ontogenics Corp.
dcarlson@ontogenics.com

There has been a rapid evolution of Web server technology since its relatively recent birth. Web servers started as simple HTML document servers, then were augmented with the Common Gateway Interface (CGI) for invoking scripts and other processes on the server. CGI scripts (mostly written in Perl), combined with HTML input forms, created the basis for very useful data access utilities and dynamic HTML documents. Developers have been very creative in applying the limited CGI interface for connecting to a wide variety of back-end systems. Through these extensions, the Web server has evolved to become a middle layer within an n-tier client/server architecture, connecting Web clients to other database and legacy servers.

However, the essential characteristic of a Web server is not that it supports CGI extensions, or even that it be capable of delivering static HTML and multimedia files. A Web server is recognized by a client simply by the fact that it supports the Hypertext Transport Protocol (HTTP). Most Web server requests are received as GET or POST commands, and the results are delivered as a data stream with additional MIME-type header information. Because HTTP rides on top of TCP/IP – the language of the Internet – it’s very easy to add HTTP support as a front-end to almost any network system. For example, embedded systems for real-time manufacturing control were already converting to TCP/IP network communication, and now are adding very lightweight HTTP servers to these embedded systems that allow any Web browser to query their status.

An object-oriented Web server can be created either by adding HTTP protocol support to an existing server platform, or by developing an extensible Web server using object-oriented technologies. I’ve focused my attention on the latter category, mostly because the systems that I develop are biased toward Web features. The best object-oriented Web servers are those whose designs and implementation are completely object-oriented, not merely an object-based API. Saying that anything is "best" is always a tenuous position. I justify my opinion not by general measures such as performance metrics, but by flexibility and extensibility for rapid development of new capabilities.

I’d like to ground this discussion by listing the innovative implementations that I’ve been following over the past 18 months, then I will describe some benefits from two perspectives: extensible Web server architectures, and distributed Model-View-Controller designs. I first became fascinated by the possibilities of object-oriented Web servers in 1995 when I came across MIT’s Common Lisp Hypermedia Server (http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html). They describe the project as "a fully object-oriented server that makes it easy for AI researchers to interface complex systems to the World-Wide Web." They demonstrated the power of reusing existing object models by embedding them within a Web system.

Then, in about January 1996, I discovered an early version of VPRO’s "James" Web server written entirely in Java (http://james.vpro.nl/). VPRO is a Dutch National

Broadcasting Organization that actively uses their server for production applications, plus they are continuing to evolve its implementation. The W3C’s Jigsaw Web Server (http://www.w3.org/pub/WWW/Jigsaw/) is a testbed and reference implementation for future Web servers. I first came across this server in mid-1996 and was told that 95% of the server development at W3C was being done in Java. They cite design goals of portability, extensibility, and efficiency that drive their implementation. The MIT, VPRO, and W3C servers are all available as a full source download. Kudos and thanks to these early innovators!

I’m aware of two fully object-oriented commercial products built with Java: Sun’s Java Web Server and WebLogic’s T3Server. I’m currently using a beta release of Sun’s product in my own development project. Netscape has taken a hybrid approach by embedding the Java virtual machine into their Web servers and allowing Java servlets to be written to their published API. If you know about any other interesting object-oriented Web servers, please pop me a quick email message.

Extensible Web Servers

In my experience, most client/server systems are designed with a 2-tier architecture: a fat client connected to a database server. Even Java-based systems are not deviating from this approach, they just use Java Database Connectivity (JDBC) in a large client applet to connect to a database. In these systems, the Web server has the trivial role of delivering the applet to the client browser. Object-oriented Web servers are able to take a more active role in a middle tier of the architecture.

Object-oriented Web servers are often described as "extensible," meaning that they either expose class interfaces to be implemented or provide superclasses for inheritance, or both. Application specific sub-classes are loaded into the server process and become an integral part of its functionality. There is growing support for a standard "servlet" API so that new subclasses can be written that will run on many different servers. See Sun’s Java site for the servlet specification.

The servlet object is primarily responsible for communicating with the client. For HTTP protocol, this communication consists of retrieving parameters from the GET and POST request, and pre-pending appropriate headers onto the response. The actual work done by the servlet is performed by other objects instantiated by the servlet object. These other objects might be responsible for database or legacy system connectivity, or they might be skeletons for CORBA-based objects that are implemented on yet another server. This is where it gets interesting. Other previously written, domain-specific classes can be integrated, thus extending the Web server with application logic, business rules, or other middle-tier functionality.

If we can extend the Web server with this additional application logic, how should we design the overall application in a way that maximizes reuse of components and produces a flexible, maintainable result? I’m currently experimenting with alternative distributed architectures that make use of Java servlets in the middle layer. I’ll give a quick summary of three related approaches that I’m evaluating.

Distributed Model-View-Controller

Model-View-Controller (MVC) designs were popularized by Smalltalk, but have wide applicability in other systems. MVC actually consists of two design patterns: Observer and Strategy. The View is an observer of the Model, and the Controller implements a strategy for handling the View’s events. The benefit is realized when an application is split into these logical components, and when different implementations of the components can be interchanged. For example, a model can have several views, and the view/model combination can have several strategies for handling their events and coordinating their communication.

With distributed MVC, the view and model run on the client and server, respectively. The controller manages their interaction. Consider a few variations on this pattern. First, for a basic HTML interface, the servlet (as described in the last section) fulfills the role of a Controller handling the HTTP messages from the View in a Web browser client. In this case, the servlet also implements an Adapter pattern, acting as an intermediary between the View and Model. The servlet uses data from the client request to invoke methods in the Model, then provides HTML translation of the results back to the client View. The Model can be an arbitrarily complex object system that is instatiated directly by the servlet, or accessible via a secondary connection such as CORBA’s IIOP.

A second scenario would use a Java applet for the View running on the client, but unlike most applets, this one uses the HTTP POST command to communicate to the servlet running in a Web server. Similar to the first case, the servlet (Controller) passes the request along to the Model. However, now the servlet can send either formatted HTML or a raw data stream back to the applet, and the applet and servlet could negotiate which return format to use. Compared with the first case, the View is completely new and the Model would require no change whatsoever. If HTML is returned to the applet (perhaps to be redirected by the applet to another frame in the browser), then the Controller is also identical to the first case. An equivalent POST command can be sent by either an HTML form or by an applet, so an equivalent Controller can be used.

A third scenario also uses an applet and servlet to fill the roles of View and Controller. But in this case, the applet opens a socket connection with the servlet and carries out its communication via a proprietary protocol on this dedicated channel. The model is the same as in the first two cases, but now both View and Controller must change to support their new communication design. The View and Controller classes should probably subclass general implementations so that the behavior that is common across all three scenarios can be inherited from one code base.

Additional scenarios should be developed that make greater use of distributed objects. For example, the servlet Controller might be primarily responsible for returning remote object references to the View, allowing the View to directly execute methods on the remote objects in the Model. There is widespread interest in using the Internet InterORB Protocol (IIOP) as a replacement for CGI. Netscape has made a major commitment to this architecture in their NetscapeONE development platform. But, I’ll postpone the details of servlets and CORBA to a future column.

 


Questions or problems regarding this web site should be directed to webmaster@ontogenics.com
Copyright 1996-2001 Ontogenics Corp. All rights reserved.