Interoperation with IBM MQ: Comparison of key features

There are three different ways that you can send messages between WebSphere® Application Server and a IBM MQ network. This topic compares the key features of each of the three ways.

Table 1. Key features comparison between the three ways of interoperating with IBM MQ. The first column of this table shows the key features of interoperating using the IBM MQ messaging provider with no bus, the second column shows the key features of interoperating using the IBM MQ network as a foreign bus (using IBM MQ links), and the third column shows the key features of interoperating using a IBM MQ server (a queue manager or queue-sharing group) as a bus member.
IBM MQ messaging provider (no bus) A IBM MQ network as a foreign bus (using IBM MQ links) A IBM MQ server (a queue manager or queue-sharing group) as a bus member
A JMS application uses the default messaging provider to pass a message to the IBM MQ messaging provider, which uses JMS messaging protocols to pass the message to a IBM MQ queue or topic.
A JMS application uses the default messaging provider to pass a message to a service integration bus. The bus passes the message across a IBM MQ link to a IBM MQ queue or topic. Service integration views the IBM MQ system as if it were a foreign bus.
A JMS application uses the default messaging provider to pass a message to a service integration bus. The bus passes the message through a IBM MQ server to a IBM MQ queue. Service integration views the IBM MQ system as if it were a bus member.

Connectivity

With the IBM MQ messaging provider, you can interoperate with IBM MQ Version 6 or later. See the following link, for details on which fix pack levels you will need for your configuration: http://www-01.ibm.com/support/docview.wss?uid=swg21498708 With a IBM MQ link, you can interoperate with any supported version or release of IBM MQ, on any platform. With a IBM MQ server, you can only interoperate with IBM MQ for z/OS® Version 6 or later, or IBM MQ Version 7 or later.
Uses the IBM MQ messaging provider. Uses the default messaging provider. Uses the default messaging provider.
No use of service integration buses. Uses a service integration bus. Uses a service integration bus.
WebSphere Application Server regards the IBM MQ messaging provider as a JMS messaging provider.

The IBM MQ messaging provider is regarded by the IBM MQ network as a IBM MQ client attaching to the queue manager or queue-sharing group.

Each end of the IBM MQ link appears in a natural form to the other end, so the IBM MQ network appears to service integration as a foreign bus and the service integration bus appears as a virtual queue manager to the IBM MQ network. The IBM MQ server regards the IBM 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 IBM MQ server is regarded by the IBM MQ network as a IBM MQ client attaching to the queue manager or queue-sharing group.

