Bus member types and their effect on high availability and workload sharing

Adding a server to a bus

When you add a server to a service integration bus, a messaging engine is created automatically. This single messaging engine cannot participate in workload sharing with other messaging engines; it can only do that in a cluster. The messaging engine also cannot be highly available, because there are no other servers in which it can run.

Adding a cluster to a bus

A cluster deployment can provide scalability and workload sharing, or high availability, or a combination of these aspects. This depends on the number of messaging engines in the cluster and the behavior of those messaging engines, such as whether the messaging engines can fail over to another server, or fail back when a server becomes available again.

You can also use messaging engine policy assistance to create a custom messaging engine policy. You can create any number of messaging engines for the cluster, and configure the messaging engines as you require. The associated core group policies and settings for the messaging engines are created automatically.

If you do not use messaging engine policy assistance, when you add a server cluster to a service integration bus, a single messaging engine is created automatically. This messaging engine uses the default SIBus core group policy that already exists in WebSphere® Application Server. The policy allows the messaging engine to fail over to any server in the cluster. You can then add further messaging engines if required. The cluster deployment depends on the number of messaging engines in the cluster and the policy bound to the high availability group (HAGroup) of each messaging engine.

If there is only one messaging engine in the cluster and you deploy a destination to that cluster, the destination is localized by that messaging engine. All messaging workload for that destination is handled by that messaging engine; the messaging workload cannot be shared. The availability characteristics of the destination are the same as the availability characteristics of the messaging engine.

You can benefit from increased scalability by introducing additional messaging engines to the cluster. When you deploy a destination to the cluster, it is localized by all the messaging engines in the cluster and the destination becomes partitioned across the messaging engines. The messaging engines can share all traffic passing through the destination, reducing the impact of one messaging engine failing. The availability characteristics of each destination partition are the same as the availability characteristics of the messaging engine the partition is localized by.

If you do not use messaging engine policy assistance, you control the availability behavior of each messaging engine by modifying the core group policy that the HAManager applies to the HAGroup of the messaging engine.

The simplest way to create and configure messaging engines in a cluster is to add a cluster to a bus and use messaging engine policy assistance with one of the predefined messaging engine policy types. If you are familiar with creating messaging engines and configuring messaging engine behavior, you can use messaging engine policy assistance and the custom messaging engine policy type. To add a cluster to a bus without using messaging engine policy assistance, you should be familiar with all the creation and configuration steps involved, for example, creating a messaging engine, configuring core group policies and using match criteria.