Choose messaging providers for a mixed environment

Choose messaging providers for a mixed environment

If the existing or planned messaging environment involves both WebSphere MQ and WebSphere Application Server systems, choose between the default messaging provider, the MQ messaging provider, or a mixture of the two, by considering the messaging requirements, the business environment, and the needs of each messaging application.
For messaging between appservers, with interaction with a MQ system, we can use the default messaging provider or the MQ provider. Neither provider is necessarily better than the other. The choice of providers depends primarily on factors relating to the business environment and planned changes to that environment, and also on what each JMS application needs to do. Moreover, these two types of messaging providers are not mutually exclusive:

Configure both types of providers within one cell.
Different applications can use the same, or different, providers.

Factors relating to the business environment include the following:

Messaging requirements
Existing skill set
Existing messaging infrastructure
Planned changes to that infrastructure

Seting and managing the messaging infrastructure is simpler if we use just one provider. If the messaging is primarily in MQ, you should probably choose the MQ messaging provider. Similarly, if the messaging is primarily in WAS, you should probably choose the default messaging provider. If the business environment does not clearly indicate that you should use just one provider, then you should consider using a mixture of the two, and choosing the most appropriate messaging provider for each application.
A useful way of doing this is to identify the types of destinations...

service integration bus
MQ queue
topic

...that the application is using. If the application uses only bus destinations, the natural choice is to use the default messaging provider (solution "DMP"). If the application needs to communicate with one or more MQ destinations, we can choose any of the following solutions depending upon the business environment, usage scenarios, and system topologies:

Use the MQ messaging provider (solution "MQP").
Use the default messaging provider to integrate a MQ server (a MQ queue manager or queue-sharing group) as a bus member (solution "DMP interop bus member").
Use the default messaging provider to integrate a MQ network as a foreign bus, using MQ links (solution "DMP interop, foreign bus").

See about these solutions, see Interoperation with MQ: Comparison of key features. To help you choose between these solutions, several of the following steps contain tables in which each row represents a business or system requirement, and asterisks (*) indicate the solutions that are likely to be most effective for meeting the requirement. These tables are designed to provide general guidance, rather than to identify precisely a "right" solution. Most requirements have multiple possible solutions, and the absence of an asterisk does not necessarily mean that we cannot use that solution. To derive best guidance from using each of these tables:

Focus on the rows that reflect the most important requirements.
For all the rows that you consider, count the number of asterisks for each solution.

The solutions with the largest number of asterisks are likely to be the most effective.

If we have limited experience of MQ or WAS, and are trying to decide which product best meets the messaging needs, see Comparison of WAS and MQ messaging.
Whichever of these products you choose as the main focus for the messaging, we can still use either the default messaging provider or the MQ provider for interoperation between WAS NDs.
Consider the business environment, to see if we can use just one provider. In deciding which provider to use, consider the following constraints:

The current and future messaging requirements
The existing messaging infrastructure
The skill set that we have in the organization

If the majority of the messaging is today performed in MQ, continue with that approach and configure MQ as an external JMS provider (that is, use the MQ messaging provider) in WAS. If the JMS requirements of the WAS applications are limited, it is debatable whether using a service integration bus for those applications gives sufficient benefit.
If we have messaging applications in WAS that have no requirement to interoperate with the MQ network, use the default messaging provider (the service integration bus). If the WAS messaging requirements demand a tighter integration with WAS, the service integration bus provides the following benefits:

Integrated administration
WAS high availability capabilities
WAS scalability

If we choose to use the default messaging provider to interoperate between service integration and MQ, be aware that there is an added cost involved in converting messages between service integration format and MQ format.
Also consider the following messaging scenarios:

