The WebSphere Application Server works with a Web server
to route requests for dynamic content, such as servlets, from Web
applications. The Web servers are necessary for directing traffic
from browsers to the applications that run in WebSphere Application
Server. The Web server plug-in uses the XML configuration file to
determine whether a request is for the WebSphere Application Server.
Before you begin
- Install your Web server if it is not already installed.
If you want to use an IBM
HTTP Server for WebSphere Application Server, see Installing IBM HTTP Server. Otherwise,
see the installation information provided with your Web server.
If you want to use an IBM HTTP Server
for WebSphere Application Server, see Installing
IBM HTTP Server. Otherwise, see the installation information
that is provided with your Web server.
- Ensure that your Web server is configured to perform operations
required by Web applications, such as GET and POST. Typically, this
involves setting a directive in the Web server configuration file
(such as the httpd.conf file for an IBM HTTP Server). Refer to the
Web server documentation for instructions.
![[AIX HP-UX Linux Solaris Windows]](../../dist.gif)
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.
![[z/OS]](../../ngzos.gif)
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:
IMW0093E Method POST is disabled on this server.
Make sure the appropriate plug-in file has
been installed on your Web server and the configureWeb_server_name
script has been run to create and configure the Web server definition
for this Web server.
If you are using a distributed
platform Web server, use the Plug-in Installation wizard to install the appropriate
plug-in file to your Web server. Then run the configureWeb_server_name
script created by the wizard to create and configure the Web server
definition in the WebSphere configuration repository.
If you are using
the Version 5.3 HTTP Server that is provided with the z/OS base operating
system, see Installing and configuring the plug-in for V5.3 HTTP Server for z/OS.
If you are using a distributed
platform Web server with a WebSphere Application Server running on
a z/OS platform, FTP the plug-in to the Web server and use the Plug-in Installation
wizard to install the appropriate plug-in file to your Web
server.
About this task
![[z/OS]](../../ngzos.gif)
The following steps are performed during the plug-in
installation process. See the Plug-in Installation Roadmap for additional
information.
A node
is created. An unmanaged node is created when
the Web server is on a different computer from the Application Server.
An unmanaged node is a node that does not have a WebSphere node agent
running on it. Using unmanaged nodes, WebSphere Application Server
can represent servers that are not application servers within its
configuration topology. This representation enables connection information
between those servers and application servers to be maintained. Managing nodes describes
how to create a node.
- A Web server definition is created.
You can also use either
the administrative console or use the ConfigureWebServerDefintion.jacl
script to create a Web server definition. If you use the administrative
console:
- Select the node that was created in the preceding step, and in
the Server name field, enter the local name of the Web server for
which you are creating a Web server definition.
- Use the wizard to complete the Web server definition.
When creating a Web
server definition for local or remote z/OS Web server in a WebSphere
Application Server for z/OS cell, the process is slightly different.
Use the Customization Dialog job BBOWCFGW to create a Web server
definition in a stand-alone application server, and use Customization
Dialog job BBODCFGW to create a Web server definition in a Network
Deployment cell. Note that Web server definitions created in a stand-alone
application server with BBOWCFGW are not federated into a Network
Deployment cell as part of addNode.sh processing.
- An application or modules are mapped to a Web server. If an application
that you want 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.
- The master repository is updated and saved.
When you install a plug-in, the configuration
file for that plug-in is automatically created. You can change or
fine tune the default settings for the properties in this configuration
file. If change any of the settings, you must regenerate the file
before your 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
Procedure
- 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 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:
- 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.
Avoid trouble: 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.
gotcha
To
use the administrative console:
- Select Servers > Web Servers > webserver >
plug-in properties.
- 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. Note: It is recommended that you do not manually
update the plugin-cfg.xml file. Any manual updates
you make for a given Web server are overridden whenever the plugin-cfg.xml file
for that Web server is regenerated.
- Click OK.
- You might need to stop the application server and then start the application server again
to enable the Web server to locate the plugin-cfg.xml file.
Optional:
Edit the plug-in configuration file. You should not
have to edit the configuration file. If you do edit this file remember
that:
- The file is in ASCII format (ISO-98859-1).
![[z/OS]](../../ngzos.gif)
Issue
the following command to convert the file to EBCDIC format:
> iconv -f ISO8859-1 -t IBM-1047 plugin-cfg.xml.ASCII > plugin-cfg.xml.EBCDIC
Edit
the file, and then issue the following command to convert it back
to ASCII format:
> iconv -f IBM-1047 -t ISO8859-1 plugin-cfg.xml.EBCDIC > plugin-cfg.xml.ASCII
- Any manual changes you make to the file are overwritten the next
time the file is regenerated.
If you want to use Secure-socket layer
(SSL) with this configuration, use the plug-in's installation wizard
to install the appropriate GSKIT installation image file on your workstation.
See Configuring the Web server plug-in for Secure Sockets Layer for information
on how to configure GSKIT.
- If you want to enable the Application
Server to use the private headers that the Web server plug-in sends,
set the TrustedProxy HTTP transport custom property to true.
After
you enable the TrustedProxy custom property, this transport trusts
all inbound private headers it receives. Therefore, you must ensure
that all inbound paths to this transport are trusted.
Tune your Web server. See Tuning Web servers for
more information.
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. (It are located on the same
machine as an application server.)
- The Web server is a remote IBM HTTP Server Version 6.0 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 <WASROOT>/profiles/<profilename>/config/cells/../../nodes/../servers/<webservername> to
the Web server host location, which is <PluginInstallRoot>/config/<webservername>/.
Important: If you 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, if
you need to manually copy the plugin-cfg.xml from an AIX operating
system, you 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
you created the node for this Web server.
Results
The configuration is complete. To activate the configuration,
stop and restart the Web server. If you encounter problems restarting
your 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. You can then use the administrative 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 you 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
you are making a series of simultaneous changes, like installing numerous
applications, you 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 administrative
console click elect Servers > Application Servers > server_name >
Administration Services >Web server plug-in configuration service and
then unselect the Enable automated Web server configuration processing
option.
Tip: If your installation uses a firewall,
make sure you configure the Web server plug-in to use a port that
has been opened. (See your security administrator for information
on how to obtain an open port.)