First steps are here
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.
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:
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:
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.
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.
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.
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.
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: