Choosing a messaging system: WebSphere MQ vs. the WebSphere Application Server Service Integration Bus


If you use IBM® WebSphere® Application Server to deploy an application that uses Java™ Message Service (JMS), the application can use a variety of JMS providers. This article compares two of the JMS providers available in WebSphere Application Server and the messaging systems those providers relate to: WebSphere MQ and the Service Integration Bus (SIBus) built into WebSphere Application Server.

What is JMS?

JMS is a standard that specifies how Java applications send and receive messages. The JMS specification defines the application programming interface (API) used by an application to access a messaging system, with the benefit that an application that uses the standard JMS API should be portable between different implementations of JMS. The JMS specification is limited in scope to the API.

What is a JMS provider?

An implementation of the JMS API is known as a JMS provider. Each provider maps the operations of the API onto a messaging system that establishes connections to other systems and conveys messages to them. Whilst the JMS Provider is a mapping to a messaging system, it does not necessarily include the messaging system. The messaging system may well support other APIs, thus ensuring a separation between the concepts of messaging system and JMS provider.

Figure 1. Role of the JMS provider
Role of the JMS provider
Role of the JMS provider

How does an application become associated with a JMS provider?

For a JMS application deployed to WebSphere Application Server, the choice of JMS provider is governed by the configuration of administered JMS resources – such as the JMS Connection Factory and the JMS Queue -- that are generally looked up in the JNDI namespace of the application server. When you configure these JMS resources, you use definitions supplied by the JMS provider that you want the application to use. The configuration of the resources therefore dictates which messaging system will handle the application's connection and convey the application's messages.

Whilst it offers portability, JMS does not guarantee interoperability. As noted above, the JMS specification is limited in scope to the API, and therefore does not define a standard "wire format" for how messages should be structured, nor does it specify a standard "wire protocol" to define the conversation between messaging endpoints. But messaging generally involves at least one other application with which you intend to exchange messages. For communication to be possible, the choice of JMS provider and associated messaging system must be compatible with the messaging system used by the other applications.

JMS providers in WebSphere Application Server

Figure 2. JMS providers in WebSphere Application Server
JMS providers in WebSphere Application Server
JMS providers in WebSphere Application Server

WebSphere Application Server provides three options for configuring JMS providers:

Default messaging provider

The default messaging provider is a popular choice because it uses the SIBus messaging system built into the runtime for WebSphere Application Server V6 or later. It is written in Java and runs inside a WebSphere Application Server process. Administration of the SIBus is integrated with the WebSphere Application Server administration system, so you can use either the console or scripting commands to configure it. The SIBus lets you construct a "bus" within a WebSphere cell. Servers or clusters within the cell can join the bus, and each server or cluster that is a member of the bus runs an in-process messaging engine. The messaging engines discover and connect to one another, and send and receive messages submitted by applications.

WebSphere MQ JMS provider

The WebSphere MQ JMS provider maps to the WebSphere MQ messaging system. WebSphere MQ is not part of WebSphere Application Server, but a separate product that runs on many different platforms and supports a variety of programming languages and APIs. The WebSphere MQ JMS provider is a popular choice because WebSphere MQ is the most widely used message-oriented-middleware (MOM) product in the industry. It has been available for many years and is widely used to integrate applications on disparate platforms. The key runtime artifact in WebSphere MQ is called a queue manager. For more information on WebSphere MQ, see the WebSphere MQ V7 information center.

Since WebSphere MQ is not part of WebSphere Application Server, its queue managers run in separate processes and are separately administered. The WebSphere MQ JMS provider enables an application to connect to a queue manager or queue sharing group, via a WebSphere MQ client connection.

Generic third-party messaging provider

Your organization may use a third-party messaging product, in which case you can configure WebSphere Application Server to use the third-party messaging provider. Less common than the first two choices, it can be customised to map to an arbitrary messaging system. Because of its generic nature, configuration of the third-party messaging provider is based on a flexible but somewhat primitive system of configuring properties.

Deciding which messaging system to use

The choice of JMS provider is generally driven by the choice of messaging system. Sometimes, your organization has already chosen a messaging system and made a significant investment in implementing it, so that is the messaging system you will need to use. In other cases, the choice of a messaging system is still open and requires careful functional comparison of the two main alternative messaging systems, as well as an investigation of the characteristics required by the applications in your applications.

Deciding to use WebSphere MQ

If your organization already uses WebSphere MQ, they probably have a significant investment in installed infrastructure, skills, administrative procedures, and monitoring capabilities, and it is usually wise to capitalize on that investment by continuing to use WebSphere MQ for messaging. In many large organizations, an experienced messaging team of WebSphere MQ administrators within the IT department has the ability to rapidly and efficiently provision messaging resources for your use. Furthermore, if WebSphere MQ is used by the other application or service to which your JMS application will communicate, then it is a natural choice as the messaging system for your JMS application. The other application may also be using the JMS API, but it does not have to, because a WebSphere MQ application written in another language can exchange messages with a JMS application.

