Message Structure

JMS defines a set of interfaces that represent the different types of messages classified by the type of content they can have. These interfaces extend the interface javax.jms.Message. The structure of a typical JMS message is depicted in the figure shown below:

Regardless of the type of the message, all JMS messages are composed of the three basic components shown above: the message header, message properties, and the message body.

Message Header

Message headers contain a set of standard fields defined by the JMS specification. JMS providers are required to provide access to all these header fields in their implementation classes. The values in the header fields are used for proper routing and processing of the messages. JMS header fields identify properties like message destination, message ID, delivery mode, priority, etc. Message headers are covered in detail in the coming sections.

Message Properties

Message properties are used in JMS for adding optional header fields to messages. JMS property values can be any of the Java primitive types, java. lang. String, or Java objects. The only Java objects supported are of wrapper types defined for the Java primitives like java. lang. Boolean, java. lang. Byte, etc. The interface javax.jms.Message defines methods for the different types of JMS properties. JMS defines three types of property:

• Standard Properties are the same as the header fields apart from the fact that they are optional. Standard properties have ‘JMSX’ as the property name prefix.

• Application Properties are custom properties that can be used by JMS clients for implementing application-specific logic.

• Provider Properties may be useful for the integration of JMS clients with the providers' non-JMS native clients. These properties are all defined by the JMS providers.

Note 

JMS properties are covered in detail in the coming sections.

Message Body

JMS defines messages that can support different messaging styles. JMS messages are categorized depending on the type of content they can have in the message body. JMS defines standard interfaces for these messages that extend the interface javax.jms.Message. The standard messages supported by JMS are listed below:

• BytesMessage

  Bytes messages are used for exchanging messages containing a stream of uninterpreted bytes, which can often be useful in integrating JMS clients with the provider's native messaging clients. The interface javax.jms.BytesMessage defines the methods for bytes messages.

• TextMessage

  Text messages are used for exchanging plain text. Text messages are very useful in exchanging XML documents. The interface javax.jms.TextMessage defines the methods for text messages.

• ObjectMessage

  Object messages are used for exchanging serialized Java objects. The interface javax.jms.ObjectMessage defines the methods for object messages.

• StreamMessage

  Stream messages are used for exchanging a stream of Java primitives, strings, and objects of types Java primitive wrapper classes. The interface javax.jms.StreamMessage defines the methods for stream messages.

• MapMessage

  Map messages are used for exchanging a map of name-value pairs. Names are always strings and values can be Java primitives, strings or objects of types Java primitive wrapper classes. The interface javax.jms.MapMessage defines the methods for map messages.

The interface javax.jms.Session defines various factory methods (see below) for creating optimized provider implementation of all the aforementioned interfaces. These methods were discussed in detail in the last chapter. The different types of JMS messages are covered in detail in the coming sections. Factory methods define an abstract interface for creating objects, and let the concrete implementation implement the real code for creating objects.

Note 

The Factory Method pattern is a special case of the Template Method pattern. In this pattern the factory method defines an interface for creating an object. However, it lets subclasses decide which class to instantiate. The Factory Method pattern, in addition to its more general Template Method pattern, is very common in framework design.