A JMS control makes it easy for your application to communicate with messaging systems. To better understand how to use a JMS control, it helps to understand messaging systems and how JMS control interact with them. This topic describes the characteristics of messaging systems that are accessible using Java Message Service (JMS), and explains how JMS interacts with them.
Messaging systems provide communication between software components. A client of a messaging system can send messages to, and receive messages from, any other client. Each client connects to a messaging server that provides facilities for sending and receiving messages. WebLogic JMS, which is a component of WebLogic Server, is an example of a messaging server. WebLogic Server also supports third-party messaging systems.
Messaging systems provide distributed communication that is asynchronous. This means that a component sends a message to a destination and a message recipient can retrieve messages from a destination, but the sender and receiver do not communicate directly. The sender only knows that a destination exists to which it can send messages, and the receiver also knows there is a destination from which it can receive messages. As long as they agree what message format and what destination to use, the messaging system manages the actual message delivery.
Messaging systems also provide reliability for message delivery. The
specific level of reliability is typically configurable on a per-destination
or per-client basis, but messaging systems are capable of guaranteeing that a
message will be delivered, and that it will be delivered to each intended
recipient exactly once.
JMS supports two basic styles of message-based communications: point-to-point
and publish-and-subscribe. Each is described in greater detail below.
Point-to-point messaging is accomplished with JMS queues, which are specific named resources configured in a JMS server. A JMS client, of which the JMS control is an example, sends messages to a queue or receives messages from a queue.
Point-to-point messages have a single consumer. Multiple receivers can
listen for messages on the same queue, but once any receiver retrieves a
particular message from the queue that message is consumed and is no longer
available to other potential consumers.
The messaging system continues to resend a particular message until a
predetermined number of retries have been attempted. Once the message is
received, a message consumer acknowledges receipt.
To learn more about sending messages to queues, see Supported and Unsupported Messaging Scenarios.
Publish-and-subscribe messaging is accomplished with JMS topics. A topic is a specific named resource configured in a JMS server.
A JMS client, of which the JMS control is an example, publishes messages to a topic, or subscribes to a topic. Published messages have multiple potential subscribers. All current subscribers to a topic receive all messages published to that topic after the subscription becomes active.
To learn more about publishing and subscribing to topics, see Supported and Unsupported Messaging Scenarios.
Before a JMS client can send or receive messages to a queue or topic, it must obtain a connection to the messaging system, via a connection factory. A connection factory is a resource that is configured by the message server administrator. The names of connection factories are stored in a JNDI directory, where clients wishing to make a connection can look them up.
There is a default connection factory pre-configured in WebLogic Workshop named cgConnectionFactory. You can use this connection factory for all JMS controls that do not explicitly override it.
To override the default connection factory and specify another connection factory for the control to use, you must (1) add the connection factory to the deployment descriptor (see the example weblogic-ejb-jar.xml file below) and (2) add the connection factory definition to the server's configuration file (see the example config.xml file below). If the JMS traffic is to be transacted then (3) you must also make sure that the connection factory is XA-enabled (see the example config.xml file below).
(1) To change the connection factory in the deployment descriptor, in the weblogic-ejb-jar.xml file, edit the connection-factory-jndi-name element to point to the new connection factory class.
weblogic-ejb-jar.xml
<weblogic-ejb-jar> <weblogic-enterprise-bean> <ejb-name>myMessageDrivenBean</ejb-name> <message-driven-descriptor> . . . <connection-factory-jndi-name>some.other.QueueConnectionFactory</connection-factory-jndi-name> . . . </message-driven-descriptor> <jndi-name>myMessageDrivenBean</jndi-name> </weblogic-enterprise-bean> </weblogic-ejb-jar>
For detailed information on the weblogic-ejb-jar.xml file, see weblogic-ejb-jar.xml Deployment Descriptor Reference in the WebLogic Server 8.1 documentation.
(2) To add the connection factory to the server's configuration file, add a <JMSConnectionFactory> element to the server's config.xml file.
(3) To ensure that the JMS traffic participates in transactions, set the XAConnectionFactoryEnabled attribute to true.
config.xml
<JMSConnectionFactory JNDIName="myMessageDrivenBean" Name="JMSConnectionFactory" Targets="myWebLogicServer" XAConnectionFactoryEnabled="true"/>
For detailed information on the <JMSConnectionFactory> element, see JMSConnectionFactory in the WebLogic Server 8.1 documentation.
To learn how to create, configure and register JMS queues, topics and connection factories, please consult the WebLogic Server documentation on Programming WebLogic JMS.