Interposing middleware services and ilities between web client and server
Paul Pazandak, Venu
Vasudevan, Frank Manola,
Mark Palmer, Gil
Hansen, Steve Ford
Object Services and Consulting,
November 21, 1997
This position paper describes what we are calling
an Intermediary Architecture (IA), a specific infrastructure
architecture for combining web and ORB/service architectures. The
idea is to interpose intermediary middleware plug-in services between the
web client and server. The architecture consists of a generic URL
request interceptor and one or more plug-in services. Services
can be dynamically installed and placed on the client, server, or in between
for different purposes. Services may share
a common service support infrastructure: a system management policy
governs the behavior of a service; services typically store their metadata
in a local or remote, possibly shared repositories; and traders
can be used to discover and federate repositories. In our implementation
(in progress), intermediaries are implemented as light weight proxies;
services can be put in place with minimal changes to existing web infrastructure;
they can be implemented in Java, C++, or other languages or using distributed
programming architectures such as CORBA, DCOM, or ActiveX; and they may
optionally modify the client browser or editor. We
describe examples that use the IA: an annotation service, a personal
web performance monitoring service, and ideas for others. The Intermediary
Architecture appears to be a generally useful way to integrate web architectures
with middleware services. Remaining challenges include composition
of services, scaling, and federation of the IA infrastructure.
The overall thesis of our DARPA project Scaling
Object Services Architectures to the Internet (also see Scaling
OSAs architectural presentation) is that the web and 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 OMG's
Object Management Architecture to accommodate architectural properties
like composability, scaling, and evolution (OMA-NG),
what a web object model might look like (Web Object
Model), and new infrastructures for web object middleware integration
(the subject of this paper). In a related DARPA project we are working
on Survivability of Object Services Architectures.
We are long-time active members of OMG, currently chairing its Internet
SIG, relatively recent members of W3C, and active as architects or
reviewers in several other projects including National
Industrial Information Infrastructure Protocols Consortium (NIIIP),
MCC Object Infrastructure Project
(OIP), and DARPA
Advanced Information Technology Services (AITS).
Today the Web consists of thin clients, which provide
universal browser interfaces, and web servers, which provide back-end access
to global information resources (e.g., that's where the data is).
Meanwhile ORBs provide access to suites of middleware services (e.g., that's
where the management is). 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.
Web clients and servers today leave certain hooks
It would be desirable if it were easy for end-users
and developers to plug in modules from component software libraries to
extend web 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:
client-side browser plug-in APIs - typically these
are selected via the MIME type of the resource being downloaded and support
client-side composer plug-in APIs - these support
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
A third web-ORB integration architecture, which we
are calling an Intermediary Architecture, also appears to be broadly useful
in that it interposes intermediary middleware services directly between
web client request and web server response. There are others as well:
enables one to associate a (CORBA) service with a URL.
backend ORBs - server-side CGI scripts call ORB clients
that access middleware services
downloading ORB clients as applets - when a Java
applet is downloaded, it 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.
From a somewhat higher vantage point, we (like
others before us) are noticing that Web and ORB architectures are naturally
growing into each other's turf. We are going through an architectural
exercise in comparing the two architectures and then performing an operation
on architectures by extending one with capabilities of the other by splicing
OMG ORB-like service architectures between web client and server, in effect
creating URL brokers.
Intermediary Architecture Examples
The design pattern of interposing intermediary behavior
between components is not 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, Blakeley, Thompson. "Architecture of an Open Object-Oriented
Database Management System." IEEE Computer, October 1992]
used 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 OIP, others) are
exploring a general intermediary design pattern for installing QoS -ilities
in communication paths in ORB and now web architectures.
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:
Some of these also require client-side access to
browser or editor/composer - a lesson we've learned is that the APIs to
these components are deficient in some popular web products. Few have explored
general-purpose, open intermediary architectures: Server-side
includes support feature insertion -- pages are scanned before being
sent to the client for embedded instructions (html tokens) which can direct
further execution. Sun's JavaServer
Toolkit and The Open Group's WAIBA
are closest to our own. The W3C Protocol
Extension Protocol (PEP) is addressing the same need (see more below).
NS Enterprise Server's NSAPI
enables one to attach code to steps in the request-response cycle
client-side caching - a management interface allows
some control over cache size and can allow the cache to be cleared
history mechanism - keeps a record of URLs visited
recently; has a management interface.
bookmarks mechanism - keeps a record of URLs
visited recently; has a management interface.
multiple views - for instance, the Page Source view
that shows/edits the page in html txt mode and the Page Info view that
provides some metadata about the page and URLs it references
optional versioning on the server
In order to better understand the design space
for an intermediary architecture, we prototyped some plug-in services and
the IA support infrastructure and at present are integrating the services
into the infrastructure. The plug-ins we have built include:
Others have developed what appear to be candidate
IA services usually for dedicated purposes and minus a compositional service
infrastructure. Some potential examples of services include:
Service. The annotation service
allows a third party (which may be the document author or someone else)
to author annotations to a document. The basic architecture of the
annotation service involves annotation creation and storage in an annotation
metadata repository, and later a URL access which has the side-effect of
accessing annotations from the repository, merging annotations with the
document being returned, and annotation viewing. The annotation service
can be a personal service if the annotation creator and viewer are the
same client. Then the repository may typically be located on the
client. (The repository could equally be provided as a generic service
and still keep separate the personal annotations of different clients.)
The service can be a group service if the service is located at an intermediary
proxy shared by a group and the annotations are shared by the group.
It can be a public annotation service if the annotations are public and
the access knows where to locate them either by being told explicitly or
by some registry/trader that associates annotations
Web Performance Monitor Service. This
service captures network performance metadata including trend data based
on URL accesses. A URL interceptor overloads the access with a data
collection facility that captures route and timing and stores it in a performance
metadata repository. The repository can be federated with other personal
weather repositories to provide performance data for a group. This service's
structure shows off the idea of service augmentors -- several different
network monitor tools can (eventually) be plugged into the framework to
collect different sorts of performance metadata.
Service Augmentors. A query service refines a user's query using
query augmentors that improve the performance or accuracy of search results.
Augmentors can use repository information that captures a user's search
preferences and habits. This is currently implemented with CGI access to
an ORB which accesses a search engine and thesaurus, not via the IA, but
it raises an issue of how to more seamlessly connect IA ORBs, CGI accessible
ORBs and downloaded-client ORBs.
Additionally, as part of the IA infrastructure prototype,
we are working on a collaborative authoring environment using a versioning
service and stubbed security and compression service pairs.
shielded pages -- access is blocked for certain users
to a certain pages for certain purposes. Pages can be rated with a level
of security and compared with the user's security clearance. Alternatively,
in rating services, labels are assigned by content providers or by third
party rating services and the client "signs up" with a rating service.
It's worth noting that this is exactly what W3C PICS is proposing to do,
and PICS will be supported by the major browser vendors. What we're effectively
proposing is to extend the general PICS idea to support arbitrary addlet
behavior, as opposed to the built-in behavior specified by PICS (access
the page's rating, possibly by accessing a separate rating service, compare
the rating with what the user has specified the rating should be, and either
allow or disallow access). This also emphasizes the role of an appropriate
object model for representing the required metadata; a suitably generic
model allows customized rating systems to be both defined by rating services
and used by browsers, as opposed to the use of built-in rating systems
that are hard to change.
rerouting -- access to a given page is rerouted to
another page. This might be done because the page has been moved.
Or to a mirror site because the target server is overloaded.
filtering -- e.g., an AI military doctrine filter
that checks commands for doctrine compliance
augmenting or modifying -- e.g., removing, replacing,
adding, customizing advertisements for web pages. Also, locating similar
pages in background mode.
logging and system management instrumentation, managing
-- e.g., clocking or charging service, micropayments
disconnected, intermittent access to roving web clients
- see Caubweb which
supports intermittent web access via caching specified parts of the web
for access/update during "low-bandwidth periods"
tracking URL usage patterns of a community of interest
so you can keep trails for others (application to situation awareness)
background indexing of pages you have seen before
so you can find them again (suggested by Murray Mazer)
virtual private networks - these are usually handled
at a lower level of the protocol stack but might be handled here
indexing of streams of audio or video - other DARPA/ICV
projects do this
translingual translation service that translates
pages; closed caption in multiple languages
augmenting a web page with voice access to URLs
the list is not at all exhaustive!
Intermediary Architecture Design Overview
A longer paper documenting our detailed design and
interfaces is in preparation and should be available 1Q98 on our
web site document log.
The idea of the Intermediary Architecture is conceptually
to interpose intermediary middleware plug-in services between the web client
and web server. The main components of the architecture are:
ORBs permit the request and response of an object
invocation to be intercepted and manipulated on either the client or the
server side. But commercial web clients (like Netscape Navigator) and servers
so far do not directly support client side or server side filtering.
The experimental Jigsaw server does support server-side filters.
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. One can draw a wrapper-like picture
of client-IA-server where client is red and server is green and 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.
URL interceptor. 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
Composition specifications. The
purpose of composition specifications is to sequence a collection of services
so they are executed in a known order. This is the least well understood
component of ours and anyone's similar architecture.
Service Plug-in API. This 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, DCOM, or ActiveX.
Services. Services implement some behavior
that a third party can specify. A service itself can be extensible.
Services not only implement side-effect behaviors but may optionally modify
the client browser or editor.
Service Support Infrastructure.
Services may or may not share a common service support infrastructure.
All these could be provided in service specific ways
but they can also be provided in such a way that services can share the
a system management policy governs their behavior.
Guards are needed to avoid backdoor access problems and enforce policies.
services typically store their metadata in a (local
or remote, possibly shared) repository
traders can be used to discover and federate repositories
security infrastructure is needed to allow trusted
third parties to install and maintain support services.
a management GUI is needed to toggle service policies
some intermediary functions benefit from ready access
to parsed HTML or XML (e.g., adding in-line annotations).
One of our design goals was to avoid making changes
to existing web infrastructure and still install the IA architecture.
We closely examined the Netscape browser client API to locate a hook for
URL interceptors but found the API to be pretty minimal and the available
hooks to be insufficient. So in our current prototype (in progress),
intermediaries are implemented as proxies. At first we avoided this
solution because proxy servers are generally heavy weight, but a very thin
pass-through proxy can server as a URL interceptor. 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 PEP (see below) to allow IA openness supported
directly in clients or servers. But it appears that both might effectively
just be incorporating (bundling) IA, and there will still be a need for
intermediary implementations separate from client and server as well
as a need for improved client and server APIs.
Intermediaries can be placed on the client, on
the server, or in between. It makes sense to place intermediaries
The above placement considerations are not the only
ones. You may want the service on the server-side if the operation needs
to be protected (e.g., it's proprietary and the owner wants to charge for
its use, even if the operation is tailored for a specific client, e.g.,
by a client profile on the server). Also, you may want to locate services
on client or server based on performance tradeoffs (reduce data shipped
over the network by processing at the server, or offload processing from
the server by moving the responsibility to the client), or security considerations.
client if the intermediary (optionally) serves the
server if the intermediary serves all clients that
need to access the requested resource(s)
in between if the intermediary serves a community
Brief Comparison of IA with PEP
Extension Protocol (PEP) appears to share the same motivation as IA.
PEP requires web servers to change to install the PEP protocol seamlessly
where IA can make use of existing browsers but requires clients to explicitly
redirect their browser to an IA proxy - really this is a small difference,
we use proxies as a way to intercept URLs and if PEP-enabled servers provided
this, we could use PEP. Both PEP and IA provide for sequencing of intermediate
side-effecting services and dynamic loading of new services. At this level,
both assume services that are protocol independent. PEP reasonably stops
short of suggesting much about an infrastructure for services (policies,
federated repositories, traders) nor is it exploring ORB services as plug
ins or client-side extension mechanisms.
Our next steps are:
revise our current prototypes to fit into the emerging
demonstrate IA accessing ORB services.
gain experience with the IA architecture style.
implement additional services 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.
implement enough services to understand more about
common IA infrastructure support services and build them as components.
Most interesting to us:
learn how to distribute these services and how to
scale the infrastructure architecture via decentralized, federated services
like repositories, traders, policy managers,
learn how to use IA services to make web servers
QoS (generally -ility) aware by inserting new side-effect behaviors (security,
monitors, ...) into communication paths.
demonstrate IA and its services in a DoD application,
to be selected.
continue to work with OMG and W3C to transfer what
we learn on this project into wide-spread use.
Work on component-based architectures is in its infancy.
The IA presented here appears to be a productive architecture pattern though
there is still much to learn before we can confirm this. It appears to
offer a convenient way to deliver new services to end users in a way that
may be amenable to visual application assembly from a potential smorgasbord
of standard services that could be made available by third parties, opening
the door a little wider for a component economy. The idea is not entirely
new, so we can learn from related work on ORB interceptors and MOPs.
There remain several unexplored questions about
If we are successful in providing a widely useful
architecture for web plus object integration, we will help to provide "objects
for the masses" in the form of an understandable abstract framework for
scaling, composing, and federating services to enable rapid application
Some uses of intermediaries might bring up legal
issues like copyright (see the Xanadu notion of transclusion)
since web pages originally authored and copyrighted by one party might
appear changed by some third party without the author's permission. This
is reasonable in some circumstances, not in others.
We have not yet considered safety issues. 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 to push, filter, or block information.
The boundaries of the IA are not yet clear.
Should the IA include access to web browser/editor client and server APIs?
Should the service support infrastructure be kept separate from the
interceptor and service sequencing?
We don't know all there is to know about composition
of services (nor does OMG!). We have explored sequencing services
in series but can see parallel, compositional, or scripted composition
as useful too. In some cases, proxies 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, HTTP-NG, and CORBA/IIOP so that all
these architectures will tend toward convergence. For instance, it
would be most useful if IA services could plug into ORBs and vice versa;
also some IA services might just as well be intermediaries between servers
than client and server. It would seem these might all generalize
to end up as one architecture. But not unless the community can demonstrate
a path to convergence. The alternative is industry spending many $B on
replicating similar functionality in similar but different infrastructure
A related problem is the kind of object
model that is appropriate for both web and ORB, which we assume will
be based on industry developments (XML, Document Object Model) that converge
Web and object representations with APIs (IDL, Java) and object services.
Related OBJS papers include OMA-NG,
Object Model, Trader, Annotations
Monitor Service, and Query
Augmentor Service, and others.
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 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 paper.
Last revised: December 8, 1997. Send comments to