in Resources

How to Integrate IBM HTTP Server with WebSphere Application Server 8.5.5: An In-Depth 2500+ Word Guide

Integrating your WebSphere Application Server (WAS) behind a web server like IBM HTTP Server (IHS) provides several benefits including improved performance, enhanced security, and better scalability.

As an IT professional who has worked with WebSphere for many years, I cannot emphasize enough the importance of front-ending WAS with a high performance web server like IHS. It is an essential deployment architecture for any organization that runs business critical applications on WebSphere.

In this comprehensive 2500+ word guide, you will learn:

  • Key benefits of using IHS with WebSphere
  • Step-by-step instructions to connect IHS with WAS
  • Best practices for optimal performance and security
  • Troubleshooting tips from my experience
  • And much more!

By the end, you will have all the knowledge to seamlessly integrate IHS and WebSphere for your environment. Let‘s get started!

Why Integrate IHS with WebSphere?

Based on my experience deploying web applications on WebSphere for various enterprises, I strongly recommend using IHS as a reverse proxy to WebSphere.

Here are some key reasons why:

1. Substantial Performance Gains

IHS is designed from the ground up to be a high performance web server capable of handling thousands of concurrent connections easily. It can effortlessly serve static content, handle SSL/TLS termination, and pass dynamic requests to backend application servers like WebSphere.

This greatly improves the overall throughput and response times for your web applications compared to WebSphere alone.

As per IBM estimates, IHS can increase throughput capacity by 3x times compared to using WebSphere default HTTP transport. And response times can be twice as fast in most use cases.

2. Enhanced Security

With IHS as a reverse proxy, your WebSphere nodes are shielded from direct attacks from the internet. The application servers can safely sit in the internal network while IHS handles all external requests.

This provides an additional layer of security and protects WebSphere against common attacks like DDoS, vulnerabilities scanners etc.

IHS can also offload CPU intensive SSL/TLS encryption/decryption allowing WebSphere to focus on application logic. Studies show dedicated SSL accelerators can improve response times by 20-40% for HTTPS traffic.

3. Flexible Scalability

One great advantage of IHS is the ability to scale-out the web tier independently as per demand. You can easily add more IHS servers with just a httpd.conf change.

Whereas scaling WebSphere requires extensive capacity planning and deployment of additional nodes. With IHS, you have much finer control over right-sizing your web tier.

IHS can also load balance requests between multiple WebSphere nodes. This allows a single entry point for users while distributing the application load.

4. Simplified Maintenance

Software updates, security patches, and configuration changes can be quickly rolled out to IHS servers without disrupting backend WebSphere services.

You also get centralized configuration of your web servers via the single httpd.conf file. Any changes get propagated automatically to all nodes.

5. Improved Compliance and Monitoring

IHS provides rich logs out of the box – access logs, agent logs, error logs. These can feed into security information and event management (SIEM) systems.

The reverse proxy model also helps segregate internal WebSphere traffic from external traffic for better auditing.

With these significant benefits in mind, let‘s discuss the integration steps:

Software Versions Used

The instructions provided here are based on:

  • WebSphere Application Server Network Deployment 8.5.5
  • IBM HTTP Server 8.5.5

You can follow the same overall process for other versions too. The plugin files and exact configuration may differ slightly across versions.

Now, let‘s look at the steps to integrate IHS and WAS.

Step 1 – Downloading and Installing WebSphere Plug-ins

WebSphere provides plugins for popular web servers like IHS, Apache, Nginx and IIS to delegate requests. You need to first download and install these plugins:

  1. Open your browser and go to the WebSphere plugin download page. This requires a free IBM account.

  2. Fill in your contact details and submit the form. You will be taken to the downloads page.

  3. Under the "Download using http" tab, search for the plugin zip files for your web server. For IHS, you need to download 2 zip files named similarly to:

    • was.repo.8550.plg.ilan_part1.zip
    • was.repo.8550.plg.ilan_part2.zip

  4. Once downloaded, transfer these zip files to your IHS server using pscp/WinSCP etc.

  5. Extract the contents of both zip files using the unzip command:

    unzip was.repo.8550.plg.ilan_part1.zip  
unzip was.repo.8550.plg.ilan_part2.zip

  6. This will extract a file named repository.config containing metadata about the plugins.

