Oracle Application Server Deployment

When deploying Java applications within Oracle Application Server, there are several configuration options available. Typically an application would include some static files, html, images, css as well as the Java code and view layer. Using common internet practices, the application server would be installed on the DMZ, and the database installed behind the firewall. With Oracle, the HTTP Server and OC4J (now BEA) may be bundled in the same Oracle Home on the application server.

I do not like this configuration because a connection is made directly to the database from the DMZ. It is very common for information to be included in either application logs or in configuration files that would be dangerous to expose, and the DMZ is not a secure zone. An application put into debug mode may log personal information about users and if the DMZ were infiltrated those files are at risk. Although most companies have rules about encrypting password and connections, and not logging private data, often they do not review the code to ensure those practices are followed.

With the addition of a multi-firewall zoning in the intranet, the application architecture can be made more secure by extracting the web server portion from the application server and putting it in the DMZ. The DMZ web server could simple reverse proxy all connections to the application server, or it could serve static content directly and proxy the application through to the application server. Database connections are established securely from within the intranet.

This is a better solution for both performance (if you are serving the static content from the web server) and for security. It has an additional benefit . it is very easy to put up a maintenance page on the web server if the application server is unavailable. Patching the application server means bringing down both the HTTP Server and OC4J (if they are installed in the same home) so you can not easily put up a maintenance page in the first environment. This seems like a minor benefit but in fact I have seen many organizations that have no maintenance provisions and simply bring down their applications during patching.

Finally, my favourite solution. Split the internal firewall into three zones, C, B, and A. Install the Apache server on the DMZ strictly as a reverse proxy and for maintenance pages. Zone C contains an OHS-only installation of the Oracle Application Server. This servers the static files associated with the application and provides the mod_ajp connection to an application server cluster in Zone B. Database access is allowed only from Zone B application servers and is isolated from the end user by three firewalls.

If SSL is required it can terminate at the DMZ or in Zone C. Because all components are non-colocated they can each be scaled or moved as necessary, with minimal changes to the overall architecture.

As a note, Solaris 10 containers work great for this scenario if you have a small application load, as you can split the resources across 3 zones and put each zone in a different firewall.