Interoperation with WebSphere MQ: Comparison of key features

Interoperation with WebSphere MQ: Comparison of key features

+
Search Tips | Advanced Search

There are three different ways that we can send messages between WAS and a WebSphere MQ network.

No bus. MQ messaging provider MQ network as a foreign bus MQ server as a bus member

WAS uses MQ messaging provider. WAS uses default messaging provider. WAS uses default messaging provider.
Cooperative admin domains for MQ and WAS:

Mutually agree definitions of channels, foreign destinations and buses, to reflect MQ connectivity.
Both ends of the link must be started.
Independent admin domains for MQ and WAS:

Separate authority
Temporal decoupling of admin changes

Links act as funnels:

Messages are routed through the gateway messaging engine or queue manager.
Administrators can stop or start a link.

We might have to define server connection channels in MQ. You must define partner channel definitions in MQ. We might have to define server connection channels in MQ.
No use of service integration buses. Uses service integration bus. MQ network is viewed as a foreign bus. Uses service integration bus. A queue manager or queue-sharing group is viewed as a bus member, and a queue is viewed as a bus destination.
Messages are pushed across the link, regardless of whether a consumer is ready. Messages are pulled from the queue by a WAS consumer, and pushed by a WAS producer.
Store and Forward capability.
Traffic can be indirect, routed to a mapped queue.
Can consume messages from a MQ queue. This is particularly useful if we are working with a MQ for z/OS shared queue. Cannot consume messages from a MQ queue. Can consume messages from a MQ queue. This is particularly useful if we are working with a MQ for z/OS shared queue.
Provides multiple connections between WAS application servers and MQ queue managers or queue-sharing groups. Connections are established as and when required, to allow WAS applications to access MQ queues located on MQ queue managers or queue-sharing groups. Provides a single connection between a service integration bus and a MQ network (comprising one or more interconnected MQ queue managers or queue-sharing groups). This single connection is used to transfer all the messages that are exchanged between the service integration network and the MQ network.
In a multiple links configuration, we cannot define multiple links to the same foreign bus. This means that to establish multiple links from a service integration network, define multiple foreign buses to represent different (gateway) queue managers or queue-sharing groups on the MQ network.
Provides multiple connections between messaging engines in a service integration bus and MQ queue managers or queue-sharing groups. Connections are established as and when required, to allow WAS applications to access MQ queues located on MQ queue managers or queue-sharing groups.
Managed using the admin console. Managed using the admin console. Managed using the admin console.
Does not integrate the service integration bus with the MQ network. Service integration bus mediations running in WAS cannot process messages from a MQ queue, and MQ applications cannot use MQ servers to put messages to, or get messages from, service integration bus queue-type destinations.
Integrates the service integration bus with the MQ network through a gateway queue manager.
Allows closer integration; messaging applications can directly produce messages to, and consume messages from MQ queues.
WAS applications can send messages to MQ queues, and can receive messages from MQ queues.
When a WAS application sends a message to a MQ queue, the message is immediately added to that queue; it does not use the service integration bus.
When a WAS application receives a message from a MQ queue it receives the message directly from the queue.
WAS applications can send messages to MQ queues, but they cannot receive messages from MQ queues.
MQ applications can put messages to service integration bus queue-type destinations, but they cannot get messages from service integration bus queue-type destinations.
WAS applications can send messages to MQ queues, and they can receive messages from MQ queues.
When a WAS application sends a message to a MQ queue, the message is immediately added to that queue; it is not stored by the service integration bus for later transmission to MQ.
When a WAS application receives a message from a MQ queue, it receives the message directly from the queue rather than indirectly from the bus.
WAS applications can use asynchronous consumer sessions to receive messages from a MQ queue, and message-driven beans can be configured to process messages as soon as they arrive at the MQ queue. WAS applications can use asynchronous consumer sessions to receive messages from a MQ queue, and message-driven beans can be configured to process messages as soon as they arrive at the MQ queue. Also, service integration bus mediations running in WAS can process messages as they arrive at a MQ queue.
Permission for WAS applications and mediations to send messages to, and receive messages from, a particular MQ queue is controlled by MQ administration. Permission for WAS applications to send messages to a particular MQ queue is controlled by service integration bus administration.
Permission for MQ applications to send messages to service integration destinations is controlled by MQ administration.
Permission for WAS applications and mediations to send messages to, and receive messages from, a particular MQ queue is controlled by service integration bus administration.
Permission for WAS (which includes permission for its applications and mediations) to access MQ queues is controlled by MQ administration.
The MQ messaging provider regards the MQ queue manager or queue-sharing group as a JMS messaging provider.
The MQ messaging provider is regarded by the MQ network as just another MQ client attaching to the queue manager or queue-sharing group.
Each end of the MQ link appears in a natural form to the other end, so the MQ network appears to service integration as a bus (a foreign bus) and the service integration bus appears as a virtual queue manager to the MQ network. MQ server regards the MQ queue manager or queue-sharing group as a mechanism for queuing messages for the service integration bus.
MQ server is regarded by the MQ network as just another MQ client attaching to the queue manager or queue-sharing group.
Messages are stored on queues, not messaging engines; one or many WAS applications can access the messages, even when the applications are running on different servers. Messages are stored on queues, not messaging engines; one or many WAS applications can access the messages, even when the applications are running on different servers.
Messages can be stored on shared queues; if a queue manager fails, messages can still be retrieved from a different queue manager (no single point of failure exists). WAS applications sending messages to MQ, and MQ applications putting messages to the service integration bus are not affected by temporary failures of the communication link. The messages are stored by MQ or the service integration bus and are delivered when the communication link recovers. Messages can be stored on queues; if a queue manager fails, messages can still be retrieved from a different queue manager (no single point of failure exists).
Automatically discovers resources (queue managers and queues) on the MQ network during configuration and administration.
Can be configured to use properties of the message bus to which it belongs, giving the potential for each MQ server to be bus-specific.
Does not support mediations. Does not support mediations. Supports different mediation scenarios for modifying message content, or routing, and for logging.
Optimum load balancing is easier to achieve because applications can pull messages from the MQ network. Optimum load balancing is easier to achieve because applications can pull messages from the MQ network.
User authentication is required for configuring and for messaging.
Connection between the WAS and the MQ network can use a TCP/IP communication link or, if the WAS is running on the same image as the MQ queue manager, it can use a direct call interface (this is called bindings mode). Connection between the service integration bus network and the MQ network uses a TCP/IP communication link. SSL channels are also supported. Connection between the service integration bus network and the MQ network can use a TCP/IP communication link or, if the WAS application server is running on the same image as the MQ queue manager, it can use a direct call interface (this is called bindings mode). For related information, see Transport chain security.

