| The Message interface is the root interface of all JMS
messages. It defines the message header and the acknowledge
method used for all messages.
Most message-oriented middleware (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 the JMS API
to support all of these message models.
With this in mind, the JMS message model has the following goals:
- Provide a single, unified message API
- Provide an API suitable for creating messages that match the
format used by provider-native messaging applications
- Support the development of heterogeneous applications that span
operating systems, machine architectures, and computer languages
- Support messages containing objects in the Java programming language
("Java objects")
- Support messages containing Extensible Markup Language (XML) pages
JMS messages are composed of the following parts:
- Header - All messages support the same set of header fields.
Header fields contain values used by both clients and providers to
identify and route messages.
- Properties - Each message contains a built-in facility for supporting
application-defined property values. Properties provide an efficient
mechanism for supporting application-defined message filtering.
- Body - The JMS API defines several types of message body, which cover
the majority of messaging styles currently in use.
Message Bodies
The JMS API defines five types of message body:
- Stream - A
StreamMessage object's message body contains
a stream of primitive values in the Java programming
language ("Java primitives"). It is filled and read sequentially.
- Map - A
MapMessage object's message body contains a set
of name-value pairs, where names are String
objects, and values are Java primitives. The entries can be accessed
sequentially or randomly by name. The order of the entries is
undefined.
- Text - A
TextMessage object's message body contains a
java.lang.String object. This message type can be used
to transport plain-text messages, and XML messages.
- Object - An
ObjectMessage object's message body contains
a Serializable Java object.
- Bytes - A
BytesMessage object's message body contains a
stream of uninterpreted bytes. This message type is for
literally encoding a body to match an existing message format. In
many cases, it is possible to use one of the other body types,
which are easier to use. Although the JMS API allows the use of
message properties with byte messages, they are typically not used,
since the inclusion of properties may affect the format.
Message Headers
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 a provider-specific message ID,
an application-specific String object, or a provider-native
byte[] value.
Message Properties
A Message object 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, or filter, messages on its behalf using
application-specific criteria.
Property names must obey the rules for a message selector identifier.
Property names must not be null, and must not be empty strings. If a property
name is set and it is either null or an empty string, an
IllegalArgumentException must be thrown.
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. Note that header fields are distinct from
properties. Header fields are never in read-only mode.
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 use
message properties only 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
primitive's valueOf method does not accept the
String as a valid 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.
Attempting to read a null value as a primitive type must be treated as
calling the primitive's corresponding valueOf(String)
conversion method with a null value.
The JMS API 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 the JMS API. 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. If they are not present in a
message, they are treated like any other absent property.
JMSX properties defined in the specification as "set by provider on
send" are available to both the producer and the consumers of the message.
JMSX properties defined in the specification as "set by provider on
receive" are available only to the consumers.
JMSXGroupID and JMSXGroupSeq are standard
properties that 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.
The JMS API reserves the JMS_vendor_name property
name prefix for provider-specific properties. Each provider defines its own
value for vendor_name. 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 integrate JMS clients with provider-native clients in a
single JMS application. They should not be used for messaging between JMS
clients.
Provider Implementations of JMS Message Interfaces
The JMS API 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 messages. This allows
a provider to use message implementations tailored to its specific needs.
A provider must be prepared to accept message implementations that are
not its own. They may not be handled as efficiently as its own
implementation; however, they must be handled.
Note the following exception case when a provider is handling a foreign
message implementation. If the foreign message implementation contains a
JMSReplyTo header field that is set to a foreign destination
implementation, the provider is not required to handle or preserve the
value of this header field.
Message Selectors
A JMS message selector allows a client to specify, by
header field references and property references, the
messages it is interested in. Only messages whose header
and property values
match the
selector are delivered. What it means for a message not to be delivered
depends on the MessageConsumer being used (see
javax.jms.QueueReceiver QueueReceiver and
javax.jms.TopicSubscriber TopicSubscriber ).
Message selectors cannot reference message body values.
A message selector matches a message if the selector evaluates to
true when the message's header field values 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. If the value of a message selector
is an empty string, the value is treated as a null and indicates that there
is no message selector for the message consumer.
The order of evaluation of a message selector is from left to right
within precedence level. Parentheses can be used to change this order.
Predefined selector literals and operator names are shown here in
uppercase; however, they are case insensitive.
A selector can contain:
- Literals:
- A string literal is enclosed in single quotes, with a single quote
represented by doubled single quote; for example,
'literal' and 'literal''s'. Like
string literals in the Java programming language, these use the
Unicode character encoding.
- An exact numeric literal is a numeric value without a decimal
point, such as
57, -957, and
+62; numbers in the range of long are
supported. Exact numeric literals use the integer literal
syntax of the Java programming language.
- An approximate numeric literal is a numeric value in scientific
notation, such as
7E3 and -57.9E2, or a
numeric value with a decimal, such as 7.,
-95.7, and +6.2; numbers in the range of
double are supported. Approximate literals use the
floating-point literal syntax of the Java programming language.
- The boolean literals
TRUE and FALSE.
- Identifiers:
- White space is the same as that defined for the Java programming
language: space, horizontal tab, form feed, and line terminator.
- Expressions:
- A selector is a conditional expression; a selector that evaluates
to
true matches; a selector that evaluates to
false or unknown does not match.
- Arithmetic expressions are composed of themselves, arithmetic
operations, identifiers (whose value is treated as a numeric
literal), and numeric literals.
- Conditional expressions are composed of themselves, comparison
operations, and logical operations.
- Standard bracketing
() for ordering expression evaluation
is supported.
- Logical operators in precedence order:
NOT,
AND, OR
- Comparison operators:
=, >, >=,
<, <=, <> (not equal)
- Only like type values can be compared. One exception is that it
is valid to compare exact numeric values and approximate numeric
values; the type conversion required is defined by the rules of
numeric promotion in the Java programming language. If the
comparison of non-like type values is attempted, the value of the
operation is false. If either of the type values evaluates to
NULL, the value of the expression is unknown.
- String and boolean comparison is restricted to
= and
<>. Two strings are equal
if and only if they contain the same sequence of characters.
- Arithmetic operators in precedence order:
+, - (unary)
*, / (multiplication and division)
+, - (addition and subtraction)
- Arithmetic operations must use numeric promotion in the Java
programming language.
arithmetic-expr1 [NOT] BETWEEN arithmetic-expr2
AND arithmetic-expr3 (comparison operator)
"age BETWEEN 15 AND 19" is
equivalent to
"age >= 15 AND age <= 19"
"age NOT BETWEEN 15 AND 19"
is equivalent to
"age < 15 OR age > 19"
identifier [NOT] IN (string-literal1,
string-literal2,...) (comparison operator where
identifier has a String or
NULL value)
"Country IN (' UK', 'US', 'France')"
is true for
'UK' and false for 'Peru'; it is
equivalent to the expression
"(Country = ' UK') OR (Country = ' US') OR (Country = ' France')"
"Country NOT IN (' UK', 'US', 'France')"
is false for 'UK' and true for 'Peru'; it
is equivalent to the expression
"NOT ((Country = ' UK') OR (Country = ' US') OR (Country = ' France'))"
- If identifier of an
IN or NOT IN
operation is NULL, the value of the operation is
unknown.
identifier [NOT] LIKE pattern-value [ESCAPE
escape-character] (comparison operator, where
identifier has a String value;
pattern-value is a string literal where
'_' stands for any single character; '%'
stands for any sequence of characters, including the empty sequence;
and all other characters stand for themselves. The optional
escape-character is a single-character string
literal whose character is used to escape the special meaning of the
'_' and '%' in
pattern-value.)
"phone LIKE '12%3'" is true for
'123' or '12993' and false for
'1234'
"word LIKE 'l_se'" is true for
'lose' and false for 'loose'
"underscored LIKE '\_%' ESCAPE '\'"
is true for '_foo' and false for 'bar'
"phone NOT LIKE '12%3'" is false for
'123' or '12993' and true for
'1234'
- If
identifier of a LIKE or
NOT LIKE operation is NULL, the value
of the operation is unknown.
identifier IS NULL (comparison operator that tests
for a null header field value or a missing property value)
identifier IS NOT NULL (comparison operator that
tests for the existence of a non-null header field value or a property
value)
JMS providers are required to verify the syntactic correctness of a
message selector at the time it is presented. A method that provides a
syntactically incorrect selector must result in a JMSException.
JMS providers may also optionally provide some semantic checking at the time
the selector is presented. Not all semantic checking can be performed at
the time a message selector is presented, because property types are not known.
The following message selector selects messages with a message type
of car and color of blue and weight greater than 2500 pounds:
"JMSType = 'car' AND color = 'blue' AND weight > 2500"
Null Values
As noted above, property values may be NULL. The evaluation
of selector expressions containing NULL values is defined by
SQL92 NULL semantics. A brief description of these semantics
is provided here.
SQL treats a NULL value as unknown. Comparison or arithmetic
with an unknown value always yields an unknown value.
The IS NULL and IS NOT NULL operators convert
an unknown value into the respective TRUE and
FALSE values.
The boolean operators use three-valued logic as defined by the
following tables:
The definition of the AND operator
| AND | T | F | U
+------+-------+-------+-------
| T | T | F | U
| F | F | F | F
| U | U | F | U
+------+-------+-------+-------
The definition of the OR operator
| OR | T | F | U
+------+-------+-------+--------
| T | T | T | T
| F | T | F | U
| U | T | U | U
+------+-------+-------+-------
The definition of the NOT operator
| NOT
+------+------
| T | F
| F | T
| U | U
+------+-------
Special Notes
When used in a message selector, the JMSDeliveryMode header
field is treated as having the values 'PERSISTENT' and
'NON_PERSISTENT'.
Date and time values should use the standard long
millisecond value. When a date or time literal is included in a message
selector, it should be an integer literal for a millisecond value. The
standard way to produce millisecond values is to use
java.util.Calendar.
Although SQL supports fixed decimal comparison and arithmetic, JMS
message selectors do not. This is the reason for restricting exact
numeric literals to those without a decimal (and the addition of
numerics with a decimal as an alternate representation for
approximate numeric values).
SQL comments are not supported.
See Also: javax.jms.MessageConsumer.receive
See Also: javax.jms.MessageConsumer.receive(long)
See Also: javax.jms.MessageConsumer.receiveNoWait
See Also: javax.jms.MessageListener.onMessage(Message)
See Also: javax.jms.BytesMessage
See Also: javax.jms.MapMessage
See Also: javax.jms.ObjectMessage
See Also: javax.jms.StreamMessage
See Also: javax.jms.TextMessage |