| The WebSphere product versions provide Web server "plug-ins" for various Web servers enabling the Web servers to forward requests for J2EE Web elements, namely servlets and JSPs, to the WebSphere Application Server. (As with most J2EE application servers, serving HTML is not a primary focus for WAS. WAS V5 does come with an embedded HTTP server based on the IBM HTTP Server, but it is provided mainly to handle specific features such as WAS administration and to offer HTTP itself as a means of communication between external components and WAS.) In particular, a Web server plug-in is provided for the Domino HTTP Server, which allows requests for servlets and JSPs directed to Domino to be handled by a WAS node. This plug-in mechanism was one of the first integration points between the Domino and WAS products. The WebSphere Domino HTTP Server plug-in can be viewed as a basic means of enabling J2EE access from Domino. With the plug-in installed, access to J2EE elements is via explicit URL links. For example, sending a URL of the form http://A.Domino.Host/servlet/SomeServlet to a Domino Server will result in the Domino HTTP task passing the request via the plug-in to a WAS node, which passes the response back via Domino. Figure 9-1 depicts Domino and WAS using the WAS HTTP plug-in. Figure 9-1. WAS plug-in for Domino HTTP. 
Let's examine more closely how this WebSphere plug-in is configured and how it operates. The plug-in itself is provided as a shared library (DLL for Windows, .a for AIX, .so for Solaris, and as of this writing no plug-in exists for Domino on Linux) and a default configuration file: plugin-cfg.xml. The plug-in files are packaged with both the Domino and WAS product installations and can be automatically installed during a WAS installation. The plug-in also can be installed manually. The plug-in files can be found under the Domino install path : Domino/Data/domino/plugins/was5. There are two essential steps to installing the plug-in: 1) specifying the plug-in library file to the Domino HTTP Server and 2) specifying the location of the plug-in configuration file to the plug-in itself. The first step is straightforward and simply requires a change to the Domino server document in the Domino directory. You specify the plug-in library file as a DSAPI filter file on the Internet Protocols/HTTP page of the server document as indicated in Figure 9-2. Figure 9-2. Domino Server plug-in setup. 
The second step is not as straightforward and is operating system-dependent. The plug-in library itself looks for the plug-in configuration file via an operating system environment variable (registry key on Windows). Unfortunately, these variable names are not well advertised in the WebSphere or Domino documentation. For Windows systems, a registry key value needs to be set as shown in Figure 9-3 (you can use the regedit utility program to create the required key path if it is not already defined). For Unix systems, the plug-in looks for the configuration file in the config sub-directory under the path defined by the WAS_HOME environment variable, that is, $ WAS_HOME/config . For IBM iSeries systems, the configuration file location is specified in the Domino notes.ini file. Figure 9-3. Registry setting for the WAS plug-in. 
Once these settings have been made, you can restart the Domino HTTP Server task to have it load the WebSphere plug-in as a DSAPI filter. If the settings are correct, you will see the following messages at the Domino console:
HTTP Server: Java Virtual Machine loaded WebSphere HTTP DSAPI filter loaded HTTP Server: DSAPI WebSphere HTTP DSAPI Filter Loaded successfully HTTP Server: Started
Next, let's take a closer look at the plug-in configuration file, plugin-cfg.xml, to see what it controls and how it can be tailored. This configuration file specifies three key aspects of how the plug-in operates: which URL hostnames and which URL types get routed to WAS and to which WAS servers they get routed. It also allows specification of the log file written by the plug-in and the level of logging. The following shows the configuration file that comes with Domino R6:
<Config> <!-- The LogLevel controls the amount of information that gets written to the plug-in  log file. Possible values are Error,Warn, and Trace. --> <Log Name="C:/WebSphere/AppServer/logs/native.log" LogLevel="Error"/> <!-- Server groups provide a mechanism of grouping servers together. --> <ServerGroup Name="default_group"> <Server Name="default_server"> <!-- The transport defines the hostname and port value that the web serverplugin will use to communicate with the application server. --> <Transport Hostname="localhost" Port="9080" Protocol="http"/> </Server> </ServerGroup> <!-- Virtual host groups provide a mechanism of grouping virtual hosts together. --> <VirtualHostGroup Name="default_host"> <VirtualHost Name="*:*"/> </VirtualHostGroup> <!-- URI groups provide a mechanism of grouping URIs together. Only the context root of a web application needs to be specified unless you want to restrict the request URIs that get passed to the application server. --> <UriGroup Name="default_host_URIs"> <Uri Name="/servlet/*"/> <Uri Name="/webapp/examples/*"/> <Uri Name="*.jsp"/> <Uri Name="*.jsv"/> <Uri Name="*.jsw"/> <Uri Name="/ErrorReporter"/> <Uri Name="/j_security_check"/> <Uri Name="/tradetheme/*"/> <Uri Name="/theme/*"/> <Uri Name="/WebSphereSamples/*"/> <Uri Name="/estore/*"/> </UriGroup> <!-- A route ties together each of the above components. --> <Route ServerGroup="default_group" UriGroup="default_host_URIs" VirtualHostGroup="default_host"/> </Config>
As with all WAS configuration files, the plug-in configuration file has XML syntax and thus can be edited with any text editor. The Log Name element specifies the file name of the log file written by the plug-in and the level of logging desired. The ServerGroup element specifies the WAS server(s) to which URLs are routed and the protocol to be used. The default is to route URLs to the local WAS server at port 9080 (the embedded WAS HTTP Server) over HTTP. Additional servers can be specified here, as well as HTTPS instead of HTTP. If more than one server is specified within a server group , the plug-in routes to the servers in a round- robin fashion. If HTTPS is used, additional system environment variables must be set pointing to the SSL libraries and the certificate and encryption key files required by the plug-in for the HTTPS protocol. One or more VirtualHostGroup elements can be specified to define the hostname patterns, which the URLs must match to be considered part of that host group. Similarly, one or more UriGroup elements can be specified to define the types of URLs belonging to the URI group. Finally, the Route element specifies a single routing definition in terms of the virtual host and Urigroup elements. That is, a Route element defines that URLs belonging to the specified VirtualHostGroup and UriGroup should be routed to the specified ServerGroup . The operation of the plug-in is straightforward. Every URL sent to the Domino HTTP task is intercepted by the plug-in and compared to the set of Route definitions. If a match is found, the URL is routed to a server specified in the specified ServerGroup for the Route definition. Otherwise, the URL is passed back to the Domino HTTP task for processing. This is straightforward indeed, but some care should be taken. Since every URL, including requests for images, goes through the plug-in, and each URL is compared against every VirtualHost and Uri element within each VirtualHostGroup and UriGroup , the VirtualHost and Uri elements should be kept as minimal as possible. If a URL pattern is not supported by the WAS node, you should remove it from the UriGroup . (The fact that every URL is passed to the plug-in is due to the nature of the Domino DSAPI used by the plug-in ”and can't be avoided.) The WAS HTTP Server plug-in periodically rereads the plug-in configuration file, so any changes made to it are picked up by the plug-in without having to restart the Domino HTTP task. | 