Configuring BPEL Service Engine Clustering and Failover

The BPEL Service Engine supports clustering and failover in order to optimize and ensure business process throughput on highly scalable systems. Clustering distributes processing over multiple BPEL server engines via multiple BPEL service units. Failover prevents processing from being interrupted by picking up business processes from any failed systems and processing them to completion.

This section contains the following topics for configuring BPEL Service Engine clustering and failover:

• Clustering

• Failover

• Clustering/Failover Considerations

Clustering

When a business process needs to be scaled to meet heavier processing needs, you can distribute it across multiple service engines to increase throughput. The BPEL Service Engine's clustering algorithm automatically distributes processing across multiple engines. To configure clustering, deploy your composite applications across multiple BPEL Service Engines running on multiple processors or systems.

For details about setting up a cluster of application servers with BPEL Service Engines, see the documentation for Sun Java System Application Server.

Failover

When your business process is configured for clustering, the BPEL Service Engine's failover capabilities ensure throughput of running business process instances. When business process instances encounter an engine failure, any suspended instances are picked up by all available BPEL Service Engines.

To configure failover, in the BPEL Service Engine properties, set the EngineExpiryInterval property so that it registers itself as alive frequently enough to meet the demands of your system. Optimizing this property setting might require some testing. The default setting is 15.

Clustering/Failover Considerations

In order to configure a cluster of BPEL Service Engines, you must adhere to the following guidelines.

• Persistence must be enabled for both clustering and failover.

• To run persistence, all BPEL Service Engines must be restarted.

• Service assemblies must be deployed manually across all clustered JBI environments.

• Clustering/failover is implemented consistently for the specific protocol and binding components involved in a given business process.

• Only a single database can be used for all BPEL Service Engines when implementing clustering/failover.

• The database must be highly available; should the database fail, clustering/failover will fail.

• When a BPEL Service Engine fails, a single BPEL Service Engine picks up those instances without distributing them across the cluster. Consequently, a large number of failed over instances can overload an entire cluster, one service engine at a time—a sort of domino effect.

• All BPEL Service Engines in a cluster must reside in the same time zone.

• The following inbound message activities (within flows) are not supported by failover: Receive, On-Message, On-Event.