Interoperation with WebSphere MQ: Comparison of architectures
The three different ways that we can send messages between WAS and WebSphere MQ...
- WebSphere MQ as an external messaging provider
The WebSphere MQ messaging provider does not use service integration. It provides JMS messaging access to WebSphere MQ from WAS.
- A WebSphere MQ network as a foreign bus (WebSphere MQ links)
A WebSphere MQ link provides a server to server channel connection between a service integration bus and a WebSphere MQ queue manager or queue-sharing group, which acts as the gateway to the WebSphere MQ network.
When you use a WebSphere MQ link, the messaging bus is seen by the WebSphere MQ network as a virtual queue manager, and the WebSphere MQ network is seen by service integration as a foreign bus. A WebSphere MQ link allows WAS applications to send point-to-point messages to WebSphere MQ queues (defined as destinations in the service integration bus), and allows WebSphere MQ applications to send point-to-point messages to destinations in the service integration bus (defined as remote queues in WebSphere MQ). The link also allows WAS applications to subscribe to messages published by WebSphere MQ applications, and WebSphere MQ applications to subscribe to messages published by WAS applications. The link ensures that messages are converted between the formats used by WAS and those used by WebSphere MQ.
- A WebSphere MQ server (a queue manager or queue-sharing group) as a bus member
A WebSphere MQ server provides a direct client connection between a service integration bus and queues on a WebSphere MQ queue manager or (for WebSphere MQ for z/OS) queue-sharing group. For interoperation with WAS WAS V7 or later, the version of WebSphere MQ must be WebSphere MQ for z/OS V6 or later, or WebSphere MQ (distributed platforms) V7 or later. A WebSphere MQ server supports the high availability and optimum load-balancing characteristics provided by a WebSphere MQ for z/OS network. A WebSphere MQ server defines the connection and quality of service properties used for the connection, and also ensures that messages are converted between the formats used by WAS and those used by WebSphere MQ.
Interoperation model Advantages Disadvantages WebSphere MQ as an external messaging provider
This architecture requires more WebSphere MQ administration, less WAS administration.
- You do not have to configure a service integration bus or messaging engines.
- We can connect directly to WebSphere MQ queue managers.
- You manage a single JMS messaging provider rather than two.
- We can connect to queue managers in client mode or bindings mode.
- We can exploit WAS clusters.
- 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.
- You must configure a service integration bus and messaging engines.
- We cannot connect to queue managers in bindings mode.
- Optimum load balancing is less easy to achieve because messages have to be "pushed" from either end of the link.
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