This page provides a starting point for finding information about the use of asynchronous messaging resources for enterprise applications with WebSphere® Application Server.
WebSphere® Application Server supports asynchronous messaging based on the JavaTM Message Service (JMS) and the Java EE Connector Architecture (JCA) specifications, which provide a common way for Java programs (clients and Java EE applications) to create, send, receive, and read asynchronous requests, as messages.
JMS support enables applications to exchange messages asynchronously with other JMS clients by using JMS destinations (queues or topics). Some messaging providers also allow WebSphere Application Server applications to use JMS support to exchange messages asynchronously with non-JMS applications; for example, WebSphere Application Server applications often need to exchange messages with WebSphere MQ applications. Applications can explicitly poll for messages from JMS destinations, or they can use message-driven beans to automatically retrieve messages from JMS destinations without explicitly polling for messages.
WebSphere Application Server supports the following messaging providers:
More introduction...
The default messaging provider is installed and runs as part of WebSphere Application Server, and is based on service integration technologies. For messaging between application servers, perhaps with some interaction with a WebSphere MQ system, you can configure your messaging applications to use messaging resources provided by the default messaging provider.
A JMS provider enables messaging based on the Java™ Messaging Service (JMS). It provides Java EE connection factories to create connections for JMS destinations. This panel is used to manage the default messaging provider and its JMS resources.
A JMS activation specification is associated with one or more message-driven beans and provides the configuration necessary for them to receive messages.
A JMS connection factory is used to create connections to the associated JMS provider of JMS destinations, for both point-to-point and publish/subscribe messaging. Use connection factory administrative objects to manage JMS connection factories for the default messaging provider.
A JMS queue connection factory is used to create connections to the associated JMS provider of JMS queues, for point-to-point messaging. Use queue connection factory administrative objects to manage JMS queue connection factories for the default messaging provider.
A JMS queue is used as a destination for point-to-point messaging. Use JMS queue destination administrative objects to manage JMS queues for the default messaging provider.
A JMS topic connection factory is used to create connections to the associated JMS provider of JMS topics, for publish/subscribe messaging. Use topic connection factory administrative objects to manage JMS topic connection factories for the default messaging provider.
A JMS topic is used as a destination for publish/subscribe messaging. Use topic destination administrative objects to manage JMS topics for the default messaging provider.
You can use these administrative commands to manage JMS resources for the default messaging provider.
Use the createSIBJMSActivationSpec command to create a new JMS activation specification for the default messaging provider at a specific scope.
Use the deleteSIBJMSActivationSpec command to delete a JMS activation specification for the default messaging provider at a specific scope.
Use the listSIBJMSActivationSpecs command to list all JMS activation specifications for the default messaging provider at a specific scope.
Use the modifySIBJMSActivationSpec command to change properties of a JMS activation specification for the default messaging provider at a specific scope.
Use the showSIBJMSActivationSpec command to show properties of a JMS activation specification for the default messaging provider at a specific scope.
Use the createSIBJMSConnectionFactory command to create a new JMS connection factory for the default messaging provider at a specific scope.
Use the deleteSIBJMSConnectionFactory command to delete a JMS connection factory for the default messaging provider at a specific scope.
Use the listSIBJMSConnectionFactories command to list all JMS connection factories for the default messaging provider at a specific scope.
Use the modifySIBJMSConnectionFactory command to modify the properties of a JMS connection factory for the default messaging provider at a specific scope.
Use the showSIBJMSConnectionFactory command to show the properties of a JMS connection factory for the default messaging provider at a specific scope.
Use the createSIBJMSQueue command to create a new JMS queue for the default messaging provider at a specific scope.
Use the deleteSIBJMSQueue command to delete a JMS queue for the default messaging provider at a specific scope.
Use the listSIBJMSQueues command to list all JMS queues for the default messaging provider at a specific scope.
Use the modifySIBJMSQueue command to change the properties of a JMS queue for the default messaging provider at a specific scope.
Use the showSIBJMSQueue command to show properties of a JMS queue for the default messaging provider at a specific scope.
Use the createSIBJMSTopic command to create a new JMS topic for the default messaging provider at a specific scope.
Use the deleteSIBJMSTopics command to delete a JMS topic for the default messaging provider at a specific scope.
Use the listSIBJMSTopics command to list all JMS topics for the default messaging provider at a specific scope.
Use the modifySIBJMSTopic command to change the properties of a JMS topic for the default messaging provider at a specific scope.
Use the showSIBJMSTopic command to show properties of a JMS topic for the default messaging provider at a specific scope.
Code your JMS applications so that you can safely pass message payloads by reference for asynchronous messaging between producer and consumer applications within a single server.
A JMS forwarder application receives a message (through a connection factory, or if it is a message-driven bean through an activation specification), then sends the message object on to another destination. Explore the different usage scenarios, then code your JMS forwarding applications so that you can safely pass message payloads by reference when forwarding messages from one queue to another within a single server.
Through the WebSphere MQ messaging provider in WebSphere Application Server, Java Message Service (JMS) messaging applications can use your WebSphere MQ system as an external provider of JMS messaging resources. To enable this approach, you configure the WebSphere MQ messaging provider in WebSphere Application Server to define JMS resources for connecting to any queue manager on the WebSphere MQ network.
For messaging between application servers, most requirements are best met by either the default messaging provider or the WebSphere MQ messaging provider. However, you can instead use a third-party messaging provider (that is, use another company's product as the provider). You might want to do this, for example, if you have existing investments. For backwards compatibility with earlier releases, there is also support for the V5 default messaging provider.
You can manage the Java EE Connector Architecture (JCA) Version 1.5-compliant message-driven beans that you deploy as message endpoints, and you can manage the message listener resources for non-JCA message-driven beans that you deploy against listener ports.