2.2. JMS Message Basics
Overview
Messages are the backbone of a messaging system and the most important part of the JMS specification. A messages is a self-contained autonomous entity that may be resent several times across many clients throughout its life span. Each consumer along a message's route will examine it and, depending on its contents, may execute some business logic, modify it, or create new messages to accomplish a communicated task.
Message anatomy
As shown in Figure 2.1, “Anatomy of a JMS message”, a JMS message consists of three components:
- headers
- properties
- body
Figure 2.1. Anatomy of a JMS message
Message body
The body component contains the payload, which can be textual or binary data, as specified by using one of the six supported Java message types:
| Message Type | Description |
|---|---|
Message | Base message type. Payload is empty; only headers and properties are active. Typically used for simple event notification. |
TextMessage | Payload of type String. Typically used to transmit simple text and XML data. |
MapMessage | Payload of name/value pairs, with names of type String and values of Java primitive type. |
BytesMessage | Payload is an array of uninterpreted bytes. |
StreamMessage | Payload is a stream of Java primitive types, filled and read sequentially. |
ObjectMessage | Payload is a serializable Java object. Usually used for complex Java objects, but also supports Java collections. |
Message headers
Message headers contain a predefined set of metadata that are used to communicate information about a message between the different parties that handle the message. The header properties are identified by a
JMS prefix and outlined in the JMS specification.
A number of the headers are automatically assigned by the producer's
send() method and some are automatically set by the broker. The remaining headers are left to the user to set when a message is created.
Message properties
Message properties, like message headers, provide metadata about a message to the different parties that handle the message. The difference between message headers and message properties is that message properties are not standardized. They allow JMS providers and client applications to add their own metadata to a message. A messaging client does not need to understand the properties to consume a message containing them. Unrecognized properties are simply ignored.
Client applications can create user-defined properties based on Java primitive types. The JMS API also provides generic methods for working with these user-defined properties.
Red Hat AMQ has a number of vendor specific message properties that are used to control how the broker treats messages, The AMQ specific properties are identified by the
JMSActiveMQBroker prefix.
There are a few JMS-defined properties that are identified by the
JMSX prefix. Vendors are not required to support all of these properties.
For a list of supported headers and properties, see ActiveMQ in Action (Snyder, Bosanac, and Davies).
