Deployment Options for the Reference Configuration

Depending on your quality-of-service requirements, certain parts of the reference configuration can be changed or omitted. This section briefly discusses these options which include the following:

• Omitting Portlet Session Failover

• Omitting Access Manager Session Failover

• Omitting Secure Remote Access

• Using a Different Web Container

Omitting Portlet Session Failover

The reference configuration deployment architecture supports portlet session failover, as described in Session State Availability. It does this by deploying Portal Server in an Application Server cluster that uses High Availability Session Store (HADB) to store and replicate portlet session state.

If your business solution does not involve portlets that store session state, then portlet session failover might not be a requirement for your portal service deployment. If that is the case, you do not need to deploy Portal Server in an Application Server cluster. However, if you have other reasons beside portlet session failover for deploying Portal Server in an Application Server cluster, you can use this guide, but omit the section on implementing portlet session failover.

Portal Server can be deployed in a web container provided by nonclustered Application Server instances. This approach would substantially change the implementation of the portal service module described in Chapter 6, Implementation Module 3: Portal Server With Portlet Session Failover on Application Server Cluster.

At the present time, however, an alternative implementation for Portal Server on Application Server (without portlet session failover) has not yet been documented.

Omitting Access Manager Session Failover

The reference configuration deployment architecture supports Access Manager session failover, as described in Session State Availability. It does so by configuring Access Manager to use Message Queue and a highly available database to store and replicate Access Manager session state.

If your business solution permits users to log in again to reestablish a session after a service failover, then Access Manager session failover is not a requirement for your portal service deployment. If that is the case, you do not need to configure Access Manager for Access Manager session failover, and Message Queue would not be included as a component in the Access Manager service module. This approach would change the implementation of the Access Manager service module by not requiring the procedures in Implementing Session Failover for Access Manager .

Omitting Secure Remote Access

The reference configuration deployment architecture supports secure access to portal services, applications, and other content on an internal intranet to users on the public Internet. This feature is supported by the SRA Gateway module, as described in Secure Remote Access.

If your business solution does not require secure access to portal services, applications, and other content over the public Internet, then secure remote access is not a security requirement for your portal service deployment. For example, you might be using one of the following alternate scenarios to access the portal service:

• An Internet-accessible portal service that communicates over SSL and is deployed in a DMZ

• A portal service that is located behind an organization's firewalls and accessed only locally or through VPN connections

• An internal portal service that is only accessed on a corporate network

In these scenarios, you can omit Chapter 7, Implementation Module 4: Secure Remote Access Gateway from the reference configuration architecture. However, depending on the scenario, you might need to modify the network topology of the reference configuration accordingly.

Using a Different Web Container

Two of the components in the reference configuration, Portal Server and Access Manager, run in web containers. The Java ES component set gives you the choice of using either Sun Java System Web Server or Sun Java System Application Server for a web container.

You need to consider both technical and non-technical factors when you choose a web container.

The following technical factors address the abilities of the different containers to run different types of portal content:

• Portlets and providers are Portal Server mechanisms for building presentation channels that can aggregate content from other applications. If your plans include developing portlets or providers that use Java EE APIs that are not supported by Web Server, such as the Enterprise JavaBeans (EJB) or Java Connector Architecture (JCA) interfaces, then you must use Application Server as your web container.

• Web Server 7.0 supports a lightweight mechanism for HTTP session failover. This mechanism can be eventually used to enable portlet session failover in the same way that HADB and Application Server clusters enable such failover. However, this new feature of Web Server and its impact on the reliability, security, and performance has not yet been fully analyzed.

• A reference configuration guide that documents a portal service deployment on Web Server does not yet exist.

If none of the technical factors are decisive for your organization, the following non-technical considerations could prove decisive:

• Does your organization have existing standards for a web container? If so, you are likely to use that web container to implement the portal service reference configuration.

• What does a price-to-performance comparison of the web containers reveal? Your organization might choose a web container based on the cost of the licenses that are needed to support the organization's user base. Your organization might have a volume discount agreement with a vendor that affects this decision.

• Your organization might have support agreements with a web container vendor.

• You might want to choose the same web container for all elements of your portal service even if you are not colocating Portal Server instances and portal channel applications. For example, if you have portal channels that are running in Application Server, you might want to deploy Portal Server in Application Server for the sake of consistency.

• If there is no compelling reason to use Application Server in your portal, Web Server can be easier to administer.