Types of messaging providers

You can configure any of three main types of Java™ Message Service (JMS) providers in WebSphere® Application Server: The WebSphere Application Server default messaging provider (which uses service integration as the provider), the WebSphere MQ messaging provider (which uses your WebSphere MQ system as the provider) and third-party messaging providers (which use another company's product as the provider).


WebSphere Application Server supports JMS messaging through the following providers:

Your applications can use messaging resources from any of these JMS providers. The choice of provider is most often dictated by requirements to use or integrate with an existing messaging system. For example, you might already have a messaging infrastructure based on WebSphere MQ. In this case, you can either connect directly by using the WebSphere MQ messaging provider, or configure a service integration bus with links to a WebSphere MQ network and then access the bus through the default messaging provider.

You can have more than one type of messaging provider configured in WebSphere Application Server:
  • All types of provider can be configured within one cell.
  • Different applications can use the same, or different, providers.
  • One application can access multiple providers.

Default messaging provider

If you mainly want to use messaging between applications in WebSphere Application Server, perhaps with some interaction with a WebSphere MQ system, the default messaging provider is a logical choice. This provider uses service integration functions and is part of the WebSphere Application Server runtime environment.

To use the default messaging provider, your applications connect to a service integration bus. You can assign JMS queues (for point-to-point messaging) or JMS topics (for publish/subscribe messaging) as destinations on the service integration bus.

The default messaging provider is characterized as follows:
  • A service integration bus comprises messaging engines that run in WebSphere Application Server processes and dynamically connect to one another by using dynamic discovery. A messaging application connects to the bus through a messaging engine.
  • Messaging engines use WebSphere Application Server clustering to provide high availability and scalability, and they use the same management framework as the rest of WebSphere Application Server.
  • Bus client applications can run from within WebSphere Application Server (JMS), or run as stand-alone Java clients (using the J2SE Client for JMS) or run as non-Java clients (XMS).
There are two ways in which you can connect to a WebSphere MQ system through the default messaging provider:
  • Connect a bus to a WebSphere MQ network, by using a WebSphere MQ link. The WebSphere MQ network appears to the service integration bus as a foreign bus, and the service integration bus appears to WebSphere MQ as another queue manager.
  • Connect directly to WebSphere MQ queues located on WebSphere MQ queue managers or (for WebSphere MQ for z/OS®) queue-sharing groups, by using a WebSphere MQ server bus member. Each WebSphere MQ queue is made available at a queue-type destination on the bus.
For more information about these two approaches, see Interoperation with WebSphere MQ: Comparison of key features.

To configure and manage messaging with the default messaging provider, see Managing messaging with the default messaging provider.

WebSphere MQ messaging provider

Through the IBM® MQ messaging provider in WebSphere Application Server, Java Message Service (JMS) messaging applications can use your IBM MQ system as an external provider of JMS messaging resources.

You can use WebSphere Application Server to configure WebSphere MQ resources for applications (for example queue connection factories) and to manage messages and subscriptions associated with JMS destinations. You administer security through WebSphere MQ.

WebSphere MQ is characterized as follows:
  • Messaging is handled by a network of queue managers, each running in its own set of processes and having its own administration.
  • Features such as shared queues (on WebSphere MQ for z/OS) and WebSphere MQ clustering simplify administration and provide dynamic discovery.
  • Many IBM and partner products support WebSphere MQ with (for example) monitoring and control, high availability and clustering.
  • WebSphere MQ clients can run within WebSphere Application Server (JMS), or almost any other messaging environment by using a variety of APIs.

For more information about the WebSphere MQ messaging provider, see Interoperation using the WebSphere MQ messaging provider. To configure and manage messaging with this provider, see Managing messaging with the IBM MQ messaging provider.

Third-party messaging provider

You can configure any third-party messaging provider that supports the JMS Version 1.1 specification. You might want to do this, for example, if you have existing investments.

To administer a third-party messaging provider, you use either the resource adaptor (for a Java EE Connector Architecture (JCA) 1.5-compliant or 1.6-compliant messaging provider) or the client (for a non-JCA messaging provider) that is supplied by the third party. You use the WebSphere Application Server administrative console to administer the activation specifications, connection factories and destinations that are within WebSphere Application Server, but you cannot use the administrative console to administer the JMS provider itself, or any of its resources that are outside of WebSphere Application Server.

To use message-driven beans, third-party messaging providers must either provide an inbound JCA 1.5-compliant or 1.6-compliant-resource adapter, or (for non-JCA messaging providers) include Application Server Facility (ASF), an optional feature that is part of the JMS Version 1.1 specification.

To work with a third-party provider, see Managing messaging with a third-party JCA 1.5 or 1.6-compliant messaging provider or Managing messaging with a third-party non-JCA messaging provider.