3.7.  Manage the plug-in configuration file (e.g., regenerate, edit, propagate, etc.).

[Note]

Web servers and WebSphere Application Server Plug-in

Most WebSphere Application Server topologies will have a Web server which receives HTTP-based requests from clients. For security reasons the Web server should be placed in a separate network zone secured by firewalls (a DMZ).

Usually the Web server, in conjunction with the WebSphere Application Server Plug-in, provides the following functionality in the topology:

WebSphere Application Server comes with Web server plug-ins for all supported Web servers.

The plug-in uses a configuration file (plugin-cfg.xml) that contains settings describing how to pass requests to the application server. The configuration file is generated on the application server. Each time a change on the application server affects the request routing of requests (for example, a new application is installed) the plug-in must be regenerated and propagated to the Web server machine again.

Note: In a stand-alone topology, only unmanaged Web servers are possible. This means the plug-in must be manually pushed out to the Web server system. The exception to this is if you are using IBM HTTP Server. The application server can automatically propagate the plug-in configuration file to IBM HTTP Server, even though it is an unmanaged node, by using the administrative instance of IBM HTTP Server.

Figure 3.9. IBM HTTP Server (IHS) as unmanaged node (remote)

IBM HTTP Server (IHS) as unmanaged node (remote)


Figure 3.10. Web Server on a managed node (local)

Web Server on a managed node (local)


Web server configuration

Plug-in configuration involves configuring the Web server to use the binary plug-in module that WebSphere Application Server provides. Plug-in configuration also includes updating the plug-in XML configuration file to reflect the current application server configuration. The binary module uses the XML file to help route Web client requests.

After installing a supported Web server, you must install a binary plug-in module for the Web server. The plug-in module lets the Web server communicate with the application server. The Plug-ins installation wizard installs the Web server plug-in. The wizard configures the Web server. The wizard also creates a Web server definition in the configuration of the application server. The Plug-ins installation wizard uses the following files to configure a plug-in for the Web server that you select:

Implementing a web server plug-in

  1. Use the administrative console to change the settings in the plug-in configuration file.

    When setting up your web server plug-in, you must decide whether to have the configuration automatically generated in response to a configuration change. When the web server plug-in configuration service is enabled and any of the following conditions occur, the plug-in configuration file is automatically generated:

    • When the web server is created or saved

    • When an application is installed

    • When an application is uninstalled

    • When the virtual host definition is updated

    You can either use the administrative console, or issue the GenPluginCfg command to regenerate your plugin-cfg.xml file.

    NOTE: You must delete the plugin-cfg.xml file in the profile_root/config/cells directory before you complete this task. Otherwise, configuration changes do not persist to the plugin-cfg.xml file.

    Complete the following steps to regenerate your plugin-cfg.xml file by using the administrative console:

    1. Select Servers > Server Types > Web Servers > web_server_name > Plug-in properties.

      Figure 3.11. Plug-in properties

      Plug-in properties


    2. Select Automatically generate plug-in configuration file, or click one or more of the following topics to manually configure the plugin-cfg.xml file:

      • Caching

      • Request and response

      • Request routing

      • Custom Properties

      NOTE: Do not manually update the plugin-cfg.xml file. Any manual updates you make for a web server are overridden whenever the plugin-cfg.xml file for that web server is regenerated.

    3. Click OK.

    4. You might need to stop the application server, and then restart the application server for the web server to locate the plugin-cfg.xml file.

  2. Propagate the plug-in configuration. The plug-in configuration file, plugin-cfg.xml, is automatically propagated to the web server if the web server plug-in configuration service is enabled, and one of the following conditions is true:

    Figure 3.12. Propagating the plugin-cfg.xml

    Propagating the plugin-cfg.xml


    • The web server is a local web server, which means that the web server is located on the same workstation as an application server.

    • The web server is a remote IBM HTTP Server Version 7.0 that has a running IBM HTTP Server administration server.

    If neither of these conditions is true, you must manually copy the plugin-cfg.xml file to the location of the installation for the remote web server. Copy the plugin-cfg.xml file in app_server_root/profiles/profile_name/config/cells/../../nodes/../servers/web_server_name to the web server host location, which is Plugin_Install_Root/config/web_server_name/.

    NOTE: If you use the FTP function to copy the file, and the configuration reload fails, check the file permissions on the plugin-cfg.xml file, and make sure that they are set to rw-r--r--. If the file permissions are not correct, the web server is not able to access the new version of the file, which causes the configuration reload to fail.

    If the file permissions are incorrect, issue the following command to change the file permissions to the appropriate settings:

    chmod 644 plugin-cfg.xml
    								

    The remote web server installation location is the location you specified when you created the node for this web server.

