DRAFT ACM Computing Surveys v(i), month 1999, http://www.acm.org/surveys/tbd.html. Copyright © 1999 by the Association for Computing Machinery, Inc. See the permissions statement below.

Intermediary Architecture: 
Interposing Middleware Object Services between Web Client and Server

Craig Thompson, Paul Pazandak, Venu Vasudevan, Frank Manola, Mark Palmer, Gil Hansen, Tom Bannon
Object Services and Consulting, Inc.
2725 Deep Valley Trail, Plano, TX  75023
thompson@objs.com, http://www.objs.com/bios.htm

Abstract: This paper describes the Intermediary Architecture, which interposes a distributed object services architecture between Web client and server.  The architecture extends current Web architectures with a new kind of plug-in, making a new collection of Web applications easier to develop.  Example services including Web annotations and Web performance monitoring are described.

Categories and Subject Descriptors: H.3.4 [Information Systems]:  Systems and Software - Information Networks

General Terms: World Wide Web, distributed objects, object request brokers

Additional Key Words and Phrases: annotations 

1  Introduction

The objective of our project "Scaling Object Services Architectures to the Internet" [Thompson 1998b] is to develop a software infrastructure architecture aimed at unifying Web and distributed object component software architectures.  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 et. al. 1997; Thompson 1998a], what a web object model might look like [Manola 1998a; Manola 1998b], how to deserialize World Wide Web Consortium (W3C) Extensible Markup Language (XML) documents as Java objects [Pazandak 1998a], and new infrastructures for Web-object middleware integration (the subject of this paper).  

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 like CORBA) provide a distributed object bus for accessing suites of middleware services -- that's where the middleware management services are.  At present, ORBs are not really connected well to control access to web data sources.  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.

This paper describes a third general-purpose Web-ORB integration architecture, which we call an Intermediary Architecture (IA). The idea of the Intermediary Architecture is to interpose intermediary middleware plug-in services between the Web client and Web server, thus creating URL brokers. One can draw a wrapper-like picture of client-IA-server where the client is red, the 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 fairly general purpose interceptors to install security into OMG's distributed object architecture.  The OMG Portable Object Adapter specification provides before-after filters. On the web, most work on intermediaries, has focused on special-purpose proxy servers for page caching mechanisms and security firewalls.  Web platform vendors have 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.  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.

Figure 1:  Intermediary Architecture

2  Intermediary Architecture Design Overview

