Web servers

By default WebSphere Portal uses the internal HTTP transport within IBM WAS to handle requests. However, because WAS also supports the use of an external web server, you can access WebSphere Portal from web server. You can use a local web server on the same machine as WebSphere Portal or you can use a remote web server on a different machine. A remote web server is typical for a production environment or other high-traffic configuration and is also typically placed in demilitarized zones (DMZ) outside a firewall to protect portal ports.

To enable communication between the web server and WAS, a web server plug-in is required. The web server plug-in determines whether a request is handled by the web server or by the application server. The plug-in can be installed into a web server that is located either on the same machine as WAS or on a separate machine. The web server plug-in uses an XML configuration file (plugin-cfg.xml) that contains settings that describe how to handle and pass on requests to the WAS made accessible through the plug-in.

In the WAS administrative console, the web server is represented as a specific server type, and you can view or modify all of the configuration properties used in the plugin-cfg.xml file for the web server plug-in from the administrative console. For some portal functions to work you need to verify write and delete operations are permitted by the web server so that the HTTP operations POST, PUT, and DELETE are enabled. For example, this is required for mashup integration.
i users: For detailed information on using an external web server with i system, see Select a web server topology diagram and road map, in addition to the steps listed on this page.

Access WebSphere Portal through another HTTP port in a stand-alone or clustered environment

By default WebSphere Portal is configured to be accessed through the internal HTTP port in WAS. For example, http://hostname.example.com:10039/wps/portal, where hostname.example.com is the fully qualified host name of the machine where WebSphere Portal is running and 10039 is the default transport port that is created by WAS; the port number may be different for environment. The default host name and port used by WebSphere Portal are specified by the WpsHostName and WpsHostPort properties in wkplc.properties.

After configuring WebSphere Portal to use an external web server, you will 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), unless there is a corresponding virtual host definition for port 10039 in the WAS configuration.

Many of the WebSphere Portal configuration tasks rely on the WpsHostName and WpsHostPort properties from wkplc.properties. You must ensure that WebSphere Portal can be accessed using the host name and port specified by these property values. You can do this in one of two ways:

• Modify the WpsHostName and WpsHostPort property values to specify the web server host name and port.

• Add the appropriate virtual host definition, as described below.

To access WebSphere Portal using a host name and port different from 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 dmgr 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 WebSphere Portal application.

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

4. Save 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. If you 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.

8. Recycle web server, and the portal.

9. 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_name script on the dmgr system, synchronize and restart the cluster to ensure proper communication between the web server and the cluster members.

• If a stand-alone WebSphere Portal 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 administration console after you federate the node.

Parent

Plan to install WebSphere Portal

 

+

Search Tips   |   Advanced Search