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 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.
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.)