The Intermediary Architecture is shown in Figure 1.  The main components of the architecture are: The architecture can appear in many variations:
  • Many kinds of services can be inserted via an intermediary, including security, versioning, internationalization, query augmentors, shielded pages, rating systems, rerouting, filtering, logging, system management instrumentation, clocking, micropayments, disconnected and intermittent access, tracking URL usage patterns of a community of interest, background indexing of pages you have seen before so you can find them again, indexing streams of audio or video, translingual translation service, closed caption in multiple languages, and augmenting a web page with voice access to URLs.
  • There can be more than one intermediary.  Different groups in an organization could manage security, caching, filtering, system management and logging, functions like annotation, the ability to add new functions, etc.
  • Services can be inserted dynamically at run-time.  One way to do this is via a Trader that provides service discovery.  The trader can do this once at the beginning or can be continuously polling to locate new or better service providers or to make the system more robust if some providers fail.
  • Intermediaries can be implemented as adjunct to the client or the server or somewhere in between.  We talk about client intermediaries, server intermediaries, and proxy intermediaries.
  • A given service can store metadata it collects in a repository.  If local to the Web client, the service might provide personal services (e.g., personal Web annotations -- see the Annotation Service below).  If shared in a group, the service can provide group services (e.g., group annotations).  If shared within a community or on the server it can provide public or community services.
  • Repositories can be federated together to allow more sharing.
  • Repositories can be different for different services or they can be shared across services, e.g., so that both the performance monitor and the annotations services could share one repository.
  • It is important to be able to view and query the metadata and adjust the policy associated with a service.
  • Federation can appear in many places within this architecture:  individual services can be federated; repositories can be federated.
  • 3  Intermediary Architecture Examples

    To better understand the design space for an intermediary architecture, we prototyped the intermediary architecture interceptor and support infrastructure and developed two services.  Both were similarly structured.

    4  Conclusions

    Component-based software architectures are still immature. The Intermediary Architecture provides a productive architectural pattern for combining two of the most important mainstream component architecture frameworks, the Web and ORBs.  It makes it easier for third-parties to produce plug-in services and opens the door a little wider for a component economy.

    Based on our prototype work, we have learned some lessons and identified some open issues:


    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.


    [Hansen 1998a]
    HANSEN, G.   Personal Web performance monitor service, OBJS Project Report (September 15, 1998), http://www.objs.com/OSA/Network-Performance-Monitor-Service.html
    [Hansen 1998b]
    HANSEN, G.   Natural Language Query Interface, OBJS project report (September 15, 1998),  http://www.objs.com/OSA/NLI-Query-Service.html
    [Manola 1998a]
    MANOLA, F.  Towards a richer Web object model, SIGMOD Record, 27, 1 (March 1998),   http://www.acm.org/sigmod/sigmod_record/
    [Manola 1998b]
    MANOLA, F.  Technologies for a Web object model, Special issue on web object models, IEEE Internet Computing,  (Jan/Feb 1999), http://www.objs.com/survey/wom-ieee.htm
    [Pazandak 1998a]
    PAZANDAK, P.  Extending XML parsers to deserialize Java objects, OBJS technical report (September 15, 1998), To appear: http://www.objs.com/OSA/XML-to-Java-Mapping.html when released.
    [Pazandak 1998b]
    PAZANDAK, P.  Intermediary Architecture Infrastructure, OBJS project report (September 15, 1998), http://www.objs.com/OSA/Intermediary-Architecture-Infrastructure.html
    [Thompson 1998a]
    THOMPSON, C. (ed), OMG-DARPA Workshop on Compositional Architectures - Final Report, Monterey, California (January 6-8, 1998).  http://www.objs.com/workshops/ws9801/
    [Thompson 1998b]
    THOMPSON, C.  Scaling object services architectures to the Internet, DARPA project report, (September 15, 1998), http://www.objs.com/OSA/Final-Report.html
    [Thompson et. al. 1997]
    THOMPSON, C., LINDEN, T., FILMAN, R.  OMG OMA NG: Towards the next generation OMG object management architecture, OMG Document ormsc/97-09-01.html (October, 1997), http://www.objs.com/omg/OMG-OMA-NG.html
    [Vasudevan 1998]
    VASUDEVAN, V.   A reference model for trader-based distributed systems architectures, OBJS technical report (January, 1998), http://www.objs.com/survey/trader-reference-model.html
    [Vasudevan and Bannon 1998]
    VASUDEVAN, V. and BANNON, T.  Trader Service, OBJS project report (September 15, 1998), http://www.objs.com/OSA/Trader-Service.html
    [Vasudevan and Palmer 1998a]
    VASUDEVAN, V. and PALMER, M.  Web Annotations Service, OBJS project report (September 15, 1998), http://www.objs.com/OSA/Annotations-Service.html
    [Vasudevan and Palmer 1998b]
    VASUDEVAN, V. and PALMER, M.    Web annotation: promises and pitfalls of Web infrastructure, 32nd Hawaii International Conference on Systems Sciences (January 1999),  http://www.objs.com/survey/annotations-hicss.doc
    [Wells et. al. 1992]
    WELLS, D., BLAKELEY, J., THOMPSON, C.  Architecture of an open object-oriented database management system." IEEE Computer (October 1992).

    Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or permissions@acm.org.

    Last modified:  Saturday October 31 1998 23:00:00 CST