javax.jms
Interface Message

All Known Subinterfaces:
BytesMessage, MapMessage, ObjectMessage, StreamMessage, TextMessage
public abstract interface Message

The Message interface is the root interface of all JMS messages. It defines the JMS header and the acknowledge method used for all messages.

Most MOM products treat messages as lightweight entities that consist of a header and a payload. The header contains fields used for message routing and identification; the payload contains the application data being sent.

Within this general form, the definition of a message varies significantly across products. It would be quite difficult for JMS to support all of these message models.

With this in mind, the JMS message model has the following goals:

JMS Messages are composed of the following parts:

JMS defines five types of message body:

The JMSCorrelationID header field is used for linking one message with another. It typically links a reply message with its requesting message.

JMSCorrelationID can hold either a provider-specific message ID, an application-specific String or a provider-native byte[] value.

A Message contains a built-in facility for supporting application defined property values. In effect, this provides a mechanism for adding application specific header fields to a message.

Properties allow an application, via message selectors, to have a JMS provider select/filter messages on its behalf using application-specific criteria.

Property names must obey the rules for a message selector identifier.

Property values can be boolean, byte, short, int, long, float, double, and String.

Property values are set prior to sending a message. When a client receives a message, its properties are in read-only mode. If a client attempts to set properties at this point, a MessageNotWriteableException is thrown. If clearProperties is called, the properties can now be both read from and written to.

A property value may duplicate a value in a message's body or it may not. Although JMS does not define a policy for what should or should not be made a property, application developers should note that JMS providers will likely handle data in a message's body more efficiently than data in a message's properties. For best performance, applications should only use message properties when they need to customize a message's header. The primary reason for doing this is to support customized message selection.

Message properties support the following conversion table. The marked cases must be supported. The unmarked cases must throw a JMSException. The String to primitive conversions may throw a runtime exception if the primitives valueOf() method does not accept it as a valid String representation of the primitive.

A value written as the row type can be read as the column type. 


 |        | boolean byte short int long float double String 

 |----------------------------------------------------------

 |boolean |    X                                       X

 |byte    |          X     X    X   X                  X 

 |short   |                X    X   X                  X 

 |int     |                     X   X                  X 

 |long    |                         X                  X 

 |float   |                               X     X      X 

 |double  |                                     X      X 

 |String  |    X     X     X    X   X     X     X      X 

 |----------------------------------------------------------

In addition to the type-specific set/get methods for properties, JMS provides the setObjectProperty and getObjectProperty methods. These support the same set of property types using the objectified primitive values. Their purpose is to allow the decision of property type to made at execution time rather than at compile time. They support the same property value conversions.

The setObjectProperty method accepts values of class Boolean, Byte, Short, Integer, Long, Float, Double and String. An attempt to use any other class must throw a JMSException.

The getObjectProperty method only returns values of class Boolean, Byte, Short, Integer, Long, Float, Double and String.

The order of property values is not defined. To iterate through a message's property values, use getPropertyNames to retrieve a property name enumeration and then use the various property get methods to retrieve their values.

A message's properties are deleted by the clearProperties method. This leaves the message with an empty set of properties.

Getting a property value for a name which has not been set returns a null value. Only the getStringProperty and getObjectProperty methods can return a null value. The other property get methods must throw a java.lang.NullPointerException if they are used to get a non-existent property.

JMS reserves the `JMSX' property name prefix for JMS defined properties. The full set of these properties is defined in the Java Message Service specification. New JMS defined properties may be added in later versions of JMS. Support for these properties is optional. The String[] ConnectionMetaData.getJMSXPropertyNames method returns the names of the JMSX properties supported by a connection.

JMSX properties may be referenced in message selectors whether or not they are supported by a connection. They are treated like any other absent property.

JSMX properties `set by provider on send' are available to both the producer and the consumers of the message. JSMX properties `set by provider on receive' are only available to the consumers.

JMSXGroupID and JMSXGroupSeq are simply standard properties clients should use if they want to group messages. All providers must support them. Unless specifically noted, the values and semantics of the JMSX properties are undefined.

JMS reserves the `JMS_' property name prefix for provider-specific properties. Each provider defines there own value of . This is the mechanism a JMS provider uses to make its special per message services available to a JMS client.

The purpose of provider-specific properties is to provide special features needed to support JMS use with provider-native clients. They should not be used for JMS to JMS messaging.

JMS provides a set of message interfaces that define the JMS message model. It does not provide implementations of these interfaces.

Each JMS provider supplies a set of message factories with its Session object for creating instances of these messages. This allows a provider to use implementations tailored to their specific needs.

A provider must be prepared to accept message implementations that are not its own. They may not be handled as efficiently as their own implementations; however, they must be handled.

A JMS message selector allows a client to specify by message header the messages it's interested in. Only messages whose headers match the selector are delivered. The semantics of not delivered differ a bit depending on the MessageConsumer being used (see QueueReceiver and TopicSubscriber).

Message selectors cannot reference message body values.

A message selector matches a message when the selector evaluates to true when the message's header field and property values are substituted for their corresponding identifiers in the selector.

A message selector is a String, whose syntax is based on a subset of the SQL92 conditional expression syntax.

The order of evaluation of a message selector is from left to right within precedence level. Parenthesis can be used to change this order.

Predefined selector literals and operator names are written here in upper case; however, they are case insensitive.

A selector can contain: