WAS v8.5 > WebSphere applications > Messaging resources > Interoperation with WebSphere MQ > How messages are passed between service integration and a WebSphere MQ network

Differences between service integration and a WebSphere MQ network

Applications can use both service integration and WebSphere MQ to convey messages. Service integration messaging uses messaging engines, whereas WebSphere MQ uses queue managers.

WebSphere MQ is a stand-alone messaging and queuing system, and is not a part of an application server. In WebSphere MQ, messaging and queuing services are provided by queue managers. An application attaches to a queue manager and uses an application programming interface to get messages on and from queues. One of these application interfaces is the Java Messaging Service (JMS) API. Applications can attach directly to a queue manager using a call interface or indirectly using a TCP/IP socket connection. The TCP/IP socket connection which an application uses to attach to a queue manager is called an MQI channel. The application uses the same programming interface for both direct (bindings mode) and indirect (client mode) attachments.

Service integration is part of WAS. In service integration, messaging and queuing services are provided by messaging engines (ME). A service integration messaging engine runs in a WAS server. A service integration messaging engine is similar to a WebSphere MQ queue manager plus its associated message channel agent (MCA), which is used to move messages from one queue manager to another. However, unlike a queue manager, a messaging engine also includes transformation and routing capabilities.

A WAS application connects to a messaging engine using JMS services, and uses the JMS application programming interface to send and receive messages from destinations. A JMS destination is similar to a WebSphere MQ queue or topic. A service integration messaging engine uses WAS communication capabilities for connecting clients outside the WAS server where it runs, and for communicating with other messaging engines. Service integration messaging engines provide services for transformation and routing, and support publish/subscribe messaging. A separate message broker is not required.

WebSphere MQ applications consume messages from queues that are locally defined on a queue manager or (for WebSphere MQ for z/OS ) queue-sharing group. In service integration, the equivalent component to a WebSphere MQ locally-defined queue is a queue point on the local messaging engine. In service integration there is no similar restriction imposed on the queue point and the location in the bus where the consuming application is connected.

The JMS API is available to messaging applications in both WAS and WebSphere MQ. WebSphere MQ also has a native API called the Message Queue Interface (MQI). The JMS send and receive interfaces are similar to the MQI put and get interfaces.

Each WebSphere MQ queue manager usually has a dead-letter queue (also known as the undelivered message queue) defined for it. Messages are put on this queue if they cannot be delivered to their intended destination. In WAS service integration, the equivalents to dead-letter queues are exception destinations. A default exception destination is automatically created for each messaging engine. If messages cannot be delivered, messages are put on the specific exception destination for the queue, if it exists, or on the default exception destination.


+

Search Tips   |   Advanced Search