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:
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:
To achieve high availability of Business Process Choreographer services, consider the following items:
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.
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.
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:
Business Process Choreographer Observer requires a database. It can use the same database as the Business Process Choreographer business process container, but in a production system, it is preferable for performance reasons, to have a separate database.
WebSphere Platform Messaging (WPM) is the default JMS provider. It supports clustering, workload management, and failover.
For more information about considerations that apply when WPM is used, refer to Creating a clustered environment.
Business Process Choreographer can be configured to use WebSphere MQ as the JMS provider for receiving requests and sending replies. However, 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.
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.
Several different sequences are available for you to follow when creating a cluster for Business Process Choreographer. If you have already configured a standalone server, perform Promoting a server that has Business Process Choreographer configured to a cluster, otherwise, the following sequence is recommended:
Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)