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 WebSphere 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.. The first column of this table lists the checklist questions.
The second column shows whether or not using the WebSphere MQ messaging provider is likely
to be most effective solution for meeting the requirement. The third
column shows whether or not using the default messaging provider to
integrate a WebSphere MQ server (a WebSphere MQ queue manager or queue-sharing
group) as a bus member is likely to be most effective solution for
meeting the requirement. The fourth column shows whether or not using
the default messaging provider to integrate a WebSphere MQ network as a foreign bus,
by using WebSphere MQ links (solution
"DMP interop, foreign bus") is likely to be most effective solution
for meeting the requirement.
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? |
* See 1 |
* |
See 2 |
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.)
|
* |
* |
|
Note:
- 1 Provided that WebSphere MQ Version
7.0.1 is used.
- 2 XA two-phase commit can be used with the WebSphere MQ link, but it only covers
the sending of the message to the WebSphere MQ link.
It does not cover the subsequent sending of the message from the WebSphere MQ link to a WebSphere MQ queue manager using store
and forwards.
- 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.. The
first column of this table lists the checklist questions. The second
column shows whether or not using the default messaging provider to
integrate a WebSphere MQ server (a WebSphere MQ queue manager or queue-sharing
group) as a bus member is likely to be most effective solution for
meeting the requirement. The third column shows whether or not using
the default messaging provider to integrate a WebSphere MQ network as a foreign bus,
by using WebSphere MQ links (solution
"DMP interop, foreign bus") is likely to be most effective solution
for meeting the requirement.
Question: |
DMP interop, bus member |
DMP interop, foreign bus |
Does the application have to consume from a WebSphere MQ shared 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.)
|
|
* 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 WebSphere MQ to the service
integration bus via the WebSphere MQ link,
although you do need to open a port to your application server. Sending
messages from the service integration bus to WebSphere MQ via the WebSphere 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 WebSphere MQ or service
integration solution is simpler and avoids the cost of converting
messages between service integration and WebSphere MQformats.
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. The second column shows
whether or not using the default messaging provider is likely to be
most effective solution for meeting the requirement. The third column
shows whether or not using the WebSphere MQ messaging
provider is likely to be most effective solution for meeting the requirement.
The fourth column shows whether or not using the default messaging
provider to integrate a WebSphere MQ server
(a WebSphere MQ queue manager or
queue-sharing group) as a bus member is likely to be most effective
solution for meeting the requirement. The fifth column shows whether
or not using the default messaging provider to integrate a WebSphere MQ network as a foreign bus,
by using WebSphere MQ links (solution
"DMP interop, foreign bus") is likely to be most effective solution
for meeting the requirement.
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? |
* |
|
* |
* |