Types of messaging providers
We can configure any of three main types of Java Message Service (JMS) providers in WebSphere Application Server: The WAS default messaging provider (which uses service integration as the provider), the IBM MQ messaging provider (which uses the IBM 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:
The 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, we might already have a messaging infrastructure based on IBM MQ. In this case, we can either connect directly using the IBM MQ messaging provider, or configure a service integration bus with links to an IBM 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 we mainly want to use messaging between applications in WAS, perhaps with some interaction with an IBM 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 WAS 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 an IBM MQ system through the default messaging provider:
- Connect a bus to an IBM MQ network, using an IBM MQ link. The IBM MQ network appears to the service integration bus as a foreign bus, and the service integration bus appears to IBM MQ as another queue manager.
- Connect directly to IBM MQ queues located on IBM MQ queue managers or (for IBM MQ for z/OS ) queue-sharing groups, using an IBM MQ server bus member. Each IBM MQ queue is made available at a queue-type destination on the bus.
For more information about these two approaches, see Interoperation with IBM MQ: Comparison of key features.
To configure and manage messaging with the default messaging provider, see Manage messaging with the default messaging provider.
IBM MQ messaging provider
Through the IBM MQ messaging provider in WAS, Java Message Service (JMS) messaging applications can use the IBM MQ system as an external provider of JMS messaging resources.
Use WAS to configure IBM MQ resources for applications (for example queue connection factories) and to manage messages and subscriptions associated with JMS destinations. You administer security through IBM MQ.
IBM 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 IBM MQ for z/OS) and IBM MQ clustering simplify administration and provide dynamic discovery.
- Many IBM and partner products support IBM MQ with (for example) monitoring and control, high availability and clustering.
- IBM MQ clients can run within WAS (JMS), or almost any other messaging environment using a variety of APIs.
For more information about the IBM MQ messaging provider, see Interoperation using the IBM MQ messaging provider. To configure and manage messaging with this provider, see IBM MQ messaging provider.
Third-party messaging provider
We can configure any third-party messaging provider that supports the JMS Version 1.1 specification. We 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 Java EE Connector Architecture (JCA) 1.5-compliant or 1.6-compliant messaging provider) or the client (for a non-JCA messaging provider) supplied by the third party. We use the WAS administrative console to administer the activation specifications, connection factories and destinations that are within WAS, but we cannot use the administrative 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 Version 1.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:
