| Installing Upgrading Designing Configuring Deploying Monitoring Administering Troubleshooting Reference JBI Components | |
| Close Print View | |
| Using JBI Components: Clustering/Failover Considerations |
|
| Installing Upgrading Designing Configuring Deploying Monitoring Administering Troubleshooting Reference JBI Components | |
| Close Print View | |
| Using JBI Components: Clustering/Failover Considerations |
|
Configuring WSDL Extensibility Elements
HTTP WSDL Extensibility Elements
SOAP WSDL Extensibility Elements
Configuring JBI Runtime Properties
Configuring the BPEL Service Engine Runtime Properties
Starting the Application Server
Viewing Service Engine Properties
HTTP Binding Component Runtime Properties
Configuring BPEL Service Engine Clustering and Failover
Configuring the HTTP Binding Component for Clustering
Administering JBI Components for Java CAPS
Using the Java EE Service Engine in a Project
Using the Java EE Service Engine to Create a Composite Application
Using the BPEL Designer and Service Engine
Using the HTTP Binding Component
Processing an Order in a Purchase Order System
XSLT Designer: Simple Transformation Tutorial
Using the File Binding Component
Using the File Binding Component in a Project
Using the JMS Binding Component
Understanding the FTP Binding Component
Using the FTP Binding Component in a Project
Understanding the LDAP Binding Component
Using the LDAP Binding Component in a Project
Using the JAXB Wizard and Code-Seeder Pallete
Understanding the Database Binding Component
Using the Database Binding Component
Migrating From eTL to Sun Data Integrator
Designing Intelligent Event Processor (IEP) Projects
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.
|