A large installed backbone of MQ queue managers, perhaps with WebSphere Message Broker.
If we want to use WAS to run a newly introduced messaging application, we can deploy a WAS JMS messaging application that will exchange messages with an existing application that uses a MQ queue or topic.
A WAS installation, perhaps with existing Web and enterprise apps, but no WAS messaging application.
If we have no existing messaging infrastructure, we can deploy a WAS JMS messaging application to exchange messages with an existing WAS messaging application that uses a service integration bus destination.
An infrastructure that uses WAS to connect WAS messaging applications.
Introduce WAS JMS messaging between a pair of WAS applications.
An infrastructure that includes both MQ and service integration buses. This could be the result of a merger, or because the message traffic tends to be from WAS to WAS, or from MQ to MQ, but not typically between WAS and MQ.
Deploy a WAS JMS messaging application to exchange messages with an application that uses a MQ queue or topic.
A WebSphere Process Server or WebSphere Enterprise Service Bus infrastructure, which uses Service Component Architecture (SCA).
We can choose either a MQ or a service integration bus binding for the SCA components.

If the business environment does not clearly indicate that you should use just one messaging provider, use a mixture of the two and choose the most appropriate provider for each application, based upon the destination types that the application uses.
The application might need to exchange messages with existing partner applications or services that use one or more known destinations of known type. Alternatively, the partner applications or services might not yet be deployed and the choice of destination type might still be open, in which case the solution architect needs to decide how best to connect the applications or services together.
If the application uses multiple destinations, there are four possible outcomes:

The application uses only bus destinations.
The application uses only MQ destinations.
The application uses a mixture of bus and MQ destinations.
The destination types are not yet known.

If there is no clear business or technical reason why the application uses MQ destinations rather than bus destinations, and the partner application is also a WAS JMS application, consider migrating the existing destinations to service integration so that the application uses only bus destinations.
If the application uses only bus destinations, configure the application and its JMS resources to use the default messaging provider.
If the application uses only MQ destinations (queues or topics), use the following checklist to determine which provider solution to use.

Table 1. Provider checklist for an application that uses only MQ destinations.

Question: MQP DMP interop, bus member DMP interop, foreign bus
Is performance critical?
(If so, use MQ directly, rather than perform message conversion.)
*

Does the application have to send or receive large messages (that is, messages > 500k.)? *

Is location transparency desirable for simplifying programming and deployment of applications?
* *
Does the application have to consume from a MQ queue, the configuration of which is fixed?
(That is, the queue cannot be moved to service integration and you do not want to deploy a push-style MQ application to send messages to a bus destination.)
* *

Is the partner application a JMS application that will run outside WAS, as a bus or MQ client?
(Do not mix service integration and MQ unless we have to do so; a pure MQ or service integration solution is simpler and avoids the cost of converting messages between service integration and MQ formats.)
*

Is the partner application a non-JMS (non-WAS) application?
(Wherever possible choose a pure MQ or service integration solution. Use the MQI MQ client, or the XMS MQ client, or the XMS bus client depending on the API preference.)
*

Do you prefer traffic passing between the MQ network and WAS applications to be funneled into a single long-running connection?

*
Do you want to use the high availability features of WAS?

*
Is XA 2pc needed between the application and a MQ queue-sharing group?
* *
Is XA 2pc needed between the application and a MQ cluster?
*

If the application uses a mixture of bus and MQ destinations, for example consuming from service integration and sending to MQ, then either of the default messaging provider interoperation models can support this by using a single connection factory or activation specification. Use the following checklist to help you decide between a bus member and a foreign bus solution.
Table 2. Provider checklist for an application that uses a mixture of bus and MQ destinations.

Question: DMP interop, bus member DMP interop, foreign bus
Does the application have to consume from a MQ shared queue? *

Is there a need to distribute work to a pool of WAS workers from a MQ queue? *

Do you prefer traffic passing between the MQ network and WAS applications to be funneled into a single long-running connection?
*
Do we need distributed MQ in versions earlier than WAS Version 7 and MQ V7?
*
Do you want store and forward capabilities to allow the application to continue to send messages when the MQ queue manager is unavailable?
*
Do you prefer not to configure server connection channels?
(This is because they open a port, which could be seen as a security risk.)

