Types of messaging providers
Configure any of three main types of JMS providers in WAS:
For backwards compatibility with earlier releases, WAS V7 supports...
This support enables the applications that still use these resources to communicate with V5 and V6 nodes in V7 mixed cells.
Default messaging provider
For messaging between applications in WAS, perhaps with some interaction with a WebSphere MQ system, the default messaging provider is sufficient.
To use the default messaging provider...
- Set a connection factory or activation spec to connect the application to a service integration bus.
- Assign a queue or topic to a bus destination on the bus. This topic or queue is then available to any application that can access the bus destination.
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...
- Within WAS (JMS)
- Stand-alone Java clients (J2SE Client for JMS)
- non-Java clients (XMS)
In a pure WAS environment, service integration provides the following benefits:
- An all-Java implementation for JMS within a single server process, yielding good performance for local JMS traffic.
- Direct delivery of messages to a consumer application that is ready to receive them, without first writing the messages to disk.
- Avoidance of copying and serialization of message payloads, if the application is written in accordance with the typical pattern of a messaging application.
- Full integration of the administration model with WAS, providing management of single and federated nodes within a cell.
- Full use of the provided WAS infrastructure for tracing and threading, and for a range of communications protocols with a single point of administration.
- Extensive interoperation with MQ networks.
There are two ways in which we can connect to a MQ system through the default messaging provider:
- Connect a bus to a MQ network, using a MQ link.
The MQ network appears to the service integration bus as a foreign bus, and the service integration bus appears to MQ as another queue manager.
- Connect directly to MQ queues located on MQ queue managers or (MQ for z/OS) queue-sharing groups, using a MQ server bus member.
Each MQ queue is made available at a queue-type destination on the bus.
MQ messaging provider
If the business also uses MQ, and you want to integrate WAS messaging applications into a predominately MQ network, choose the WebSphere MQ messaging provider.
With WebSphere MQ...
- 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 (MQ for z/OS) and MQ clustering provide dynamic discovery.
- Many IBM and partner products support MQ with monitoring and control, high availability and clustering.
- MQ clients can run within WAS JMS, or almost any other messaging environment using a variety of APIs.
For more information about scenarios and considerations for using MQ with WAS, see the WebSphere MQ library Web page
Third-party messaging provider
You can configure any third-party messaging provider that supports the JMS V1.1 unified connection factory. We might want to do this, for example, because of existing investments.
To administer a third-party messaging provider, use the resource adaptor or client supplied by the third party. You can still use the WAS admin console to administer the JMS connection factories and destinations that are within WAS, but we cannot use the admin 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 include Application Server Facility (ASF), an optional feature that is part of the JMS V1.1 specification, or use an inbound resource adapter that conforms to Java EE Connector Architecture (JCA) V1.5.
Related concepts
Introduction: Messaging resources
Related tasks
Choose a messaging provider
Manage messaging with the default messaging provider
Manage messaging with the MQ messaging provider
Manage messaging with a third-party messaging provider
Maintain (deprecated) V5 default messaging resources
Related
Comparison of WAS and MQ messaging
Related information
Interoperation with MQ: Comparison of key features
MQ library