Object Service Architecture

Intermediary Architecture:
Interposing Middleware Services between Web Client and Server

Project Summary

Craig Thompson, Paul Pazandak, Venu Vasudevan, Frank Manola, Mark Palmer, Gil Hansen, Tom Bannon
Object Services and Consulting, Inc.
March 31 1998


This paper describes an Intermediary Architecture (IA), a specific software infrastructure architecture aimed at unifying Web and ORB architectures.

Today the Web consists of thin clients, which provide universal browser interfaces, and web servers which provide back-end access to global information resources -- that's where the data is.  Meanwhile object request brokers (ORBs) provide a distributed object bus for accessing suites of middleware services -- that's where the management services are.  At present, ORBs are not really connected well to control access to web data sources.  Without better integration, the web community will build protocol extensions (e.g., WEBDAV) parallel to but different than the ORB community, and enterprise architects will be forced to make idiosyncratic tradeoffs in constructing systems that need to use both architectures together.

The overall thesis of our project "Scaling Object Services Architectures to the Internet" [Thompson, 1997] is that the web and distributed object technology bases need to be better integrated to realize the benefits of both. We are working on several aspects of the problem including how to extend the Object Management Group (OMG) Object Management Architecture to accommodate architectural properties like composability, scaling, and evolution [Thompson, Linden, Filman, 1997; Thompson, 1998]), what a web object model might look like [Manola, 1998], how to internalize World Wide Web Consortium (W3C) Extensible Markup Language (XML) documents as Java objects [Pazandak, 1998], and new infrastructures for Web-object middleware integration (the subject of this paper and [Thompson et. al. 1998]).  In a related DARPA project we are working on "Survivability of Object Services Architectures" [Wells, 1997].  If we are successful in providing a widely useful architecture for Web-object integration, we will help to provide "objects for the masses" in the form of an understandable abstract framework for scaling, composing, and federating service components to enable rapid Web-based application development.

Today's Web clients and servers leave certain hooks for extensibility: client-side browser plug-in APIs, client-side composer plug-in APIs, server side plug-in APIs, arbitrary CGI operations that return pages and which may have side-effects like page counts, applets embedded within pages to be interpreted by the client, servlets embedded within pages to be interpreted by the server, and client-side and server-side scripts embedded in the page. It would be desirable if it were easy for end-users and developers to plug in modules from component software libraries to rapidly build extensive web application architectures.  Middleware ORB-based service architectures provide candidate component libraries.  So a next questions is, how can we combine web and ORB architectures?  Two approaches to web-ORB integration are already in common use: backend ORBs wherein server-side CGI scripts call ORB clients that access middleware services, and downloading ORB clients as applets wherein a Java applet is downloaded which contains a Java ORB client that then can communicate to an ORB server. Netscape's Visigenic CORBA client is pre-downloaded to optimize the download time.

A third Web-ORB integration architecture, which we are calling an Intermediary Architecture (IA), also appears to be broadly useful. The idea of the Intermediary Architecture is to interpose intermediary middleware plug-in services between the web client and web server. The normal architecture of the web is for a client to issue a GET request referencing a URL and a server to return the associated resource (page).  Intermediaries provide a general way to augment or overload this access behavior to add new behaviors.  Effectively intermediaries splice ORB-like service architectures between Web client and server, thus creating URL brokers. One can draw a wrapper-like picture of client-IA-server where the client is red and server is green and the IA has a green-red layer so the client sees IA as a server and the server sees IA as a client.  This is like mating male and female leads via an adapter. But now, new services can be delivered via the intermediary.

The design pattern of interposing intermediary behavior between components is not entirely new. Wrappers do this in an ad hoc way.  More generally, reflective architectures (e.g., CLOS) provide expansion joints where new behaviors can be interposed.  The DARPA Open OODB system [Wells et. al. 1992] used interceptors (called sentries) to install new behaviors like persistence and versioning and treated querying as a service.  OMG's security architecture uses (nearly) general purpose interceptors to overload the CORBA dispatch mechanism and install security into OMG's distributed object architecture.  The OMG Portable Object Adapter specification provides before-after filters. Several groups (ours, MCC Object Infrastructure Project, others) are exploring a general intermediary design pattern for installing quality of service (QoS) -ilities (architectural properties) in communication paths in ORB and now web architectures. But commercial web clients (like Netscape Navigator) and servers so far do not directly support client side or server side filtering.  The experimental W3C Jigsaw server does support server-side filters.


