Web servers and WebSphere Portal

 

+
Search Tips   |   Advanced Search

 

 

Overview

By default WebSphere Portal uses the internal HTTP transport within WebSphere Application Server (WAS) to handle requests. We can optionally configure access to WebSphere Portal from a Web server.

We can use a local Web server on the same machine as portal, or we can use a remote Web server on a different machine. A remote Web server is typical for production and high-traffic environments.

To enable communication between the Web server and portal, a Web server plug-in is configured, which determines whether a request is handled by the Web server or by WebSphere Application Server. The plugin-cfg.xml file contains the settings that describe how to handle requests. We can modify plugin-cfg.xml properties by selecting the relevant Web server from the administrative console.

Portal supports the following Web servers:

  • Apache Server
  • IBM HTTP Server
  • Microsoft Internet Information Server
  • IBM Lotus Domino
  • Sun Java System Web Server

 

Access portal through another HTTP port

By default portal is configured to be accessed through the internal HTTP port in WAS. For example, a typical installation might use port 10038, and the portal would be accessed with a URL like...

http://host:10038/wps/portal

The default host name and port used by portal are specified by the WpsHostName and WpsHostPort properties in the wpconfig.properties file.

After configuring portal to use an external Web server, you will access the portal with the Web server host name and port (80).

You will be unable to access the portal using the portal host name and port (10038), unless there is a corresponding virtual host definition for port 10038 in the WAS configuration. Many of the portal configuration tasks rely on the WpsHostName and WpsHostPort properties from the wpconfig.properties file. Ensure that portal can be accessed using the host name and port specified by these property values. We can do this in one of two ways:

To access portal using a host name and port different from the Web server, add the required virtual host definition using the WAS administrative console. If you are using the Web server in a clustered environment, use the deployment manager administrative console to perform these steps.

  1. Select Environment > Virtual Hosts.

  2. Select the default_host entry or the entry for the virtual host that is being used to access the portal application.

  3. Select Host Aliases, and verify whether there is a host name and port entry corresponding to the values used to access portal (for example, *:10038). If the entry does not exist, select New, and enter the information for the host name and port you want to use.

  4. Save the changes.

  5. Regenerate the Web server plug-in.

  6. If you are using a remote Web server, copy the updated plugin-cfg.xml file to the Web server machine.

  7. Recycle the Web server, and the portal.

 

Cluster considerations for Web servers

When using a Web server in a clustered environment with portal, the following considerations apply:

  • If you run the configureweb_servername script on the deployment manager system, synchronize and restart the cluster to ensure proper communication between the Web server and the cluster members.

    Before using the configureweb_servername script during Web server configuration in a managed cell, change the timeout request period for the SOAP client on the deployment manager machine. The default, in seconds, is 180. Edit...

    was_profile_root/properties/soap.client.props

    ...and change the line to... 

    com.ibm.SOAP.requestTimeout=6000

  • When federating a portal node to the deployment manager system, any Web server definition previously existing on that node is deleted. To use the Web server with the cluster, recreate the Web server definition in the deployment manager administration console after you federate the node.

 

Related information

 

Parent topic:

Configuring Web servers