Interoperation with MQ: Comparison of key features

Interoperation with MQ: Comparison of key features

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

MQ messaging provider
No bus MQ network as a foreign bus
MQ links MQ server as a bus member
Queue manager and queue-sharing group

Interoperate with MQ v6 or later. Interoperate with any supported version or release of MQ, on any platform. With a MQ server, we can only interoperate with MQ for z/OS v6 or later, or MQ Version 7 or later.
MQ messaging provider. Default messaging provider. Default messaging provider.
No use of service integration buses. Uses a service integration bus. Uses a service integration bus.
WAS regards the MQ messaging provider as a JMS messaging provider. The MQ messaging provider is regarded by the MQ network as a 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 foreign bus and the service integration bus appears as a virtual queue manager to the MQ network. The MQ server regards the MQ queue manager or queue-sharing group as a bus member, or a mechanism for queuing messages for the service integration bus. A queue is viewed as a bus destination. The MQ server is regarded by the MQ network as a MQ client attaching to the queue manager or queue-sharing group.
Provides multiple connections between appservers and MQ queue managers or queue-sharing groups. Connections are established as and when required to allow WAS applications to access MQ queues. 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. The link acts as a funnel, routing messages through the gateway messaging engine or queue manager. To establish multiple links from a service integration network, we can define multiple foreign buses to represent different 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. A connection 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.
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). The channel for the connection is a bidirectional MQI channel. Connection between the service integration bus network and the MQ network uses a TCP/IP communication link. The sender and receiver channels for the connection are message channels. 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). The channel for the connection is a bidirectional MQI channel.
For MQ for z/OS, messages can be stored on shared queues. If a queue manager fails, messages can still be retrieved from a different queue manager (so no single point of failure exists). If the communication link fails temporarily, messages are stored by MQ or the service integration bus and are delivered when the communication link recovers. For MQ for z/OS, messages can be stored on shared queues. If a queue manager fails, messages can still be retrieved from a different queue manager (so no single point of failure exists).

Applications
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. Traffic can be indirect, routed to a mapped queue. Allows closer integration; messaging applications can directly produce messages to, and consume messages from MQ queues.
WAS applications can send messages to MQ queues. Sent messages are immediately added to the queue. If the MQ queue is unavailable, applications cannot send messages. WAS applications can send messages to MQ queues. Sent messages are stored by the service integration bus for transmission to MQ (this is called store and forward messaging). Applications can continue to send messages if the MQ queue is unavailable. WAS applications can send messages to MQ queues. Sent messages are immediately added to the queue. If the MQqueue is unavailable, applications cannot send messages.
WAS applications can receive messages from MQ queues. The applications can use message consumers to receive messages, and message-driven beans can be configured to process messages as soon as they arrive at the MQ queue. WAS applications cannot receive messages from MQ queues, because the queues are destinations in a foreign bus. For messages to pass from MQ to WAS applications, MQ applications must send the messages to a suitable destination in the service integration bus used by the WAS applications. WAS applications can receive messages from MQ queues. The applications can use message consumers to receive messages, 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.
WAS applications can publish messages to MQ topics and subscribe to messages on MQ topics in the same way as applications in the MQ environment. We can set up a publish/subscribe bridge on the MQ link, so that WAS applications and MQ applications can publish or subscribe to selected topics that exist in both the MQ environment and the WAS environment. A MQ server provides connections with queues for point-to-point messaging. A topic for publish/subscribe messaging cannot be associated with a MQ server.
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 messaging engines. 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 pulled from the queue by a consuming application, and pushed by a producing application. 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.
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. Messages are pushed to applications from the MQ network, but workload balancing options are available in WAS. Optimum load balancing is easier to achieve because applications can pull messages from the MQ network.

Administration and security
Configured and managed using the console. Configured and managed using the console. Configured and managed using the console. Automatically discovers queues on the MQ network during configuration and administration.
Administration is carried out in MQ. In WAS we need to define JMS artefacts such as destinations, connection factories, listener ports, and activation specifications. Cooperative administrative 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

Administrators can stop or start a link

Independent administrative domains for MQ and WAS:

Separate authority

Temporal decoupling of administrative changes

We might have to define server connection channels in MQ. We must define partner channel definitions in MQ. We might have to define server connection channels in MQ.
Permission for WAS applications and mediations to send messages to, and receive messages from, a particular MQ 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.

