1224-1226

Previous Table of Contents Next

Page 1224

This delineation makes sense when dealing with the restrictions of the Internet such as bandwidth. Following are some other driving reasons to applying server-side functionality:

• Tie the processing to the data: Apply functionality where the date resides. It is foolish to apply a client-side filter to a large database. When only a handful of rows are needed from a table of millions of rows, the filter should reside on the server. Otherwise, millions of unwanted rows are copied over the Internet just to be tossed away by the client computer, which rejects all but those rows that are needed.
• Hardware maintenance: Centralized computers can be upgraded to support the required load demand. In the past, as software grew in complexity, consumers were forced to upgrade their systems just to use the latest software products.
• Software maintenance: Centralized cartridges can be easily maintained and upgraded. Programming modifications can take immediate effect the next time a client uses the software. In fact, the user might not even know that any changes are made. It is that seamless.
• Productivity: Cartridges are public component modules. Once installed, they can be available for any programmer to access. This provides the programmer with potentially thousands of off-the-shelf software components to perform the lion's share of the application's processing. One day, perhaps soon, 100 percent of programming will occur from combining predeveloped components without a single line of native code.

Most cartridges are developed to reside on the server side.

Persistent Cartridges

A server-side cartridge maintains a lifetime that can span many client-side screens. The cartridge has the capability to apply locks on shared resources and allocate and free private memory. The client processing has the capability to return to the persistent cartridge through a handle to that specific context. An example of this is found in a typical update to a database row. Rather than simply apply an update to a given row, a user wants a lock so that other users cannot affect the same row at the same approximate time. One browser-based screen allows the user to apply the lock. If the lock succeeds, the next screen returns the information to be edited. That screen then allows the user to either cancel the operation or apply the update. The key value for the locked row is stored in private memory of the cartridge. This approach has several advantages:

• Performance: Resources such as logging in and out of the database can be minimized. Also, intermediate results from calculations can be maintained.
• Separation of processing and presentation: Isolation of business rules can be placed strictly on the server side. Front-end presentation can be placed strictly on the browser side. This minimizes the impact of application maintenance and simplifies future programming changes.

Page 1225

• Distributed processing: This architecture places a great deal of the processing on server-side computers. Rather than use client-side resources to save intermediate results, this information is stored on one or more server computers. This minimizes any possible security problems on client computers.

An example can illustrate how state information is saved and used to support several different requests from the client. Suppose an application is used to let a user retrieve information from an Oracle table and save modifications. The following steps show how the server cartridge can be used to maintain session information between client requests :

1. Request to lock a row. The first screen lets the user indicate which database row is needed. This request is sent to the server.
2. Lock a row. The server receives the request and applies a lock to the appropriate table. The lock is maintained until further processing.
3. Request the row's detail. The second screen sends a request to the server and displays the detail for editing.
4. Select the detail. The server prepares the detail and sends it back to the client.
5. User modifies the detail. Client-side processing handles the user modifications.
6. Request to update detail. The modifications are sent to the server.
7. Update the row. The changes are applied to the locked row and the transaction is committed.

Supported Languages for Cartridge Development

Oracle offers several language options for cartridge development. Currently supported languages include Java, PL/SQL, Perl, and C. C is the most powerful of the supported languages. C offers full access to the Web Request Broker (WRB) API. The other languages are interpreted by Oracle's supplied cartridges. This means that they have some limitations as well as performance degradation. This chapter focuses on creating cartridges in C.

The Cartridge Internals

All cartridges have common elements. It is this makeup that enables the WRB to interact with the cartridge. Following are some of the most common elements of a cartridge:

Entry point: This function is called by the WRB engine when the cartridge is first loaded. The entry point function can be called any valid function name . The main purpose of this function is to set the callbacks of the remaining standard functions. Initialize: This standard callback serves to perform any initialization steps for the cartridge. Typical use of this routine is to allocate any memory and set initial values to be shared with other cartridge functions.

Page 1226

Exec: The exec function is the handler routine called by the WRB dispatcher. This function typically parses the requested URL and maintains a state machine, which determines what to do with a given request. Shutdown: This function is called by the WRB engine upon preparing the cartridge to exit. The function needs to perform any resource deallocating, such as freeing memory.
Authorize: This function is called by the WRB to determine whether the client is authorized to process a given request. This function is optional. Other more sophisticated mechanisms offer more restrictive security.

The WRB standard functions return one of the following return values to the Web Request Broker:

WRB_DONE	The function was successful.
WRB_ERROR	The function did not complete successfully. Error during execution.
WRB_ABORT	An unrecoverable error occurred. You need to terminate the application.

PL/SQL Web Applications

As mentioned previously, the Web Application Server has a prepackaged cartridge that allows a developer to write an application in PL/SQL. This cartridge acts a bridge between the Web server and the PL/SQL code stored within the database. For simple transactions to the Oracle database, interacting with the PL/SQL cartridge is a fast and easy way to build dynamic Web pages.

PL/SQL Developer's Toolkit

The Web Application Server comes with many building blocks. Several Oracle-developed packages are available to perform a variety of processing within user-developed PL/SQL.

Oracle Web Server Hypertext Procedures and Hypertext Functions Packages

Oracle implemented a set of methods that abstract the HTML tag language for the PL/SQL programmer. The programmer must learn how to use these packaged methods to create output in the form of HTML pages, and a basic understanding of HTML is necessary. The Hypertext Procedures (HTP) and Hypertext Functions (HTF) packages are useful for creating dynamic Web pages with 100 percent of the source code developed using PL/SQL. The idea is that PL/SQL is already good at processing information and interacting with the RDBMS. Now, PL/SQL can use this database-originated information and easily create a dynamic Web page.

Previous Table of Contents Next