Connecting directly to existing WebSphere MQ

Assume that based on the above considerations, you elect to use WebSphere MQ. In the majority of cases, the best way to connect a WebSphere Application Server JMS application to a WebSphere MQ queue manager is to configure WebSphere Application Server to connect directly to WebSphere MQ. Direct connection is the simplest and most popular method, and uses the WebSphere MQ JMS provider included in WebSphere Application Server. You simply use the WebSphere Application Server admin interfaces to configure the JMS resources offered by the WebSphere MQ JMS provider. These resources are typically of type JMS Connection Factory, JMS Queue, JMS Topic, or JMS Activation Specification.

Connecting indirectly to existing WebSphere MQ

There are two circumstances in which you might use WebSphere MQ as the messaging system with a less common, indirect approach to connecting WebSphere Application Server to WebSphere MQ. Indirect connection requires more complex configuration than the direct approach, but it does have two usage scenarios that you may find relevant. In both cases, WebSphere Application Server is configured to use the default messaging provider to connect the application to the SIBus, which in turn is configured to connect to WebSphere MQ.

Using WebSphere MQ indirectly for store and forward

Suppose you have a WebSphere Application Server application deployed to a server that is physically remote from the queue manager. If the application uses the WebSphere MQ JMS provider to connect directly to WebSphere MQ, it would connect to the queue manager using a synchronous connection, and therefore messages could be transmitted only when all of the application server, network, and queue manager are all available. A network outage would prevent the application from sending messages to the queue manager and could prevent the application from doing any useful work, reducing overall availability. One way to mitigate the risk of such an outage is to co-locate the queue manager with the application, but that may not be practical or affordable. An alternative mitigation is to connect the application to the SIBus, using a bus that the application server belongs to, so the application server will contain a messaging engine for the bus. Interaction between the application and messaging engine will be local and synchronous, and messages can be stored by the messaging engine until it can forward them asynchronously to the remote system, when the network is available. The application can therefore send messages even when there is no connectivity to other sites, enabling the application to function during a network outage.

Using WebSphere MQ indirectly to access a WebSphere MQ queue sharing group (QSG) prior to V7.0.1

The second scenario involves using a QSG hosted by queue managers on WebSphere MQ prior to V7.0.1. A QSG is a facility provided only by WebSphere MQ on z/OS, in which multiple queue managers concurrently operate on the same set of queues. Imagine that your application needs to connect to the QSG to send or receive a message as part of a distributed transaction. For example, a unit of work for the application might include receiving a request message, updating a database, and transmitting a response message. The operations on the database and queue manager must be performed within a distributed transaction, using a two-phase commit protocol. As with any two-phase protocol, if the connection between the application and queue manager is broken when a transaction has been prepared but not yet committed or rolled back, then the transaction will go in-doubt. Prior to WebSphere MQ V7.0.1 the transaction coordinator must reconnect to the same queue manager to resolve the in-doubt transaction. The WebSphere MQ JMS provider does not have a way to maintain affinity for recovery in a QSG. However, you can make the QSG a member of an SIBus. Configure the application to use the default messaging provider and hence connect to the SIBus, and to address the message to a destination that represents a queue within the QSG. SIBus manages affinity within the QSG and is able to resolve in-doubt transactions.

The above approach is only necessary prior to WebSphere MQ V7.0.1 because from that version onwards, the application can connect using the QSG name and use the GROUP unit of recovery disposition. The transaction coordinator can reconnect to any queue manager in the QSG to recover an in-doubt transaction.

Deciding to use an SIBus

As described above, you may want to use an existing messaging system that is well-established in your enterprise, or use the same messaging system as another application or service with which your JMS application will communicate. These considerations may lead you to choose an SIBus as the messaging system.

The SIBus performs two roles – it is both a messaging system supporting JMS applications, and the asynchronous transport for a number of Java-based Business Process Management products from IBM. Your organization may already be using an SIBus in either of these roles, in which case it may be best to capitalize on the existing skills, knowledge, and procedures. To connect the application to the SIBus, configure the application's JMS resources using the default messaging provider.

Choosing between WebSphere MQ and an SIBus

If your organization does not have an existing messaging infrastructure, or is migrating from other messaging systems to either WebSphere MQ or an SIBus, then your choice of messaging system should be influenced by the considerations described below. The foremost consideration is to select the messaging system that has the operational characteristics you require. The choice of JMS provider will follow. After you have selected your messaging system, your options are similar to the ones described above. You would normally use the default messaging provider to connect to an SIBus, or use the WebSphere MQ JMS provider to connect directly to WebSphere MQ.

Runtime environment and platform

If your application is running in a WebSphere Application Server Java EE environment, then its integration with WebSphere Application Server makes an SIBus a natural fit. If your environment is heterogeneous (including WebSphere Application Server and other non-Java technologies) then use WebSphere MQ. For example, if you are using WebSphere Message Broker or CICS, then WebSphere MQ is a natural choice. The physical platform on which your applications are running is not generally a significant factor, as both the SIBus and WebSphere MQ support a broad range of platforms.