For WAS Version 7 and later, listener ports are stabilized. For more information, read the article on stabilized features. You should plan to migrate the MQ message-driven bean deployment configurations from using listener ports to using activation specifications. For more information about how to configure activation specifications for non-ASF mode, see Configure activation specifications for non-ASF mode. However, you should not begin this migration until you are sure the application does not have to work on application servers earlier than WAS Version 7. For example, if we have an application server cluster with some members at v6.1 and some at a later version, you should not migrate applications on that cluster to use activation specifications until after you migrate all the application servers in the cluster to the later version.

Related concepts

High availability and workload sharing

MQ messaging provider No bus	MQ network as a foreign bus MQ links	MQ server as a bus member Queue manager and queue-sharing group

Interoperate with MQ v6 or later.	Interoperate with any supported version or release of MQ, on any platform.	With a MQ server, we can only interoperate with MQ for z/OS v6 or later, or MQ Version 7 or later.
MQ messaging provider.	Default messaging provider.	Default messaging provider.
No use of service integration buses.	Uses a service integration bus.	Uses a service integration bus.
WAS regards the MQ messaging provider as a JMS messaging provider. The MQ messaging provider is regarded by the MQ network as a 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 foreign bus and the service integration bus appears as a virtual queue manager to the MQ network.	The MQ server regards the MQ queue manager or queue-sharing group as a bus member, or a mechanism for queuing messages for the service integration bus. A queue is viewed as a bus destination. The MQ server is regarded by the MQ network as a MQ client attaching to the queue manager or queue-sharing group.
Provides multiple connections between appservers and MQ queue managers or queue-sharing groups. Connections are established as and when required to allow WAS applications to access MQ queues.	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. The link acts as a funnel, routing messages through the gateway messaging engine or queue manager. To establish multiple links from a service integration network, we can define multiple foreign buses to represent different 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. A connection 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.
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). The channel for the connection is a bidirectional MQI channel.	Connection between the service integration bus network and the MQ network uses a TCP/IP communication link. The sender and receiver channels for the connection are message channels.	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). The channel for the connection is a bidirectional MQI channel.
For MQ for z/OS, messages can be stored on shared queues. If a queue manager fails, messages can still be retrieved from a different queue manager (so no single point of failure exists).	If the communication link fails temporarily, messages are stored by MQ or the service integration bus and are delivered when the communication link recovers.	For MQ for z/OS, messages can be stored on shared queues. If a queue manager fails, messages can still be retrieved from a different queue manager (so no single point of failure exists).
Applications
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. Traffic can be indirect, routed to a mapped queue.	Allows closer integration; messaging applications can directly produce messages to, and consume messages from MQ queues.
WAS applications can send messages to MQ queues. Sent messages are immediately added to the queue. If the MQ queue is unavailable, applications cannot send messages.	WAS applications can send messages to MQ queues. Sent messages are stored by the service integration bus for transmission to MQ (this is called store and forward messaging). Applications can continue to send messages if the MQ queue is unavailable.	WAS applications can send messages to MQ queues. Sent messages are immediately added to the queue. If the MQqueue is unavailable, applications cannot send messages.
WAS applications can receive messages from MQ queues. The applications can use message consumers to receive messages, and message-driven beans can be configured to process messages as soon as they arrive at the MQ queue.	WAS applications cannot receive messages from MQ queues, because the queues are destinations in a foreign bus. For messages to pass from MQ to WAS applications, MQ applications must send the messages to a suitable destination in the service integration bus used by the WAS applications.	WAS applications can receive messages from MQ queues. The applications can use message consumers to receive messages, 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.
WAS applications can publish messages to MQ topics and subscribe to messages on MQ topics in the same way as applications in the MQ environment.	We can set up a publish/subscribe bridge on the MQ link, so that WAS applications and MQ applications can publish or subscribe to selected topics that exist in both the MQ environment and the WAS environment.	A MQ server provides connections with queues for point-to-point messaging. A topic for publish/subscribe messaging cannot be associated with a MQ server.
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 messaging engines.	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 pulled from the queue by a consuming application, and pushed by a producing application.	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.
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.	Messages are pushed to applications from the MQ network, but workload balancing options are available in WAS.	Optimum load balancing is easier to achieve because applications can pull messages from the MQ network.
Administration and security
Configured and managed using the console.	Configured and managed using the console.	Configured and managed using the console. Automatically discovers queues on the MQ network during configuration and administration.
Administration is carried out in MQ. In WAS we need to define JMS artefacts such as destinations, connection factories, listener ports, and activation specifications.	Cooperative administrative 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 Administrators can stop or start a link	Independent administrative domains for MQ and WAS: Separate authority Temporal decoupling of administrative changes
We might have to define server connection channels in MQ.	We must define partner channel definitions in MQ.	We might have to define server connection channels in MQ.
Permission for WAS applications and mediations to send messages to, and receive messages from, a particular MQ 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.