*
Do you prefer to define a server connection channel, rather than a pair of sender and receiver channels? *

If the destination types are not yet known, decide the relative priorities of the known concerns then use the following checklist to assess how well each of them is addressed by the possible provider solutions.
The choice is really over what type of destinations this application should use. The destination types are not yet fixed, so any of the four solutions is possible, but as a general rule you should aim for solution "DMP" or "MQP", because a pure MQ or service integration solution is simpler and avoids the cost of converting messages between service integration and MQ formats.

Table 3. Provider checklist for an application for which the destination types are not yet known.

Question: DMP MQP DMP interop, bus member DMP interop, foreign bus
Do we have an existing base of strong skills in managing MQ?
* * *
Do you want management of all messaging to be handled by the MQ team?
*

Do we have administrators skilled in WAS but not in MQ? *

Do you want a messaging product with a large installed base (including references) and a wide choice of ISV tools?
*

Are you reluctant to buy a separately licensed product in addition to WAS? *

Are you reluctant to install and manage a separate product in addition to WAS? *

Are you already using WebSphere Message Broker?
(If so, we need MQ anyway).

* * *
Are you using the WebSphere Enterprise Service Bus to mediate messages from, or deliver them to, a MQ queue?
(For example, using WebSphere Business Integration adapters, or connecting to a service provider such as CICS.)

*

Does the application need to send or receive large messages (that is, messages > 500k.)?
*

