Web Request Broker (WRB)

The Web Request Broker (WRB) is the core of the WAS. It is a CORBA compliant Object Request Broker (ORB) (see the earlier discussion on CORBA). It receives and processes incoming requests, analyzes them to determine which application is being requested, and regardless of where they are on the network, invokes the relevant cartridges as necessary. It also provides various services to these cartridges as required. The WRB performs load-balancing, address translation, security functions, and manages and monitors the execution of applications throughout the entire system.

The WRB consists of several processes, listed in Table 27.2. The processes include such things as the Virtual Path Manager, which helps to route the incoming request to the appropriate cartridge by analyzing the virtual path—a portion of the URL—and determining the cartridge that is being asked for. The Logger service keeps track of requests and messages in a file or in the database for later review. It provides a generic interface to all cartridges, so that any cartridge can write log data.

For more information about the Authentication service, see Web Security.

If your configuration of the WRB includes distribution of processes across multiple nodes, most of the WRB processes will stay on the primary node. The cartridges and the cartridge factory processes (wrbfac’s) run on the remote nodes. The Authentication service may also be configured to run on remote nodes as well.

Transaction Management

This option, which is only available in the WAS 3.0 Advanced Version, is used by applications that must lock records in one Web display, and takes the user through a series of hyperlinks before deciding to either COMMIT the set of changes or ROLLBACK the entire set of changes.

To appreciate the significance of this service, we must first understand what Oracle does in a multi-user environment. When a user logs in to a system and accesses a record in a table, Oracle locks that record in that table for that user, allowing that user the time to decide to either COMMIT his changes, or ROLLBACK the data to its original state. While the user is online, and before deciding to either COMMIT or ROLLBACK, other users may log in and query the same record. But Oracle’s built-in, row-level locking mechanism prevents that second person from doing work that will conflict with the first user—for example, changing data in another part of the same record. The first user can complete his or her work, possibly performing multiple INSERT, UPDATE, and DELETEs, until finally deciding to either COMMIT or ROLLBACK all of his work. For mission critical multi-user RDBMSs, this is a required capability.

Unfortunately, it’s not easily accomplished on the Web. The Web uses HTTP, which is a stateless protocol. In other words, users don’t really “log in” to a session, but instead they “connect” for a single request. When that request has been answered, the connection is terminated. There is no login session in which the database can easily maintain “state”, over which a lock can persist.

If a transaction can be accomplished within one HTTP request, there is no problem. But some transactions requires multiple requests—for example, letting the user click through multiple hyperlinks, displaying different pages, entering or modifying data in various fields, and then finally reaching a Web screen in which the user decides to COMMIT or ROLLBACK his or her work. Each click is an HTTP request, and every Web screen that follows is a response. And each response results in a terminated connection.

One way to create a persistent session is through the use of cookies. This method is manageable for such things as user authentication (when combined with other features), but transaction management is potentially more complex when juggled across multiple incoming requests. The developer can create an internal session table of some sort, and write logic into each application that locks records according to a particular user request. The application can issue cookies, to keep track of who implicitly requested which lock, and associate timeouts with each lock in case someone who requests a lock just turns off their machine and walks away without performing either a COMMIT or a ROLLBACK. After all, there is no logoff process for users other than the end of a single request and, if you choose to ignore that for maintaining state, there’s no dependable logoff process at all.