Web servers
Overview
By default WebSphere Portal uses the internal HTTP transport within IBM WAS to handle requests.
WAS supports the use of a local or remote Web server. A remote Web server is typical for a production environment or other high-traffic configuration and is typically placed in the DMZ outside a firewall to protect portal ports.
A Web server plug-in is required for communication between the Web server and WAS. The Web server plug-in determines whether a request is handled by the Web server or by the appserver. The Web server plug-in configuration file is plugin-cfg.xml. In the WAS 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 make sure that 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.
Access WebSphere Portal through another HTTP port
By default WebSphere Portal is configured to be accessed through the internal HTTP port in WAS. For example...
http://hostname.example.com:10040/wps/portal
...where hostname.example.com is the fully qualified host name of the machine where WebSphere Portal is running and 10040 is the default transport port that is created by WAS; the port number may be different for your 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, access the portal with the Web server host name and port (for example, 80). In addition, you will be unable to access the portal using the WebSphere Portal host name and port (for example, 10040), unless there is a corresponding virtual host definition for port 10040 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 your Web server, add the required virtual host definition using the administrative console. For the Web server in a clustered environment, use the deployment manager administrative console to perform these steps.
- Select Environment > Virtual Hosts.
- Select the default_host entry or the entry for the virtual host that is being used to access the WebSphere Portal application.
- 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, *:10040).
If the entry does not exist, select New, and enter the information for the host name and port you want to use.
- Save changes.
- Regenerate the Web server plug-in.
- For a remote Web server, copy the updated plugin-cfg.xml file to the Web server machine.
- For systems under stress, increase ServerIOTimeout to avoid requests being sent twice.
- Recycle your Web server, and the portal.
Cluster considerations for Web servers
When using a Web server in a clustered environment with WebSphere Portal...
- If you run the configureweb_server_name script on the deployment manager system, synchronize and restart the cluster to ensure proper communication between the Web server and the cluster members.
- When federating a WebSphere Portal node into a cell managed by the deployment manager, 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.
Parent topic:
Plan for WebSphere Portal