The configuration of messaging engines in service integration
is very flexible. You can have a single messaging engine that does
not provide high availability or workload sharing. With a cluster
bus member, you can have a single highly available messaging engine.
Alternatively, with a cluster bus member, you can have multiple messaging
engines that share workload, or that share workload and also provide
high availability.
- A simple configuration has one messaging engine that runs on a
single server. This configuration is suitable for many purposes. However,
one messaging engine is a single point of failure and the configuration
does not provide high availability or workload sharing.
- A configuration for high availability has a single messaging engine
that runs on a server in a cluster, where that messaging engine can
fail over to one or more alternative servers in the cluster. By using
failover, you avoid a single point of failure and ensure that there
is always a messaging engine running in the cluster.
- A configuration for workload sharing or scalability has multiple
messaging engines running in a cluster, where each messaging engine
runs on one specific server in the cluster. The messaging load is
spread across multiple servers, and you can add new servers to the
cluster without affecting the existing messaging engines.
- A configuration for workload sharing with high availability has
multiple messaging engines running in a cluster, where each messaging
engine runs on a specific server in the cluster and can also can fail
over to one or more alternative servers in the cluster.
The configurations that are possible depend on the type of bus
member you create. If you create a server bus member, you can create
only a simple configuration. If you create a cluster bus member, you
can create any of the configurations in the previous list, depending
on the number of messaging engines in the cluster and the behavior
of those messaging engines. For more details, see the topic about
bus member types and their effect on high availability and workload
sharing.
For details and examples of the configurations you can create,
see the subtopics.
Configuring messaging engine behavior
To
configure messaging engine behavior, add a cluster to a bus and use
a predefined messaging engine policy. The predefined messaging engine
policies support frequently-used cluster configurations, such as workload
sharing and scalability, high availability, or a combination. You
use messaging engine policy assistance, which creates one or more
messaging engines and configures them to provide the required behavior.
You can also use messaging engine policy assistance to set up a custom
configuration. Messaging engine policy assistance guides you through
the configuration and many of the settings are created automatically.
For more information, see the topic about messaging engine policy
assistance.
It is possible to add a cluster to a bus and configure
the messaging engine behavior without using messaging engine policy
assistance. Use this procedure if you are already familiar with it.
Otherwise, use messaging engine policy assistance.
If you add
a cluster to a bus without using messaging engine policy assistance,
you configure a policy to control the availability behavior of the
messaging engine on that bus member.
- If you want high availability, you can use a cluster bus member
with one messaging engine and the default service integration policy, "Default
SIBus Policy", which allows the messaging engine to fail over to
any other application server in the cluster. Alternatively, you can
create a new policy and configure it to specify other availability
behavior, such as a preference for particular servers or the ability
to fail back.
- If you want workload sharing but not high availability, you can
use a cluster bus member with multiple messaging engines and create
a Static policy for each messaging engine. This might be useful for
scalable express messaging, in which there is no persistent state
associated with any one messaging engine, so no failover is required.
- If you want an external high availability framework to manage
the messaging engines, create a "No operation" policy for them.
For more information about policies and
configuration, see the topic about policies for service integration.
The
following table shows how you can achieve different configurations
without using messaging engine policy assistance.
Table 1. Service integration configurations. The
first column of the table lists the different configurations available.
The second column lists the types of bus members used in configuring
the messaging engines. The third column displays the number of messaging
engines used in the configuration. The fourth column lists the policy
types.Configuration |
Type of bus member |
Number of messaging engines |
Policy type |
Simple |
Server |
1 |
Default ("One of N") |
Simple |
Cluster |
1 |
Static |
High availability |
Cluster |
1 |
"One of N" or "No operation" |
Workload sharing without high availability |
Cluster |
more than 1 (typically, one messaging engine
for each server) |
Static |
High availability and workload sharing |
Cluster |
more than 1 (typically, one messaging engine
for each server) |
"One of N" or "No operation" |