A
high-level architectural comparison of the different ways that you can send
messages between WebSphere Application Server and a WebSphere MQ network,
describing the advantages and disadvantages of each approach.
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 directly from WebSphere Application Server.
Multi-bus: WebSphere MQ network as a foreign bus (using WebSphere MQ
links). A WebSphere MQ link provides an indirect connection between a
service integration bus and a queue manager within a WebSphere MQ messaging
network. With this type of connection, 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 messaging bus. A Websphere MQ link allows WebSphere
Application Server 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 WebSphere Application Server applications to subscribe
to messages published by WebSphere MQ applications, and WebSphere MQ applications
to subscribe to messages published by WebSphere Application Server applications.
The link converts messages between the formats used by WebSphere Application
Server and those used by WebSphere MQ, and handles data conversion of messages.
Single-bus: Queue manager as a bus member (a WebSphere
MQ server). A WebSphere MQ server provides direct connection between service
integration messaging engines in WebSphere Application Server and queue managers
or queue sharing groups in WebSphere MQ for z/OS. WebSphere MQ server is designed
to exploit the high availability, and optimum load balancing characteristics
provided by a WebSphere MQ for z/OS network. 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 WebSphere
Application Server, and those used by WebSphere MQ.
Interoperation model |
Advantages |
Disadvantages |
General |
WebSphere MQ as an external JMS provider |
- You do not have to configure a service integration bus or messaging engines.
- You can connect directly to WebSphere MQ queue managers.
- You only have to manage a single JMS messaging provider rather than two.
- You can connect to queue managers in client mode or bindings mode.
- You can exploit WebSphere Application Server clusters.
|
- If using message-driven beans, performance is lower.
- Interaction between WebSphere Application Server and WebSphere MQ is not
seamless.
- You cannot use mediations for modifying messages, for routing or for logging.
|
- This architecture requires more WebSphere MQ administration, less WebSphere
Application Server administration.
|
WebSphere MQ link |
- 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 application server in the cell.
- You do not have to define individual WebSphere MQ queues to the service
integration bus.
- You can join publish and subscribe domains across service integration
bus and WebSphere MQ.
- Good security support is provided, for example control over which users
are allowed to put messages onto queues.
- You can use mediations for modifying messages, for routing, and for logging.
- WebSphere Application Server and WebSphere MQ can exist on separate hosts.
- Seamless interaction between WebSphere Application Server and WebSphere
MQ.
|
- You must configure a service integration bus and messaging engines.
- You 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.
|
- This architecture requires more WebSphere Application Server administration,
less WebSphere MQ administration.
|
WebSphere MQ server |
- WebSphere Application Server 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.
- You can connect to queue managers in client mode or bindings mode.
- You can use mediations for modifying messages, for routing, and for logging.
- Good security support is provided, for example control over which users
are allowed to put messages onto queues.
- You can get messages from WebSphere MQ queues (GET).
- Seamless interaction between WebSphere Application Server and WebSphere
MQ.
- Queues on the WebSphere MQ network are automatically discovered.
|
- You must configure a service integration bus and messaging engines.
- If you are using different nodes, CAF is required.
- The queue managers and queue sharing groups must be accessible from all
the messaging engines in the bus.
- You cannot use publish and subscribe messaging.
- WebSphere MQ for z/OS Version 6 CSD1 or later version is a prerequisite.
- You must explicitly define all destinations.
- You cannot access remote queues from the connected queue manager.
- WebSphere MQ servers can only interoperate with WebSphere MQ on z/OS.
|
- This architecture requires more WebSphere Application Server administration,
less WebSphere MQ administration.
|