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