The Web Request Broker: A Framework for Distributed Web-Based Applications

M. Anand, E. Chien, R. Condamoor, A. Mathur, S. Adunuthula, S. Chou, and S. Nakhoda
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065.

Abstract

The World Wide Web (WWW) is rapidly evolving from a platform for serving up static documents to a platform for deploying distributed, cross-platform, and language and location independent applications. There is thus a need for appropriate frameworks that would allow not only the deployment but also the development of such applications. In this paper, we describe the Web Request Broker (WRB), a system developed here at Oracle that provides a distributed, scalable, and daemon-independent framework for developing and deploying distributed web-based applications. The framework description is along three dimensions. The first dimension is the overall architecture of the WRB. The next dimension is the application programming interface (API) offered by the WRB to applications, and the final dimension is the kinds of programming paradigms that can be used with the above API to develop applications.

1. Introduction

The World Wide Web (WWW) is rapidly evolving from a platform for serving up static documents to a platform for deploying distributed, cross-platform, and language and location independent applications. Developing such applications for the web involves a number of challenges. The application needs to be accessible from conventional web browsers and hence needs to be able to communicate using protocols such as HTTP. The application needs to use names in accordance with URL's as used on the web. The application also needs to be able to inter-operate with existing HTTP server daemons, i.e., it needs to be daemon independent. In this paper, we describe the Web Request Broker (WRB), a system developed here at Oracle that addresses some of these challenges.

The WRB is part of Oracle's Web Application Server. The WRB provides a distributed, scalable, daemon-independent framework for developing and deploying distributed web-based applications. Bernstein defines a framework in the context of application development environments as follows [2]:

A framework is a software environment that is defined to simplify application development and system management for a specialized application domain.

The application domain in our case is quite general and encompasses web-based distributed applications. The WRB provides a framework to support the development and deployment of such applications. We describe this framework here. The framework description is along three dimensions. The first dimension is the overall architecture of the WRB. The next dimension is the application programming interface (API) offered by the WRB to applications, and the final dimension is the kinds of programming paradigms that can be used with the above API to develop applications.

The rest of the paper is organized as follows: Section 2 describes the overall architecture of the WRB. Section 3 describes cartridges, an application structuring mechanism provided by the WRB. Section 4 discusses the API offered by the WRB to application developers. Section 5 describes programming paradigms that can be used with the WRB API. Section 6 discusses related work and Section 7 concludes the paper.

2. Web Request Broker Architecture

The WRB is designed to provide a framework for the development and deployment of industrial strength applications for the web. The main components that make up the WRB are shown in Fig. 1.

These include the dispatcher, application and system cartridges , and a Corba [4] compliant Object Request Broker (ORB) . The dispatcher and cartridges are built over the ORB and utilize the ORB for inter-component communication. This allows the components to be distributed on remote machines, for performance and scalability reasons.

The dispatcher is responsible for routing requests received from the HTTP daemon to the appropriate cartridge. It is designed to be extensible and daemon independent.

Cartridges are modules of code performing specific application or system functions. They form the centerpiece of the WRB framework. We discuss cartridges in detail in the following section. For now it suffices to think of cartridges as specialized code modules.

The typical stages involved in processing a client request are as follows. Upon receiving the client request from the underlying daemon, the dispatcher determines which cartridge needs to handle the request by using the naming service system cartridge. It then authenticates the request using the authentication service system cartridge . Once authenticated, the dispatcher obtains an instance of the cartridge that will handle the request from the resource manager system cartridge. Finally, it dispatches the request for execution to that cartridge by calling the execution manager system cartridge.

3. Cartridges

In the framework provided by the WRB, all services be they application or system services, can be structured as one or more cartridges. Cartridges are thus central to the framework. In this section we describe various aspects related to cartridges.

3.1 Cartridge Naming

A cartridge forms the basic unit of distribution in the system. Thus there needs to be a uniform way of naming cartridges. Cartridges are named using URL's. A cartridge name has two parts. The first part is the IP address of the server on which the cartridge resides. The second part is a virtual path in the server directory structure that can be used uniquely associated with the cartridge. This allows the cartridge name space to be global as well as allows cartridges to be accessed uniformly as other web resources such as documents etc.. It also allows quite a lot of flexibility in naming cartridges, avoiding name conflicts, as well as allowing the name space to grow as new cartridges are added to the system.

3.2 Cartridge Interface

Each cartridge has a standard interface, which provides a common overall structure for all cartridges. The abstract cartridge interface is as follows:




interface Cartridge {



   boolean init(); 

   boolean authenticate(in Principal user_passwd); 

   boolean exec(in Request req_obj, out Response resp_obj);

   boolean shutdown();

   boolean quiesce();	

   boolean unquiesce();

}

