Engine User's Guide
Release 3 (8.1.7)
This chapter contains instructions on how to configure and use OSE, a servlet server, with Apache, an HTTP Web server. You will see how this arrangement delegates the dynamic content through
mod_ose to the OSE running in Oracle8i.
The topics we cover are the following:
mod_ose requires the following Apache capabilities:
mod_somust be installed in Apache (or other support for Dynamic Shared Objects)
mod_mimemust be installed in Apache
mod_ose is a module in the Oracle HTTP server (Apache), which serves as a conduit from Apache to OSE. In conjunction with
mod_ose, OSE is the servlet engine for Apache, where only static pages are served by Apache and the dynamic pages are served by OSE.
You can create multi-node, in-tandem configurations. With these types of configurations, you can make a more scalable service than you can with simple stand-alone OSE or Apache components.
Specifically, with a multi-node arrangement there is:
mod_ose works in a network in conjunction with Net8. The Oracle8 Net8 Administrator's Guide describes, in detail load balancing, using Oracle Listener, and the fail-over configuration.
Before determining how many and which type of server your network requires, you must understand the basic configuration of the two servers, Web and servlet. Figure 5-1 depicts a simple representation of the base network arrangement, in this order: browser, Apache,
mod_ose inside Apache, Net8 (represented by the connection between
mod_ose and the database), the database, and OSE.
This section introduces
mod_ose configuration steps needed to use Apache as the HTTP server and OSE as the servlet server.
The following steps define the database connection descriptors for use with
mod_ose and set the Apache configuration so that the requests are sent to the appropriate database.
tnsnames.oraas a pointer to the OSE service (see Example 5-1).
exportwebdomain(see Example 5-2).
httpd.conf(see Example 5-3).
mod_ose uses the same configuration mechanism for finding connection descriptors that other Oracle clients, such as OCI clients, do.
Depending on the
sqlnet.ora configuration, connections are defined by either:
Entries for the connection used by Apache must be in
tnsnames.ora and be defined by the following lines:
listenerAddress (CONNECT_DATA= serviceSpec presentationSpec ) ) where the syntax is defined as, listenerAddress := (PORT=...)(ADDRESS=(HOST=...)(PROTOCOL=...)...) serviceSpec := (SERVICE_NAME=...) [ (INSTANCE_NAME=...) ] presentationSpec := (PRESENTATION=http://<JndiServiceName
An ADDRESS_LIST (host, port, protocol) in the case of multiple Oracle Listeners on the back end (multiple nodes). This allows for load balancing and fail-over configurations, as well as the use of CMAN for connection concentration.
Read the Oracle8 Net8 Administrator's Guide for details on how to set this parameters.
group of database instances: specify SERVICE_NAME
single database instance: specify INSTANCE_NAME
<JndiServiceName> is a place holder for the name of a service in the JNDI namespace (for example,
Connection(s) are named in the
tnsnames.ora file, as shown in the following example.
inst1_http = (DESCRIPTION= (ADDRESS=(PORT=5521)(host=dlsun1609)(PROTOCOL=tcp)) (CONNECT_DATA= (SERVICE_NAME=<WebServerName>) (PRESENTATION=http://admin) ) )
OSE was design for stateful Web applications. For these types of applications, each browser client is assigned a database session that keeps track of all stateful applications the user is executing in the domain. By default, all applications are considered stateful.
You can configure Apache to use a stateless connection to OSE. There are certain applications for which a database session does not keep state information, with respect to the client. For these requests, each Apache process has a semi-persistent connection to a session used to process stateless connections to any client. Because each Apache worker handles only one request at a time, the stateless connection is used sequentially by different incoming clients. Stateless servlet contexts and stateless servlets must be indicated as such when published to the JNDI namespace.
ServletContext entry and
Servlet (see Oracle Java Tools Reference for each entry) in the session shell tool have a -stateless option that you can use to declare which application contexts or particular servlets are stateless. This information, used in conjunction with the
Export command, simplifies management of the configuration.
Several Oracle APPS use the stateless model. It is advantageous in such cases to declare them as stateless when installed in OSE.
We specify whether a request uses the stateful or the stateless connection by specifying the particular variant of the handler to use:
A unique place specifying the configuration of Web applications running on OSE is the JNDI name space in JServer. A tool, exportwebdomain, extracts the information about the applications installed in a Web domain and generates the corresponding
Apache.conf file. Include this file in the Apache main configuration file (see Example 5-2, "Export the Web Domain Structure to an Apache CFG File").
webdomainin a configuration file for mod_ose. The export utility works in two stages:
contextswithin a domain.
mod_ose. Generate a configuration file at the shell level.
The command connects to the server and generates the
webdomain information in the format required by Apache and saves it into <file.conf>.
The parameters are defined as:
> - The JNDI location of the Web domain to export (defaulted to service root for the single-domain).
> - The name of the file to store the generated configuration, in this case,
The options are defined as:
format type: produces output in a defined format. Use the text string Apache or
apache to generate the configuration file for
export command, in the Oracle Java Tools Reference, for details of all the options available. In particular, you can select to export particular contexts, or for whether doc_root (static pages) should be requested to OSE or will be served locally.
The output file
webdomains.cfg holds the Web domain configuration.
mod_ose, you can configure different network topologies with the system in your Web environment. Specifically, you can define configurations that do not have a single point of failure. In such configurations, when a node failure occurs, any available Oracle Listener can redirect requests to some other database instance if the one being used for the client state has failed. For this to work, the application must have been replicated in all nodes, and it must be able to handle the recovery from an expired database session.
If Apache is already installed on your system, you must set the configure as required by OSE. If Apache is installed by Oracle with the OSE, the installation is complete.
bin directory of your Apache installation, execute the command:
This command copies the module to your Apache installation and makes it available by adding the corresponding
LoadModule directive to
httpd.config. The next time Apache is restarted, the new module will be available.
The Apache configuration is divided in two parts:
In this step, we configure which connection to use when communicating with OSE in the database. You can configure the OSE service in Apache only at the virtual host level. Paths in a virtual host can be routed to only one OSE server.
AuroraService, to specify which connection description should be used to contact OSE. The syntax is:
If the virtual host does not define its own
AuroraService configuration, then the default Host configuration will be used.
defined as part of
mod_mime, specify which requests are sent
to Aurora. (See "Requirements for OSE with Apache"
This sends stateful requests for a file with a .
jsp or .
snoop extension to OSE.
This command must be used in conjunction with the Location directive, parsing the components of the virtual path served by OSE:
The virtual path of the request used in Apache are forwarded as is to the OSE. The OSE generates the passed segment of the Apache configuration string from the JNDI namespace information.
When an HTTP request comes through Apache to
mod_ose, the initial path information,
> is discarded. The remaining path is sent to OSE. After the servlet is executed, the result is returned to the client. In general, the request path initiates Apache routing a request through
mod_ose to the servlet server.
If 3000 is the port on which Apache is listening and the following directive is included in the
The client asks for
mod_ose forwards the request as,
/MyContexts/Counter, to OSE. If
/Counter is found as a published servlet in the
/MyContexts servlet context directory, then OSE sends a response. If not found, the default servlet returns Error 404 (Not Found) by default. You can change this behavior with the servlet management tools.
The same logic applies when processing static files.
If the client asks for,
/MyContexts/index.html file must exist under the root directory, as specified in the URL., showing how you can send a path and a file name and the entire path is read.
Example 5-8 highlights a specific request operation detail for those who use