Introduction
The Java Messaging Service, or JMS, is a mechanism that enables two or more processes to communicate. The nature and content of the messages are the province of software developers; we, as administrators, are concerned with seeing that the messages are delivered.
In the context of WebLogic, the term producer is used to describe a process that generates messages and sends them out into the world. The term consumer refers to processes that receive messages. Any application process may be a producer, a consumer, or both.
Messages may be sent under either a one-to-one connection protocol (usually called point-to-point or PTP) or a one-to-many connection protocol (usually called publish-and-subscribe or pub/sub). When they are sent point-to-point, the destination is referred to as a queue. When they are sent publish-and-subscribe, the destination is referred to as a topic. Topics and queues are collectively referred to as destinations.
Point-to-Point
In point-to-point messaging, each message generated by a producer will be received by exactly one consumer. Think of point-to-point messaging as being analogous to a physical mail message (as delivered by the post office), which can be delivered to only one consumer, as opposed to a piece of e-mail, which may be delivered to many consumers.
As you can see in Figure 8-1, the point-to-point model specifies that there will be exactly one producer and exactly one consumer per message. That's all it says, and you should be careful not to read any more into it. In particular, there is nothing that says the producer must send all messages to a single consumer. In PTP messaging, a single producer may send messages to more than one consumer, as long as any individual message goes to exactly one consumer.
Figure 8-1. The Point-to-Point Distribution Model
Another noteworthy feature is that the producer and consumer may switch roles. That is, the producer of the first message, M1, may be the consumer of the second message, M2.
Publish-and-Subscribe
In publish-and-subscribe (pub/sub) messaging, a producer generates messages that may be received by more than one consumer. Such messages are implemented with a broadcast mechanism called a topic. Again, we have one or more publishers generating messages that will be stored to a topic. However, in the pub/sub model we see that all subscribers to a given topic receive all messages published on that topic.
A few fine points about this model are worth mentioning. As shown in Figure 8-2, a consumer may subscribe to more than one topic at time. A topic may be published to by more than one publisher. Although not shown in Figure 8-2, there is nothing to stop a single process from publishing and subscribing to the same topic.
Figure 8-2. The Publish-and-Subscribe Distribution Model
Connections
Regardless of the type of messaging being done, consumer processes do not communicate directly with producer processes. Instead, all communication is done using a connection to JMS. A connection is an object created by a connection factory that contains the parameters needed to route messages between producer and consumer. Connections may reference either a PTP queue or a pub/sub topic.
In a sense, a connection factory is the bridge between you, the WebLogic administrator, and the application developer. All the connections utilized by an application must come from a connection factory. A connection factory is a JNDI-named class that is created within the WebLogic console.
Messages
JMS messages consist of three parts: a header containing exactly 10 fields (see below), an optional collection of key/value pairs called properties, and the message body.
| Header Field | Explanation |
|---|---|
| JMSMessageID | A unique ID number assigned by WebLogic server. |
| JMSDestination | The queue or topic to which the message is directed. |
| JMSDeliveryMode | Either “Persistent,” which specifies that the message should be stored to protect against server failure, or “Nonpersistent,” which is slightly faster but provides no safeguards against message loss. |
| JMSTimeStamp | A timestamp indicating when the server received the message. |
| JMSCorrelationID | This field may be used by the application to indicate a relationship to another message or object. |
| JMSReplyTo | The JNDI-named destination to which a reply should be directed. |
| JMSExpiration | Either 0, indicating that that message does not expire, or the number of milliseconds to expiration. |
| JMSType | This field could be used to specify a message type, but it isn't used by WebLogic. |
| JMSPriority | This field would specify the priority of the message, but it is not used by WebLogic. |
As mentioned above, the properties of a message are a collection of key=value pairs. In the context of WebLogic, these pairs are most commonly used by message selectors. A message selector is a class that enables a message consumer to examine the contents of a queue or topic and do some preselection without actually looking at the message content. This is convenient in that property values are available for preconsumption examination but the body of the message is not.
The body of a message is the part in which the consumer is typically interested. It may be one of five possible types:
| Bytes | A collection of bytes |
| Map | A sequence of key=value pairs, where the key is a string and the value is a Java primitive type |
| Object | A collection of one or more Java objects |
| Stream | A stream of Java primitive values |
| Text | A text string |