About this task
For messaging between application servers, with interaction with
a WebSphere MQ
system, you can use the default messaging provider or the WebSphere 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 WebSphere MQ,
you should probably choose the WebSphere 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 WebSphere 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 WebSphere MQ
destinations, you can choose any of the following solutions depending upon
your business environment, usage scenarios, and system topologies:
- Use the WebSphere MQ
messaging provider (solution "MQP").
- Use the default messaging provider to integrate a WebSphere MQ server (a WebSphere MQ
queue manager or queue-sharing group) as a bus member (solution "DMP interop
bus member").
- Use the default messaging provider to integrate a WebSphere MQ network as a foreign
bus, by using WebSphere MQ
links (solution "DMP interop, foreign bus").
For more information about these solutions, see Interoperation with WebSphere 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 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 WebSphere MQ or WebSphere Application
Server, and are trying to decide which product best meets your messaging needs,
see Comparison of WebSphere Application Server and WebSphere 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 WebSphere 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 WebSphere MQ,
continue with that approach and configure WebSphere MQ as an external JMS provider
(that is, use the WebSphere 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 WebSphere 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 WebSphere MQ, be aware that there
is an added cost involved in converting messages between service integration
format and WebSphere MQ
format.
Also consider the following messaging scenarios:
- A large installed backbone of WebSphere MQ queue managers, perhaps
with WebSphere Message
Broker.
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 WebSphere 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 WebSphere 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 WebSphere MQ
to WebSphere MQ,
but not typically between WebSphere Application Server and MQ.
Deploy a WebSphere Application
Server (JMS) messaging application to exchange messages with an application
that uses a WebSphere MQ
queue or topic.
- A WebSphere Process
Server or WebSphere Enterprise
Service Bus infrastructure, which uses Service Component Architecture (SCA).
You
can choose either a WebSphere MQ or a service integration bus binding
for your SCA components.
- 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 WebSphere 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 WebSphere 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 WebSphere MQ
destinations.
Question: |
MQP |
DMP interop, bus member |
DMP interop, foreign bus |
Is performance critical? (If so, use WebSphere 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 WebSphere 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 WebSphere 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 WebSphere MQ client? (Do not mix service integration
and WebSphere MQ
unless you have to do so; a pure WebSphere MQ or service integration
solution is simpler and avoids the cost of converting messages between service
integration and WebSphere MQ
formats.)
|
* |
|
|
Is the partner application a non-JMS (non-WebSphere
Application Server) application? (Wherever possible choose a pure WebSphere MQ
or service integration solution. Use the MQI WebSphere MQ client, or the XMS WebSphere MQ
client, or the XMS bus client depending on your API preference.)
|
* |
|
|
Do you prefer traffic passing between your WebSphere 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 WebSphere MQ
queue-sharing group? |
|
* |
* |
Is XA two-phase commit (2PC) needed between the application
and a WebSphere MQ
cluster? |
|
* |
|
Are you using the WebSphere Enterprise Service Bus to
mediate messages from, or deliver them to, a WebSphere 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 WebSphere 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 WebSphere MQ
application to send messages to a bus destination.)
|
* |
* |
|
- If the application uses a mixture of bus and WebSphere MQ
destinations, for example consuming from service integration and sending to WebSphere 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 WebSphere MQ destinations.
Question: |
DMP interop, bus member |
DMP interop, foreign bus |
Does the application have to consume from a WebSphere MQ
shared queue? |
* |
|
Is there a need to distribute work to a pool of WebSphere Application
Server workers from a WebSphere MQ queue? |
* |
|
Do you prefer traffic passing between your WebSphere MQ
network and WebSphere Application
Server applications to be funneled into a single long-running connection? |
|
* |
Do you need distributed WebSphere MQ in versions earlier than WebSphere Application
Server Version 7 and WebSphere MQ Version 7? |
|
* |
Do you want store and forward capabilities to allow
the application to continue to send messages when the WebSphere 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.)
|
|
* |
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 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 WebSphere MQ
or service integration solution is simpler and avoids the cost of converting
messages between service integration and WebSphere 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 you have an existing base of strong skills in managing WebSphere MQ? |
|
* |
* |
* |
Do you want management of all messaging to be handled
by the WebSphere MQ
team? |
|
* |
|
|
Do you have administrators skilled in WebSphere Application
Server but not in WebSphere 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 WebSphere Message Broker? (If so,
you need WebSphere 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 WebSphere MQ client? (Do not mix service integration
and WebSphere MQ
unless you have to do so; a pure WebSphere MQ or service integration
solution is simpler and avoids the cost of converting messages between service
integration and WebSphere MQ
formats.)
|
* |
* |
|
|
Is the partner application a non-JMS (non-WebSphere
Application Server) application? (Wherever possible choose a pure WebSphere MQ
or service integration solution. Use the MQI WebSphere MQ client, or the XMS WebSphere 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 WebSphere MQ
cluster? (WebSphere 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 WebSphere 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 WebSphere MQ
for z/OS shared
queues? |
|
* |
* |
* |
Do you want to use the high availability or scalability
features of WebSphere Application
Server clustering? |
* |
|
* |
* |