Communicating with Web servers

 

+

Search Tips   |   Advanced Search

 

WAS ND v7.0 works with a Web server to route requests for dynamic content, such as servlets, from Web apps. The Web servers are necessary for directing traffic from browsers to the applications that run in an application server. The Web server plug-in uses the XML configuration file to determine whether a request is for an appserver.

• Install the Web server.

  Use the IBM HTTP Server that is provided with WAS ND.

• Verify that the Web server is configured to perform the operations that are required by Web apps, such as GET and POST.

  Typically, configuring the Web server to perform these operations involves setting a directive in the Web server configuration file. Refer to the Web server documentation for instructions. If an operation is not enabled when a servlet or JSP file requiring the operation is accessed, an error message displays, such as this one from the IBM HTTP Server:

  HTTP method POST is not supported by this URL.

• Make sure the appropriate plug-in file has been installed on the Web server and the configureWebServer script has been run to create and configure the Web server definition for this Web server.

  For a distributed platform Web server, use the Plug-in Installation wizard to install the appropriate plug-in file to the Web server. Then run the configureWebServer script created by the wizard to create and configure the Web server definition in the WebSphere configuration repository.

The following steps are performed during the plug-in installation process.

1. A node is created.

   An unmanaged node is created when the Web server is on a different computer from the appserver. An unmanaged node is a node that does not have a node agent running on it. Using unmanaged nodes, WAS can represent servers that are not appservers within its configuration topology. This representation enables connection information between those servers and appservers to be maintained.

2. A Web server definition is created.

   We can also use either the admin console or use the ConfigureWebServerDefinition.jacl script to create a Web server definition. If we use the admin console:

   1. Select the node created in the preceding step, and in the Server name field, enter the local name of the Web server for which we are creating a Web server definition.

   2. Use the wizard to complete the Web server definition.

3. An application or modules are mapped to a Web server.

   If an application to use with this Web server is already installed, the application is automatically mapped to the Web server. If the application is not installed, select this Web server during the Map modules to servers step of the application installation process.

4. The master repository is updated and saved.

When you install a plug-in, the configuration file for that plug-in is automatically created. We can change or fine tune the default settings for the properties in this configuration file. If change any of the settings, regenerate the file before the changes take affect.

Generating or regenerating the configuration file might take a while to complete. After it finishes, all objects in the administrative cell use their newest settings, which the Web server can access. If the Application Server is on the same physical machine as the Web server, the regeneration usually takes about 30 to 60 seconds to complete. The regeneration takes longer if they are not both on the same machine.

The following procedure describes the steps for updating the plug-in configuration file, including configuring for SSL and Web server tuning

 

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

   When setting up the Web server plug-in, decide whether or not 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:

   • The Web server is created or saved.
   • An application is installed.
   • An application is uninstalled.
   • The virtual host definition is updated

   Avoid trouble: When the plug-in configuration file is first generated, it does not include admin_host on the list of virtual hosts. Allow Web servers to access the admin console describes how to add it to the list

   We can either use the admin console, or issue the GenPluginCfg command to regenerate plugin-cfg.xml. To use the admin console:

   1. Select...

      Servers | Server Types | Web Servers | web_server_name | 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

      
      Web server plug-in configuration properties maps each property to one of these topics.

      Avoid trouble: IBM recommends that you do not manually update plugin-cfg.xml. Any manual updates you make for a given Web server are overridden whenever the plugin-cfg.xml file for that Web server is regenerated.

   3. Click OK.

   4. We might have to stop the appserver and then start the appserver again to enable the Web server to locate the plugin-cfg.xml file.

2. To use SSL with this configuration, use the plug-in's installation wizard to install the appropriate GSKIT installation image file on the workstation.
3. Tune the Web server.

4. 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 is true:

   • The Web server is a local Web server, which means that the Web server is located on the same machine as an appserver.

   • The Web server is a remote IBM HTTP Server V7 that has a running IBM HTTP Server administration server.

   If neither of these conditions is true, the plugin-cfg.xml file must be manually copied to the remote Web server's installation location. Copy plugin-cfg.xml in...

   WAS_HOME/profiles/profile/config/cells/../../nodes/../servers/webserver

   ..to the Web server host location...

   PLUGIN_ROOT/config/webserver/

   If we use the FTP function to perform the copy, and the configuration reload fails, check the file permissions on the plugin-cfg.xml file and make sure 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 AIX FTP function does not preserve file attributes. Therefore, to manually copy the plugin-cfg.xml from an AIX operating system, we might want to use the AIX RCP function instead of the FTP function to copy the file.

   The remote Web server installation location is the location you specified when creatingd the node for this Web server.

 

Results

The configuration is complete. To activate the configuration, stop and restart the Web server. If we encounter problems restarting the Web server, check the http_plugin.log file for information on what portion of the plugin-cfg.xml file contains an error. The log file states the line number on which the error occurred along with other details that might help you diagnose why the Web server did not start. We can then use the admin console to update the plugin-cfg.xml file.

If applications are infrequently installed or uninstalled, which is usually the situation in a production environment, or if we can tolerate the performance impact of generating and distributing the plug-in configuration file each time any of the previously listed actions occur, you should consider enabling this service.

If making a series of simultaneous changes, like installing numerous applications, we might want the configuration service disabled until after you make the last change. The Web server plug-in configuration service is enabled by default. To disable this service, in the admin console click...

Servers > Server Types > WebSphere application servers > server_name > administration services > Web server plug-in configuration service

...and then unselect the option...

Enable automated Web server

Avoid trouble: If the installation uses a firewall, make sure you configure the Web server plug-in to use a port that has been opened.

Install IBM HTTP Server
Install Web server plug-ins
Edit Web server configuration files
Install Web server plug-in maintenance
Uninstall the Web server plug-ins for WAS
Allow Web servers to access the admin console
Web server plug-in properties
Web server plug-in configuration service property
Application Server property settings for a Web server plug-in
Web server plug-in configuration properties
Web server plug-in connections
Web server plug-in remote user information processing
Web server plug-ins
Check the IBM HTTP Server version
Set a global Web server plug-in configuration file
Gskit install images files
Plug-ins: Links
Web server plug-in tuning tips
Private headers
plugin-cfg.xml file
Set up a local Web server
Set up a remote Web server
Web server definition
Edit the Web server type
Web server collection

 

Related concepts

Transport chains

 

Related tasks

Set the Web server plug-in for SSL
Key store settings
Set transport chains
Change the HTTP plug-in configuration
Tuning Web servers