Policies for service integration

Policies for service integration

Each messaging engine on a service integration bus belongs to one high availability group (HAGroup). The members of each HAGroup are controlled by a policy assigned to the group at run time. This core group policy determines the availability characteristics of the messaging engine in the HAGroup.
If we add a server to a service integration bus, a messaging engine that uses the default service integration policy, a "One of N" policy, is created automatically. The behavior of the messaging engine is to run only on that server, because there is only one server available to it. It is possible to configure a non-default policy for the messaging engine, but it would not affect the behavior of the messaging engine.
If we add a server cluster to a bus, we can control which servers the messaging engine can run on, and the behavior of the messaging engine if a server is unavailable. We can also deploy additional messaging engines to the cluster. For example, we can configure the cluster to provide high availability, scalability or workload sharing (increasing performance by increasing the resources that provide the service), or a combination of these factors.
When we add a cluster to a bus, we can configure the messaging engine behavior by using messaging engine policy assistance. There are predefined messaging engine policies that support frequently-used cluster configurations, and an option to set up a custom configuration while still using messaging engine policy assistance. The advantage of messaging engine policy assistance is that you are guided through the configuration and many of the settings are created automatically. For more information, see the related topics.
The remainder of this topic describes the configuration of messaging engine behavior without using messaging engine policy assistance. Use these settings if you are already familiar with this procedure. Otherwise, use messaging engine policy assistance.
To configure the messaging engine behavior, you configure the core group policy for the HAGroup of the messaging engine. We can configure the policy to control whether the messaging engine has a preference for a particular server, or set of servers, and whether the messaging engine is restricted to the set of preferred servers. We can control whether a messaging engine can fail back to a more preferred server after failover. We can also modify the policy to change the monitoring interval for the messaging engine.
The following table shows the types of core group policy we can use for messaging engines, and how each type affects the behavior of a messaging engine that belongs to a cluster bus member.

used for messaging engines. The second column explains how the policy
Policy type Behavior
Static - with one server in the static group servers list The messaging engine is restricted to a particular server. The messaging engine can run only on the server to which it is restricted, and cannot fail over to any other server in the cluster. For multiple messaging engines, this can be a useful configuration for workload sharing, where failover is not wanted.
One of N - with no preferred servers The messaging engine runs on the first available server and can fail over to any of the other servers in the cluster. It has no preference for any particular server.
The "Default SIBus Policy" provides this behavior.
One of N - with preferred servers The messaging engine runs on the first server in the preferred servers list that is available when the messaging engine starts. It can fail over to the first server in the preferred servers list that is available at the time of failover. The earlier a server is in the preferred servers list, the stronger the preference for that server. If no preferred servers are available, it can fail over to any other server in the cluster. After the messaging engine fails over, it does not move, even if a more preferred server becomes available again.
One of N - with preferred servers and the Fail back setting The messaging engine always runs on the most preferred server that is available. It runs on the first server in the preferred servers list that is available when the messaging engine starts. It can fail over to the first server in the preferred servers list that is available at the time of failover. The earlier a server is in the preferred servers list, the stronger the preference for that server. If no preferred servers are available, it can fail over to any other server in the cluster. After the messaging engine fails over, if a more preferred server becomes available again, the messaging engine moves automatically to that server.
One of N - with preferred servers and the Preferred servers only setting The messaging engine runs on only servers in the list of preferred servers. It runs on the first server in the preferred servers list that is available when the messaging engine starts. It can fail over to the first server in the preferred servers list that is available at the time of failover. The earlier a server is in the preferred servers list, the stronger the preference for that server. If no preferred servers are available, it cannot fail over to any other server in the cluster. If the Fail back setting is selected, after the messaging engine fails over, if a more preferred server becomes available again, the messaging engine moves automatically to that server.
No operation The messaging engine is managed by an external high availability framework and can fail over to any of the other servers in the external high availability cluster. If a you require server affinity, configure this as a preference in the high availability cluster configuration. The configuration details depend on the choice of high availability framework.
This policy is useful where a high availability clustered database is being used for the data store for the messaging engine; we can put the messaging engine under the control of the same high availability cluster that is managing the database. This policy is also useful where a messaging engine is connected to a WebSphere MQ queue manager; the messaging engine can fail over if it is using a high availability clustered IP address for its inbound channel chains. For more information, see External high availability frameworks and service integration.

