Introduction

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

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:

• Annotations Service.  This service allows a third party to author annotations to a document [Palmer and Vasudevan, 1997].
• Personal Web Performance Monitor Service. This service captures network performance metadata including trend data based on URL accesses [Hansen, 1997].

• shielded pages -- access is blocked for certain users to a certain pages for certain purposes via a rating service wherein trusted third parties rate pages.
• filtering, augmenting or modifying, e.g., only selected parts of selected pages are returned, removed, replaced, or customized; possibly locating similar pages in background mode; augmenting a web page with voice access to URLs.
• logging and system management instrumentation, e.g., clocking or charging service, micropayments.
• disconnected, intermittent access to roving web clients.
• background indexing of pages you have seen before, e.g., indexing of streams of audio or video.

Intermediary Architecture Design Overview

• URL interceptor(s).  The purpose of the URL interceptor is to trap and allow for one or many side-effects at the point before or after of client send, server receive, server send, client receive. Interceptors can be installed at more than one point; proxy servers is just one approach.
• Services and Service Plug-in API.  Services implement some behavior that a third party can specify.  A service can itself be extensible. The Service Plug-in API provides a means of registering and invoking services at run time including the ability to add-remove or turn on-off services.  Services can be dynamically installed and placed on the client, server, or in between for different purposes.   Services can be implemented in Java or C++ or using distributed programming architectures such as CORBA or ActiveX.
• Composition Specifications.   The purpose of composition specifications is to sequence a collection of services so they are executed in a known order.
• Service Support Infrastructure.   Services may or may not share a common service support infrastructure.
• A system management policy governs their behavior.  Guards are needed to avoid backdoor access and enforce policies.
• Services typically store their metadata in a (local or remote, possibly shared) repository.
• Traders [Venu Vasudevan, 1998] can be used to discover and federate repositories for scaling.
• Security infrastructure is needed to allow trusted third parties to install and maintain support services.
• A management GUI is needed to toggle service policies and parameters
• Some intermediary functions benefit from ready access to parsed HTML or XML (e.g., adding in-line annotations).

Lessons Learned and Next Steps

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:

• The natural boundary of a service (component) is not always clear. For instance, should the performance monitoring service measure performance for the user-specified URL and each embedded URL (e.g., .gifs) separately or should it aggregate the result? The answer depends on what one is using the service for, which may not be entirely known at the time the service is defined. Transactional control boundaries are also an issue - to display a page, the Netscape browser client first issues a series of URL fetches including requesting embedded URLs but a proxy-based URL interceptor only sees a string of individual requests and not the fact that many are transactionally related.
• There appear to be many ways that services can interact with other services (including services of their own kind as in browser caching and proxy caching).  Right now, it still looks like scripting languages and system program languages will be needed to compose services though we are still looking for stronger, more declarative results for important special cases like OMG basic object services.
• Services in the wild are more difficult to tame than services in the lab.  Knowing where to place intercept points is part of the problem, accessibility to make the connection is often lacking and undocumented, and obscure interactions can and often do occur. Wrapper approaches often replicate significant capabilities of the underlying system in order to install a new capability. Making use of undocumented APIs or formats, like accessing a file-based data structure, is subject to change in the underlying scheme.

• We have not yet considered in enough detail who can install new services in a users path? IA seems to offer some nice opportunities for separation of roles via third party experts - allowing a security function to install security, a configuration board to manage versioning and deployment, a system management function to monitor bandwidth, and services subscribed to push, filter, or block information.
• We do not know all there is to know about composition of services.  We have explored sequencing services in series but can see parallel and hybrid control structures being useful too.  In some cases, services occur in pairs (e.g., compress-decompress, encode-decode) which means there may be higher level controls.
• We are not sure yet how to generalize IA with other Web-ORB integration architectures like W3C HTTP-NG and newly emerging XML-based distributed architectures.  It would seem these might generalize to end up as one architecture.

References

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.

© 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.