Choosing messaging providers for a mixed environment

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:

Factors relating to your business environment include the following:

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 either of the following solutions depending upon your business environment, usage scenarios and system topologies:

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:

Procedure

  1. 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.
  2. 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.

  3. 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.
  4. If the application uses only bus destinations, configure the application and its JMS resources to use the default messaging provider.
  5. 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, multi-bus
    Is performance critical?

    (If so, use WebSphere MQ directly, rather than perform message conversion.)

    Yes No
    Does the application need to send or receive large messages?

    (that is, messages > 500k.)

    Yes No
    Is location transparency desirable for simplifying programming and deployment of applications? No 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 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
    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
    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 want to use the high availability features of WebSphere Application Server? No Yes
    Is XA two-phase commit (2PC) needed between the application and a WebSphere MQ cluster or queue sharing group? No Yes
  6. If the application uses a mixture of bus and WebSphere MQ destinations, for example consuming from service integration and sending to WebSphere MQ, use the default messaging provider multi-bus interoperation model. For more information about how to do this, see Using WebSphere MQ links to integrate a bus into a WebSphere MQ network of queue managers.
  7. 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 2. Provider checklist for an application for which the destination types are not yet known.
    Question: DMP MQP DMP interop, multi-bus
    Do you have an existing base of strong skills in managing WebSphere MQ? No Yes Yes
    Do you want management of all messaging to be handled by the WebSphere MQ team? No Yes No
    Do you have administrators skilled in WebSphere Application Server but not in WebSphere MQ? Yes 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
    Are you reluctant to buy a separately licensed product in addition to WebSphere Application Server? Yes No No
    Are you reluctant to install and manage a separate product in addition to WebSphere Application Server? Yes No No
    Are you already using WebSphere Message Broker?

    (If so, you need WebSphere MQ anyway).

    No 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
    Does the application need to send or receive large messages?

    (that is, messages > 500k.)

    No Yes No
    Is location transparency desirable for simplifying programming and deployment of applications? Yes No Yes
    Do the throughput requirements need multiple parallel channels or routes? 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 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
    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
    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
    Is maintenance of strict message order important? Yes 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
    Does the application need the level of high availability provided by WebSphere MQ for z/OS shared queues? No Yes Yes
    Do you want to use the high availability or scalability features of WebSphere Application Server clustering? Yes No Yes
    Is XA 2pc needed between the application and a WebSphere MQ cluster or queue sharing group? Yes No Yes



In this information ...


Related information

IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Sep 20, 2010 10:03:57 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-zos&topic=tmj_jmsp_mixed
File name: tmj_jmsp_mixed.html