In one of my previous posts, I mentioned multiple Oracle HTTP server deployment options. Let me do a small "show & tell" to explain how I pick the configuration.

Before we start to discuss deployment options, let's refresh what is Oracle HTTP Server 12c is. Oracle offers a precompiled version of the Apache HTTPD Server with a few proprietary modules, such as Oracle Security Layer (mod_ossl)   and prepackaged products as Oracle WebGates 12c. To line up Oracle HTTP with the other Oracle Fusion Middleware infrastructure, standalone Oracle HTTP Server comes with a limited edition of Oracle WebLogic Server and WLST libraries. Each Oracle HTTP Server Installation could be used for one or more WebLogic Domains. While limited domains can't run managed or admin server instances, they facilitate one or more HTTP Server instances, controlled by domain Node Manager. This complicated structure gives you multiple options to fit your web tier design. The diagram below illustrates Oracle HTTP Server Installations, WebLogic domains, and OHS instances.

One single Oracle HTTP server Installation could be used to configure one or more WebLogic domains. Each domain could manage one or more HTTP server instances.
Oracle HTTP Server Components relations

It's about time to talk deployments and configurations, and virtual hosts would be first in line.

One OHS instance with multiple virtual hosts. This is the most natural approach for classic HTTP 2.4 or NGINX system architects. But Oracle HTTP Server has a severe limitation: it does not support secured name-based virtual hosts. It means that if you have secured virtual hosts, you should consider IP- or port-based virtual hosts instead. That's not an issue for big enterprises; users never interact with web servers but load balancers. With that in mind, it's a lean installation for the applications that share the same security configuration and access settings. For example - use Oracle Access Manager (OAM) as a Single Sign-On.

One WebLogic domain, multiple OHS instances. When a virtual host can't meet your application requirements, the separate HTTP Server instance is an excellent option to separate such resources. The most common case in Oracle Fusion Middleware - OAM and WebGates protects only a subset of your applications. Each HTTP instance manages one or more virtual hosts but enforced security configuration does not impact the public instance.  You still have only one domain and node manager, with a single set of binaries to maintain. I would recommend this configuration all the time unless you have some specific WebLogic domain requirements.

Multiple WebLogic domains, one or more OHS instances. There is nothing wrong with numerous WebLogic domains on the same machine. However, it takes a toll; you need extra space on disk devices. It will produce an additional set of logs in the different locations, implying an additional Node Manager to control the domain. On top of my head, there are only a few options when you should create a separate domain:

  • You need to create an OHS instance for the different OS users or groups on the same VM
  • You have specific application requirements for Oracle FMW installation patches that impact the other applications. This situation requires not only a separate WebLogic domain but separate product installation.  
  • You have mixed standalone and integrated installation requirements: Fully functional WebLogic domain with OHS instances and standalone OHS installation on the same VM.  

With all being said, we come to a twist in the plot. If you have no explicit limitations - consider the Apache HTTPD server instead.   There are multiple arguments to consider, but the only one requirement that could prevent you from that drastic change.

Open source software. No license costs, no limitations. Wide community adoption. The #2 HTTP server in the World OSS support could be tricky. Enterprises prefer to pay vendors to have a predictable response and assistance.
The Apache HTTPD offers all the features from all developers. Wide range of modules and configuration options. Proprietary Oracle modules come only with Oracle HTTP Server. A variety of the 3rd party solutions may raise an eyebrow in security-centric environments.
No NZOS-related limitations. HTTPD supports all the latest and greatest security protocols and ciphers, as far as your OpenSSL installation allows. No support for Oracle security implementation, Oracle wallets, and other security-related features.
If standard ReverseProxy configuration gives you a hard time, Oracle offers mod_wl_24 for Apache HTTPD server to enable native communications with WebLogic backend. WebLogic Proxy plug-in works way better as a part of Oracle HTTP Server.
-- Your application requires OAM or Oracle Cloud Identity Service Single Sign-On configuration.