[Chapter 2] 2.3 Content Delivery Model

2.3 Content Delivery Model

In this section I'll explain how the OAS and WebDB servers apply the ideas introduced in the previous section to deliver content from the server to the client (e.g., URLs, virtual directories, ports, etc.).

Although the specific details vary, OAS and WebDB follow the same basic process model to deliver web content and rely on a virtual schema mapping called a Database Access Descriptor (DAD) to access the database. A DAD is similar to a virtual directory mapping; it creates a name, used within a URL, that links the request to a specific schema in the database.

Figure 2.1 illustrates the basic parts of the model.

Figure 2.1: Basic components of OAS and WebDB systems

A request begins when a user submits a URL or an HTML form to an OAS or WebDB server. A server component called the HTTP listener intercepts the request and extracts its path section. This step, called URL resolution, determines what type of resource the request is for and how it will be processed. If the URL's path section matches a virtual directory mapping, then the request is for a static resource and the HTTP listener returns the requested resource (if found) to the user's browser. If the path section matches a DAD stored in the server's configuration files, the request is for a dynamic resource and the HTTP listener forwards, or dispatches, the request to the PL/SQL gateway.

The PL/SQL gateway reparses the URL (or HTML form action attribute), extracting the DAD name and the name of the procedure to execute, which is found in the resource name section of the URL. The gateway also extracts any parameters that might have been passed as part of the request. If the request was made with a URL, the parameters are stored in the query string. If the request was made with a form, the parameters are stored in the form's named data entry fields.

The gateway uses the DAD configuration information to connect to the appropriate database schema, then executes the specified procedure, passing any parameters included in the call. The procedure, which executes directly inside the database, usually calls procedures in a set of packages called the PL/SQL toolkit. These calls create the page's contents by "printing" HTML tags into a temporary buffer. When the procedure completes, the gateway signals the HTTP listener to send the contents of the buffer -- now populated with the HTML output from the procedure -- back to the user's browser. The user's browser displays the page, just as it would any other static resource.

Let's look at this procedure in more detail, especially the functions of the HTTP listener and the PL/SQL gateway.

2.3.1 The HTTP Listener

The HTTP listener is what we normally think of as the web server. Its job is to receive the requests users make with their browsers, determine how to process them, then return the requested resources (along with their MIME types) to the client machines that made the request. Most of the listener's life is spent monitoring a TCP port for requests made from a web browser. Although OAS and WebDB use port 80 by default, they can be configured to use other ports.

TIP: Only one application at time can listen on a port. To run OAS and WebDB on the same machine, you must configure them to listen on different ports. For example, if OAS is listening on port 80, you could configure WebDB to listen on port 81.

The HTTP listener makes static resources available by mapping physical directories on the OAS or WebDB server to a virtual alias. These aliases are used in the URL to request a static resource that resides in the corresponding directory. The goal is to give clients a uniform way to locate a resource that is independent from the operating system of the OAS or WebDB server. For example, on an NT server, you can map the directory c:\files\public\web_stuff to a virtual directory called web. URLs that need to access resources in the directory must use the alias "web", rather than the actual directory name, to retrieve static resources.

You can configure OAS to make subdirectories beneath a mapped directory accessible from the Web; WebDB maps subdirectories by default. The subdirectory name, as defined on the server's operating system, is appended to the "root" alias of the URL. For example, if c:\files\public\web_stuff had two subdirectories named bob and sue, the virtual mapping to them would be /web/bob and /web/sue.[2]

[2] Since the Web originated mostly on Unix systems, URLs use the forward slash ("/") to denote directories, much to the chagrin of the DOS world, which uses the backslash ("\").

Since they include operating system specific names, subdirectory mappings are not completely platform independent. On Unix systems, for example, directory names are case sensitive, so the directories Junk and junk are not the same. Consequently, a URL that accesses a subdirectory on a Unix server must be case sensitive as well. Other platforms have similar caveats. The spaces in Win9x directory names cause all sorts of headaches, and the 3.x version has an eight-character limit. The best advice on any platform is to keep subdirectory names simple.

2.3.2 The PL/SQL Gateway

The PL/SQL gateway is to the database what the HTTP listener is to the filesystem:

Just as static resources are accessed with a URL, PL/SQL dynamic resources are accessed with a URL.
Just as physical directories are mapped to virtual directories, physical database schemas are mapped to virtual schemas. These virtual mappings are used in a URL to select the database schema in which a particular dynamic resource resides.
Just as static resources are identified by filenames, PL/SQL dynamic resources are identified by procedure names (packaged procedures are identified with both a package and a procedure name). These names are used in a URL to select the procedure to execute.

Both OAS and WebDB use the Database Access Descriptors to connect to a specific schema, which includes all the information necessary to establish a database connection, such as a username, password, and connect string. In either case, the DAD is mapped to a virtual alias that is used within a URL to select a schema.

OAS schema mappings have two parts: a DAD, which maps a schema, and agents, which map to a DAD. The agent name, not the DAD, appears in the URL to make the connection between the Web and the database. Both the URL and the ACTION attribute of a form that requests a dynamic resource have the following general format (optional sections are bracketed):

http://server[:port]/agent_name/plsql/[package.]procedure[?parm1=foo...]

Here are a few examples:

http://gandalf/agent_webtest/plsql/print_all_emps
http://gandalf/agent_webtest/plsql/show_emps?i_name=BOB
http://207.25.98.87:8181/secure_agent/plsql/show_users
http://betty/agent_webtest/plsql/forum.current_forum_list

WebDB has a slightly simpler mapping system that uses just the DAD in the URL; WebDB does not use agents. The URL's format is as follows (optional sections are bracketed):

http://server[:port]/dad_name/[package.]procedure[?parm1=foo...]

Here are some examples:

http://pcandrew.ora.com/WebDB/WEBDB.home
http://gandalf:8181/WebDB/show_emps?I_name=FRED+FLINTSTONE
http://www.travel.com/travelers_site/flights.show_list?country=FR


2.2 Server-to-Client Communication		2.4 Database Integration