Understand configuration options for process integration

 

+

Search Tips   |   Advanced Search

 

You can configure the WebSphere Portal and the WebSphere Process Server server in different cells of IBM WAS.

Alternatively, you can configure stand-alone or clustered portal servers and process servers in the same cell of IBM WAS.

WP and WPS managed in different WAS cells

1. A stand-alone portal server configured to use a stand-alone process server

2. A stand-alone portal server configured to use a process server cluster

3. A portal server cluster configured to use a stand-alone process server

4. A portal server cluster configured to use a process server cluster

WP and WPS managed in the same WAS cell

1. A single, federated portal server configured to use a single, federated process server

2. A single, federated portal server configured to use a process server cluster

3. A portal server cluster configured to use a single, federated process server

4. A portal server cluster configured to use a process server cluster

You can only install WP into a Base Application Server profile.

Installing WPS on top of WP supports only the WPS Client functionality.

The WPS Client functionality and the complete WPS server are mutually exclusive. Therefore, you enable business process integration by installing the WPS Client and connecting to a remote WPS server.

Deployment choices

The decision to use a cluster is driven mainly by the following factors:

• The need to support advanced availability

• The planned load of the portal, which may exceed the capabilities of a single server.

A single-cell deployment is simpler than a cross-cell deployment because the portal and process server cooperate through the common name space (JNDI) of the single-cell.

A cross-cell deployment requires that LTPA single sign-on SSO be enabled in WAS for the processing of CSIv2. However, single-cell deployment increases the dependencies between the products.

For example, if one of the products requires a maintenance upgrade, the other product is likely to require an upgrade as well. It is important to consider the DMGR because it coordinates both products.

In additions to these technical factors, various non-technical factors, such as the availability of skilled administrators, will influence your decision.

Consider the following factors when choosing a single-cell setup or a cross-cell setup for business process integration:

• The need for manual remote artifact loading

  The remote artifact loader allows the generic portlets to retrieve the process artifacts from the process definition, namely, the XML definitions of the input and output messages required for task processing. In a cross-cell setup, manually deploy the process artifacts to the WP cell. If you intend to use the generic portlets and want to manage a simple deployment, choose single-cell setup.

• One type of server is already in operation

  If either WP or WPS is already in operation when the complementary servers are added, it is normally a good practice to use two cells because this will minimize the influence of building up the new servers in the existing environment.

• Availability and skills of the required staff

  A cross-cell setup requires an additional management console and creates slightly more complexity for the administrator. If your enterprise is small, the availability of a skilled administrator to manage the integrated deployment might be a factor in choosing a single-cell setup over a cross-cell setup.

The illustration shows the various ways in which business process integration can be configured in combination with clustering. The orange arrows indicate the process of scaling an existing portal installation from a single server into a cluster, while the green arrows indicate the configuration step for business process integration. These two actions can be performed in any order. To build up a clustered portal server that is connected to a process server, choose the sequence that meets your needs:

• Cluster first.

  This sequence is most often used when WP is already installed and running, before the decision to use WPS is made, because availability or the system load required clustering while process server was not available at that time. Once the new process server is available, install the WPS Client on top of the portal to enable portal-to-process server communication:

  1. Install WP as a stand-alone server.

  2. Cluster the portal.

  3. Add the WPS Client on top of each portal node.

• Connect first.

  This sequence is preferred when WPS is already installed and running, before WP is installed. This approach allows for early prototypes and testing. After prototyping and testing has been successfully completed, the portal will be clustered to carry the load of a production environment.

  1. Install WP as a stand-alone server.

  2. Add the WPS Client on top of each portal node.

  3. Cluster the portal.

Parent topic:

Plan integration with WPS

Previous topic:

Prerequisites for setting up process portals

Next topic:

Plan to use process portals

Related concepts

Plan for multiple clusters