The init() routine is responsible for intializing the cartridge instance. This may include invoking the constructors of several subobjects, preforking threads and acquiring all other required shared resources. The shutdown() routine is responsible for cleaning up all of the resources and shutting down the cartridge instance. Once the shutdown() routine is invoked on a cartridge instance, it immediately becomes unavailable for servicing subsequent requests. The authenticate() routine validates whether the client requesting the services of the cartridge is authorized to use those services. The exec() routine is the generic way to dispatch all service requests to the cartridge. The quiesce() and unquiesce() routine are called to temporarily suspend/resume the cartridge instance without bringing it down. Once the cartridge instance has been quiesced, it will ignore all routines except for unquiesce(). Normal processing resumes after unquiescing.

3.3 Cartridge States

The major states in the lifetime of a cartridge instance are shown in Fig. 2. The cartridge instance starts out in state 1, and transitions to state 2 when the init() routine is called. If the authenticate() routine is called next, it then transitions to state 3. If the cartridge does not perform authentication, then the execute() routine will be called next, which causes the cartridge to transition to state 4. The cartridge instance will also transition to state 4 from state 3 when the execute() routine is called. Finally, the cartridge instance transitions to state 5 when the shutdown() routine is called.

4. The Web Request Broker API

The Web Request Broker supports a rich API that is accessible to cartridges, independent of the underlying HTTP daemon. Due to space considerations we do not describe all of the routines in the API, but rather describe four key sets of routines that give a sense for the kind of functionality available in the API.

4.1 Request Service Routines

The set of request service routines provides cartridges information about the client making the request, information about the request itself, as well as information about the underlying daemon. Some of the routines in this set are:

WRB_getParsedContent(): retrieves the current HTTP request's query string if the request method is GET, or its POST data if the request data is POST.
WRB_getRequestInfo(): retrieves information about the incoming request.
WRB_recvHeaders(): returns the HTTP headers associated with the current request.
WRB_read(): reads the specified number of bytes from the request POST data.
WRb_getCookies(): returns the cookies associated with the current request.
WRB_setCookies(): adds a cookie to the response header for the current request.
WRB_sendHeader(): sends the HTTP response headers to the remote client.
WRB_write() and WRB_printf(): writes the specified number of bytes from the specified buffer to the remote client.

4.2 Inter-Cartridge Communication Routines

The inter-cartridge communication routines allow a cartridge to communicate with cartridges on local and remote hosts using the HTTP protocol. Some of the routines in this set are:

WRB_ICXcreateRequest(): creates a request data object.
WRB_ICXsetMethod(): sets request method data.
WRB_ICXsetAuthInfo(): sets the authentication header data.
WRB_ICXsetContent(): sets content data.
WRB_ICXsetHeader(): sets the HTTP header data.
WRB_ICXmakeRequest(): issues the specified request to the remote cartridge.
WRB_ICXdestroyRequest(): destroys the request data object.

4.3 Transaction Service Routines

The transaction service routines are based on the X/Open transaction model, and allow a cartridge to associate transactional semantics to groups of operations. Some of the routines in this set are:

tx_reg(): register a resource manager.
tx_open(): opens a connection to the resource managers.
tx_begin(): begins the transaction.
tx_commit(): commits the transaction.
tx_rollback(): rolls back the transaction.
tx_close(): disconnects from the specified resource manager.

4.4 Content Management Routines

The content management routines provide a uniform interface to content stored either in the file system or the database. Some of the routines in this set are:

WRB_CNTopenRepository(): establishes a connection to a content repository.
WRB_CNTopenDocument(): locates a specified document in the content repository and returns a pointer to it.
WRB_CNTreadDocument(): reads a specified number of bytes from the current position in a document.
WRB_CNTwriteDocument(): writes a specified number of bytes from the specified buffer to the current position in the document.
WRB_CNTflushDocument(): flushes any buffers.
WRB_CNTcloseDocument(): closes the specified document.
WRB_CNTdestroyDocument(): deletes the specified document.
WRB_CNTcloseRepository(): closes the connection to the repository.

5. Programming Paradigms

The WRB API discussed in the previous section lends itself to a number of different programming idioms or paradigms . Each paradigm is a way to structure the code and has certain well defined properties. Thinking in terms of paradigms simplifies application development considerably, as a complex task can be broken down into smaller manageable modules, with each module structured around a paradigm whose properties and behavior are well understood.

5.1 Request/Response Paradigm

The request/response paradigm involves a client requesting a resource from the server. The server, if it has access to the resource, responds by returning the resource to the client. At this point the server no longer has any state associated with the client's request, and so to the server, each client request is independent of any previous requests.

The typical states that the cartridge goes through when implementing the request/response paradigm are shown in Fig. 3. When the cartridge receives a request, it transitions from the initial state (state 1) to the next state (state 2). In state 2 it does various things related to the request received. When the cartridge sends the response to the requesting client, it transitions to state 3, where it is done executing. Note that there are other intermediate states possible, but the three states shown capture the essential nature of the request/response paradigm.

