Oracle HTTP Server (OHS) is based on Apache infrastructure and includes Oracle modules that you can use to extend OHS core functionality.

Oracle HTTP Server (OHS) doesn't require a WebLogic domain but you usually use it with one. Oracle recommends associating OHS with a domain so that you can incorporate OHS into the Administration Console, where you can manage and monitor it.

The mod_wl_ohs module handles the link to Managed Servers. You configure mod_wl_ohs by routing requests of a particular type, such as JSPs, or by routing requests destined to a URL to specific Managed Servers.

OHS usually front ends a cluster. In this configuration, a special mod_wl_ohs directive, WebLogicCluster, specifies a comma-separated list of cluster members.

These steps describe the mod_wl_ohs directive process:

1. mod_wl_ohs receives a request for a Managed Server then sends the request to one cluster member in the directive. At least one Managed Server must be available to fulfill the request.

2. The Managed Server receives the request, processes it, and sends a complete list of cluster members back to mod_wl_ohs.

3. When mod_wl_ohs receives the updated list, it dynamically adds previously unknown servers to the known servers list. By doing this, all future requests are load balanced across the cluster member list. The benefit is that new Managed Servers are added to a cluster without updating mod_wl_ohs or adding OHS.

   Note:

   The mod_wl_ohs directive DynamicServerList controls whether or not unknown servers are added to the known servers list. You must set DynamicServerList to ON to enable dynamic addition of servers.

After Oracle HTTP Server starts, it is ready to listen for and respond to HTTP(S) requests.

The request processing model is different on Microsoft Windows systems compared to UNIX systems:

• For Microsoft Windows, there is one parent process and one child process. The child process creates threads that handle client requests. The number of created threads is static and you can configure them for performance.

• For UNIX, there is one parent process that manages multiple child processes. Child processes handle requests. The parent process brings up more child processes as necessary, based on configuration.

Use Fusion Middleware Control or the WebLogic Scripting Tool (WLST) to start, stop, and restart Oracle HTTP Server.

Oracle HTTP Servers and Managed Servers reside on different hosts, behind a load balancer, in a high availability topology.

Figure 6-1 shows two Oracle HTTP Servers behind a load balancer.

The load balancer receives user requests and forwards them to connected Oracle HTTP Servers. The load balancer receives requests on standard HTTP/HTTPS ports (80/443). However, it then passes requests to Oracle HTTP Servers using completely different ports. Advantages of this setup are:

• Actual ports are hidden from users.

• Users don't have to add port numbers to the URL.

On UNIX-based systems, starting OHS with root privileges isn't mandatory. Only root can start a process that uses a port less than 1024. However, for processes that use a port number below 1024, you must use root privilege to start a process.

The load balancer routes requests to the functioning Oracle HTTP Server.

Figure 6-1 also shows how OHS distributes requests to Managed Servers. For high availability, each pair of components (OHS and Managed Servers) should reside on different host computers. Managed Servers belong to the same cluster; to load balance across a set of Managed Servers, they must belong to the same cluster.

Oracle HTTP Server (OHS) has two failure types: process failures and node failures. An individual operating system process may fail. A node failure can involve failure of the entire host computer that OHS runs on.

If you use the Configuration Wizard to configure Oracle HTTP Server (OHS) and OHS is part of a domain, update the mod_wl_ohs.conf file for each instance.

• Prerequisites to Configure a Highly Available OHS
  Complete the following prerequisites before configuring a highly available Oracle HTTP Server deployment:
• Installing and Validating Oracle HTTP Server on WEBHOST2
  
• Configuring and Validating an OHS High Availability Deployment
  To configure and validate the OHS high availability deployment, update mod_wl_ohs.conf and then use test URLs to validate OHS configuration.

NameVirtualHost *:7777
<VirtualHost *:7777>
 ServerName http://myapp.example.com:80
 RewriteEngine On
 RewriteOptions inherit
 UseCanonicalName On
</VirtualHost>

NameVirtualHost *:7777
<VirtualHost *:7777>
 ServerName https://myapp.example.com:443
 RewriteEngine On
 RewriteOptions inherit
 UseCanonicalName On
</VirtualHost>

LoadModule weblogic_module PRODUCT_HOME/modules/mod_wl_ohs.so
 
<IfModule mod_weblogic.c>
 WebLogicCluster apphost1.example.com:7050, apphost2.example.com:7050
 MatchExpression *.jsp
 </IfModule>
 
<Location /weblogic>
 SetHandler weblogic-handler
 WebLogicCluster apphost1.example.com:7050,apphost2.example.com:7050
 DefaultFileName index.jsp
</Location>

<Location /console>
 SetHandler weblogic-handler
 WebLogicCluster apphost1.example.com
 WebLogicPort 7003
</Location>

<Location /weblogic>
 SetHandler weblogic-handler
 WebLogicCluster apphost1.example.com:7050,apphost2.example.com:7050
 WLProxySSL On
 WLProxySSLPassThrough ON
 DefaultFileName index.jsp
</Location>

LoadModule lbmethod_byrequests_module
"${PRODUCT_HOME}/modules/mod_lbmethod_byrequests.so"

<VirtualHost myohs.com:8080>

   # Proxy : HTTP - HTTP
   <Proxy "balancer://ha">
      ProxySet lbmethod=byrequests
      BalancerMember http://OHS_Host1:Port
      BalancerMember http://OHS_Host1:Port
   </Proxy>

   # Proxy pass : HTTP - HTTP
   ProxyPass        "/ha"   "balancer://ha"
   ProxyPassReverse "/ha"   "balancer://ha"

</VirtualHost>