Programming language

WebSphere MQ supports a wide range of programming languages. SIBus programming support consists primarily of JMS, although the SIBus does support C, C++, and C# through the IBM Message Service Clients for C/C++ and .NET, known as XMS. For more information, see the developerWorks article Introducing XMS -- The IBM Message Service API.

Monitoring tools

WebSphere MQ is a well-established product with a huge install base and a wide range of tooling support, including many excellent monitoring and management tools from both IBM and third parties.

Integration vs. isolation

The SIBus uses the WebSphere Application Server runtime, console, and command interfaces, which may be a benefit due to the integration of configuration and administration between WebSphere Application Server and the messaging system. Alternatively, you may prefer to use WebSphere MQ, because it does not run in the WebSphere Application Server process. As a result, you can offload the message processing into a separate process group isolated from WebSphere Application Server, so that it does not affect the JVM heap or other resources that are important to the WebSphere Application Server process and its deployed applications. Isolation may also simplify tuning, and can reduce the startup time of the application server.

High availability (HA)

A key consideration for HA is the downtime experienced when a failure occurs. Either the SIBus or WebSphere MQ can start quickly from a quiesced state in which it has relatively empty queues, but WebSphere MQ will typically start more quickly when there is a high volume of stored messages.

The way that you detect failures and orchestrate restarts depends on which messaging system you use. Both SIBus and WebSphere MQ failover can be managed by an external HA cluster framework, such as High Availability Cluster Multi-Processing (HACMP) or Veritas Cluster Server (VCS). An external HA cluster can be a good solution when integrating the messaging system into the resource management in your production environment. Where you don't need that integration, both the SIBus and WebSphere MQ have additional HA support that avoids the need for external clustering.

An SIBus messaging engine automatically exploits the built-in HA support in a WebSphere Application Server Network Deployment (ND) cluster. HA is therefore very easy to set up, and is the default in a cluster bus member.

WebSphere MQ V7.0.1 or later has an integrated HA mechanism that enables two machines to cooperatively run instances of a queue manager and perform a seamless failover when needed.

At the edges of your environment, where your messaging system interacts with the messaging system in another organization such as a business partner, the remote queue managers or messaging engines will connect to yours using an IP address. It is important to maintain the correlation between that IP address and the WebSphere MQ queue manager or SIBus messaging engine with which it is associated. A simple addressing scheme helps to isolate your external partners from your network topology, because it prevents them from needing to configure and maintain channel exits or search lists that reflect your topology. Affinity can be maintained with an external HA cluster framework somewhat more easily with WebSphere MQ than with an SIBus.

Message traffic profile

If you are using large messages, then WebSphere MQ may be a better choice. WebSphere MQ has an architectural limit on message size of 100 MB, and WebSphere MQ owns and controls its memory and can be tuned according to the message profile. An SIBus has no architected limit, and the empirical maximum is 40 MB on 32-bit systems and 80 MB on 64-bit systems. Because there is no hard limit, an SIBus is not as well isolated from the demands placed on the JVM heap by applications or other services. For an SIBus, a build-up of large messages (such as when a link is down) will place a lot of stress on the JVM heap.

Performance and scalability

As of Sep. 2011, performance of WebSphere MQ persistent messages is approximately twice as fast as SIBus persistent messages. There is little difference for non-persistent messages.

WebSphere MQ supports clustering of queue managers for enhanced throughput and scalability of administration. There are many examples of production clusters containing thousands of queue managers. WebSphere MQ clustering is extremely flexible, supporting selective parallelism of cluster queues, enabling you to independently tailor the number of instances of each cluster queue. SIBus messaging engines can be clustered within a WebSphere Application Server cluster for throughput and administrative scalability. However, a WebSphere Application Server cluster has a much lower scalability limit than a WebSphere MQ cluster, and if a queue is assigned to a WebSphere Application Server cluster bus member, it is partitioned across all messaging engines in the cluster – you cannot selectively locate partitions.


The SIBus is a component of WebSphere Application Server and therefore does not incur any additional cost, while WebSphere MQ is a separately licensed product. As of Sep. 2011, both products are sold on a capacity-based pricing model, and to form a meaningful comparison you would need to calculate the approximate capacity you would need for each product. Performance reports available from IBM can help you with this comparison.


This article introduced the concepts that underpin JMS, JMS providers, and messaging systems, and presented a number of factors to consider when deciding which messaging system and which JMS provider to use to support a JMS application. There may be organizational or compatibility reasons to use either WebSphere MQ or an SIBus, or you may be able to choose based purely on the functional characteristics of each messaging system, which were summarized above. In situations where it's preferable to use WebSphere MQ, you should generally configure your application to connect directly to WebSphere MQ using the WebSphere MQ JMS Provider in WebSphere Application Server. In other situations where it's preferable to use an SIBus, you should use the default messaging provider.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Choosing a messaging system: WebSphere MQ vs. the WebSphere Application Server Service Integration Bus