All Known Implementing Classes:
ObjectMessage, MapMessage, BytesMessage, StreamMessage, TextMessage
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:
JMS messages are composed of the following parts:
The JMS API defines five types of message body:
StreamMessage
object's message body contains
a stream of primitive values in the Java programming
language ("Java primitives"). It is filled and read sequentially.
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.
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.
ObjectMessage
object's message body contains
a Serializable
Java object.
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.
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.
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.
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.
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
QueueReceiver and
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:
'literal'
and 'literal''s'
. Like
string literals in the Java programming language, these use the
Unicode character encoding.
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.
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.
TRUE
and FALSE
.
Character.isJavaLetter
returns true. This includes '_'
and '$'
.
A letter or digit is any character for which the method
Character.isJavaLetterOrDigit
returns true.
NULL
,
TRUE
, and FALSE
.
NOT
, AND
,
OR
, BETWEEN
, LIKE
,
IN
, IS
, or ESCAPE
.
NULL
.
myMessage.setStringProperty("NumberOfOrders", "2");The following expression in a message selector would evaluate to false, because a string cannot be used in an arithmetic expression:
"NumberOfOrders > 1"
JMSDeliveryMode
, JMSPriority
,
JMSMessageID
, JMSTimestamp
,
JMSCorrelationID
, and JMSType
.
JMSMessageID
, JMSCorrelationID
, and
JMSType
values may be null and if so are treated as a
NULL
value.
'JMSX'
is a JMS defined
property name.
'JMS_'
is a provider-specific
property name.
'JMS'
is an
application-specific property name.
true
matches; a selector that evaluates to
false
or unknown does not match.
()
for ordering expression evaluation
is supported.
NOT
,
AND
, OR
=
, >
, >=
,
<
, <=
, <>
(not equal)
NULL
, the value of the expression is unknown.
=
and
<>
. Two strings are equal
if and only if they contain the same sequence of characters.
+
, -
(unary)
*
, /
(multiplication and division)
+
, -
(addition and subtraction)
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'))"
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'
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)
"prop_name IS NULL"
identifier IS NOT NULL
(comparison operator that
tests for the existence of a non-null header field value or a property
value)
"prop_name IS NOT NULL"
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"
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 +------+-------
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.
Field Summary | ||
---|---|---|
static final int | DEFAULT_DELIVERY_MODE | The message producer's default delivery mode is PERSISTENT .
|
static final int | DEFAULT_PRIORITY | The message producer's default priority is 4. |
static final long | DEFAULT_TIME_TO_LIVE | The message producer's default time to live is unlimited; the message never expires. |
Method from javax.jms.Message Detail: |
---|
All consumed JMS messages support the Calls to A client may individually acknowledge each message as it is consumed, or it may choose to acknowledge messages as an application-defined group (which is done by calling acknowledge on the last received message of the group, thereby acknowledging all messages consumed by the session.) Messages that have been received but not acknowledged may be redelivered. |
If this message body was read-only, calling this method leaves the message body in the same state as an empty body in a newly created message. |
The message's header fields and body are not cleared. |
boolean property with the
specified name. |
byte property with the specified
name. |
double property with the specified
name. |
float property with the specified
name. |
int property with the specified
name. |
This method is used to return correlation ID values that are
either provider-specific message IDs or application-specific
|
The use of a |
DeliveryMode value specified for this message. |
Destination object for this message.
The When a message is sent, this field is ignored. After completion
of the When a message is received, its |
When a message is sent, the If the time-to-live is specified as zero, When a message's expiration time is reached, a provider should discard it. The JMS API does not define any form of notification of message expiration. Clients should not receive messages that have expired; however, the JMS API does not guarantee that this will not happen. |
The When a message is sent, A All Since message IDs take some effort to create and increase a
message's size, some JMS providers may be able to optimize message
overhead if they are given a hint that the message ID is not used by
an application. By calling the
|
The JMS API defines ten levels of priority value, with 0 as the lowest priority and 9 as the highest. In addition, clients should consider priorities 0-4 as gradations of normal priority and priorities 5-9 as gradations of expedited priority. The JMS API does not require that a provider strictly implement priority ordering of messages; however, it should do its best to deliver expedited messages ahead of normal messages. |
If a client receives a message with the |
Destination object to which a reply to this
message should be sent. |
The When a message is sent, Since timestamps take some effort to create and increase a
message's size, some JMS providers may be able to optimize message
overhead if they are given a hint that the timestamp is not used by an
application. By calling the
|
|
long property with the specified
name. |
This method can be used to return, in objectified format,
an object that has been stored as a property in the message with the
equivalent |
Enumeration of all the property names.
Note that JMS standard header fields are not considered properties and are not returned in this enumeration. |
short property with the specified
name. |
String property with the specified
name. |
|
boolean property value with the specified name into
the message. |
byte property value with the specified name into
the message. |
double property value with the specified name into
the message. |
float property value with the specified name into
the message. |
int property value with the specified name into
the message. |
A client can use the
Since each message sent by a JMS provider is assigned a message ID
value, it is convenient to link messages via message ID. All message ID
values must start with the In some cases, an application (made up of several clients) needs to
use an application-specific value for linking messages. For instance,
an application may use If a provider supports the native concept of correlation ID, a JMS
client may need to assign specific |
The array is copied before the method returns, so future modifications to the array will not alter this message header. If a provider supports the native concept of correlation ID, a
JMS client may need to assign specific The use of a |
DeliveryMode value for this message.
JMS providers set this field when a message is sent. This method can be used to change the value for a message that has been received. |
Destination object for this message.
JMS providers set this field when a message is sent. This method can be used to change the value for a message that has been received. |
JMS providers set this field when a message is sent. This method can be used to change the value for a message that has been received. |
JMS providers set this field when a message is sent. This method can be used to change the value for a message that has been received. |
JMS providers set this field when a message is sent. This method can be used to change the value for a message that has been received. |
This field is set at the time the message is delivered. This method can be used to change the value for a message that has been received. |
Destination object to which a reply to this
message should be sent.
The Messages sent with a null Messages with a In some cases a client may wish to match a request it sent earlier
with a reply it has just received. The client can use the
|
JMS providers set this field when a message is sent. This method can be used to change the value for a message that has been received. |
Some JMS providers use a message repository that contains the
definitions of messages sent by applications. The The JMS API does not define a standard message definition repository, nor does it define a naming policy for the definitions it contains. Some messaging systems require that a message type definition for
each application message be created and that each message specify its
type. In order to work with such JMS providers, JMS clients should
assign a value to To ensure portability, JMS clients should use symbolic values for
|
long property value with the specified name into
the message. |
Note that this method works only for the objectified primitive
object types ( |
short property value with the specified name into
the message. |
String property value with the specified name into
the message. |