2.2. JMS Message Basics


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

JMS message with headers, properties and body broken out

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:

Table 2.1. Java message types

Message TypeDescription
MessageBase message type. Payload is empty; only headers and properties are active. Typically used for simple event notification.
TextMessagePayload of type String. Typically used to transmit simple text and XML data.
MapMessagePayload of name/value pairs, with names of type String and values of Java primitive type.
BytesMessagePayload is an array of uninterpreted bytes.
StreamMessagePayload is a stream of Java primitive types, filled and read sequentially.
ObjectMessagePayload 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 JBoss A-MQ has a number of vendor specific message properties that are used to control how the broker treats messages, The JBoss A-MQ 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).