We will next install the plugins using IBM‘s Installation Manager tool.

Installing Plug-ins via Installation Manager

Follow these steps to install the downloaded WebSphere Plugin packages on RHEL/CentOS Linux:

  1. Launch IBM‘s Installation Manager. The default install location is /opt/IBM/InstallationManager/eclipse/IBMIM.

  2. Go to File > Preferences and click on Add Repository.

  3. Use Browse to select the extracted repository.config file.

  4. Click OK to add the repository information.

  5. Now go to the Installation tab and click Install.

  6. Select WebSphere version 8.5.5 from the list and click Next.

  7. Accept the license agreement and click Next.

  8. Verify the install location which is /opt/IBM/WebSphere/Plugins by default. Click Next after verifying.

  9. Select 64-bit runtime for Java/JDK and click Next.

  10. Review the installation summary page and click Install.

This will begin the plugin installation process which can take 10-20 minutes based on system resources. The progress will be shown.

  1. Once installation completes, you will see a confirmation message. Click Finish to exit Installation Manager.

The WebSphere plugins are now installed and ready to be configured with IHS!

Next, we will define the IHS instance within the WebSphere Administration Console.

Step 2 – Register IHS Server in WebSphere

For WebSphere to delegate requests to IHS, we need to define the web server in its configuration:

  1. Login to the WebSphere Admin Console, usually at http://host:9060/ibm/console.

  2. Go to Servers > Server Types > Web Servers.

  3. Click New to add a new web server definition.

WebSphere Add Web Server

  1. Leave the node as default if IHS is installed on the same machine as WebSphere. Else select the correct cluster node.

  2. Enter a name like "IHS85Server" and select type as "IBM HTTP Server".

  3. Leave the default settings for templates and click Next.

  4. Specify the HTTP port which is 80 by default. Use the actual IHS HTTP port if different.

  5. Enter the IHS install location path. For RHEL this is /opt/IBM/HTTPServer by default.

  6. Enter the plugin install path which is /opt/IBM/WebSphere/Plugins.

  7. Click Next and review the summary page.

  8. Click Finish to create the IHS server definition.

  9. Select the option to synchronize changes and click Save.

This replicates the configuration to all nodes.

We have now defined IHS as a web server within WebSphere. Next, we need to generate the required plugins.

Step 3 – Generate and Propagate Plugins

For integration to work, WebSphere needs to create plugin files configured for the IHS server:

  1. In the WebSphere console, select the newly created IHS server definition.

  2. Click Generate Plug-in to create the plugin files.

  3. Once generated successfully, click Propagate Plug-in.

    This copies the plugins to the defined install location, usually /opt/IBM/WebSphere/Plugins.

  4. Note down the full path shown for the plugin-cfg.xml file.

We need this later for the IHS httpd.conf configuration. The plugins are now ready for use by IHS.

Next we‘ll configure the httpd.conf with the WebSphere plugin details.

Step 4 – Update IHS httpd.conf Configuration

For IHS to forward requests to WebSphere, the httpd.conf needs to be updated with the plugin configuration:

  1. Edit the httpd.conf located at /opt/IBM/HTTPServer/conf on RHEL systems.

  2. Always take a backup of the file before making any changes!

  3. Add the following lines anywhere in httpd.conf:

    LoadModule was_app22_module /opt/IBM/WebSphere/Plugins/bin/64bits/mod_was_ap22_http.so

WebSpherePluginConfig /opt/IBM/WebSphere/Plugins/config/WebServer-1/plugin-cfg.xml

  4. Replace the paths with your generated plugin-cfg.xml location.

  5. Save httpd.conf after making the changes.

  6. Restart the IBM HTTP Server for changes to take effect.

    service httpd restart

This concludes the IHS integration steps with WebSphere! The two servers are now connected together.

Let‘s move on to verifying and troubleshooting the implementation.

Verifying the IHS + WebSphere Integration

To confirm everything is working correctly between IHS and WebSphere:

  • Deploy a test application on WebSphere and select the option to use IHS for handling requests.

  • Try accessing the app URL through IHSinstead of WebSphere ports.

  • The application home page should display successfully.

  • Check for any errors logged in IHS error.log or WebSphere SystemOut.log if you face access issues.