Provides multiple connections between WebSphere Application Server application servers and IBM MQ queue managers or queue-sharing groups. Connections are established as and when required to allow WebSphere Application Server applications to access IBM MQ queues. Provides a single connection between a service integration bus and a IBM MQ network (comprising one or more interconnected IBM 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 IBM MQ network. The link acts as a funnel, routing messages through the gateway messaging engine or queue manager. If you want to establish multiple links from a service integration network, you can define multiple foreign buses to represent different queue managers or queue-sharing groups on the IBM MQ network. Provides multiple connections between messaging engines in a service integration bus and IBM MQ queue managers or queue-sharing groups. Connections are established as and when required, to allow WebSphere Application Server applications to access IBM MQ queues. A connection can be configured to use properties of the message bus to which it belongs, giving the potential for each IBM MQ server to be bus-specific.
Connection between the WebSphere Application Server and the IBM MQ network can use a TCP/IP communication link or, if the WebSphere Application Server is running on the same image as the IBM 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 IBM 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 IBM MQ network can use a TCP/IP communication link or, if the WebSphere Application Server application server is running on the same image as the IBM 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 IBM 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 IBM MQ or the service integration bus and are delivered when the communication link recovers. For IBM 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 IBM MQ network. Service integration bus mediations running in WebSphere Application Server cannot process messages from a IBM MQ queue, and IBM MQ applications cannot use IBM MQ servers to put messages to, or get messages from, service integration bus queue-type destinations. Integrates the service integration bus with the IBM 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 IBM MQ queues.
WebSphere Application Server applications can send messages to IBM MQ queues. Sent messages are immediately added to the queue. If the IBM MQ queue is unavailable, applications cannot send messages. WebSphere Application Server applications can send messages to IBM MQ queues. Sent messages are stored by the service integration bus for transmission to IBM MQ (this is called store and forward messaging). Applications can continue to send messages if the IBM MQ queue is unavailable. WebSphere Application Server applications can send messages to IBM MQ queues. Sent messages are immediately added to the queue. If the IBM MQqueue is unavailable, applications cannot send messages.
WebSphere Application Server applications can receive messages from IBM 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 IBM MQ queue. WebSphere Application Server applications cannot receive messages from IBM MQ queues, because the queues are destinations in a foreign bus. For messages to pass from IBM MQ to WebSphere Application Server applications, IBM MQ applications must send the messages to a suitable destination in the service integration bus used by the WebSphere Application Server applications. WebSphere Application Server applications can receive messages from IBM 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 IBM MQ queue. Also, service integration bus mediations running in WebSphere Application Server can process messages as they arrive at a IBM MQ queue.
WebSphere Application Server applications can publish messages to IBM MQ topics and subscribe to messages on IBM MQ topics in the same way as applications in the IBM MQ environment. You can set up a publish/subscribe bridge on the IBM MQ link, so that WebSphere Application Server applications and IBM MQ applications can publish or subscribe to selected topics that exist in both the IBM MQ environment and the WebSphere Application Server environment. A IBM MQ server provides connections with queues for point-to-point messaging. A topic for publish/subscribe messaging cannot be associated with a IBM MQ server.
Messages are stored on queues, not messaging engines; one or many WebSphere Application Server 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 WebSphere Application Server 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 WebSphere Application Server consumer, and pushed by a WebSphere Application Server 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 IBM MQ network. Messages are pushed to applications from the IBM MQ network, but workload balancing options are available in WebSphere Application Server. Optimum load balancing is easier to achieve because applications can pull messages from the IBM MQ network.

Administration and security

Configured and managed by using the administrative console. Configured and managed by using the administrative console. Configured and managed by using the administrative console. Automatically discovers queues on the IBM MQ network during configuration and administration.
Administration is carried out in IBM MQ. In WebSphere Application Server you need to define JMS artefacts such as destinations, connection factories, listener ports, and activation specifications. Cooperative administrative domains for IBM MQ and WebSphere Application Server:
  • Mutually agree definitions of channels, foreign destinations and buses, to reflect IBM MQ connectivity
  • Both ends of the link must be started
  • Administrators can stop or start a link
Independent administrative domains for IBM MQ and WebSphere Application Server:
  • Separate authority
  • Temporal decoupling of administrative changes
You might have to define server connection channels in IBM MQ. You must define partner channel definitions in IBM MQ. You might have to define server connection channels in IBM MQ.
Permission for WebSphere Application Server applications and mediations to send messages to, and receive messages from, a particular IBM MQ is controlled by IBM MQ administration. Permission for WebSphere Application Server applications to send messages to a particular IBM MQ queue is controlled by service integration bus administration.

Permission for IBM MQ applications to send messages to service integration destinations is controlled by IBM MQ administration.

Permission for WebSphere Application Server applications and mediations to send messages to, and receive messages from, a particular IBM MQ queue is controlled by service integration bus administration.

Permission for WebSphere Application Server (which includes permission for its applications and mediations) to access IBM MQ queues is controlled by IBM MQ administration.

For WebSphere Application Server Version 7 and later, listener ports are stabilized. For more information, read the article on stabilized features. You should plan to migrate your WebSphere MQ message-driven bean deployment configurations from using listener ports to using activation specifications. [AIX Solaris HP-UX Linux Windows][IBM i]For more information about how to configure activation specifications for non-ASF mode, see Configuring 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 WebSphere Application Server Version 7. For example, if you have an application server cluster with some members at Version 6.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.


指出主題類型的圖示 概念主題



時間戳記圖示 前次更新: July 9, 2016 11:11
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cmm_comp_feat
檔名:cmm_comp_feat.html