WAS v8.5 > WebSphere applications > Messaging resourcesTypes of messaging providers
We can configure any of three main types of JMS providers in WebSphere Application Server: The 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).
Overview
WAS 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, we can either connect directly 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.
We can have more than one type of messaging provider configured in WAS:
- 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 WAS, 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 WAS runtime environment.
To use the default messaging provider, the applications connect to a service integration bus. We 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 WAS processes and dynamically connect to one another using dynamic discovery. A messaging application connects to the bus through a messaging engine.
- Messaging engines use clustering to provide high availability and scalability, and they use the same management framework as the rest of WAS.
- Bus client applications can run from within WAS (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 we can connect to a WebSphere MQ system through the default messaging provider:
- Connect a bus to a WebSphere MQ network, 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, 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 manage messaging with the default messaging provider, see Manage messaging with the default messaging provider.
WebSphere MQ messaging provider
Through the WebSphere MQ messaging provider in WAS, JMS messaging applications can use your WebSphere MQ system as an external provider of JMS messaging resources.
We can use WAS 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 WAS (JMS), or almost any other messaging environment using a variety of APIs.
For more information about the WebSphere MQ messaging provider, see Interoperation using the WebSphere MQ messaging provider. To manage messaging with this provider, see Manage messaging with the WebSphere MQ messaging provider.
Third-party messaging provider
We can configure any third-party messaging provider that supports the JMS v1.1 specification. You might want to do this, for example, if we have existing investments.
To administer a third-party messaging provider, we use either the resource adaptor (for a JCA 1.5-compliant or 1.6-compliant messaging provider) or the client (for a non-JCA messaging provider) supplied by the third party. Use dmgr console to administer the activation specifications, connection factories and destinations that are within WAS, but we cannot use the dmgr console to administer the JMS provider itself, or any of its resources that are outside of WAS.
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 v1.1 specification.
To work with a third-party provider, see Manage messaging with a third-party JCA 1.5 or 1.6-compliant messaging provider or Manage messaging with a third-party non-JCA messaging provider.
Related concepts:
Interoperation with WebSphere MQ: Comparison of key features
Related
Choose a messaging provider
Manage messaging with the default messaging provider
Manage messaging with the WebSphere MQ messaging provider
Manage messaging with a third-party JCA 1.5 or 1.6-compliant messaging provider
Manage messaging with a third-party non-JCA messaging provider
Reference:
Comparison of WAS and WebSphere MQ messaging
Related information: