Computer
`
`Networks
`
`and
`
`ISDN
`
`Systems
`
`30 (1998)
`
`509-5
`
`18
`
`Intermediaries: new places for producing and manipulating Web
`content
`Rob Barrett *- ’ , Paul P. Maglio ’
`Research
`CenteK
`650 Harryv Rd., San Jose, CA 95120, USA
`
`IBM Aitmdtw
`
`Abstract
`
`We propose a new approach to programming Web applications that increases the Web’s computational power, the Web’s
`flexibility, and Web programmer productivity. Whereas Web servers have traditionally been responsible for producing
`all content. intermediaries now provide new places for producing and manipulating Web data. We define intermediaries
`as computational elements that lie along the path of a Web transaction. In this paper, we describe the fundamental
`ideas behind intermediaries and provide a collection of example applications. We also describe WEX, an implemented
`architecture for building intermediaries that we have used to construct many applications, including personal histories,
`password management, image distillation, collaborative filtering, targeted advertising, and Web advising. 0 1998 Published
`by Elsevier
`Science
`B.V.
`All
`rights
`reserved.
`
`Kqwvrds:
`
`Intermediaries; Programmable proxies; Server API
`
`1, Ilmduction
`
`The current model of the Web gives the Web
`server the full responsibility and privilege of defin-
`ing the information
`that the browser will display.
`Displayed information may include text, images, dy-
`namic pages and interactive applications. Yet one en-
`tity, the server? maintains complete control over the
`content that is delivered to the browser. Therefore,
`the server is the only place for computing content.
`In this paper, we describe how to enhance the com-
`putational power of the Web by extending content
`computation beyond the server. We define interme-
`diuries as computational elements that lie along the
`
`author.
`* Corresponding
`’ E-mail:
`{ barrett,pmaglio]
`
`@aImaden.ibm.com
`
`path of Web transactions. They may operate on Web
`data as the request is sent from the browser, passes
`through
`firewalls and proxies,
`is satisfied by the
`generation of a document, and as the document is re-
`turned to the browser. Intermediaries have access to
`Web data at all these points, and are able to observe,
`respond to requests, and modify both the request and
`the resulting documents.
`two
`from
`Intermediaries
`can be differentiated
`other forms of non-server computation, applets and
`browser plugins. Applets allow computation
`to be
`performed on the client, but the actual executed code
`is determined by the server that delivered both the
`references to the code and the code itself. Seen an-
`other way, applets affect only
`the particular page
`on which the server chose to place them. Browser
`plugins render new content
`types or replace default
`
`0169-7552/98/$19,00
`fl/
`S~l69-75S~(98)00084-1
`
`@ 1998 Published
`
`by Elsevier
`
`Science
`
`B.V. All
`
`rights
`
`reserved.
`
`Oracle Exhibit 1005, page 1
`
`