5.2 Session/Conversational Paradigm

The session/conversational paradigm is characterized by the ability of the server to maintain client state across multiple requests. This allows applications to maintain a session with the server, and execute multiple requests/responses within that session. A cartridge that implements the session paradigm needs to be assigned a session lifetime, which specifies the duration of the session. This information is registered with the WRB.

The typical states that the cartridge goes through when implementing the session paradigm are shown in Fig. 4. When the cartridge receives a request, it transitions from the initial state (state 1) to the next state (state 2). In state 2 it does various things related to the request received. When the cartridge sends the response to the requesting client, it transitions back to state 1, where it can receive additional requests from clients. When the session has been in existence for the specified duration, the cartridge transitions to state 3, where it is done executing.

5.3 Transactional Paradigm

The transactional paradigm allows a group of operations to be executed atomically, i.e., either all of the operations in the group are executed successfully or none are. The typical states that the cartridge goes through when implementing the transactional paradigm are shown in Fig. 5. When the cartridge receives a request, it transitions from the initial state (state 1) to the next state (state 2). In state 2 it does various things related to the request received. It transitions to state 3 after it initiates the transaction. In state 3 it performs various operations that are part of the transaction. It then transitions to state 4 after committing or aborting the transaction. Finally, it transitions to state 5 after it sends a response back to the client.

5.4 Examples

We next describe two examples that illustrate the paradigms detailed above. The first example illustrates the request/response paradigm, while the second example illustrates both the session and transactional paradigms. In the first example, as shown in Fig. 6, a client makes a request to cartridge A, which exists on host server X. Cartridge A in order to respond to the request, in turn makes a request to cartridge B on host Y. Cartridge B responds with the necessary information, which cartridge A uses to satisfy the original request to the client. Both cartridges A and B do not retain any information regarding the request after sending their respective responses. This illustrates not only the stateless nature of the request/response paradigm, but also the distributed operation of cartridges.

In the next example, as shown in Fig. 7, a client makes a request to a cartridge that involves the cartridge initiating a transaction on the database. After the cartridge responds to the client's original request, the cartridge maintains state regarding the client's original request, in particular information about the active transaction. The client then sends another request, possibly with information to update the database. The cartridge includes this information within the active transaction. Finally, the client sends a third request to commit the transaction to the cartridge. Thus the cartridge retains state about the client's request across multiple requests for the duration of the session. The transactional semantics ensure that the operations executed by the cartridge during the session are atomic, i.e., either all are applied to the database, or none are.

6. Related Work

Application development frameworks for distributed web-based applications are also being developed by other software vendors. Due to space restrictions we are unable to make a detailed technical comparison of the features offered by the other systems with the features offered by the WRB. However, we highlight here some of the key differences between these systems and the WRB.

The systems offered by Apache [1], Purveyor/Microsoft [5], Netscape [7], and Spyglass [8] are all structured such that applications run in the same address space as the web server. In the WRB, the application runs in a separate process. However, unlike CGI [3], we do not create a new process for each request. The WRB maintains a pool of processes, and processes are re-used from this pool in order to satisfy incoming requests. Java servlets from Sun [6] uses a similar approach by maintaining a pool of threads.

7. Conclusions

The World Wide Web (WWW) is rapidly evolving from a platform for serving up static documents to a platform for deploying distributed, cross-platform, and language and location independent applications. There is thus a need for appropriate frameworks that would allow not only the deployment but also the development of such applications. We presented the Web Request Broker (WRB), a system developed here at Oracle that provides a distributed, scalable, and daemon-independent framework for developing and deploying distributed web-based applications. The framework was described along three dimensions. The first dimension is the overall architecture of the WRB. The next dimension is the application programming interface (API) offered by the WRB to applications, and the final dimension is the kinds of programming paradigms that can be used with the above API to develop applications.

References

[1] Apache API Notes, Apache, 1996.

[2] P. A. Bernstein, "Middleware: A Model for Distributed System Services," Communications of the ACM, Vol. 39, No. 2, Feb. 1996, pp. 86-98.

[3] CGI version 1.1 Specification, 1996.

[4] The Common Object Request Broker: Architecture and Specification, revision 2.0, Object Management Group, Cambridge, MA, 1995.

[5] ISAPI Specification, Purveyor Corp., Framingham, MA, 1996.

[6] Java Servlet API White Paper, Sun Microsystems Inc., Mountain View, CA, 1996.

[7] Netscape API Functions, Netscape Communications, Mountain View, CA, 1996.

[8] Spyglass Web Server SDK 2.1, Spyglass Inc., Naperville, IL, 1996.

[9] Web Request Broker API, Oracle Corp., Redwood Shores, CA, 1996.

Return to Top of Page
Return to Posters Index