The policy is assigned to the appropriate HAGroup at run time using the match criteria configured for the policy.

Default service integration policy

The most general policy for service integration is the default included with the product, the "Default SIBus Policy". This is a "One of N" policy with no preferred servers, that is, the messaging engine starts on the first available server in the cluster and can fail over to any other application server in the cluster. There is no automatic fail back and there is a monitoring interval of 120 seconds. The policy has a single match criterion that matches any service integration messaging engine, so the policy applies to any messaging engine, unless the messaging engine is in an HAGroup with a stronger match to a different policy.

Subtopics

Messaging engine policy assistance
Messaging engine policy assistance provides guidance about creating and configuring messaging engines in a cluster to provide the behavior you require. Messaging engine policy assistance also automatically creates the associated core group policies and other settings. Messaging engine policy assistance is available when we add a cluster as a bus member, or when you administer a messaging engine in a cluster.

Match criteria for service integration
Match criteria are a set of one or more name-value pairs in a policy definition. Use match criteria to make a policy bind to a particular messaging engine, or a set of messaging engines. To do this, you configure the match criteria of the policy to match the properties of the high availability group HAGroupwe want the policy to manage, that is, the HAGroup containing the messaging engine.

Related concepts

Configuration for high availability
Configuration for workload sharing or scalability
Configuration for workload sharing with high availability
Data store high availability

Related tasks

Configure a core group policy for messaging engines
Create a policy for messaging engines
Add a cluster as a member of a bus
Add a cluster to a bus without using messaging engine policy assistance

Policy type	Behavior
Static - with one server in the static group servers list	The messaging engine is restricted to a particular server. The messaging engine can run only on the server to which it is restricted, and cannot fail over to any other server in the cluster. For multiple messaging engines, this can be a useful configuration for workload sharing, where failover is not wanted.
One of N - with no preferred servers	The messaging engine runs on the first available server and can fail over to any of the other servers in the cluster. It has no preference for any particular server. The "Default SIBus Policy" provides this behavior.
One of N - with preferred servers	The messaging engine runs on the first server in the preferred servers list that is available when the messaging engine starts. It can fail over to the first server in the preferred servers list that is available at the time of failover. The earlier a server is in the preferred servers list, the stronger the preference for that server. If no preferred servers are available, it can fail over to any other server in the cluster. After the messaging engine fails over, it does not move, even if a more preferred server becomes available again.
One of N - with preferred servers and the Fail back setting	The messaging engine always runs on the most preferred server that is available. It runs on the first server in the preferred servers list that is available when the messaging engine starts. It can fail over to the first server in the preferred servers list that is available at the time of failover. The earlier a server is in the preferred servers list, the stronger the preference for that server. If no preferred servers are available, it can fail over to any other server in the cluster. After the messaging engine fails over, if a more preferred server becomes available again, the messaging engine moves automatically to that server.
One of N - with preferred servers and the Preferred servers only setting	The messaging engine runs on only servers in the list of preferred servers. It runs on the first server in the preferred servers list that is available when the messaging engine starts. It can fail over to the first server in the preferred servers list that is available at the time of failover. The earlier a server is in the preferred servers list, the stronger the preference for that server. If no preferred servers are available, it cannot fail over to any other server in the cluster. If the Fail back setting is selected, after the messaging engine fails over, if a more preferred server becomes available again, the messaging engine moves automatically to that server.
No operation	The messaging engine is managed by an external high availability framework and can fail over to any of the other servers in the external high availability cluster. If a you require server affinity, configure this as a preference in the high availability cluster configuration. The configuration details depend on the choice of high availability framework. This policy is useful where a high availability clustered database is being used for the data store for the messaging engine; we can put the messaging engine under the control of the same high availability cluster that is managing the database. This policy is also useful where a messaging engine is connected to a WebSphere MQ queue manager; the messaging engine can fail over if it is using a high availability clustered IP address for its inbound channel chains. For more information, see External high availability frameworks and service integration.