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.
Important: If you want to run the Web server
provided with i5/OS, it is already installed on the machine under
product 5722DG1. The i5/OS Web server is known as "IBM HTTP Server
for i5/OS." The "IBM HTTP Server for WebSphere Application Server"
is different than the IBM HTTP Server for i5/OS. "IBM HTTP Server
for WebSphere Application Server" is provided with the WebSphere Application
Server product and does not run on i5/OS systems.
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 IBM HTTP Server
for z/OS, which is powered by Apache, that is provided with WebSphere
Application Server, see Installing and configuring the plug-in for IBM HTTP Server for WebSphere Application Server on z/OS.
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. See the WebSphere Application Server
Network Deployment version of the Information Center for a description
of how to use this wizard.
About this task
The appropriate plug-in file is installed.
In addition, an http profile is created (/QIBM/UserData/WebSphere/Plugins/V61/webserver/profiles/http). The http profile can be used to facilitate
the creation of Web server definitions. Refer to Selecting a Web server topology diagram and roadmap for instructions
on how to configure IBM HTTP Server for i5/OS to communicate with
a WebSphere Application Server.
![[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 ConfigureWebServerDefinition.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.
Propagate the plug-in configuration.
To propagate the plug-in configuration from the administrative
console, click Servers > Web servers >webserver. Select
the webserver name and then click Propagate Plug-in. Another method to propagate the plug-in configuration is to run the GenPluginCfg command.
You do not need to propagate
the plug-in configuration if the Web server is on the same machine
as the associated stand-alone WebSphere Application Server. If the
propagation of the plug-in configuration fails due to an unknown cause,
you must manually copy the plugin-cfg.xml file
to the remote Web server's installation location.
Important: If you use the FTP function to perform the copy,
and the configuration reload fails, check the file authorities on
the
plugin-cfg.xml file and make sure that users
QTMHHTTP, QNOTES and QEJBSVR have RWX authority. If the authorities
are not correct, the Web server will not be able to access the new
version of the file, which causes the configuration reload to fail.
To check the authorities, run the following i5/OS command:
wrklnk 'plug_in_folder_location/plugin-cfg.xml'
Then
select option 9 to view the authorities that are assigned to the users
(QTMHHTTP, QNOTES and QEJBSVR).
If the authorities are incorrect,
issue the following i5/OS command to change the file authorities to
the appropriate settings: CHGAUT USER(QEJBSVR QTMHHTTP QNOTES) OBJ('plug_in_folder_location/plugin-cfg.xml') DTAAUT(*RWX)
The plug_in_folder_location is the location you specified
when you FTP'ed the plugin-cfg.xml file.
- 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.
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.)