What is the proxy server and where did it come from?
You may not realize that there are actually two proxy servers included in the WebSphere Application Server Network Deployment package.
One was traditionally referred to as Web Traffic Express, which was previously shipped in packages like the WebSphere Performance Pack and WebSphere Edge Server as both a reverse HTTP proxy and forward HTTP proxy. Web Traffic Express has been included in WebSphere Application Server Network Deployment as a reverse proxy since Version 5.0.
The proxy server shipping with WebSphere Application Server Network Deployment as a reverse HTTP proxy beginning with the Version 6.0.2 release shares much more in common with the WebSphere Application Server platform. The proxy server builds on the Transport Channel Framework in much the same way that other WebSphere Application Server components, such as the Web container, SIP container, and JMS Server utilize the framework and components.
The proxy is also an advanced extendable architecture, which enables our WebSphere development team to add advanced function. The proxy is the foundation for the WebSphere Extended Deployment On Demand Router, which has been shipping since WebSphere Extended Deployment V5.1.
In addition to acting as a reverse HTTP proxy, the proxy server also acts as a stateless SIP proxy beginning with WebSphere Application Server Network Deployment V6.1. The stateless SIP proxy is required for the SIP container to be highly available. This is our strategic proxy server moving forward and will continue to be augmented with some exceptional features in upcoming releases.
So why am I explaining all this?
The proxy server is an important component in our WebSphere Application Server Network Deployment (hereafter referred to as Network Deployment) and WebSphere Extended Deployment products, and since a number of clients have recently shown an interest in the proxy server, I wanted to answer some of the most commonly asked questions I have been asked about this component. For instance...
What is the difference between a reverse and forward HTTP proxy?
When many people hear about the HTTP proxy server, they think of the forward proxy server that is configured in your browser for forwarding an HTTP request to connect to an external HTTP server. This activity is usually performed for network access authorization and authentication, content filtering, or to better utilize network bandwidth through caching. Many forward proxy servers can be configured transparently such that you never need to configure your browser to use the proxy. Forward proxies cannot see the content in SSL requests, and so they just forward the requests as a bunch of bytes without knowing much more than the proxy was told.
Unlike forward proxies, reverse proxy servers sit in front of a Web server or Web application server to handle the requests from clients and forward them on to the Web servers; while the forward proxy is typically deployed on the client side of the network, the reverse proxy is deployed on the server side. The browser client is pointed directly at the reverse proxy -- unaware that it is connected to the reverse proxy and not the Web server itself. Since it is the primary point of contact, the reverse proxy can perform such operations as SSL offload, which requires that the server be the hostname to which the client is expecting to connect.
What HTTP features are included with the Network Deployment proxy server?
The proxy server has far too many features to adequately cover here, but I will highlight two of what I consider its best features.
Dynamic routing and configuration. Since the proxy server is built on the High Availability Manager in WebSphere Application Server, it is able to dynamically tap into the configuration and availability information in the containers themselves. This is in contrast to the model available with the Web server plug-in, which takes its configuration statically through the plug-in configuration file. The proxy can discover new applications deployed and be able to route to them, and also has the ability to route to generic non-application server HTTP end points.
Caching built into the server. The proxy server can cache dynamic and static content in memory and on disk. This caching capability enables the proxy to substantially offload the backend server by caching static content (such as images) in applications, and caching some of the dynamic content (including anything that is enabled through the servlet) in the Web container.
Then, do I replace my Web server and plug-in with the proxy server?
This is a tough one. The answer is yes and no. The Version 6.0.2 and Version 6.1 proxy server has many of the functions that the Web server and plug-in provide, but it cannot be a full replacement. First, the proxy does not have Web serving capabilities; static content can be served from the proxy cache, but it is not pushed to the proxy itself. It also does not have the capabilities (like CGI) that a Web server has. Additionally, the proxy server is not considered demilitarized zone (DMZ) ready.
What are the implications of the proxy server not being DMZ ready?
Because the proxy server is not DMZ ready, the proxy server should stay in the intranet/secure zone only.
The proxy server lacks some features that prevent it from being ready for the DMZ; for example, the proxy server cannot bind to protected ports (ports below 1024) without being root on most operating systems and, at this point, has no way to switch users after binding.
Figures 1 and 2 show some network topology options with the proxy.
Figure 1. Proxy and Web server together in front of the application server
Figure 2. Proxy with an application level firewall and optional DataPower appliances
Does that mean you need a proxy server and a Web server?
Not necessarily. If the only purpose of the Web server was routing with session affinity and load balancing, then the proxy server can easily take the place of the Web server. If the Web server was used as a security measure in the DMZ, then the proxy cannot replace it -- but it can sit in the secure zone to help with the routing and load balancing. With stateful and application level firewalls, the Web server in the DMZ is not adding much in terms of security, unless it is being used for authentication, authorization, and auditing. If you have this type of firewall equipment, you may be able to bypass the Web server in the DMZ and just include the proxy in the secure zone.
What advantages does the proxy server have building on the WebSphere Application Server base?
The proxy server heavily utilizes some specific components in WebSphere Application Server. First, it utilizes the high availability infrastructure introduced in Network Deployment V6.0. This infrastructure gives the proxy indepth information about what is happening in the containers that the proxy is fronting. The proxy also utilizes the Transport Channel Framework, the highly scalable I/O framework in WebSphere Application Server. In Version 6.1, the Transport Channel Framework builds specific I/O management code per platform to handle thousands of connections and perform I/O operations very quickly.
The proxy server also builds on top of the WebSphere Application Server administration and management infrastructure, which enables the proxy to be configured as part of a WebSphere Application Server cell and administered through JMX, just as WebSphere Application Server is administered. Also, proxy configuration changes can be scripted in languages such as Jython, using the Jython tools in the Application Server Toolkit. Finally, building on WebSphere Application Server gives the proxy powerful monitoring capabilities, such as what is available with IBM Tivoli® Performance Viewer.
How can I use the proxy to isolate the threads for multiple HTTP applications in the same container?
While the transports and proxy can work together to isolate threads from Web applications, this is a very coarse-grained way of trying to manage resources between applications. Success may vary. WebSphere Extended Deployment's On Demand Router does this by utilizing CPU and memory load, as well as factors such as response time, to properly ensure that separation of resources and service levels are met. I highly recommend using it if you are trying to isolate application resource utilization within a physical set of servers or within a single application server. Even so, separating the thread pools per application is a great example of how the proxy abstract changes. Here is how you would accomplish this:
Start by setting up the proxy in WebSphere Application Server. As of Version 6.0.2, resources in the Web container can be isolated in a couple of ways that might be valuable. One such option is to put each virtual host on the Web container on a different endpoint listener, which is a unique hostname and port combination. To do that in the administrative console, you first need to create an endpoint for each virtual host:
- In the console, navigate to Servers => Application Servers, then right-click on the server name, and select Web Container Settings => Web Container Transport Chains.
- From here, press the New button to create a new transport.
- You will need to have a new hostname and port that you would like to use for this group of applications.
Once you have a Transport chain created, select it in the collection of Web Container Transport Chains.
Inside the first link on that page is the TCP Inbound Channel, which includes settings for thread pools and maximum open connections, which can be set in the TCP inbound channel per port.
On the right of the TCP channel configuration panel, click on ThreadPools to create a new Thread Pool for this channel (Figure 3).
Figure 3. Define thread pool
After the thread pool is created, you can select the TCP inbound channel link from the trail above, which lets you to go back and set the thread pool for that port (Figure 4).
Figure 4. Define TCP channel
Once the transport chain is created and the thread pool is set, the virtual host must be configured for that port. Select the Virtual Hosts link in the Environment section on the right (Figure 5).
Figure 5. Configure virtual host
Create a new virtual host from the top of the new configuration screen. Create host aliases for that virtual host to tie traffic from the port to the application. The result is that the hostname and port that was configured with the transport chain is configured as a host alias. When installed, applications should be installed to the new virtual host.
So, now that you have configured the Web container, what needs to be done with the proxy? Nothing! Once the application is started, the proxy will detect that the application and port are available and will route traffic as appropriate.
As you can see, understanding what the proxy server is how it works in the latest version of WebSphere Application Server can clearly yield enormous benefits for your enterprise Web applications.
- Wikipedia: Reverse proxy definition
- WebSphere Application Server product documentation
- IBM developerWorks: WebSphere Application Server zone
- IBM developerWorks: WebSphere Extended Deployment resources