About this task
For messaging between application servers, with interaction with a IBM MQ system, you can use the default messaging provider or the IBM MQ provider. Neither provider is necessarily better than the
other. The choice of providers depends primarily on factors relating to your 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:
- You can configure both types of providers within one cell.
- Different applications can use the same, or different, providers.
Factors relating to your business environment include the following:
- Messaging requirements
- Existing skill set
- Existing messaging infrastructure
- Planned changes to that infrastructure
Configuring and managing your messaging infrastructure is simpler if you use just one provider.
If your messaging is primarily in IBM MQ, you should probably
choose the IBM MQ messaging provider. Similarly, if your
messaging is primarily in WebSphere Application Server, you should probably
choose the default messaging provider.
If your 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, or
IBM MQ queue or 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
IBM MQ destinations, you can choose any of the
following solutions depending upon your business environment, usage scenarios, and system topologies:
- Use the IBM MQ messaging provider (solution "MQP").
- Use the default messaging provider to integrate a IBM MQ
server (a IBM MQ queue manager or queue-sharing group) as a bus
member (solution "DMP interop bus member").
- Use the default messaging provider to integrate a IBM MQ
network as a foreign bus, by using IBM MQ links (solution "DMP
interop, foreign bus").
For more information about these solutions, see Interoperation with IBM 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 precise solutions. Most requirements have multiple
possible solutions, and the absence of an asterisk does not necessarily mean that you cannot use
that solution. To derive best guidance from using each of these tables:
- Focus on the rows that reflect your 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 you have limited experience of IBM MQ or WebSphere Application Server, and are trying to decide which product best meets
your messaging needs, see Comparison of WebSphere Application Server and IBM MQ messaging.
Note: Whichever of these products you choose as the main focus for your messaging, you can still use
either the default messaging provider or the IBM MQ provider for
interoperation between the products.
- Consider your business environment, to see if you 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 you have in your organization
If the majority of your messaging is today performed in IBM MQ, continue with that approach and configure IBM MQ as an
external JMS provider (that is, use the IBM MQ messaging
provider) in WebSphere Application Server. If the JMS requirements of your
WebSphere Application Server applications are limited, it is debatable
whether using a service integration bus for those applications gives sufficient benefit.
If you have messaging applications in WebSphere Application Server that
have no requirement to interoperate with your IBM MQ network, use
the default messaging provider (the service integration bus). If your WebSphere Application Server messaging requirements demand a tighter integration
with WebSphere Application Server, the service integration bus provides the
following benefits:
- Integrated administration
- WebSphere Application Server high availability capabilities
- WebSphere Application Server scalability
If you choose to use the default messaging provider to interoperate between service integration
and IBM MQ, be aware that there is an added cost involved in
converting messages between service integration format and IBM MQ
format.
Also consider the following messaging scenarios:
- A large installed backbone of IBM MQ queue managers, perhaps
with message broker product.
If you want to use WebSphere Application Server to run a newly introduced messaging application, you can deploy a WebSphere Application Server (JMS) messaging application that will exchange
messages with an existing application that uses a IBM MQ queue or
topic.
- A WebSphere Application Server installation, perhaps with existing web
and enterprise applications, but no WebSphere Application Server messaging
application.
If you have no existing messaging infrastructure, you can deploy a WebSphere Application Server (JMS) messaging application to exchange messages
with an existing WebSphere Application Server messaging application that uses
a service integration bus destination.
- An infrastructure that uses WebSphere Application Server to connect WebSphere Application Server messaging applications.
Introduce WebSphere Application Server (JMS) messaging between a pair of WebSphere Application Server applications.
- An infrastructure that includes both IBM MQ and service
integration buses. This might be the result of a merger, or because the message traffic tends to be
from WebSphere Application Server to WebSphere Application Server, or
from IBM MQ to IBM MQ, but not
typically between WebSphere Application Server and IBM MQ.
Deploy a WebSphere Application Server (JMS) messaging application to exchange messages with an application that uses a IBM MQ queue or topic.
- If your 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:
Note: If there is no clear business or technical reason why the application uses IBM MQ destinations rather than bus destinations, and the partner
application is also a WebSphere Application Server 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 IBM 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 IBM MQ destinations. The first column of this table lists the checklist questions for the business or system
requirements for an application that uses only IBM MQ
destinations. In the second column, the requirements that are met by the IBM MQ messaging provider (MQP) solution are marked with an asterisk.
In the third column, the requirements that are met by the default messaging provider bus member (DMP
interop, bus member) solution are marked with an asterisk. In the fourth column, the requirements
that are met by the default messaging provider foreign bus (DMP interop, foreign bus) solution are
marked with an asterisk. In columns two to four, any requirements that are not met by the solution
shown in that column are not marked with an asterisk.Question: |
MQP |
DMP interop, bus member |
DMP interop, foreign bus |
Is performance critical? (If so, use IBM 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 IBM 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 IBM MQ application to send messages to a bus
destination.)
|
* |
* |
|
Is the partner application a JMS application that will run outside WebSphere Application Server, as a bus or IBM MQ client? (Do not mix service integration and IBM MQ unless
you have to do so; a pure IBM MQ or service integration solution
is simpler and avoids the cost of converting messages between service integration and IBM MQ formats.)
|
* |
|
|
Is the partner application a non-JMS (non-WebSphere Application Server)
application? (Wherever possible choose a pure IBM MQ or
service integration solution. Use the MQI IBM MQ client, or the
XMS IBM MQ client, or the XMS bus client depending on your API
preference.)
|
* |
|
|
Do you prefer traffic passing between your IBM MQ network and WebSphere Application Server applications to be funneled into a single long-running connection? |
|
|
* |
Do you want to use the high availability features of WebSphere Application Server? |
|
|
* |
Is XA two-phase commit (2PC) needed between the application and a IBM MQ queue-sharing group? |
* See 1 |
* |
See 2 |
Is XA two-phase commit (2PC) needed between the application and a IBM MQ cluster? |
|
* |
|
Are you using the WebSphere Enterprise Service Bus to mediate messages from, or deliver
them to, a IBM MQ queue? (For example, using WebSphere Business Integration
adapters, or connecting to a service provider such as CICS®.)
|
* |
|
|
Does the application have to consume from a IBM 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 IBM MQ application to send messages to a bus
destination.)
|
* |
* |
|
Note: - 1 Provided that IBM MQ Version 7.0.1 is
used.
- 2 XA two-phase commit can be used with the IBM MQ
link, but it only covers the sending of the message to the IBM MQ
link. It does not cover the subsequent sending of the message from the IBM MQ link to a IBM MQ queue
manager using store and forwards.
- If the application uses a mixture of bus and IBM MQ
destinations, for example consuming from service integration and sending to IBM 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 IBM MQ destinations. The first column of this table lists the checklist questions for the business or system
requirements for an application that uses a mixture of bus and IBM MQ destinations. In the second column, the requirements that are
met by the default messaging provider bus member (DMP interop, bus member) solution are marked with
an asterisk. In the third column, the requirements that are met by the default messaging provider
foreign bus (DMP interop, foreign bus) solution are marked with an asterisk. In columns two and
three, any requirements that are not met by the solution shown in that column are not marked with an
asterisk.Question: |
DMP interop, bus member |
DMP interop, foreign bus |
Does the application have to consume from a IBM MQ shared queue? |
* |
|
Do you prefer traffic passing between your IBM MQ network and WebSphere Application Server applications to be funneled into a single long-running connection? |
|
* |
Do you need distributed IBM MQ in versions
earlier than WebSphere Application Server Version 7 and IBM MQ Version 7? |
|
* |
Do you want store and forward capabilities to allow the application to
continue to send messages when the IBM MQ queue manager is
unavailable? |
|
* |
Do you prefer not to configure server connection channels? (This is because
they open a port, which might be seen as a security risk.)
|
|
* See 1 |
Do you prefer to define a server connection channel, rather than a pair of
sender and receiver channels? |
* |
|
Do you only want to use bindings connections? |
* |
|
Note: - 1 This is only applicable if you want to send messages from IBM MQ to the service integration bus via the IBM MQ link, although you do need to open a port to your application
server. Sending messages from the service integration bus to IBM MQ via the IBM MQ link requires a port to be opened to the queue
manager through your firewall.
- 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 underlying choice is 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 IBM MQ
or service integration solution is simpler and avoids the cost of converting messages between
service integration and IBM MQ formats.
Table 3. Provider checklist for an application for which the destination types are not yet
known. The first column of this table lists the checklist questions for the business or system
requirements for an application for which the destination types are not yet known. In the second
column, the requirements that are met by the default messaging provider (DMP) solution are marked
with an asterisk. In the third column, the requirements that are met by the IBM MQ messaging provider (MQP) solution are marked with an asterisk.
In the fourth column, the requirements that are met by the default messaging provider bus member
(DMP interop, bus member) solution are marked with an asterisk. In the fifth column, the
requirements that are met by the default messaging provider foreign bus (DMP interop, foreign bus)
solution are marked with an asterisk. In columns two to five, any requirements that are not met by
the solution shown in that column are not marked with an asterisk.Question: |
DMP |
MQP |
DMP interop, bus member |
DMP interop, foreign bus |
Do you have an existing base of strong skills in managing IBM MQ? |
|
* |
* |
* |
Do you want management of all messaging to be handled by the IBM MQ team? |
|
* |
|
|
Do you have administrators skilled in WebSphere Application Server but not in IBM 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 WebSphere Application Server? |
* |
|
|
|
Are you reluctant to install and manage a separate product in addition to WebSphere Application Server? |
* |
|
|
|
Are you already using IBM Integration Bus, known
in earlier releases as WebSphere Message Broker? (If so, you need IBM MQ anyway).
|
|
* |
* |
* |
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? |
|
* |
* |
* |
Is the partner application a JMS application that will also run in WebSphere Application Server? (Service integration runs in the WebSphere Application Server application server. On distributed platforms that
means it is in-process. On the z/OS® platform it is in another region. Therefore using the
default messaging provider gives a possible performance advantage on distributed platforms, but not
on the z/OS
platform. )
|
* |
|
|
|
Is the partner application a JMS application that will run outside WebSphere
Application Server, as a bus or IBM MQ client? (Do not mix
service integration and IBM MQ unless you have to do so; a pure
IBM MQ or service integration solution is simpler and avoids the
cost of converting messages between service integration and IBM MQ formats.)
|
* |
* |
|
|
Is the partner application a non-JMS (non-WebSphere Application Server) application? (Wherever possible choose a pure
IBM MQ or service integration solution. Use the MQI IBM MQ client, or the XMS IBM MQ
client, or the XMS bus client depending on your API preference.)
|
* |
* |
|
|
Is maintenance of strict message order important? |
* |
|
|
|
Does the application require the flexibility and convenience of a IBM MQ cluster? (IBM 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 IBM 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. WebSphere Application Server clustering
provides some of this flexibility, but you 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 IBM MQ for z/OS shared queues? |
|
* |
* |
* |
Do you want to use the high availability or scalability features of WebSphere Application Server clustering? |
* |
|
* |
* |