Request routing using plug-in

The Web Server plug-in uses an XML configuration file to determine whether a request is for the Web Server of the Application Server.

When a request reaches the Web Server, the URL is compared to those managed by the plug-in. If a match is found, the plug-in configuration file contains the information needed to forward the request to the Application Server's web container using the web container inbound chain.

For example, lets say you make a request to http://localhost:80/snoop URL, so the Web Server Plugin will check the /snoop URL to find out how it is should be handled. It will check if there is matching UriGroup element in plugin-cfg.xml:


<UriGroup Name="default_host_cluster1_URIs">
  <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/snoop/*"/>
</UriGroup>
					

In this case it knows that the /snoop/* URL is for dynamic content, so the next part is how to route it to correct server. It will read value of Name attribute for the UriGroup which is default_host_cluster1_URIs, and name of the cluster is cluster1. It will use these values find out virtual host and cluster:


<Route ServerCluster="cluster1" UriGroup="default_host_cluster1_URIs" 
	VirtualHostGroup="default_host" />

<VirtualHostGroup Name="default_host">
    <VirtualHost Name="*:9080"/>
    <VirtualHost Name="*:80"/>
    <VirtualHost Name="*:9443"/>
    <VirtualHost Name="*:5060"/>
    <VirtualHost Name="*:5061"/>
    <VirtualHost Name="*:443"/>
    <VirtualHost Name="*:9081"/>
    <VirtualHost Name="*:9082"/>
</VirtualHostGroup>

<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" 
	IgnoreAffinityRequests="true" LoadBalance="Round Robin" 
	Name="cluster1" PostBufferSize="64" PostSizeLimit="-1" 
	RemoveSpecialHeaders="true" RetryInterval="60">

  <Server CloneID="14dtuu8g3" ConnectTimeout="0" ExtendedHandshake="false" 
	LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server2" 
	ServerIOTimeout="0" WaitForContinue="false">
    <Transport Hostname="dmgr.webspherenotes.com" Port="9081" Protocol="http"/>
    <Transport Hostname="dmgr.webspherenotes.com" Port="9444" Protocol="https">
      <Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.kdb"/>
      <Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.sth"/>
    </Transport>
  </Server>

  <Server CloneID="14dtuueci" ConnectTimeout="0" ExtendedHandshake="false" 
	LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server4" 
	ServerIOTimeout="0" WaitForContinue="false">
    <Transport Hostname="dmgr.webspherenotes.com" Port="9082" Protocol="http"/>
    <Transport Hostname="dmgr.webspherenotes.com" Port="9445" Protocol="https">
      <Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.kdb"/>
      <Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.sth"/>
    </Transport>
  </Server>

  <PrimaryServers>
    <Server Name="dmgrNode01_server2"/>
    <Server Name="dmgrNode01_server4"/>
  </PrimaryServers>

</ServerCluster>
					
					

It knows that the cluster1 has two servers dmgrNode01_server2 and dmgrNode01_server4 and from the cluster definition it can find out the http and https port and then forward request to either of the server. The cluster definition also says that the load balancing algorithm is Round Robin.

Professional hosting         Free 'Oracle Certified Expert Web Services Developer 6' Guide     Free SCDJWS 5.0 Guide