Additionally, you can check that requests are flowing from IHS to WebSphere by:

  • Enabling WebSphere detailed access logs

  • Using a packet capture tool like tcpdump between IHS and WebSphere

  • Running the requests through a proxy like Fiddler for inspection

This will confirm IHS is able to route requests properly to the backend application server.

Troubleshooting Tips for IHS and WebSphere

In my experience with integrating various versions of IHS and WebSphere, here are some troubleshooting tips:

500 Internal Server Errors

  • Double check the plugin shared library path configured in httpd.conf e.g. mod_was_ap22_http.so. Incorrect path is a common misconfiguration.

  • Try restarting both IHS and WebSphere to rule out any startup issues.

  • Look for errors in SystemOut.log, FFDC logs and IHS error logs for possible clues.

Applications Not Accessible via IHS

  • Ensure you have selected IHS as the web server target when deploying the application. By default apps use WebSphere ports.

  • Regenerate and re-propagate the plugins if you make any change to context roots, web modules etc.

  • Verify the plugin-cfg.xml file contains your app context root mappings.

High Memory Utilization

  • Tune IHS settings for caching, compression, keep alive timeouts etc. Default is optimized for stability over performance.

  • Use a JVM profiler like JVisualVM to check for memory leaks, excessive GC etc.

  • Enable IHS and WebSphere access logging and correlate spikes with high load.

SSL Certificate Issues

  • If using SSL offloading, import the certificate into IHS keystore instead of WebSphere.

  • For SNI support, ensure you use OpenSSL 1.0.2+ and the correct httpd-ssl.conf template.

With these troubleshooting tips, you should be well equipped to diagnose and fix commonly encountered problems.

Best Practices for IHS and WebSphere Integration

Based on my extensive experience with using IHS as a proxy for WebSphere, here are some best practices:

Performance Tuning and Caching

  • Enable compression in IHS for static content – CSS, JS, images etc. Significant bandwidth savings.

  • Configure caching headers like Cache-Control, Expires for better browser cache utilization.

  • Offload SSL on IHS – avoids HTTPS overhead on WebSphere. Use FastCGI for best results.

  • Use WebSphere output compression for dynamic HTML and JSON responses.

Security

  • Limit WebSphere ports only to internal network access. IHS should handle external requests.

  • Configure a Web Application Firewall like ModSecurity on IHS for better attack prevention.

  • Enable IHS access logging and feed logs into a SIEM system. Correlate events with application logs.

High Availability

  • Use multiple IHS nodes behind a load balancer for eliminating single point of failure.

  • Enable sticky sessions on the load balancer to maintain user session state.

  • Follow WebSphere best practices for database clustering, server clustering etc.

Maintenance

  • Schedule a maintenance window for major version upgrades, apply patches regularly.

  • Take backups of configuration files before any changes – httpd.conf, plugin-cfg.xml etc.

  • Monitor server resources – RAM, CPU, Disk space for capacity planning.

Auditing and Compliance

  • Configure IHS for external requests, WebSphere for internal traffic. Makes auditing and compliance easier.

  • Centralize access logs into a logging system. Correlate IHS and WebSphere logs for request tracking.

I hope these tips help you optimize your IHS + WebSphere implementation! Let‘s recap what we learned.

Conclusion

We covered a lot of ground in this detailed guide!

To quickly recap:

  • IHS front-ending WebSphere improves performance, security and scalability materially.

  • Downloading and installing WebSphere plugins on IHS is step 1

  • Defining IHS server in WebSphere and generating plugins is next

  • Finally, update IHS httpd.conf with the plugin configuration

  • Validate integration by deploying an app on WAS and accessing via IHS

With the steps provided, you should be able to seamlessly connect IBM HTTP Server as a proxy for WebSphere ND.

While this guide focused on version 8.5.5 specifically, the concepts are applicable across all versions and platforms.

Let me know in the comments below if you have any other questions! I‘m happy to help troubleshoot any issues you face in the integration process.

AlexisKestler

Written by Alexis Kestler

A female web designer and programmer - Now is a 36-year IT professional with over 15 years of experience living in NorCal. I enjoy keeping my feet wet in the world of technology through reading, working, and researching topics that pique my interest.