Web servers

Overview

By default portal uses the internal HTTP transport within IBM WAS to handle requests. We can send traffic to a web server that routes requests to this internal HTTP transport, allowing portal access from the web server. Web servers typically sit in a DMZ outside a firewall to protect portal ports.

To enable communication between the web server and WAS, we use a web server plug-in that determines whether a request is handled by the web server or by the application server. If the latter, the plug-in routes the request to one of the appservers in the cluster. Routing is based on settings in plugin-cfg.xml.

In the WAS admin console, the web server is represented as a specific server type. We can use the admin console to set configuration properties used in plugin-cfg.xml.

To use features such as the portal Universal Toolbar, permit write and delete operations on the web server so that the HTTP operations POST, PUT, and DELETE are enabled.

Access portal through another HTTP port

By default WebSphere Portal is configured to be accessed through the internal HTTP port in WAS.

http://hostname.example.com:10039/wps/portal

The default host name and port used by WebSphere Portal are specified by the WpsHostName and WpsHostPort properties in wkplc.properties. We can change the port number after configuring the base portal.

After configuring WebSphere Portal to use an external web server, access the portal with the web server host name and port (for example, 80). For stand-alone servers or vertical cluster members, you will be unable to access the portal using the WebSphere Portal host name and port (for example, 10039).

To access WebSphere Portal using a host name and port different from the web server, add the required virtual host definition.

1. Log on to the dmgr console and go to...
   Environment | Virtual Hosts | portal vhost | Host Aliases

2. Verify whether there is a host name and port entry corresponding to the values used to access WebSphere Portal.

   If the entry does not exist, select New, and enter the information for the host name and port to use. The host alias examples are:

   • *:10039
   • *:9081

3. Save the changes.

4. Regenerate the web server plug-in.

5. If we are using a remote web server, copy the updated plugin-cfg.xml file to the web server in the web server home directory.

6. If we are running a system under stress and are expecting requests to take longer than the ServerIOTimeout default value, you should increase this value to avoid requests being sent twice.

7. Recycle the web server, and the portal.

8. In a clustered environment, resynchronize the nodes and restart the cluster.

Cluster considerations for web servers

When using a web server in a clustered environment with WebSphere Portal, the following considerations apply:

• If you run the configureweb_server script on the dmgr system, we must synchronize and restart the cluster to ensure proper communication between the web server and the cluster members.

• If a stand-alone node was previously configured for a web server and then federated into a cell managed by the dmgr, the web server definitions on that node are removed. To use the web server, re-create the definition in the dmgr console after you federate the node.

One IHS instance for multiple cells

1. Create 2 differently named web server definitions, each with their own plugin directory and plugin-cfg.xml
2. Merge the plugin-cfg.xml files
3. Create a new directory for the merged plugin-cfg.xml

Parent: Plan
IBM i users