The Oracle WebLogic Server Proxy Plug-In (mod_wl_ohs) enables requests to be proxied from Oracle HTTP Server to Oracle WebLogic Server. This plug-in enhances an Oracle HTTP server installation by allowing Oracle WebLogic Server to handle requests that require dynamic functionality. In other words, you typically use a plug-in where the HTTP server serves static pages such as HTML pages, while Oracle WebLogic Server serves the J2EE dynamic pages such as Servlets, Jakarta Server Pages (JSPs), and Jakarta Enterprise Beans (EJBs).

See Configuring the Plug-In for Oracle HTTP Server.

CGI programs are commonly used to program Web applications. Oracle HTTP Server enhances the programs by providing a mechanism to keep them active beyond the request lifecycle by using the mod_proxy_fcgi module.

The mod_proxy_fcgi module is the Oracle replacement for the deprecated mod_fastcgi module. The mod_proxy_fcgi module requires the service of the mod_proxy module and provides support for the FastCGI protocol.

For information on configuring the mod_proxy_fcgi module, see About Configuring mod_proxy_fcgi. For information on migrating from the mod_fastcgi module to mod_proxy_fcgi, see Configuring mod_proxy_fcgi and mod_authnz_fcgi Modules.

Oracle HTTP Server employs many security features. Key among them are:

• Oracle Secure Sockets Layer (mod_ossl)
  
• Security: Encryption with Secure Sockets Layer
  
• Security: Single Sign-On with WebGate
  

Active websites usually update their web pages and directory contents often, and possibly their URLs as well. Oracle HTTP Server makes it easy to accommodate the changes by including an engine that supports URL rewriting so end users do not have to change their bookmarks.

Oracle HTTP Server also supports reverse proxy capabilities, making it easier to make content served by different servers to appear from one single server.

A WebLogic Server Domain in Full-JRF mode contains a WebLogic Administration Server, zero or more WebLogic Managed Servers, and zero or more System Component Instances (for example, an Oracle HTTP Server instance). This type of domain provides management capabilities through the Fusion Middleware Control and WebLogic Management Framework present throughout the system. A WebLogic Server Domain can span multiple physical machines, and it is centrally managed by the administration server. A WebLogic Server Domain provide integrated management across System Components and Jakarta EE components running in the domain.

WebLogic Server Domains support all WebLogic Management Framework tools.

• For more information about installing a WebLogic Server Domain, see Installing and Configuring the Oracle Fusion Middleware Infrastructure.

• For information about installing Oracle HTTP Server either as part of a Oracle Fusion Middleware infrastructure or as standalone component, see Installing and Configuring Oracle HTTP Server.

The Weblogic Server Domain in Restricted-JRF mode is similar in architecture and functionality to Weblogic Server Domain in Full mode, except it does not define a connection to an external database. There are no database dependencies in Restricted-JRF mode.

This lack of a backing database means that cross component wiring is not supported by Oracle HTTP Server in a Restricted-JRF domain; this is the major differentiating factor between a Full JRF- and a Restricted-JRF-based domain.

Like the Full -JRF domain, the management of keys and certificates of an Oracle HTTP Server instance in a Restricted-JRF domain continues to be keystore service (KSS). In a Restricted-JRF domain, the database persistency of KSS is replaced with file persistency, although to an end user there is no visible change in basic KSS APIs to manage keys and certificates.

Like the Full -JRF domain, Oracle HTTP Server in a Restricted-JRF domain supports multiple Oracle wallets for complex virtual server configurations.

A standalone domain is a container for system components, such as Oracle HTTP Server. It has a directory structure similar to an Oracle WebLogic Server Domain, but it does not contain an Administration Server or Managed Servers.

For standalone domains, the WebLogic Management Framework supports the following tools:

• Node Manager

• The WebLogic Scripting Tool (WLST) commands, including:

  • nmStart(), nmKill(), and nmSoftRestart() that start, stop, and restart Oracle HTTP Server instance using Node Manager.

  • nmConnect() to connect to Node Manager.

  • nmLog() to get the Node Manager log information.

  For a complete list of supported WLST Node Manager commands, see Node Manager Commands in WLST Command Reference for WebLogic Server.

  Note:

  If you have a remote Oracle HTTP Server in a managed mode and another in standalone with the remote administration mode enabled, you can use WLST to perform management tasks such as SSL configuration.

• Configuration Wizard

• Pack or Unpack

Generally, you would use a standalone domain when you do not want your Oracle HTTP Server implementation installed with a WebLogic Server domain and do not need the management functionality provided by Oracle Fusion Middleware Control. You would use it when you want to keep Oracle HTTP Server in a "demilitarized zone" (DMZ, that is, the zone between the internal and external firewalls) and you do not want to open management ports used by Node Manager. See Enterprise Deployment Guide for Oracle SOA Suite for an example configuration where Oracle recommends configuring Oracle HTTP Server in standalone domains.

Two configuration directories are associated with each Oracle HTTP Server instance: a staging directory and a run-time directory.

• Staging directory

  DOMAIN_HOME/config/fmwconfig/components/OHS/componentName

• Run-time directory

  DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName

Each of the configuration directories contain the complete Oracle HTTP Server configuration -- httpd.conf, ssl.conf, admin.conf, auditconfig.xml, and so on.

Modifications to the configuration are made in the staging directory. These modifications are automatically propagated to the run-time directory during the following operations:

• Oracle HTTP Server instances which are part of a WebLogic Server Domain

  Modifications are replicated to the run-time directory on the node with the managed Oracle HTTP Server instance after changes are activated from within Fusion Middleware Control, or when the administration server initializes and prior changes need to be replicated. If communication with Node Manager is broken at the time of the action, replication will occur at a later time when communication has been restored.

• Standalone Oracle HTTP Server instances

  Modifications are synchronized with the run-time directory when a start, restart, or stop action is initiated. Some changes might be written to the run-time directory during domain update, but the changes will be finalized during synchronization.

Any modifications to the configuration within the run-time directory may be lost during replication or synchronization.

The default Oracle HTTP Server configuration contains the files described in Configuration Files.

Additional files can be added to the configuration and included in the top-level .conf file httpd.conf using the Include directive. For information on how to use this directive, see the Include directive documentation, at:

http://httpd.apache.org/docs/2.4/mod/core.html#include

The default configuration provides an Include directive which includes all .conf files in the moduleconf/ directory within the configuration.

An Include directive should be added to an existing .conf file, usually httpd.conf, for .conf files which are not stored in the moduleconf/ directory. This may be required if the new .conf file must be included at a different configuration scope, such as within an existing virtual host definition.

For instances that are part of a WebLogic Server Domain, Fusion Middleware Control and the management infrastructure manages the Oracle HTTP Server configuration. Direct editing of the configuration in the staging directory is subject to being overwritten after subsequent management operations, including modifying the configuration in Fusion Middleware Control. For such instances, direct editing should only be performed when the administration server is stopped. When the administration server is subsequently started (with start or restart), the results of any manual edits will be replicated to the run-time directory on the node of the managed instance. See About Editing Configuration Files.