`
`510
`
`R. Burrett.
`
`PP Maglio/Computer
`
`Netwrk.~
`
`and
`
`ISDN
`
`Systems
`
`30
`
`(1998)
`
`509-518
`
`to
`rendering engines, but do not allow a browser
`control the content that is rendered. In this case too,
`the server controls the content.
`for pro-
`Intermediaries
`represent a new model
`gramming Web-based applications.
`In
`this model,
`the usual case of a server delivering a document to a
`browser is but one type of Web transaction. An in-
`termediary running on the client may respond to the
`browser request directly, producing personal, Web-
`accessible applications for a particular user. An inter-
`mediary running on a Workgroup server may respond
`to requests, producing a collaborative Web-space. In
`addition to merely producing documents,
`intermedi-
`aries can modify documents produced elsewhere, al-
`lowing annotation, personalization, highlighting, and
`the integration of information
`from multiple sources.
`Intermediaries are a new way of thinking about Web
`applications
`that provides much greater freedom
`for
`design and implementation
`than traditional server-
`based Web programming.
`Many applications
`fit the intermediary model of
`Web programming. Consider just a few:
`Web personalization
`Our work on intermediaries was motivated by
`an interest in personalizing
`the Web, that is, in
`changing
`the Web’s behavior depending on the
`particular user and that user’s history of browsing
`[ 11. Based on explicit
`instructions or on obser-
`vations of a user’s browsing,
`intermediaries can
`formulate a model of the user and then alter what
`the user sees to personalize the browsing experi-
`ence. For example, pages can be annotated with
`user notes or customized
`links, alerts to related
`Web pages can appear, or new resources, such as
`personal search engines, can be added.
`Document caching
`feature of current
`Document caching, a common
`Web browsers, can easily be cast in the interme-
`diary mold.
`If the caching function
`is separated
`from
`the browser and implemented by an in-
`termediary,
`the browser becomes simply a URL
`requester.
`In
`this case, the intermediary
`cache
`checks its store of pages to see whether
`the re-
`quest can be satisfied locally or whether
`it must
`be sent to another intermediary or to the server.
`Figure 1 illustrates
`this application. One benefit
`of this approach
`is that the cache can be shared
`among multiple browsers or multiple people. An-
`
`I. A
`Fig.
`termediary.
`is
`forwarded
`document.
`mediary
`browser.
`
`issued
`is
`request
`requested
`If
`the
`the
`server
`to
`The document
`that personalizes
`
`to a caching
`the browser
`from
`in
`the
`cache.
`document
`is not
`intermediary,
`which
`produces
`passes
`through
`a customization
`the document
`and
`then
`returns
`
`in-
`it
`the
`inter-
`to the
`
`it
`
`is that different caching strategies
`other benefit
`can be implemented without affecting
`the rest of
`the system.
`Content distillation
`is in con-
`Another obvious role for intermediaries
`tent distillation
`[2]. The idea is that the same
`content can be represented at different
`levels of
`detail. For example,
`images can be stored at
`different
`resolutions and colour depths, or with
`different degrees of lossy compression. A distill-
`ing intermediary
`transforms
`the original content
`obtained
`from
`the server to optimize
`for trans-
`mission speed, browser display capabilities, or
`browser computational
`limitations. Slow dial-in
`connections provide a compellingreason
`for in-
`vestigating such schemes. The increasing popu-
`larity of devices with small displays, such as the
`PalmPilot
`‘, provide another.
`Protocol extension
`The simplicity and power of the HTTP protocol is
`responsible for much of the Web’s success. With
`simplicity, however, comes limitations.
`Interme-
`diaries allow many protocol extensions without
`altering deployed browsers and servers. For ex-
`ample, HTTP is not well-suited
`for long-latency
`wireless links. An intermediary can translate an
`HTTP
`transaction
`into a more efficient proto-
`col before delivering
`it across a wireless
`link
`to another
`intermediary
`that transforms
`it back
`to HTTP. Likewise, new security structures or
`other enhancements can be added to an existing
`protocol simply by using a pair of translating
`intermediaries.
`
`’ http://www.usr.com/palmpilot/
`
`Oracle Exhibit 1005, page 2
`
`

`
`R. Barrett,
`
`PP Maglio/Cornputer
`
`Networks
`
`and
`
`ISDN Sysiems
`
`30
`
`(1998)
`
`509-518
`
`.il
`
`I
`
`These examples illustrate how intermediaries add
`new computational power
`to the Web. Because in-
`termediaries allow for computational processes at all
`points along the stream of a transaction, and because
`these processes can be dynamically
`reconfigured
`for
`each particular
`transaction,
`the Web becomes cus-
`tomizable and extensible far beyond familiar scenar-
`ios. Moreover,
`the intermediaries approach breaks
`the servers’ monopoly on producing Web content.
`In what follows. we present our framework
`for in-
`termediary-based
`computation
`in detail. First, we
`show how
`the familiar view of
`the Web can be
`transformed by the introduction of the intermediary
`concept. Second. we describe our general archi-
`tecture for composing
`intermediary
`functions
`from
`basic building blocks. Third, we present details of
`our implementation of this architecture. And finally,
`we discuss related work and the future of our ap-
`proach.
`
`2. The move to intermediaries
`
`the
`from
`is derived
`The intermediary approach
`common browser-proxy-server model.
`In conven-
`tional
`thinking,
`the function of the browser
`is to
`initiate a request via an HTTP (or other protocol)
`connection
`to a proxy (or Internet service provider).
`Alternatively, we can think of the browser as issuing
`a conceptual
`request that is handled by an implicit
`intermediary. The implicit
`intermediary handles the
`request by making the appropriate HTTP connection
`for the browser (see Fig. 2). In making
`this inter-
`mediary
`function explicit, a new place for adding
`programmability
`appears. For instance, this client-
`side intermediary could choose to satisfy the request
`immediately
`from a cache. execute some local code
`to produce a dynamic page, access remote resources
`through another protocol. or simply make the appro-
`priate HTTP connection as browsers normally do.
`By splitting the issuing of the request from the mak-
`ing of the HTTP connection, we have increased the
`flexibility of the Web.
`Now consider the proxy. Normally a proxy trans-
`parently transmits a request to the appropriate server
`and returns
`the resulting document. Some proxies
`add simple functions such as caching. But there is no
`reason why the proxy cannot be a full-fledged
`inter-
`
`i j-cl I
`
`I ,
`i
`
`intermediary
`acting as sewi
`
`browser with
`intermediary
`
`’
`
`to a
`connects
`the browser
`Web model,
`the standard
`‘2. In
`Fig.
`its store. This
`connection
`retrieves
`a document
`from
`and
`server
`is done
`through
`an
`“implicit
`intermediary”
`which
`take>
`the
`requested
`URL
`and
`retrieves
`the document
`from
`the server. We
`extend
`this model
`by adding
`fully
`programmable
`intermediaries
`(“I”)
`at
`the
`client
`and mid-stream.
`The
`server
`is
`recast
`as an
`intermediary
`that produces
`documents
`response
`to
`requests.
`though
`it could
`also
`continue
`forwarding
`the
`request
`to other
`intermediaries.
`
`in
`
`response. In this case,
`mediary with a configurable
`some requests might simply be passed transparently,
`but others might access Workgroup
`resources or
`groupware
`functions. Furthermore,
`the proxy could
`examine retrieved documents
`for viruses or screen
`them in other ways before allowing
`them through
`the firewall. Likewise,
`if connections
`to the proxy
`are made via slow links, content distillation can be
`performed at this point. Again.
`the capabilities of
`the Web are clearly increased by introducing pro-
`grammability
`into the proxy.
`interme-
`Servers are simply a special case of
`diaries. A server is responsible
`for producing
`the
`document
`that satisfies a request. Therefore. an in-
`termediary
`that produces a document
`in response to
`a request is acting as a server. Because this is just
`one of the possible functions of an intermediary. an
`intermediary
`is more powerful
`than a server.
`By pushing on the common browser-proxy-server
`model. we have uncovered programmable
`interme-
`diaries at the client, proxy and server. The inter-
`mediary view
`is a generalization of
`the current
`Web model that increases the Web’s flexibility and
`power.
`
`Oracle Exhibit 1005, page 3
`
`

`
`si2
`
`R. Barrett,
`
`El? Maglio/Computer
`
`Networks
`
`and
`
`ISDN
`
`Swem
`
`30 (1998)
`
`509-518
`
`3. Architecture
`
`Intermediaries promise a more powerful and flex-
`ible mechanism for programming Web applications.
`Yet many of the details of intermediaries are quite
`complex. They must handle protocol details, rare
`error conditions, common perversions of specifica-
`tions and myriad other special cases. A number
`of monolithic
`intermediary-based applications have
`been built by different groups, but
`the potential
`will not be realized unless they are made easier
`to program. To solve this problem, we have de-
`signed an intermediary architecture
`that takes care
`of the details of intermediary plumbing, allowing the
`application programmer
`to concentrate on the data
`manipulations necessary for particular applications.
`Our architecture
`for
`intermediaries
`is known
`as Web Browser
`Intelligence3
`(WBI, pronounced
`“Webby”;
`[I]). WBI is a programmable proxy server
`that was designed for easy development and deploy-
`ment of intermediary applications. Our goal was to
`produce a programming platform
`that can be used
`to implement all sorts of intermediaries,
`from simple
`server functions to complex
`image and page editing
`and distributed applications. The WBI architecture
`has been used by more than 20 programmers
`for
`numerous projects including
`intelligent agents, Web
`mapping, password management, document
`format
`conversion, collaborative
`filtering, and knowledge
`management.
`
`In WBI, intermediary applications are constructed
`from five basic building blocks: request editors, gen-
`erators, document editors, monitors, and autonomous
`functions
`(see Fig. 3). We refer
`to these collec-
`tively as MEGs, for Monitor/Editor/Generator.
`Table
`I describes these different elements and their func-
`tions. Monitors observe transactions without affect-
`ing them. Editors modify outgoing
`requests or in-
`coming documents. Generators produce documents
`in response to requests. Autonomous
`functions
`run
`independently of any transaction and perform back-
`ground tasks.
`
`’ hftp://wwwcssrv.almaden.ibm,com/wbi/
`
`~~i~~r~
`
`generators
`
`document
`editcws
`
`monitors
`
`autonomous
`
`5 building
`from
`are constructed
`functions
`Intermediary
`3.
`Fig.
`a rule
`that specities
`Each
`is connected
`to WBI
`through
`blocks.
`type of
`transactions
`it should
`be
`involved
`in. For example,
`what
`a monitor
`could
`have
`a rule
`that
`specifies
`that
`it only wants
`monitor
`JPEG
`images
`delivered
`through
`the HTTP
`protocol.
`
`to
`
`3.2. WBI operation
`
`these
`
`follows
`
`WBI dynamically constructs a data path through
`the various MEGs for each transaction. To configure
`the route for a particular
`request, WBI has a rule
`and a priority number associated with each MEG.
`The rule specifies a boolean condition
`that indicates
`whether
`the MEG should be involved
`in a transac-
`tion. The boolean condition may test any aspect of
`the request header or document header, including the
`URL, content-type, client address, server name, etc.
`Priority numbers are used to order the MEGs whose
`rules are satisfied by a given request.
`When
`it receives a request, WBI
`steps:
`the rules
`(1) The original request is compared with
`for all Request Editors. The Request Editors
`whose rule conditions are satisfied by the request
`are allowed to edit the request in priority order.
`(2) The request that results from
`this Request Ed-
`itor chain is compared with
`the rules for all
`Generators. The request is sent to the highest
`priority Generator whose rule is satisfied. If that
`Generator
`rejects the request, subsequent valid
`Generators are called in priority order until one
`produces a document.
`(3) The request and document are used to determine
`which Document Editors and Monitors should
`see the document on its way back to the origi-
`nal requester. The document
`is modified by each
`Document Editor whose rule conditions are sat-
`isfied in priority order. Monitors are also contig-
`ured to monitor
`the document either (a) as it is
`
`Oracle Exhibit 1005, page 4
`
`

`
`R. Burrett,
`
`Ef! Maglio/Computer
`
`Networks
`
`and
`
`ISDN Systems
`
`30 (1998J
`
`509-518
`
`513
`
`1
`Table
`The basic MEG
`
`(Monitor/Editor/Generator)
`
`building
`
`blocks
`
`used
`
`to build
`
`intermediary
`
`applications
`
`MEG
`
`type
`
`Input
`
`output
`
`Action
`
`Examples
`
`Request
`Editor
`
`Request
`
`Request
`
`Modify
`
`request
`
`Generator
`
`Request
`
`Document
`
`Produce
`request,
`
`document
`or reject
`
`that satislies
`request
`
`Document
`Editor
`
`Request
`Document
`
`and
`
`Document
`
`(which
`document
`Modify
`text, HTML,
`image,
`applet,
`
`could
`etc.)
`
`be
`
`Monitor
`
`and
`
`None
`
`Request
`Document
`
`Autonomous
`
`None
`
`None
`
`resulting
`and
`request
`and perform
`
`Receive
`document,
`computation
`Perform
`background
`that
`is not affiliated
`particular
`transaction
`
`the
`
`request
`insert
`
`header
`to a new URL, modify
`form
`information,
`add/remove
`
`forward
`
`a
`
`Redirect
`information,
`cookies
`tile.
`a locally-stored
`from
`the document
`Read
`the request
`to another
`intermediary
`or server.
`dynamically
`compute
`the document
`(like CGI).
`compose
`the document
`from
`a database.
`produce
`control
`page such as **document
`moved”
`or “invalid
`authorization*’
`Add annotations,
`translate
`document
`Format
`to HTML).
`scripts
`statistics,
`usage
`Gather
`documents
`in a cache,
`
`highlight
`format
`change
`
`links,
`(e.g.
`form
`
`toolbars,
`add
`from Rich Text
`information.
`add
`
`record
`record
`
`trail,
`user
`tilled-out
`
`store
`forms
`
`computation
`with a
`
`user browsing
`Calculate
`new documents.
`crawl
`cleanup
`unneeded
`cache
`
`statistics,
`a server
`tiIes
`
`search
`for broken
`
`the Web
`links.
`
`for
`
`produced by the generator, (b) as it is delivered
`from
`the intermediary, or (c) after a particular
`Document Editor.
`the re-
`to
`is delivered
`(4) Finally,
`the document
`quester, which may be the browser if this is the
`first intermediary
`in the chain.
`An application
`is usually composed of a number
`of MEGs which operate
`in concert
`to produce a
`new function. Such a group of MEGs
`is a WBI
`plugin. Plugins define the basic unit of granularity
`for installation, configuration, and enable/disable.
`
`3.3. Example WBI plugins
`
`3.3.1. Cookie manager
`Figure 4 illustrates a simple WBI Plugin for man-
`aging HTTP cookies’ with an intermediary. Current
`browsers allow
`the server to send a cookie with a
`document. The cookie
`is stored on the client ma-
`chine and can be used to identify
`the user later. Some
`users do not want cookies to be stored, as cookies
`remove a certain degree of privacy. Some browsers
`allow
`the user to configure a cookie policy
`(e.g.,
`
`’ http://www.cis.ohio-state.edu/htbin/rfc/rfc2109.html
`
`out of
`built
`manager WE1 Plugin
`cookie
`Fig. 4. A simple
`the cookie
`MEGs.
`The Request
`Editor
`adds
`cookies
`from
`(not
`shown)
`to
`the appropriate
`requests.
`The Document
`removes
`cookies
`from
`the delivered
`documents
`and adds
`the cookie
`store.
`The Generator
`produces
`and
`interprets
`HTML
`forms
`so
`the user
`can manage
`the cookie
`store
`policies.
`
`three
`store
`Editor
`them
`to
`various
`and
`its
`
`always accept cookies, never accept cookies, or ask
`the user for each cookie). But these simple policies
`are often not sufficient, and it is often difficult
`to
`examine the cookies that have already been stored.
`With WBI, it is very easy to build a flexible cookie
`manager. A Document Editor modifies all documents
`that are sent to the browser. If it detects a cookie, it
`removes the cookie, only storing it if it fits a prese-
`lected policy. If the policy permits, a Request Editor
`
`Oracle Exhibit 1005, page 5
`
`

`
`si4
`
`R. Burrett,
`
`PI? Maglio/Computer
`
`Networks
`
`and
`
`ISDN Systems
`
`30
`
`(1998)
`
`509-518
`
`adds cookies back into requests before they are sent
`to the server. A Generator produces and interprets
`some simple HTML
`forms that allow the user to set
`the cookie policy and to review and delete stored
`cookies.
`is a simple example of a
`The cookie manager
`three MEGs arranged
`to
`WBI Plugin built
`from
`work in concert to form a single, useful function.
`It
`also illustrates some of the advantages of building
`functions with
`intermediaries
`rather than building
`functions directly into browsers:
`(11 the same cookies are available on multiple
`browsers
`(2) the same cookie manager program can be used
`on a Workgroup server, allowing many users
`access to this function without requiring
`them to
`install it on their personal machines
`(31 new cookie manager plugins can be developed
`for special needs
`
`3.3.2. Improving wireless performance
`A more complex set of WBI Plugins is illustrated
`in Fig. 5. The goal here is to make a wireless Inter-
`net connection more efficient. One set of client-side
`MEGs manages a cache that has a prefetch ca-
`pability. A Monitor observes all Web transactions
`and stores the results
`in a disk cache. An Au-
`tonomous
`function periodically
`requests commonly-
`needed documents
`to refresh the cache for instant
`access. A Generator intercepts all requests from the
`
`improve
`to
`together
`that work
`Plugins
`5. Several WBI
`Fig.
`manage
`A Monitor
`and Generator
`a wireless
`Web
`browser.
`prefetches
`local
`cache.
`An
`Autonomous
`function
`periodically
`the client
`and
`important
`documents,
`A pair of Generators,
`one on
`one at
`the Workgroup
`server
`convert
`the standard
`HlTP
`protocol
`to a compressed
`version
`suitable
`for wireless
`transmission.
`Document
`Editor
`distills
`documents
`to
`reduce
`image
`size
`complexity.
`
`A
`and
`
`a
`
`browser, examines the cache and, if possible, satis-
`fies the requests. If the Generator cannot
`find the
`desired document
`in the cache, it rejects the re-
`quest. The next Generator in the chain translates the
`HTTP protocol
`into a special, compressed version
`that optimizes
`the throughput of the wireless link,
`and sends the translated request across the link. The
`compressed request is received by a Workgroup
`in-
`termediary
`that contains a Generator to de-translate
`the compressed protocol back into HTTP and pass it
`to the requested server. Finally, a Document Editor
`distills what comes back from
`the server to remove
`unneeded colour depth before sending the document
`to the client.
`This application breaks down into three plugins: a
`client-side cache with prefetch, a compressed proto-
`col translator, and an image distiller. Each is useful in
`its own right, but together form a powerful means for
`improving Web browsing for the mobile user. Mod-
`ularity makes intermediary programming productive
`and intermediary applications flexible.
`
`4. WBI implementation
`
`Two equivalent versions of the WBI infrastructure
`have been built, one in C++ (both 32-bit Windows
`and OS/2) and the other in Java. Both allow WBI
`Plugins to be written
`in C, C++ or Java. WBI can
`serve as an intermediary
`for HTTP, HTTP-S, FTP
`and Gopher protocols. It can handle proxy- or server-
`type requests, and the rule system can differentiate
`between these to route requests appropriately. There-
`fore WBI can be accessed directly
`from a browser
`just like any server, or the browser can be configured
`to use WBI as a proxy.
`
`4. I. Conjigurations
`
`is to install it on a
`One typical WBI configuration
`client machine and configure the client browser to use
`“localhost” as its proxy. This client-side
`intermedi-
`ary processes all requests from that browser, and can
`provide access to local information, personalization
`functions, or can perform other client-specific com-
`putation. WBI can be configured with any appropriate
`firewall information so that normal Web requests are
`passed through a socks server or HTTP proxy.
`
`Oracle Exhibit 1005, page 6
`
`

`
`R. Burrett,
`
`PR Maglio/Computer
`
`Nehvorks
`
`and
`
`ISDN
`
`Systems
`
`30 (1998)
`
`509-518
`
`51s
`
`The workgroup
`to the
`is similar
`configuration
`client-side case, except that several client machines
`are configured
`to use the same instance of WBI
`as their proxy. WBI can be running on one of the
`client machines or on any other networked machine.
`Some functions
`require that different users be iden-
`titied, so WBI provides the capability of identifying
`the HTTP Proxy Authen-
`individual users through
`tication
`’ mechanism. Thus,
`functions within
`the
`Workgroup
`intermediary can keep users separate to
`maintain
`individual histories or to provide custom
`configurations.
`Finally, a configuration switch can set WBI to be
`a server-side intermediary. When this switch is set
`and a server name is specified, server-type requests
`run through
`the normal rule system and MEGs. But
`if no Generator accepts the request, it is forwarded
`to the specified server. In this way, WBI can appear
`to a browser as if
`it were
`the server, but
`it can
`provide additional
`functions. For example, WBI can
`translate documents that come from the server or it
`can provide search services for the server. This can
`all be done without contiguring
`the destination server
`in any way: users simply access the server-side WBI
`instead of the server to get the enhanced functions.
`
`4.2. Component model
`
`Recently, WBI’s plugin definition has been ad-
`justed to tit the Java Beans6 component model. In
`this model, WBI Plugins beans contain MEG beans,
`When WBI starts up, each registered Plugin is initial-
`ized. In their initialization code, the Plugins register
`their various MEG beans as transaction
`with WBI
`listeners. Each MEG bean contains properties
`that
`define the MEG’s firing rule, priority, and other per-
`tinent information. A standard library of beans has
`been developed for common
`functions, such as pro-
`ducing a static page of HTML, serving a file from a
`disk, adding annotations to the top of Web pages, in-
`terpreting
`forms. and generating “document moved’
`responses.
`to easily
`The bean model enables programmers
`develop systems with a visual programming envi-
`ronment. Because WBI beans are not graphical, the
`
`simplest bean builders do not provide an appropriate
`user interface. We have begun to develop a visual
`programming environment
`for WBI
`that allows the
`developer to build MEGs from other MEG beans and
`to incorporate
`them
`into Plugins. The environment
`also has facilities
`for visually
`tracing
`transactions
`through
`the MEGs and for viewing
`the results after
`each edit or generate step.
`We have found the bean model to greatly increase
`programmer productivity as common beans are com-
`bined
`to form complex MEGs and Plugins. Most
`applications still require some code to be written. but
`often this code simply instantiates basic MEG beans,
`sets their properties appropriately and then forwards
`requests to them.
`
`4.3. Peryhormance
`
`issue
`is an important
`Intermediary performance
`First,
`it should be
`for practical
`implementations.
`noted that the standard browser/firewall/server model
`is a special case of an intermediary model.
`In this
`case, the firewall
`is a simple intermediary
`that for-
`wards requests to an external network and the server
`is a simple intermediary
`that delivers file-based or
`dynamic content. Therefore,
`it is clear that interme-
`diaries do not fundamentally degrade Web perfor-
`mance.
`But what price is paid for a fully programmable
`intermediary such as WBI? Preliminary performance
`tests using WebStone 2.07 show
`that
`the C++
`implementation
`of a WBI-based
`server runs 1.2
`times slower than Microsoft
`Internet
`Information
`Server’ on Windows NT. The Java version of the
`WBI-based server, using Sun JDK 1.1.3 with the JPP
`1.1.3 just-in-time
`compiler,
`runs 2.5 times slower
`than the C++ version. This result shows that run-
`ning requests through our native-code
`rule system
`and MEG dispatcher requires 20% processing over-
`head. The Java benchmark
`indicates
`the efticiency
`of current Java implementations. We believe that the
`extra CPU load is not unreasonable considering the
`advantages of the intermediary programming model.
`Of course, adding intermediary
`functions beyond
`simple Web serving will take more processing, but
`
`Oracle Exhibit 1005, page 7
`
`

`
`516
`
`2
`Table
`A comparison
`
`Language
`Location
`Operations
`Granuhrrity
`Rules
`Contiguration
`Negotiation
`Code
`location
`
`R. Barrett,
`
`P?! Maglio/Computer
`
`Networks
`
`and
`
`ISDN
`
`Systems
`
`30 (1998)
`
`SO9-,518
`
`of programming
`
`with WBI
`
`and Servlets
`
`WBI
`
`Servlets
`
`Java
`server
`servlet
`servlet
`LJRL/content-type
`static
`ordered
`manuahy
`local or network
`
`matching
`
`Java. C, C++
`client,
`server, Workgroup
`request
`editor,
`generator,
`MEG,
`plugin
`boolean
`expressions
`dynamic
`priority
`local
`
`system,
`
`generators
`
`across
`
`document
`
`editor, monitor,
`
`autonomous
`
`request
`
`and document
`
`header
`
`lieIds
`
`may
`
`reject
`
`requests
`
`the bulk of this will be in the particular enhancement
`functions, with little additional system overhead. In
`more pragmatic
`terms, we have found that both the
`C++ and Java versions of WBI can add consider-
`able functionality when run as a personal client-side
`intermediary without
`the user noticing performance
`degradation.
`In the Workgroup and server configura-
`tions, more care must be taken to ensure that there
`is enough CPU power to handle the extra computa-
`tions.
`
`5. Discussion
`
`5. I. Comparison with other Web programming
`
`tools
`
`WBI can be compared with many other pro-
`gramming paradigms
`for Web-based applications,
`including CGI’, NSAPI
`lo, ASP ‘i, Ore0
`‘*, and
`Servlets 13. Each has strengths and weaknesses, yet
`WBI
`is the first to fully
`implement
`the intermedi-
`ary notion. Rather
`than compare WBI
`to each of
`these, we choose to consider JavaSoft’s Servlets in
`more depth; the results are summarized
`in Table 2.
`(A comparison between WBI and Ore0
`is given
`elsewhere [ 11.)
`the base
`system with
`WBI
`is a multi-language
`code in both C++ and Java. WBI Plugins can be
`
`’ http://hoohoo.ncsa.uiuc.edu/cgi/
`‘r’ http://search.netscape.co~misc/developer/conference/proceedi
`ngs/s5/index,html
`” http://www.microsoft.co~iis/usingiis/deveiopin~#ASP
`” http://www,camb.opengroup.org/www/waib~papers/etaco~et
`acom.html
`I3 http://www.javasoft.co~products/java-se~er/se~lets/index.
`html
`
`in C, C++, or Java and these plugins can
`written
`operate equivalently with either base. This cross-
`language compatibility
`is valuable but may not be
`maintained
`in future versions of WBI because of the
`unacceptable restrictions
`that result from program-
`ming
`to the lowest common denominator between
`C++ and Java. Servlets are fundamentally based on
`Java.
`WBI’s programming model places equivalent pro-
`grammability
`at the client, server and Workgroup
`server. Servlets, as the name implies are designed to
`be run on a server in the traditional model.
`WBI has five basic building blocks for construct-
`ing applications, Servlets only has one. Though all
`of the functions can be performed with Servlets, they
`are not optimized. For example, WBI runs Monitors
`at low priority because they do not affect the user
`interface. To implement a Monitor with Servlets, the
`programmer would have to write an editing servlet
`that simply copied
`its input
`to its output
`(an un-
`necessary computational
`load) and then perform
`the
`monitoring
`function.
`Servlets are configured one servlet at a time while
`WBI has a Plugin granularity
`that allows multiple
`MEGs to be configured at once. This plugin
`level
`of granularity
`is more useful for users and system
`administrators.
`WBI’s rule system for dynamically determining
`the data path
`through
`the various MEGs allows
`arbitrarily complex boolean expressions. Servlets are
`limited
`to simple URL and content-type matching.
`With WBI, rules can be dynamically altered to add or
`delete MEGs, or to change their firing condition, all
`under program control. WBI’s priority system allows
`dynamic negotiation of the data path through
`the
`ME&
`In addition, Generators may selectively reject
`
`Oracle Exhibit 1005, page 8
`
`

`
`R. Burreli,
`
`PP Muglio/Computer
`
`Networks
`
`and
`
`ISDN Systems
`
`30 (l998}
`
`509-518
`
`517
`
`requests so that, though the rules might indicate that
`the Generator can handle the request, the Generator
`itself can reject it later. This feature is crucial
`for
`implementing
`important
`functions such as a cache.
`The flow of transactions through Servlets is statically
`configured at server startup or is manually adjusted
`by a system administrator.
`features that are
`Servlets do have a couple of
`the configuration
`missing
`from WBI. Specifically,
`can load Servlets from
`remote servers rather than
`requiring
`them to be manually
`loaded on the same
`machine.
`In addition, a special <SERVLET>
`tag
`allows Servlets to insert dynamic content
`into
`the
`document. These functions can be added to WBI
`without difficulty.
`to be pow-
`the WBI architecture
`We have found
`erfully productive. Though similar
`to several other
`systems, the full-featured
`intermediary paradigm
`is
`unique and gives the programmer unpar