If your existing or planned messaging environment involves both
WebSphere MQ and WebSphere Application Server systems, choose between the
default messaging provider, the WebSphere MQ messaging provider or a mixture
of the two, by considering your messaging requirements, your business environment
and the needs of each messaging application.
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 provider are not mutually
exclusive:
- You can configure both types of provider 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 destination (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 interoperate
with WebSphere MQ in a single bus (WebSphere MQ server) topology (solution
"DMP interop single bus").
- Use the default messaging provider to interoperate with WebSphere MQ in
a multi-bus (WebSphere MQ links) topology (solution "DMP interop multi-bus").
For more information about these approaches, see Interoperating with WebSphere MQ: Comparison of key features.
To
determine where to use the default messaging provider and the WebSphere MQ
provider within your messaging environment, complete the following steps:
- 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 service integration 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, then 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 and possibly 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.
- Already using WebSphere Application Server to connect WebSphere Application
Server messaging applications.
Introduce WebSphere Application Server (JMS)
messaging between a pair of WebSphere Application Server applications.
- Both WebSphere MQ and service integration bus infrastructure. This could
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.
- WebSphere Process Server or WebSphere Enterprise Service Bus, and therefore
using 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 provider, use a mixture of the two and choose the most
appropriate messaging 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, single bus |
DMP interop, multi-bus |
Is performance critical? (If so, use WebSphere MQ
directly, rather than perform message conversion.)
|
Yes |
No |
No |
Does the application need to send or receive large messages? (that
is, messages > 500k.)
|
Yes |
No |
No |
Is location transparency desirable for simplifying programming
and deployment of applications? |
No |
Yes |
Yes |
Does the application need 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.)
|
Yes |
Yes |
No |
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.)
|
Yes |
No |
No |
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.)
|
Yes |
No |
No |
Do you prefer traffic passing between your WebSphere
MQ network and WebSphere Application Server applications to be funneled into
a single long-running connection? |
No |
No |
Yes |
Do you want to use the high availability features of
WebSphere Application Server? |
No |
No |
Yes |
Is XA two-phase commit (2PC) needed between the application
and a WebSphere MQ cluster or queue sharing group? |
No |
Yes |
Yes |
- 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 using a single connection
factory or activation specification. Use the following checklist to decide
between a single or multiple bus solution.
Table 2. Provider checklist for an application that uses a mixture of bus and
WebSphere MQ destinations.
Question: |
DMP interop, single bus |
DMP interop, multi-bus |
Does the application need to consume from a WebSphere
MQ shared queue? |
Yes |
No |
Is there a need to distribute work to a pool of WebSphere
Application Server workers from a WebSphere MQ queue? |
Yes |
No |
Do you prefer traffic passing between your WebSphere
MQ network and WebSphere Application Server applications to be funneled into
a single long-running connection? |
No |
Yes |
Do you needs distributed WebSphere MQ? |
No |
Yes |
Do you want store and forward capabilities to allow
the application to continue to send messages when the WebSphere MQ queue manager
is unavailable? |
No |
Yes |
Do you prefer not to configure server connection channels? (because
they open a port, which could be seen as a security risk)
|
No |
Yes |
Do you prefer to define a server connection channel,
rather than a pair of sender and receiver channels? |
Yes |
No |
- 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 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, single bus |
DMP interop, multi-bus |
Do you have an existing base of strong skills in managing
WebSphere MQ? |
No |
Yes |
Yes |
Yes |
Do you want management of all messaging to be handled
by the WebSphere MQ team? |
No |
Yes |
No |
No |
Do you have administrators skilled in WebSphere Application
Server but not in WebSphere MQ? |
Yes |
No |
No |
No |
Do you want a messaging product with a large installed
base (including references) and a wide choice of ISV tools? |
No |
Yes |
No |
No |
Are you reluctant to buy a separately licensed product
in addition to WebSphere Application Server? |
Yes |
No |
No |
No |
Are you reluctant to install and manage a separate product
in addition to WebSphere Application Server? |
Yes |
No |
No |
No |
Are you already using WebSphere Message Broker? (If
so, you need WebSphere MQ anyway).
|
No |
Yes |
Yes |
Yes |
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.)
|
No |
Yes |
No |
No |
Does the application need to send or receive large messages? (that
is, messages > 500k.)
|
No |
Yes |
No |
No |
Is location transparency desirable for simplifying programming
and deployment of applications? |
Yes |
No |
Yes |
Yes |
Do the throughput requirements need multiple parallel
channels or routes? |
No |
Yes |
Yes |
Yes |
Does the application need 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.)
|
Yes |
Yes |
Yes |
No |
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’s in-process. On the z/OS platform it’s in another region.)
|
Yes |
No |
No |
No |
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.)
|
Yes |
Yes |
No |
No |
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.)
|
Yes |
Yes |
No |
No |
Is maintenance of strict message order important? |
Yes |
No |
No |
No |
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.)
|
No |
Yes |
Yes |
Yes |
Does the application need the level of high availability
provided by WebSphere MQ for z/OS shared queues? |
No |
Yes |
Yes |
Yes |
Do you want to use the high availability or scalability
features of WebSphere Application Server clustering? |
Yes |
No |
Yes |
Yes |
Is XA 2pc needed
between the application and a WebSphere MQ cluster or queue sharing group? |
Yes |
No |
Yes |
Yes |