Separating the Web server

 

When compared to a configuration where the appserver and the HTTP server are collocated on a single physical server, separation of the application server and the HTTP server can be utilized to provide varying degrees of improvement in:

1. Performance
2. Process isolation
3. Security

This configuration is illustrated in Figure 3-5.

Figure 3-5 HTTP server separated from appserver

The WebSphere V5.1 Web server plug-in allows the HTTP server to be physically separated from the appserver. It uses an XML configuration file (plugin-cfg.xml) containing settings that describe how to handle and pass on requests, via a new connection, to the WAS(s).

J2EE specifies that static Web content be packaged in the .war (Web archive) file, which means that it needs to be read and served by the WebSphere file serving servlet. This approach can be inefficient and is not recommended for a production environment.

In some cases you might want to "explode" the .war and install some of the static content on the Web server itself. In doing so, remember that you cannot secure this content with WebSphere security and you will have to adjust the plug-in configuration manually.

In WAS V5.1 serving files can be enabled/disabled during the creation of a Web module either through the File Server Enabled check box in the IBM extensions pane of the Application Server Toolkit (ASTK), or by changing the fileServingEnabled flag in the ibm-web-ext.xmi file, located in the WEB-INF directory of the installed module.

Please note the ASTK is the WAS V5.1 replacement for the Application Assembly Tool (AAT) that shipped with prior versions of WebSphere. In WAS V5.1 the ASTK ships as a separate install image in addition to the appserver.

Some reasons to separate the HTTP server from the appserver are:

1. Performance: size and configure servers appropriate to each task

   By installing components (Web server and appserver) on separate machines, each machine can be sized and configured to optimize the performance of each component (for example, an application server might require faster and more powerful machines than the Web server system).

2. Performance: remove resource contention

   By installing the Web server on a separate machine from the WAS, a high load of static requests will not affect the resources (CPU, memory, disk) available to WebSphere, and therefore will not affect its ability to service dynamic requests. The same applies when the Web server serves dynamic content using other technologies, such as CGI, ASP, and so on.

3. Maintainability: component independence

   Server components can be reconfigured, or even replaced, without affecting the installation of other components on separate machines.

4. Security: separate Web server and WebSphere interfaces

   In order to protect appservers from unauthorized outside access, the separation of the Web server from the application server is often used with firewalls to create a secure demilitarized zone (DMZ) surrounding the Web server. Isolating the HTTP server on a DMZ protects application logic and data by restricting the access from the public Web site to the servers and databases where this valuable information is stored. Desirable topologies should not have databases, nor servers that directly access databases, in the DMZ. WAS stores the configuration data as XML files. Furthermore, an application installed on WebSphere usually needs to access a database. Therefore, it is often not an acceptable solution to run WAS in the DMZ.

Consider the following when you separate the HTTP server from the appserver:

1. Maintainability: configuration complexity

   The configuration file (plugin-cfg.xml) is generated on the WAS machine and must then be copied to the Web server machine.

2. Performance: network access may limit performance

   Depending upon the network capacity and remoteness of the Web server, the network response time for communication between WAS and the Web server may limit the application response time. To prevent this insure that you have adequate network bandwidth between the Web server and the appserver. When collocated on the same server, network response is usually not an issue, but other resource constraints such as memory and CPU can limit performance.

3. Security: encrypted transport

   The HTTP plug-in also allows encryption of the link between the Web server and the appserver, using HTTP over SSL (HTTPS) data encryption. This reduces the risk that attackers would be able to obtain secure information by "sniffing" packets sent between the Web server and application server. A performance penalty usually accompanies such encryption. The HTTP plug-in is suitable for environments that require all network communication to be encrypted, even in a DMZ.

   It is recommended that this connection can be configured so that the HTTPS plug-in and Web container must mutually authenticate each other using public-key infrastructure (PKI). This prevents unauthorized access to the Web container.

4. Security: access to protected resources

   The plug-in is also compatible with the WAS V5.1 security model, allowing access to protected applications and their resources while enforcing authorization and authentication policies.

5. Security: allows the use of NAT

   Some firewall environments use Network Address Translation (NAT). NAT receives packets for one IP address and translates the headers of the packet so it can be sent to a second IP address. In this case, we should avoid using configurations involving complex protocols in which IP addresses are embedded in the body of the IP packet, such as Java Remote Method Invocation (RMI) or Internet Inter-ORB Protocol (IIOP). Most firewalls cannot translate packets for these protocols, as a result the IP addresses are not translated, making the packet useless. Using HTTP as the transport between the plug-in and the appserver avoids these problems associated with NAT and complex protocols.

6. Security: number of opened ports

   Using HTTP requests to send data between the plug-in and the appserver through the firewall requires opening only one port. Configurations that require switching to another protocol (such as IIOP), and opening firewall ports corresponding to the protocol, are less desirable. They are often more complex to set up, and the protocol switching overhead can impact performance.

The reverse proxy approach for separating the HTTP server and the appserver is generally not suggested for use with WebSphere V5.0 and higher. The HTTP plug-in behaves much like a reverse HTTP proxy, without its disadvantages.

Reverse proxy disadvantages include:

• Extra hardware and software required
• Not WebSphere workload management aware

However, the use of a reverse proxy has benefits if placed before the HTTP server. See 3.3.4, "Topology 3: reverse proxy" in the redbook IBM WebSphere Version 5.0 System Management and Configuration, SG24-6195 for more information.

  Prev | Home | Next

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.