This chapter is from the book
This chapter is from the book
This chapter is from the book
JMS Messages
JMS messages, self-contained autonomous entities, are used to exchange information between JMS clients. A message can consist of data and/or logic exchanged between clients. A JMS message is created by a producer client and consumed by a JMS consumer client. A message consists of three parts: headers, properties, and payload. The header and property information is used by a messaging server for routing, filtering, and delivering the payload. The payload is the content of the message. This is very similar to a postal letter, which consists of an envelope that has a recipient's address and return address and may have optional special delivery information as well as an enclosed letter. JMS messages are composed of a header, properties, and the message body.
Message Header
The header section of a message consists of standard information necessary for a JMS provider to identify, route, manage, and deliver the message from a producer to a consumer client. There are two types of JMD headers: those that are automatically assigned by the JMS provider and others that a developer can assign. Table 12.1 briefly describes the header fields and what sets them.
The headers (JMSCorrelationID, JMSReplyTo, and JMSType) are assigned by the developer, while the rest are automatically assigned by the provider. There are setter and getter methods associated with these headers (documented in the Message interface), which enable these header fields to be manipulated properties.
Message Properties
Message properties are extensions to the standard message headers that provide additional customizable fields. The properties information enables clients to add information that may be used by the provider for filtering messages. For example, using the message selector to send a message to only username called "johnsmith" would be done in the following way: message.setStringProperty("johnsmith", username
The value of a property can be String, boolean, byte, double, int, long, or float.
Table 12-1 JMS Header Fields
|
Field |
Brief Description |
Set By |
|
JMSDestination |
Contains the destination to which a message is being sent. Depending on the messaging model, it could either be a Queueor a Topic. This information is used for routing messages. |
send() or publish()method |
|
JMDDeliveryMode |
Contains the delivery mode. There are two types: persistent or nonpersistent. In a persistent mode, a message is guaranteed to be delivered once and only once, while in nonpersistent mode, a message may be delivered at-most-once or not at all. |
send() or publish()method |
|
JMSExpiration |
Sets the length of the time during which a message is valid. The expiration time is set in milliseconds by the producer. If the expiration time is set to 0 (default), i.e., the message never expires. |
send() or publish()method |
|
JMSPriority |
Message servers use the priority field to order message delivery to consumers; higher- priority messages are delivered earlier than lower-priority messages. There are ten priority levels, 0 being the lowest and 9 being the highest. |
send() or publish()method |
|
JMSMessageID |
Uniquely identifies a message sent by a provider. The uniqueness isn't universally guaranteed and isn't required by JMS specification. This JMSMessageID must be a Stringvalue and must start with the prefix ID: |
send() or publish()method |
|
JMSTimeStamp |
Contains the approximate time in milliseconds when a send operation was invoked on the connection, which may not be the time the message was actually transmitted to the queue. |
send() or publish()method |
|
JMSCorrelationID |
Used for associating a message with some previous message or application-specific ID and is commonly used to tag a message as a follow up to a previous message. Frequently, although it's not required, the JMSCorrelationIDfield contains the JMSMessageID. |
Client |
|
JMSReplyTo |
Contains the destination to where the consumer client should reply. When a producer sends a message with JMSReplyTofield set, it's expecting a response from the consumer client. |
Client |
|
JMSType |
Used for identifying message structure and type of payload and not the type of message (TextMessage, MapMessage, etc.) being sent. This is an optional field. |
Client |
|
JMSRedelivered |
This field indicates whether the message was delivered to the consumer client. |
Provider |
There are three basic categories of message properties:
Application-specific properties—These are defined by the bean developers to suit the needs of their applications.
JMS-defined properties—These are set by the JMS provider; you can consider them extensions to header fields, but they're optional, and a given JMS provider might support some of none of these fields.
Provider-specific properties—Proprietary to the JMS provider, these properties allow the vendor to provide special features that only their client can use. These fields must have a JMS_<vendorName>prefix. Using these fields affects the portability of an application.
JMS messages can be filtered by using SQL syntax in the JMS message selector. The message selector is a java.lang.String that contains an expression having syntax based on the SQL-92 conditional expression syntax. When a message consumer registers with the destination, it can specify the filtering criteria by setting the message selector logic. The JMS provider is responsible for filtering the messages to the consumers. For example, if a message consumer were only interested in receiving messages containing the phrases "hot deal" and "Sony Laptop," the filtering message would look like the following:
TopicSubscriber subs = session.createSubscriber
("Hot Deal", "brand=Sony Laptop", false);
Or, if an e-commerce site wants to send out a special message to its best customers who spent, say, $1000 last year and live in the states of California and Washington, the message might look like this:
String selector = "Total > 1000.00 AND State IN
('CA', 'WA')";
TopicSubscriber subscriber = session.createSubscriber
(topic, selector, false);
Note that the message selector can filter only on fields in the header and properties.
Message Body
The payload, or message body, contains the content of the message—the data being exchanged between JMS clients. The message body supports five different message types to address the most common data types and to provide compatibility with existing messaging formats. The message is the superinterface for the message types (listed with brief descriptions in Table 12.2). The simplest type of message is the javax.jms.Message, which serves as a superinterface for other message types. The message type of message contains only JMS headers and properties and no payload. It's used mainly in event notification. An event notification is a simple warning or notice of an event or occurrence. The content of the message body is immutable, meaning it cannot be changed once it's created, thus requiring the content to be deleted and recreated if necessary.
Table 12-2 Message Types
|
Message Type |
Payload Description |
|
Message |
Superinterface for other message types; carries no payload. Used mainly for event notification. |
|
TextMessage |
Payload is plain text, i.e. java.lang.String. Useful for exchanging simple text messages or complex data using XML. |
|
MapMessage |
Payload is name/value pair where values can be Java primitives and their wrapper class and Strings. |
|
ObjectMessage |
Message body consists of serializable Java objects. |
|
StreamMessage |
Payload consists of stream of primitive Java types, which are read from the same order they were written using the file stream metaphor. |
|
ByteMessage |
Body consists of an array of primitive bytes intended for binary data and commonly used for exchanging data in an application native format. |