Generating Web server plug-ins in WebSphere Network Development

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:
  • 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.


Scenario 1 - Three application server installations, each with its own  Web server and plugin.
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.
MachinePlug-in generation method
A
  1. On machine A, change directory to <WAS_ROOT>/bin
  2. Run the following command:
    GenPluginCfg.sh -cell.name <cellname> -node.name <nodename> -output.file.name <path to generated plug-in file> **
B
  1. On machine B, change directory to <WAS_ROOT>/bin
  2. Run the following command:
    GenPluginCfg.sh -cell.name <cellname> -node.name <nodename> -output.file.name <path to generated plug-in file> **
C
  1. On machine C, change directory to <WAS_ND_ROOT>/bin
  2. Run the following command:
    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
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:
  • 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.

Scenario 2 - Three application server installations with clustered servers and one Web server serving 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.
MachinePlug-in generation method
ANo action required.
BNo action required.
C
  1. On machine C, change directory to <WAS_ND_ROOT>/bin
  2. Run the following command: GenPluginCfg.sh -cell.name <cellname> -output.file.name <path to generated plug-in file>
  3. Copy the generated plugin-cfg.xml to required location on Web server machine.
D
  1. Edit plugin-cfg.xml so that paths contained in the file reflect the local machine's plug-in installation.
** 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.

Scenario 1 - Three application server installations, each with its own  Web server and plugin. Node A has clustered 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.
MachinePlug-in generation method
A
  1. On machine A, change directory to <WAS_ROOT>/bin
  2. Run the following command: GenPluginCfg.sh -cell.name <cellname> -output.file.name <path to generated plug-in file> **
B
  1. On machine B, change directory to <WAS_ROOT>/bin
  2. Run the following command: GenPluginCfg.sh -cell.name <cellname> -node.name <nodename> -output.file.name <
C
  1. On machine C, change directory to <WAS_ND_ROOT>/bin
  2. Run the following command: 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

Special Notices

This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.

Profile

Publish Date
10 April 2003


Rating:
(based on 2 reviews)


Author(s)

IBM Form Number
TIPS0141