Related concepts
Interoperation with MQ

No bus. MQ messaging provider	MQ network as a foreign bus	MQ server as a bus member

WAS uses MQ messaging provider.	WAS uses default messaging provider.	WAS uses default messaging provider.
	Cooperative admin domains for MQ and WAS: Mutually agree definitions of channels, foreign destinations and buses, to reflect MQ connectivity. Both ends of the link must be started.	Independent admin domains for MQ and WAS: Separate authority Temporal decoupling of admin changes
	Links act as funnels: Messages are routed through the gateway messaging engine or queue manager. Administrators can stop or start a link.
We might have to define server connection channels in MQ.	You must define partner channel definitions in MQ.	We might have to define server connection channels in MQ.
No use of service integration buses.	Uses service integration bus. MQ network is viewed as a foreign bus.	Uses service integration bus. A queue manager or queue-sharing group is viewed as a bus member, and a queue is viewed as a bus destination.
	Messages are pushed across the link, regardless of whether a consumer is ready.	Messages are pulled from the queue by a WAS consumer, and pushed by a WAS producer.
	Store and Forward capability.
	Traffic can be indirect, routed to a mapped queue.
Can consume messages from a MQ queue. This is particularly useful if we are working with a MQ for z/OS shared queue.	Cannot consume messages from a MQ queue.	Can consume messages from a MQ queue. This is particularly useful if we are working with a MQ for z/OS shared queue.
Provides multiple connections between WAS application servers and MQ queue managers or queue-sharing groups. Connections are established as and when required, to allow WAS applications to access MQ queues located on MQ queue managers or queue-sharing groups.	Provides a single connection between a service integration bus and a MQ network (comprising one or more interconnected MQ queue managers or queue-sharing groups). This single connection is used to transfer all the messages that are exchanged between the service integration network and the MQ network. In a multiple links configuration, we cannot define multiple links to the same foreign bus. This means that to establish multiple links from a service integration network, define multiple foreign buses to represent different (gateway) queue managers or queue-sharing groups on the MQ network.	Provides multiple connections between messaging engines in a service integration bus and MQ queue managers or queue-sharing groups. Connections are established as and when required, to allow WAS applications to access MQ queues located on MQ queue managers or queue-sharing groups.
Managed using the admin console.	Managed using the admin console.	Managed using the admin console.
Does not integrate the service integration bus with the MQ network. Service integration bus mediations running in WAS cannot process messages from a MQ queue, and MQ applications cannot use MQ servers to put messages to, or get messages from, service integration bus queue-type destinations.	Integrates the service integration bus with the MQ network through a gateway queue manager.	Allows closer integration; messaging applications can directly produce messages to, and consume messages from MQ queues.
WAS applications can send messages to MQ queues, and can receive messages from MQ queues. When a WAS application sends a message to a MQ queue, the message is immediately added to that queue; it does not use the service integration bus. When a WAS application receives a message from a MQ queue it receives the message directly from the queue.	WAS applications can send messages to MQ queues, but they cannot receive messages from MQ queues. MQ applications can put messages to service integration bus queue-type destinations, but they cannot get messages from service integration bus queue-type destinations.	WAS applications can send messages to MQ queues, and they can receive messages from MQ queues. When a WAS application sends a message to a MQ queue, the message is immediately added to that queue; it is not stored by the service integration bus for later transmission to MQ. When a WAS application receives a message from a MQ queue, it receives the message directly from the queue rather than indirectly from the bus.
WAS applications can use asynchronous consumer sessions to receive messages from a MQ queue, and message-driven beans can be configured to process messages as soon as they arrive at the MQ queue.		WAS applications can use asynchronous consumer sessions to receive messages from a MQ queue, and message-driven beans can be configured to process messages as soon as they arrive at the MQ queue. Also, service integration bus mediations running in WAS can process messages as they arrive at a MQ queue.
Permission for WAS applications and mediations to send messages to, and receive messages from, a particular MQ queue is controlled by MQ administration.	Permission for WAS applications to send messages to a particular MQ queue is controlled by service integration bus administration. Permission for MQ applications to send messages to service integration destinations is controlled by MQ administration.	Permission for WAS applications and mediations to send messages to, and receive messages from, a particular MQ queue is controlled by service integration bus administration. Permission for WAS (which includes permission for its applications and mediations) to access MQ queues is controlled by MQ administration.
The MQ messaging provider regards the MQ queue manager or queue-sharing group as a JMS messaging provider. The MQ messaging provider is regarded by the MQ network as just another MQ client attaching to the queue manager or queue-sharing group.	Each end of the MQ link appears in a natural form to the other end, so the MQ network appears to service integration as a bus (a foreign bus) and the service integration bus appears as a virtual queue manager to the MQ network.	MQ server regards the MQ queue manager or queue-sharing group as a mechanism for queuing messages for the service integration bus. MQ server is regarded by the MQ network as just another MQ client attaching to the queue manager or queue-sharing group.
Messages are stored on queues, not messaging engines; one or many WAS applications can access the messages, even when the applications are running on different servers.		Messages are stored on queues, not messaging engines; one or many WAS applications can access the messages, even when the applications are running on different servers.
Messages can be stored on shared queues; if a queue manager fails, messages can still be retrieved from a different queue manager (no single point of failure exists).	WAS applications sending messages to MQ, and MQ applications putting messages to the service integration bus are not affected by temporary failures of the communication link. The messages are stored by MQ or the service integration bus and are delivered when the communication link recovers.	Messages can be stored on queues; if a queue manager fails, messages can still be retrieved from a different queue manager (no single point of failure exists).
		Automatically discovers resources (queue managers and queues) on the MQ network during configuration and administration.
		Can be configured to use properties of the message bus to which it belongs, giving the potential for each MQ server to be bus-specific.
Does not support mediations.	Does not support mediations.	Supports different mediation scenarios for modifying message content, or routing, and for logging.
Optimum load balancing is easier to achieve because applications can pull messages from the MQ network.		Optimum load balancing is easier to achieve because applications can pull messages from the MQ network.
		User authentication is required for configuring and for messaging.
Connection between the WAS and the MQ network can use a TCP/IP communication link or, if the WAS is running on the same image as the MQ queue manager, it can use a direct call interface (this is called bindings mode).	Connection between the service integration bus network and the MQ network uses a TCP/IP communication link. SSL channels are also supported.	Connection between the service integration bus network and the MQ network can use a TCP/IP communication link or, if the WAS application server is running on the same image as the MQ queue manager, it can use a direct call interface (this is called bindings mode). For related information, see Transport chain security.