Oracle HTTP Server Administrator's Guide 10g (9.0.4) Part Number B10381-01 |
|
This appendix explains how the Oracle Application Server Containers for J2EE (OC4J) plug-in enables you to use third party HTTP listeners to access servlets running in OC4J J2EE within Oracle Application Server. OC4J Plug-in works with Sun ONE Web Server Enterprise Edition, version 4.1 and 6.0, and Microsoft Internet Information Server (IIS), version 4.0 or 5.0.
It also contains information about using mod_oc4j
in a non-Oracle Apache.
Topics discussed are:
OC4J Plug-in provides functionality for third party HTTP listeners similar to that provided by mod_oc4j for Oracle HTTP Server. In Releases 2 (9.0.2) and 2 (9.0.3), Oracle Application Server Proxy Plug-in provided third party listener support. However, the proxy plug-in provides reverse proxy functionality where requests must pass through both the third party listener and Oracle HTTP Server before reaching OC4J. For efficiency or administrative reasons, you may choose to not run Oracle HTTP Server in addition to the third party listener.
OC4J Plug-in is a shared library that can be loaded into IIS, or Sun ONE HTTP listener. It provides functionality to route requests directly from a third party listener to OC4J in the same manner mod_oc4j
routes requests from Oracle HTTP Server to OC4J. Thus, requests for OC4J can be directly routed from IIS or Sun ONE to one or more OC4J JVMs using the AJP or AJP over SSL protocol.
Figure C-1 illustrates how the OC4J Plug-in routes requests directly from a third party listener to OC4J.
The plug-in is distributed on the OracleAS Repository Creation Assistant/Utilities CD, which is included in your Oracle Application Server CD Pack.
The plug-in consists of a single shared library for either IIS or Sun ONE. The file is called opii.dll
for IIS, and opii.so
for Sun ONE.
Place the opii.so
file in a directory such as /sunone/opii.so
, where it is readable by the Sun ONE listener. The following examples assume that Sun ONE is installed in a directory called /sunone
, and that the instance being configured exists under /sunone/
https-mymachine
.
/sunone/
https-mymachine
/magnus.conf
:
Init fn="opii_init" log_file="/sunone/https-mymachine/logs/opii.log" log_level=error server_defs="/sunone/https-machine/config/opii.conf" Init fn="opii_child_init" LateInit=yes
where, log_file
points to a file where OC4J Plug-in messages will be logged and server_defs
points to an OC4J Plug-in configuration file.
/sunone/
https-mymachine
/obj.conf
:
/oc4j-service
in mod_oc4j
for Oracle HTTP Server, then make the following two changes to obj.conf
:
Perform the following steps to configure OC4J Plug-in for IIS:
HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\OPII
server_defs,
and a value pointing to the location of your configuration file, for example d:\opii\opii.conf
.
log_file
and log_level
:
log_file
, and the desired location of the log file, for example, d:\opii\plugin.log
.
log_level
, and a value for the desired log level. Valid values are debug
, inform
, error
, and emerg
.
mod_oc4j
/oc4j-service
URL, add a string value with the name status_uri
and a value like /oc4j-service
.
opii.dll
. Name the directory opii
and give it execute access.
opii.dll
as a filter in your IIS Web site. The name of the filter should be opii
and its executable must point to the directory contain opii.dll
, for example, d:\opii\opii.dll
.
In Oracle Application Server, 10g (9.0.4), you can integrate generic Apache with Oracle Application Server. In doing so, you can route requests from generic Apache to OC4J in the same manner as routing requests using Oracle HTTP Server and mod_oc4j
.
Using Oracle Notification Service (ONS), the communication method utilized between mod_oc4j
and OC4J, you can load mod_oc4j
into a generic Apache instance and use it in a static routing configuration without requiring any other Oracle infrastructure. In combination with mod_onsint
and ONS, mod_oc4j
can utilize the same dynamic configuration and failover options that are available when using Oracle HTTP Server.
This section discusses the following topics:
mod_oc4j
and mod_onsint
require the following open source software packages to be included in generic Apache builds that will be integrated with Oracle Application Server:
mod_ssl
. EAPI provides a context mechanism that is used extensively by mod_onsint
and mod_oc4j
to share information and function callbacks between modules without introducing link time dependencies. EAPI is provided by configuring Apache with mod_ssl
.
Note:
mod_ssl
does not need to be loaded at runtime as it is the integration of EAPI provided by mod_ssl
that is important.
mod_oc4j is supported in Apache versions 1.3.x only. It is not supported in Apache 2.0.x versions.
Note:
Four libraries need to be accessible by the generic Apache instance that is going to be integrated with Oracle Application Server. If mod_oc4j
is used in a static configuration and mod_onsint
is not used, then you need only two libraries.
On UNIX, the four files and their locations within an ORACLE_HOME
are:
$ORACLE_HOME
/Apache/Apache/libexec/mod_oc4j.so $ORACLE_HOME
/Apache/Apache/libexec/mod_onsint.so $ORACLE_HOME
/opmn/lib/libons.so $ORACLE_HOME
/lib/libdms2.so
On Windows, the four files and their locations within an ORACLE_HOME
are:
%ORACLE_HOME
%\Apache\Apache\modules\ApacheModuleOc4j.dll %ORACLE_HOME
%\Apache\Apache\modules\ApacheModuleOnsint.dll %ORACLE_HOME
%\opmn\bin\onsclient.dll %ORACLE_HOME
%\bin\yod.dll
It is easiest if the binaries for the two modules are copied into the same location as the other modules in the generic Apache installation (libexec
on UNIX, and modules
on Windows), although this is not a requirement. Full paths can be used if you want to place the binaries elsewhere. The dms
and ons
libraries do not need to be in any specific location, but they must be in the your LD_LIBRARY_PATH
on UNIX, and the PATH
on Windows. On UNIX, this is most easily accomplished by editing the apachectl
script used to start the generic Apache instance to set the LD_LIBRARY_PATH
appropriately. On Windows, this is most easily accomplished by placing the appropriate directory into the System environment variable PATH
. However, if more than one generic Apache instance is running on the same machine, then some other mechanism might be needed.
A simple configuration can be constructed using generic Apache and only mod_oc4j
. This configuration is very similar to the functionality provided by mod_jserv
.
In this configuration, the host and port of all OC4J instances must be statically configured. There is no automatic registration of new JVMs, nor are failed JVMs ever removed from the routing table used by mod_oc4j
. The advantage of this configuration is its simplicity, including the fact that it does not require the availability of other Oracle Application Server infrastructure components, such as ONS. Following is an example of such a configuration. This configuration loads mod_oc4j
and provides routing of all requests starting with /j2ee/
to two different JVMs, both located on the same machine, one at port 3001, and the other at port 3002:
LoadModule oc4j_module libexec/mod_oc4j.so Oc4jMount /j2ee/* ajp13://localhost:3001,ajp13://localhost:3002
On Windows, change the line used to load mod_oc4j
to the following:
LoadModule oc4j_module modules/ApacheOc4jModule.dll
On UNIX, this implies that the mod_oc4j.so
file will be copied into the libexec
directory within the Apache installation. On Windows, it means that the ApacheOc4jModule.dll
file will be copied to the modules directory within the Apache installation.
In order to provide full mod_oc4j
functionality including dynamic detection of new JVMs and Oracle Application Server installations, mod_oc4j
must be combined with mod_onsint
.
In order to utilize mod_onsint
and mod_oc4j
, ORACLE_HOME
must be set to point to an Oracle Application Server instance where OPMN is running. On UNIX, this can be accomplished by adding the setting of ORACLE_HOME
to the apachectl
script used to start the generic Apache instance. On Windows, this is most easily accomplished by setting ORACLE_HOME
as a System environment variable.
The following configuration shows how to load the modules and mount /j2ee
to the OC4J instance, myinstance,
running within the Oracle Application Server cluster, mycluster
.
LoadModule oc4j_module libexec/mod_oc4j.so LoadModule onsint_module libexec/mod_onsint.so Oc4jMount /j2ee/* cluster://mycluster:myinstance
Any allowable Oc4jMount
syntax available from within Oracle HTTP Server is available when used with generic Apache. This configuration supports all of the same routing and availability features that mod_oc4j
offers when running within Oracle HTTP Server, including dynamic discovery of new OC4J processes and instances as they are added and failover of both stateless and session based requests.
Oracle Process Manager and Notification Server (OPMN) can be configured to provide process management, such as starting, stopping, and restart capability for a generic Apache installation. To do this, the Apache instance must have mod_onsint
configured. It should have the standard Apache directory layout, that is, the directory structure created by doing a standard Apache 1.3 installation. To configure OPMN to manage this Apache instance, the following changes must be made to opmn.xml
:
In the module section add the GENERIC_APACHE
module-id to the configuration for libopmnohs
, such as:
<module path="$ORACLE_HOME/opmn/lib/libopmnohs"> <module-id id="OHS"/> <module-id id="GENERIC_APACHE"/> </module>
In the HTTP_Server
section, you must set the module to GENERIC_APACHE
and set an apache-home
, such as:
</ias-component> <ias-component id="HTTP_Server"> <process-type id="HTTP_Server" module-id="GENERIC_APACHE"> <module-data> <category id="start-parameters"> <data id="apache-home" value="/private/my/path/to/APACHE"/> </category> </module-data> <process-set id="HTTP_Server" numprocs="1"/> </process-type> </ias-component>
You can configure either an Oracle HTTP Server instance or a generic Apache instance into any opmn.xml
. Configuring both in the same opmn.xml
is currently not supported.
When you set up the OC4J Plug-in in the third party listener, the configuration file points at a server_defs
file, or the OC4J Plug-in configuration file. This file defines the OC4J instances that the OC4J Plug-in communicates with. It has the same syntax as the mod_oc4j
file for Oracle HTTP Server. For example, a configuration file that contains only the following line
Oc4jMount /j2ee/* ajp13://localhost:3000
routes any requests to URLs that begin with/j2ee/
to the OC4J instance that has an AJP listener on the localhost interface on port 3000.
All of the Oc4j*
directives defined for mod_oc4j
also work for OC4J Plug-in. In additional to these directives, the OC4J Plug-in-specific directives Oc4jOracleHome
can be used in place of setting the ORACLE_HOME
directive in the environment for the third party listener. An ORACLE_HOME
value is required if you want to use the dynamic functionality of the OC4J Plug-in.
The dynamic routing functionality of the OC4J Plug-in provides the same Oc4jMount
syntax as mod_oc4j
for routing to OC4J instances that are managed by OPMN. Accordingly, you can mount OC4J instances or clusters instead of just pointing at the host and port of a single JVM. In order to accomplish this, the OC4J Plug-in must be able to communicate with an ONS daemon on the same machine. If Oracle Application Server is installed on the same machine as the OC4J Plug-in, then this can be accomplished simply by setting either ORACLE_HOME
in the environment, or setting the Oc4jOracleHome
directive to point to the location of the ORACLE_HOME
, and ensuring that the third party listener is running as the same user as Oracle Application Server, or root
on UNIX.
If Oracle Application Server is not installed on the same machine, then the standalone ONS daemon must be installed. OC4J Plug-in supports all the mod_oc4j
functionality, including AJP over SSL and use of port tunneling.
|
![]() Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|