Is location transparency desirable for simplifying programming and deployment of applications? *
* *
Do the throughput requirements need multiple parallel channels or routes?
* * *
Does the application have to consume from a MQ queue, the configuration of which is fixed?
(that is, the queue cannot be moved to service integration and you don't want to deploy a push-style MQ application to send messages to a bus destination.)
* * *

Is the partner application a JMS application that will also run in WAS?
(Service integration runs in the WAS appserver. On distributed platforms that means it is in-process. On the z/OS platform it is in another region.)
*

Is the partner application a JMS application that will run outside WAS, as a bus or MQ client?
(Do not mix service integration and MQ unless we have to do so; a pure MQ or service integration solution is simpler and avoids the cost of converting messages between service integration and MQ formats.)
* *

Is the partner application a non-JMS (non-WAS) application?
(Wherever possible choose a pure MQ or service integration solution. Use the MQI MQ client, or the XMS MQ client, or the XMS bus client depending on the API preference.)
* *

Is maintenance of strict message order important? *

Does the application require the flexibility and convenience of a MQ cluster?
(MQ clustering makes administration simpler and provides selective parallelism of clustered queues. That is, instances of a clustered queue can be created on any (but not necessarily all) queue managers in the MQ cluster. Messages sent to the clustered queue can be addressed to a specific instance of the queue, or allowed to select an instance dynamically based on workload management statistics. WAS clustering provides some of this flexibility, but we cannot create partitions of a bus destination on a subset of the messaging engines in a cluster bus member.)

* * *
Does the application need the level of high availability provided by MQ for z/OS shared queues?
* * *
Do you want to use the high availability or scalability features of WAS clustering? *
* *

Related concepts
Introduction: Messaging resources
Interoperation with MQ: Comparison of key features

Related tasks
Manage messaging with the MQ messaging provider
Choose a messaging provider

Related
Comparison of WAS and MQ messaging

Question:	MQP	DMP interop, bus member	DMP interop, foreign bus
Is performance critical? (If so, use MQ directly, rather than perform message conversion.)	*
Does the application have to send or receive large messages (that is, messages > 500k.)?	*
Is location transparency desirable for simplifying programming and deployment of applications?		*	*
Does the application have to consume from a MQ queue, the configuration of which is fixed? (That is, the queue cannot be moved to service integration and you do not want to deploy a push-style MQ application to send messages to a bus destination.)	*	*
Is the partner application a JMS application that will run outside WAS, as a bus or MQ client? (Do not mix service integration and MQ unless we have to do so; a pure MQ or service integration solution is simpler and avoids the cost of converting messages between service integration and MQ formats.)	*
Is the partner application a non-JMS (non-WAS) application? (Wherever possible choose a pure MQ or service integration solution. Use the MQI MQ client, or the XMS MQ client, or the XMS bus client depending on the API preference.)	*
Do you prefer traffic passing between the MQ network and WAS applications to be funneled into a single long-running connection?			*
Do you want to use the high availability features of WAS?			*
Is XA 2pc needed between the application and a MQ queue-sharing group?		*	*
Is XA 2pc needed between the application and a MQ cluster?		*

Question:	DMP interop, bus member	DMP interop, foreign bus
Does the application have to consume from a MQ shared queue?	*
Is there a need to distribute work to a pool of WAS workers from a MQ queue?	*
Do you prefer traffic passing between the MQ network and WAS applications to be funneled into a single long-running connection?		*
Do we need distributed MQ in versions earlier than WAS Version 7 and MQ V7?		*
Do you want store and forward capabilities to allow the application to continue to send messages when the MQ queue manager is unavailable?		*
Do you prefer not to configure server connection channels? (This is because they open a port, which could be seen as a security risk.)		*
Do you prefer to define a server connection channel, rather than a pair of sender and receiver channels?	*

Question:	DMP	MQP	DMP interop, bus member	DMP interop, foreign bus
Do we have an existing base of strong skills in managing MQ?		*	*	*
Do you want management of all messaging to be handled by the MQ team?		*
Do we have administrators skilled in WAS but not in MQ?	*
Do you want a messaging product with a large installed base (including references) and a wide choice of ISV tools?		*
Are you reluctant to buy a separately licensed product in addition to WAS?	*
Are you reluctant to install and manage a separate product in addition to WAS?	*
Are you already using WebSphere Message Broker? (If so, we need MQ anyway).		*	*	*
Are you using the WebSphere Enterprise Service Bus to mediate messages from, or deliver them to, a MQ queue? (For example, using WebSphere Business Integration adapters, or connecting to a service provider such as CICS.)		*
Does the application need to send or receive large messages (that is, messages > 500k.)?		*
Is location transparency desirable for simplifying programming and deployment of applications?	*		*	*
Do the throughput requirements need multiple parallel channels or routes?		*	*	*
Does the application have to consume from a MQ queue, the configuration of which is fixed? (that is, the queue cannot be moved to service integration and you don't want to deploy a push-style MQ application to send messages to a bus destination.)	*	*	*
Is the partner application a JMS application that will also run in WAS? (Service integration runs in the WAS appserver. On distributed platforms that means it is in-process. On the z/OS platform it is in another region.)	*
Is the partner application a JMS application that will run outside WAS, as a bus or MQ client? (Do not mix service integration and MQ unless we have to do so; a pure MQ or service integration solution is simpler and avoids the cost of converting messages between service integration and MQ formats.)	*	*
Is the partner application a non-JMS (non-WAS) application? (Wherever possible choose a pure MQ or service integration solution. Use the MQI MQ client, or the XMS MQ client, or the XMS bus client depending on the API preference.)	*	*
Is maintenance of strict message order important?	*
Does the application require the flexibility and convenience of a MQ cluster? (MQ clustering makes administration simpler and provides selective parallelism of clustered queues. That is, instances of a clustered queue can be created on any (but not necessarily all) queue managers in the MQ cluster. Messages sent to the clustered queue can be addressed to a specific instance of the queue, or allowed to select an instance dynamically based on workload management statistics. WAS clustering provides some of this flexibility, but we cannot create partitions of a bus destination on a subset of the messaging engines in a cluster bus member.)		*	*	*
Does the application need the level of high availability provided by MQ for z/OS shared queues?		*	*	*
Do you want to use the high availability or scalability features of WAS clustering?	*		*	*