Intermediary Architecture Examples

On the web, most work has focused on single-purpose, hard-wired intermediaries, called proxy servers.  A number of http servers can act as proxy servers to receive a URL from a client and pass it on to a server, first performing some intermediary operation, then returning a page through the proxy to the client, possibly side-effecting the page transfer.  Common uses for proxies have been page caching mechanisms and security firewalls.  Web platform vendors are increasingly bundling functionality that could have been added by intermediaries, so thin clients are getting fatter via services like client-side caching, history mechanism, bookmarks, multiple views like Page Source and Page Information, SSL-based security, and versioning.

In order to better understand the design space for an intermediary architecture, we prototyped some plug-in services and the IA support infrastructure to support them:

Other potential intermediary services include (not an exhaustive list):

Intermediary Architecture Design Overview

The main components of the architecture are: One of our design goals was to avoid making changes to existing web infrastructure and still install the IA architecture.  We closely examined the then-published Netscape browser client API to locate a hook for URL interceptors but found the API to be minimal and the available hooks to be insufficient.  So in our current prototype, intermediaries are implemented as proxies. This allows IA to be portable across existing web infrastructure.  Commercial browsers and servers might in the future incorporate IA capabilities or implement extensible protocols like W3C Protocol Extension Protocol to allow IA openness supported directly in clients or servers.

Lessons Learned and Next Steps

Work on component-based architectures is in its infancy. The Intermediary Architecture appears to provide a productive architectural pattern, making it easier for third-parties to produce plug-in services, opening the door a little wider for a component economy.

Based on our prototype work, we have learned some lessons and identified some open issues that should generally be useful to the entire component software and ORB-service architecture communities:

There remain several unexplored questions about IA architectures: Our next steps are to continue to gain experience with the IA architecture style by implementing additional service stubs to settle on a plug-in API that is rich enough for use by third parties and generic enough so it is not service-specific. Most interesting to us is to learn how to scale the infrastructure architecture via decentralized, federated services like repositories, traders, policy managers, and negotiators.


Gil Hansen, "Personal Web Performance Monitor Service," OBJS Technical Report, 1998, URL: http://www.objs.com/OSA/Network-Performance-Monitor-Service.html.

Frank Manola, "Towards a Richer Web Object Model," SIGMOD Record, Volume 27, Number 1, March 1998. URL: http://www.acm.org/sigmod/sigmod_record/.

Mark Palmer and Venu Vasudevan, "Annotations Service," OBJS Technical Report, 1998, URL: http://www.objs.com/OSA/Annotations-Service.html.

Paul Pazandak, "Deserialization of XML Documents," OBJS Technical Report, 1998. To appear: URL: http://www.objs.com/OSA/XML-to-Java-Mapping.html when released.

Craig Thompson. "Scaling Object Services Architectures to the Internet," DARPA Project Description, 1998, URL: http://www.objs.com/OSA/Final-Report.html.

Craig Thompson (ed), OMG-DARPA Workshop on Compositional Architectures - Final Report, Monterey, CA, January 6-8, 1998. URL: http://www.objs.com/workshops/ws9801/.

Craig Thompson, Ted Linden, Bob Filman, "OMG OMA NG: Towards the Next Generation OMG Object Management Architecture," OMG Document ormsc/97-09-01.html, October, 1997. URL: http://www.objs.com/staging/OMG-OMA-NG.html.

Craig Thompson, Paul Pazandak, Venu Vasudevan, Frank Manola, Mark Palmer, Gil Hansen, Steve Ford, "Intermediary Architecture," Position Paper, OMG-DARPA Workshop on Compositional Architectures, 1998, URL: http://www.objs.com/workshops/ws9801/papers/paper103.html.

Venu Vasudevan, "A Reference Model for Trader-Based Distributed Systems Architectures," OBJS Technical Report, 1998, URL: http://www.objs.com/staging/trader-rm.html.

David Wells, Jose Blakeley, Craig Thompson. "Architecture of an Open Object-Oriented Database Management System." IEEE Computer, October 1992.

David Wells, David Langworthy, "Survivability of Object Services Architectures," Position Paper, OMG-DARPA Workshop on Compositional Architectures, Monterey, CA, January 6-8, 1998. URL: http://www.objs.com/workshops/ws9801/papers/paper014.html.

This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government.

© Copyright 1997, 1998 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information in this survey.
Last revised: September 28, 1998.  Send comments to Craig Thompson.