Generating Web server plug-ins in WebSphere Network Development
Web Doc
Note: This is publication is now archived. For reference only.
Abstract
The Web server plug-in is used to forward requests from a Web server to WebSphere Application Server. The Web server plug-in is installed on the Web server machine, but the configuration file (plugin-cfg.xml) for the plug-in is generated via WebSphere and then moved to the appropriate location on the Web server. This is rather straightforward in a base WebSphere installation, but can become a little confusing in a multi-node environment. This tip examines an approach for the generation of plug-in configuration file(s) in WebSphere Application Server Network Deployment topologies. We will discuss three example scenarios, each describing a different topology.
Contents
Scenario 1
In this scenario we have the following Network Deployment topology:
Using the WebSphere 5.0 administrative console "generate plug-in" operation is not recommended for a topology such as this one. The console operation generates a cell-level plug-in configuration file containing entries for all application servers and clusters on all machines in the cell. This does not match well to the requirements of our example topology, since:
Recommended Approach
The recommended approach for this topology is to generate the plugin-cfg.xml locally on each machine using the GenPluginCfg command-line tool. The necessary usage is detailed in the following table. The key points of this approach are:
Note: For further details on using GenPluginCfg, see Appendix of SG24-6195 WebSphere Version 5.0: System Management and Configuration.
Scenario 2
In this scenario we have the following Network Deployment topology:
Recommended Approach
The recommended approach for this topology is to generate the Web server plug-in configuration file on the deployment manager, using either the administrative console, or the GenPluginCfg command-line tool. The key points of this approach are:
Scenario 3
In this scenario we have the following Network Deployment topology:
Recommended Approach
The recommended approach for this topology is to generate the plugin-cfg.xml locally on each machine using the GenPluginCfg command-line tool. The key points of this approach are:
In this scenario we have the following Network Deployment topology:
- Three physical machines (A, B and C), each with a single install of WebSphere Application server base in the <WAS_ROOT> directory.
- In addition to base, Network Deployment is installed on machine C in the <WAS_ND-ROOT> directory.
- All three base installs are nodes of the cell controlled by the deployment manager on machine C.
- Each node has one or more non-clustered application servers.
- Each machine has a Web server and Web server plug-in installed.
- The plug-in on each machine is configured to pass requests only to the application server(s) on the same machine.
Using the WebSphere 5.0 administrative console "generate plug-in" operation is not recommended for a topology such as this one. The console operation generates a cell-level plug-in configuration file containing entries for all application servers and clusters on all machines in the cell. This does not match well to the requirements of our example topology, since:
- The file would have to be generated on the deployment manager machine.
- The file would then need to be copied to all of the other machines.
- The file would need to be edited on each machine so that it only contains entries for the application servers of the node on that machine.
Recommended Approach
The recommended approach for this topology is to generate the plugin-cfg.xml locally on each machine using the GenPluginCfg command-line tool. The necessary usage is detailed in the following table. The key points of this approach are:
- On machines A and B, only local node-level content is required in the plugin-cfg.xml. The file only needs to include entries (XML stanzas) for the application servers of the node on the local machine. The content of the plugin-cfg.xml generated should not require editing as the paths contained in the file should be correct.
- On machine C, the cell-level plugin-cfg.xml file needs to be generated, since both node C application servers and the deployment manager (running the admin console) must be in the generated file. This file will require editing to remove the application server entries of nodes not on machine C. In addition, since GenPluginCfg must be run from the deployment manager installation in order to generate a cell-level plugin-cfg.xml, the paths contained in the generated file will need to be edited.
Machine | Plug-in generation method |
A |
GenPluginCfg.sh -cell.name <cellname> -node.name <nodename> -output.file.name <path to generated plug-in file> ** |
B |
GenPluginCfg.sh -cell.name <cellname> -node.name <nodename> -output.file.name <path to generated plug-in file> ** |
C |
GenPluginCfg.sh -cell.name <cellname> -output.file.name <path to generated plug-in file> ** *** |
** The path of the plug-in file must in each case match the path configured in the Web server configuration file (httpd.conf in IBM HTTP Server) during the WebSphere Application Server base installation. Default is: <WAS_ROOT>/config/cells/plugin-cfg.xml | |
Scenario 2
In this scenario we have the following Network Deployment topology:
- Three physical machines (A, B and C), each with a single install of WebSphere Application server base in the <WAS_ROOT> directory.
- In addition to base, Network Deployment is installed on machine C in the <WAS_ND-ROOT> directory.
- All three base installs are nodes of the cell controlled by the deployment manager on machine C.
- Each node has one or more application servers that are members of a single cluster.
- A separate machine (D) has a Web server and Web server plug-in installed.
- The plug-in is configured to pass requests to all application servers (and deployment manager) on all machines.
- The plug-in is configured to load balance requests between the application servers that are members of the cluster.
Recommended Approach
The recommended approach for this topology is to generate the Web server plug-in configuration file on the deployment manager, using either the administrative console, or the GenPluginCfg command-line tool. The key points of this approach are:
- The cell-level configuration file is generated on machine C using the deployment manager installation's GenPluginCfg.
- The generated configuration file (plugin-cfg.xml) is copied to the Web server machine (D). The destination location is the path configured in the Web server configuration file (httpd.conf in IHS). Default is: <WAS_ROOT>/config/cells/plugin-cfg.xml
- Since GenPluginCfg is run from the deployment manager installation, the paths contained in the generated file will need to be edited to reflect the plug-in installation on the Web server machine.
Machine | Plug-in generation method |
A | No action required. |
B | No action required. |
C |
|
D |
|
** The path of the plug-in file must in each case match the path configured in the Web server configuration file (httpd.conf in IBM HTTP Server) during the WebSphere Application Server base installation. Default is: <WAS_ROOT>/config/cells/plugin-cfg.xml | |
Scenario 3
In this scenario we have the following Network Deployment topology:
- Three physical machines (A, B and C), each with a single install of WebSphere Application server base in the <WAS_ROOT> directory.
- In addition to base, Network Deployment is installed on machine C in the <WAS_ND-ROOT> directory.
- All three base installs are nodes of the cell controlled by the deployment manager on machine C.
- Node A has application servers that are clustered.
- Nodes B and C each have a single non-clustered application server.
- Each machine has a Web server and the Web server plug-in installed.
- The plug-in on each machine is configured to pass requests only to the application server(s) on the same machine.
- The plug-in on machine A is configured to load balance requests between the two local clustered application servers.
Recommended Approach
The recommended approach for this topology is to generate the plugin-cfg.xml locally on each machine using the GenPluginCfg command-line tool. The key points of this approach are:
- On machine B, only local node-level content is required in the configuration file. In other words, the file only needs to include entries for the application servers on this node.
- On machine C, the cell-level configuration file needs to be generated, since entries for both application servers on Node C and the deployment manager must be in the generated file. This file will require editing to remove the application server entries of nodes not on machine C. In addition, since GenPluginCfg must be run from the deployment manager installation in order to generate a cell-level plugin-cfg.xml, the paths contained in the generated file will need to be edited.
- On machine A, the configuration file must include a <Cluster> entry in order to load balance over the cluster of application servers on this machine. This requires the generation of a cell level plugin-cfg.xml. Since the servers in the cluster are all located on this machine, the cell level plugin-cfg.xml can be generated locally on machine A.
| Machine | Plug-in generation method |
A |
|
B |
|
C |
|
** The path of the plug-in file must in each case match the path configured in the Web server configuration file (httpd.conf in IBM HTTP Server) during the WebSphere Application Server base installation. Default is: <WAS_ROOT>/config/cells/plugin-cfg.xml | |
Special Notices
The material included in this document is in DRAFT form and is provided 'as is' without warranty of any kind. IBM is not responsible for the accuracy or completeness of the material, and may update the document at any time. The final, published document may not include any, or all, of the material included herein. Client assumes all risks associated with Client's use of this document.