Object Service Architecture
Interposing Middleware Services between Web Client and Server
Paul Pazandak, Venu
Vasudevan, Frank Manola,
Mark Palmer, Gil
Hansen, Tom Bannon
Object Services and Consulting,
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
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 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):
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
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.
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
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
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
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.
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.
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.
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
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:
David Wells, Jose Blakeley, Craig Thompson. "Architecture
of an Open Object-Oriented Database Management System." IEEE Computer,
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.