email article printer friendly more resources

Plugging into WebSphere
Take a look at the role WebSphere HTTP Plug-in serves in a clustered topology
by Kulvir Singh Bhogal

Posted June 2, 2004

In a recent article I wrote about WebSphere Application Server (WAS) Version 5 clustering—"Cluster WebSphere Servers" (Java Pro, May/June 2004)—I presented how WAS has built-in facilities that provide scalability through load balancing and high availability through failover. Here, I'll shed more light on the subject, focusing on the role of the Web server plug-in (also referred to as the WebSphere HTTP Plug-in) in a clustered topology.

In a typical environment, the HTTP server works with the Web server plug-in to forward requests to a participating WebSphere Application Server clone of a cluster (see Figure 1). You can see the link between the IBM HTTP server and the Web server plug-in in the httpd.conf file, which is located in the conf directory of your Web server directory (see Figure 2).

The WebServer plug-in is installed on the Web server machine. The plug-in uses a configuration file named plugin-cfg.xml to define load distribution policies. In many environments, the process of providing the Web server machine with the appropriate plugin-cfg.xml file for the plug-in simply involves generating the plug-in configuration file on the machine running the Deployment manager and copying the configuration file to the Web server in the appropriate location on the Web server machine.

The plug-in configuration file can be generated using the Administrative console (see Figure 3). It can also be generated using the GenPluginCfg command line tool. Refer to the IBM Redbooks technical note for more information (see Resources).

Opening up the plugin-cfg.xml file (located in the config/cells directory) of the application server installation directory shows you the different participants of the cluster in an XML-based configuration file. Each clone of the cluster has an entry like the one you see here created for it:

<Server CloneID="vifthlrb" 
  ConnectTimeout="0" 
  ExtendedHandshake="false" 
  LoadBalanceWeight="2" 
  MaxConnections="-1" Name=
  "hp3c_clone2" WaitForContinue=
  "false">
  <Transport Hostname="hp3c" 
    Port="9082" Protocol=
    "http"/>
  <Transport Hostname="hp3c" 
    Port="9445" Protocol=
    "https">
  <Property Name="keyring" 
    Value="C:\WebSphere\
    DeploymentManager\etc\
    plugin-key.kdb"/>
  <Property Name="stashfile" 
    Value="C:\WebSphere\
    DeploymentManager\etc\
    plugin-key.sth"/>
  </Transport>
</Server>

Note that this entry states the name of the clone (in this case hp3c_clone2) and LoadBalance weight (for this entry a weight of 2), which you designate through the WebSphere Administrative Console. The aforementioned Java Pro article explains how to do this designation (see Resources). Note also that the port 9082 is defined as the port that the clone is listening to. This port number is established when you federate the node. As of WebSphere Application Server 5.1, you can use a MaxConnections attribute to specify the maximum number of connections to a participating cluster member that can flow through the Web server process at any point in time. For more information about the elements and attributes of the plugin-cfg.xml file, refer to the WebSphere Application Server Information Center (see Resources).