0183-0186

Previous Table of Contents Next

Page 183

Web application development. The WRB architecture allows cartridges to perform the same tasks as CGI scripts. However, there are several advantages to using cartridges instead of CGI scripts: They provide better performance and better security, their execution can be monitored , and they can be configured and maintained centrally through a browser-based administrative interface.

Cartridges generally follow one of three basic programming models:

• Request-response
• Session
• Transaction

The request-response model is used to provide services that do not require state information to be maintained from one instance to the next. For example, you can write a cartridge to simply process SQL queries and return a result from an Oracle database. In a single execution, the cartridge authenticates the user , applies the SQL, and returns a formatted HTML page with the results in a table.

Other cartridges might need to maintain state information as long as the client is connected, using the session model. For example, a cartridge might store session preferences to provide different displays based on the client's browser.

The transaction model is used when state information needs to be stored for the life of a multi-task operation only. A cartridge to support online ordering might allow items to be added to the "shopping cart" one at time, storing this information internally until the transaction is complete.

Cartridges often use services provided by other cartridges through the intercartridge exchange. All the preceding cartridge examples would most likely rely on the PL/SQL cartridge supplied with Oracle Web Server to provide queries to Oracle tables. This modular architecture also allows you to write full-scale Web-based applications using only preexisting cartridges.

Component Interaction

One of the most important features of the Web Application Server 3.0 design is its flexible multi-process architecture. The HTTP server has the assistance of WRB processes and cartridge instances working together to satisfy a request. You can configure and deploy these components in many different ways. Figure 9.1 provides an example of the interaction between the major components in a dedicated server context.

Page 184

Figure 9.1.
The interaction
between the Web
Application Server
components.

This figure represents a Web Application Server running on a dedicated machine, processing four HTTP requests for cartridge services. This configuration shows two listener/dispatchers accepting requests for cartridges and communicating with the WRB to locate and load an instance of the requested cartridge.

NOTE

An instance of a cartridge handles only one request at a time. Two instances of Cartridge A are loaded because two clients use Cartridge A simultaneously .

When a cartridge is loaded and initialized , it informs the WRB that it is ready to accept requests. The WRB informs the dispatcher of the new instance, and the dispatcher sends the request to the cartridge instance, which processes it and sends a response to the dispatcher.

Page 185

Depending on the nature of the cartridge, it might maintain some state information and remain "occupied" to handle additional requests from the dispatcher. In this case, when the client initiates the next request, the dispatcher passes it directly to the cartridge. If the cartridge was developed to handle independent requests, it notifies the WRB that it is available immediately after responding to the dispatcher. You can then use it to process a request from a different client ( assuming that the minimum number of instances are not already available). The minimum and maximum number of instances are configurable on a per-cartridge basis. Load balancing is built into the architecture because each cartridge handles a single client at a time, and the number of instances that are available can be configured for optimal performance. Note that each cartridge instance runs in a separate WRB execution instance (WRBX), which provides the WRB interface and services. This reduces contention and prevents an execution problem in one WRBX from affecting other instances.

Although the diagram does not explicitly show the use of the intercartridge exchange, each cartridge type can access services of the other cartridge types. The intercartridge exchange is implemented by the WRB, so requests sent from one cartridge to another are initially routed through it.

The diagram in Figure 9.1 shows only one of many possible configurations. For example, each of the listener/dispatcher processes can run on separate machines. If the optional ORB service of the advanced version is enabled, the individual cartridges can run on separate machines as well. Keep in mind that listener/dispatcher security is independent for each listener. Depending on the situation, it might be desirable to have two different configurations. For example, you might configure a system with one listener behind a firewall and minimal security for intranet access and configure another listener with SSL for Internet access. This approach allows for some applications to be accessed by anybody on the Web, whereas other applications require much tighter security.

NOTE

Most applications that access Oracle databases use one or more of the supplied cartridges. These cartridges include the PL/SQL cartridge, the LiveHTML cartridge, and the Java cartridge, among others. Individual cartridges are discussed in greater detail throughout later sections of this chapter.

The diagram in Figure 9.2 illustrates the interaction between Web Server components in greater detail.

Page 186

Figure 9.2.
Processing a request for
a cartridge service that
uses the PL/SQL
cartridge through the
intercartridge exchange.

The steps in processing the cartridge request depicted in Figure 9.2 are

1. The dispatcher uses the WRB to identify the cartridge based on the URL and requests an instance of Cartridge A.
2. The WRB loads an instance of Cartridge A, and the cartridge instance informs the WRB that it is ready.
3. The WRB informs the dispatcher of the new instance of Cartridge A.
4. The dispatcher sends the request to the instance of Cartridge A.
5. After performing some internal processing, the instance of Cartridge A requests an instance of the PL/SQL cartridge from the WRB via the intercartridge exchange.
6. The WRB loads an instance of the PL/SQL cartridge instance, and the cartridge informs the WRB that it is ready.
7. The WRB informs the instance of Cartridge A of the PL/SQL cartridge instance.
8. The instance of Cartridge A sends a request to the PL/SQL cartridge.
9. The PL/SQL cartridge instance processes the request by retrieving some data from the RDBMS.
10. The PL/SQL cartridge returns response data to the instance of Cartridge A.
11. After more internal processing, the instance of Cartridge A sends a response to the dispatcher.

These processing steps, although seemingly complex, are handled by the Web Application Server and the cartridge implementations . From the client perspective, the processing is completely transparent. Clients simply request URLs and receive a response, typically an HTML page.

Previous Table of Contents Next