Interoperation with WebSphere MQ: Comparison of architectures


 

+

Search Tips   |   Advanced Search

 

The three different ways that we can send messages between WAS and WebSphere MQ...

Interoperation model Advantages Disadvantages

WebSphere MQ as an external messaging provider

This architecture requires more WebSphere MQ administration, less WAS administration.

  • If using message-driven beans, performance is lower.
  • Interaction between WAS and WebSphere MQ is not seamless.
  • We cannot use mediations for modifying messages, for routing, or for logging.

A WebSphere MQ network as a foreign bus (using WebSphere MQ links)

This architecture requires more WAS administration, less WebSphere MQ administration.

  • A WebSphere MQ client facility is not required on the gateway WebSphere MQ queue manager.

  • Each end of the link appears in natural form to the other; WebSphere MQ appears to service integration to be a (foreign) bus, service integration appears to WebSphere MQ to be a (virtual) queue manager.

  • Better performance over the link is possible when compared with WebSphere MQ servers or direct connection to WebSphere MQ as an external JMS messaging provider.

  • A managed connection from one node to another is created, but not from every appserver in the cell.

  • You do not have to define individual WebSphere MQ queues to the service integration bus.

  • We can join publish and subscribe domains across service integration bus and WebSphere MQ.

  • Good security support is provided. For example, we can control which users are allowed to put messages onto queues.

  • Use mediations for modifying messages, for routing, and for logging.

  • WAS and WebSphere MQ can exist on separate hosts.

  • Interaction between WAS and WebSphere MQ is seamless.

  • Configure a publish/subscribe bridge, through which WAS applications can subscribe to messages published by WebSphere MQ applications, and WebSphere MQ applications can subscribe to messages published by WAS applications.

A WebSphere MQ server (a queue manager or queue-sharing group) as a bus member

This architecture requires more WAS administration, less WebSphere MQ administration.

  • WAS and WebSphere MQ can exist on separate hosts.

  • Each end of the connection appears in natural form to the other; WebSphere MQ queue manager appears to service integration to be a foreign bus, service integration appears to WebSphere MQ to be a client.

  • Close integration of applications is possible; service integration applications are able to consume messages directly from the WebSphere MQ network.

  • We can connect to queue managers in client mode or bindings mode.

  • Use mediations for modifying messages, for routing, and for logging.

  • Good security support is provided. For example, we can control which users are allowed to put messages onto queues.

  • We can get messages from WebSphere MQ queues (GET).

  • Interaction between WAS and WebSphere MQ is seamless.

  • Queues on the WebSphere MQ network are automatically discovered.

  • You must configure a service integration bus and messaging engines.

  • If using different nodes, CAF is required.

  • The queue managers and queue-sharing groups must be accessible from all the messaging engines in the bus.

  • We cannot use publish and subscribe messaging.

  • WebSphere MQ for z/OS V6 or later, or WebSphere MQ (distributed platforms) V 7 or later, is a prerequisite.

  • You must explicitly define all destinations.

  • We cannot access remote queues from the connected queue manager.





 

Related concepts

Interoperation with WebSphere MQ