Business Process Choreographer scenarios for clustering

Describes different configuration options and considerations for Business Process Choreographer scenarios that use clusters.

The main advantages of using WebSphere® Process Server clusters for Business Process Choreographer instances are:

Configuration options

You can configure Business Process Choreographer in many different ways, so cluster configurations are usually very complex. Some of the main options to consider before you start creating application servers are outlined in the following descriptions:

Number of nodes in the WebSphere Process Server cell
One or more. All nodes are administered from a single deployment manager.
Number of nodes in each WebSphere Process Server cluster
One or more. Horizontal WebSphere clustering can increase service availability and the total workload capacity.
Number of application servers in each node
One or more. Vertical WebSphere Process Server clustering can increase resource utilization.
Database host
  • Remote, on a dedicated server
  • Local to one of the application servers in the cluster
It is recommended to host the database on a dedicated server, preferably one with a hot standby.
Application messaging queues
  • Local queues
  • Remote queues
Connection (default messaging)
When default messaging is used, you can configure the message engines in the same cluster or in a remote cluster. For Business Process Choreographer, you should use the same approach used for the other WebSphere Process Server components. For more details about possible scenarios, see Preparing a server or cluster to support service applications. The recommended configuration is to have the messaging engines run in a different cluster than the cluster in which Business Process Choreographer is installed. This is similar to the central queue manager configuration that can be used with WebSphere MQ.
Connection (WebSphere MQ queue managers)
  • One central (remote) queue manager hosting the queues for the application servers within one cluster. This configuration is generally recommended.
  • One local queue manager per application server. This provides no failover and no intraprocess workload sharing.
  • Two local queue managers per node, and WebSphere MQ clustering used to balance workload across several application servers.

    Workload distribution between different Business Process Choreographer instances requires that the queue managers that are used by the business process container of each application server are members of the same WebSphere MQ cluster. This configuration provides no failover and is not generally recommended.

WebSphere MQ is not recommended as JMS provider if a clustered scenario is used.
Database system
You can use any of the supported databases except Cloudscape.
Hot standby servers
You have the following options for hot standby servers:
  • None
  • For the database
  • For a central queue manager

Cluster types: This topic refers to two different types of cluster. A WebSphere cluster groups application servers together to share workload and increase service availability. A WebSphere MQ cluster, previously known as an MQSeries® cluster, groups together WebSphere MQ queue managers and can be used to achieve intraprocess workload balancing.

High availability

To achieve high availability of Business Process Choreographer services, consider the following items:

Vertical clustering to maximize resource utilization

To improve performance, you might have to create multiple application server instances on the same node so that Business Process Choreographer can use the available system resources.

Workload sharing

If you want different instances of Business Process Choreographer to share the same workloads, they must use one of the following queue manager configurations:
Central queue manager
A central queue manager hosts the queues that are needed by Business Process Choreographer. All Business Process Choreographer instances in the WebSphere cluster read from the same queues.
WebSphere MQ cluster
Each application server has two queue managers. One queue manager hosts local queues and is used for getting messages, the other queue manager hosts no queues and is used only for putting messages. All the queue managers of all the Business Process Choreographer instances in the WebSphere cluster are made members of a WebSphere MQ cluster.

The result of only putting to queue managers that host no queues is that the messages are distributed evenly across all the get queue managers in the cluster. After using the installation wizard to install and configure the business process container on the cluster, you must manually change the two connection factories per application server to point to the local get and put queue managers.

Business Process Choreographer database

Hosting the database on a dedicated server, preferably one with a hot standby is recommended. The database can be on a server that is outside the WebSphere cell, however the deployment manager must have access to it.

When planning the database, consider the following points:

WebSphere default messaging JMS provider

Business Process Choreographer can use WebSphere default messaging, which supports clustering, workload management, and failover.

Two topologies are supported:
  • The messaging resources are hosted by a different cluster than the applications. This is the recommended topology since it provides failover capabilities together with low administration overheads. This topology is similar to the central queue manager approach in the WebSphere MQ case.
  • The messaging resources and the applications are hosted by the same cluster. This topology is ideal for high performance, though it requires more administration effort, especially when changes are applied.

For more information about considerations that apply when default messaging is used, refer to Creating a clustered environment.

WebSphere MQ

Business Process Choreographer can use WebSphere MQ queues for receiving requests and sending replies. WebSphere MQ is not recommended as the JMS provider if a clustered scenario is used. If you use WebSphere MQ, you must still configure the default messaging for the Service Component Architecture (SCA), which Business Process Choreographer uses for inbound and outbound service invocation. Each application server that hosts Business Process Choreographer requires one of the following options:

Central queue manager

By using a central queue manager for all queues, administration becomes easier. One queue manager is used by all cloned containers for human tasks and business processes. However, using a central queue manager creates a single point of failure that needs to be hosted on a high availability system.

The following figure shows all the application servers in a WebSphere cluster using a single central queue manager on another server. Every application server shown with a business process container, can also have a human task container.

This figure shows all the application servers in the WebSphere cluster using a single central queue manager on another server.

Local queue manager without WebSphere MQ clustering

This example presents the standard, stand-alone Business Process Choreographer configuration. Each business process container has one local queue manager. This approach does not offer intraprocess workload sharing nor failover service availability.

WebSphere MQ clustering

This complex technique is not recommended. It supports intraprocess workload sharing for Business Process Choreographer services in a WebSphere cluster. The business processes in the cluster must all run on UNIX® only, or Windows® workstations only; a combination of UNIX and Windows servers does not work.

Each application server requires two local queue managers, one for putting and one for getting messages. All the queue managers become members of the same WebSphere MQ cluster. On Windows systems, all the queue managers must use the same binding protocol. On UNIX systems, the put and get queue managers must use different protocols. For example, you can modify the queue connection factories so that all the put queue managers use the binding protocol (interprocess communications) and all the get queue managers use the default, client (TCP/IP) protocol.

On Windows and UNIX systems, using the local bindings transport type is approximately 5% faster than using the client transport type, but has the effect that you must stop the entire application server to stop the local WebSphere MQ queue manager.

Each business process container in the WebSphere cluster must be customized to reflect its own queue managers.

It is recommended that more than one queue manager in the WebSphere MQ cluster is made a cluster repository.

The following figure shows how the queue managers that are used by the application servers are grouped together in a WebSphere MQ cluster. The WebSphere MQ cluster of queue managers is parallel to the WebSphere cluster of application servers. Requests are shared across the get queues in the cluster.

This figure illustrates how the queue managers used by the application servers are grouped together in a WebSphere MQ cluster that parallels the WebSphere cluster of application servers. Requests are shared across the get queues in the cluster.

How the WebSphere cluster is created

Several different sequences are available for you to follow when creating a cluster for Business Process Choreographer. The following sequence is recommended:

  1. Create a cluster using the defaultProcessServer template as the server template for the cluster members.
  2. Add members to the cluster.
  3. Enable the cluster for service applications.
  4. Configure Business Process Choreographer on the cluster.
  5. If you are using WebSphere MQ, and your WebSphere MQ configuration is a WebSphere MQ cluster of local queue managers, you must modify the connection factories. Because each queue manager has a different name, you must modify the connection factories in each of the cloned application servers to reflect its unique differences from the cluster-wide, standard Business Process Choreographer Install wizard configuration.
Related concepts
Business Process Choreographer and Network Deployment

Terms of use |

Last updated: Thu Apr 27 15:20:08 2006

(c) Copyright IBM Corporation 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)