Local Navigation

PHP/JavaBridge and WebSphere 2: Integrating Apache and WebSphere with the Bridge

First steps are here

Introducing the Web Server and Plug-In

In WebSphere a separate application called the Web Server Plug-In mediates between the HTTP Server and the WAS Application server, determining which URL's seen by the HTTP Server are handled directly and which are passed to the WAS application server for processing in JEE.

The WebSphere plug-inis available on the disc of the WebSphere distribution media that contains, among other things, the application client and IHS, the IBM version of the apache HTTP server.  It's also part of all the trial versions and downloadable licensed versions.

Installing the Web Server and Plug-In 

Begin by installing your web server of choice.  IBMIHS works fine, as does Apache 2.0.  Please Note that Apache 2.4 does not appear to work correctly with the IBM PlugIn as of August 2007.  Use the older 2.0 if you want vanilla Apache.

During the plug-in installation you'll be asked which web server to configure.  Choose the one you previously installed.

The Apache 2.0 installation and configuration seems to work fine; you should see two new lines in your httpd.conf file:

LoadModule was_ap20_module "C:\Program Files\IBM\WebSphere\Plugins\bin\mod_was_ap20_http.dll"
WebSpherePluginConfig "C:\Program Files\IBM\WebSphere\Plugins\config\localApache\plugin-cfg.xml"

Of course your mileage will vary with the location of the plugin-cfg.xml, which is the file that tells the web server which URL patterns are to be routed to the WAS servlet engine and which are to be served up directly by Apache or IHS.

The plugin-cfg.xml file is custom for your particular installation of web applications, and must be regenerated after every server or application configuration change that would affect how you want the web server to handle URL mappings.  IBM has tried to make this a one or two-click administration process through the Admin Console, but your mileage may vary significantly and my very best source inside IBM advises me to avoid using the autodeployment features of the plugin for production work.

However the process itself is simple enough.  Connect to your WebSphere Admin Console, usually running on port 9060, and navigate to the Web Server Administration section as shown in Figure A:

Figure A: Creating a new Web Server Configuration

If you installed IBMIHS then the subsequent installation of the plugin will probably have configured an entry for you; if you installed Apache 2.0, probably not.  If you need to create a web server entry:

  1.  Click the New button, circled in the picture
  2.  Create the definition of your server in the definition wizard below.  Give the server a name that will identify it to you in the Admin Console, select the appropriate server type, e.g. IHS or Apache, the host name the server listens on and the underlying platform where the web server resides.  Note that all these parameters are relative to the web server, not the WAS application server, and that the web server need not reside on the same physical host as the WAS server.  Load balancing is good.  Click Next
  3. Select a web server template when prompted at the next wizard screen.  Pick IBMIHS or Apache, depending on your choice.  Click Next
  4. Enter the properties for the new server as shown in Figure C below.  All properties are relative to the web server.  The parameters for Apache are fairly minimal; IBMIHS asks a little more since it has an associated admin service of its own. Click Next
  5. View a summary of your choices.  Click Next again and save. 

Figure B - First Page of Configuration Wizard

Figure C - Last Page of Configuration Wizard

Note that one of the properties is the default location of the plugin-cfg.xml file to be written.  If you want you can skip the propagation of the plugin step by indicating a file location that is actually on the target web server platform file system, matching the entry in httpd.conf.  Of course that assumes that the file system is local to the browser accessing the WAS admin console, or can be mounted there.

Generating Propagating the Plug-In 

You can now select a target web server with the checkbox, and click on Generate Plug-In, which will write a correct plugin-cfg.xml file for the current state of your WAS server environment and installed applications, and notify you of its location.  This step reliably works.

Note the location the Admin Console gives you for where it put the plugin-cfg.xml

If you cleverly set your configuration to generate the plugin-cfg.xml to the same location specified in the related web server's httpd.conf file, you're done.  Skip the rest of this step.

Otherwise propagate your plugin: 

In theory, after generating the plug-in you can click on Propagate Plug-In which is supposed to copy the generated plugin-cfg.xml file to the target location on the desired web server.  The propagation step works intermittently.  My recommendation is to generate, then manually move the plugin-cfg.xml file to its location as defined in the  WebSpherePluginConfig line in httpd.conf. That always works.

Test the Plug-In

 Unless you've taken measures to avoid it, WebSphere deploys a Snoop servlet to display servlet state.  By the way, you should remove Snoop on production systems.  Here we'll use it to verify correct routing.

  1. Restart your web server.  You don't need to restart your application server
  2. Make sure the web server is working in normal mode by accessing any static file in its document path.  In most cases with an entry like
    you will see the Apache welcome page
  3. Now test the plug-in configuration by asking for the snoop servlet using a URL of the form :
  4. If you have WAS (not HTTP) security enabled you'll be prompted for username and password.  Enter any valid combination; snoop is enabled for "All Authenticated"
  5. http://dorsetwest.com/drupal.files/image_01985.jpg
  6. You should see the snoop page like the one below.  It works!

     Repeat the propagation step every time you install a new application, change the URL mappings of an existing one, or make a relevant change to the WAS application server, for example changing a virtual host. 

Verify Access to PHP JavaBridge from the Web Server

We're finally ready to verify access to the PHP JavaBridge from our HTTP Web Server. The path of access is:

Browser ===> HTTP Web Server (Apache or IHS) ===> IBM Plug In ===> WAS Servlet Container ===> JavaBridge.war ===> PHP engine

Assuming you have the JavaBridge.war application correctly installed and running from Part 1, enter a URL of the form:

You should see the PHP JavaBridge Examples page, and it should work, just as in Step 1. All done!