WebLogic Messaging API Class Library |

# IMessage Interface

The `IMessage` 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.

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 - An `IStreamMessage` object's message body contains a stream of primitive values. It is filled and read sequentially.
- Map - An `IMapMessage` object's message body contains a set of name-value pairs, where names are `String` objects, and values are primitive type objects. The entries can be accessed sequentially or randomly by name. The order of the entries is undefined.
- Text - An `ITextMessage` object's message body contains a `String` object. This message type can be used to transport plain-text messages, and XML messages.
- Object - An `IObjectMessage` object's message body contains a `Serializable` .Net object.
- Bytes - An `IBytesMessage` 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.

#### 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.

Other message header fields include `JMSMessageID` - a unique message identifier, `JMSDestination`, `JMSDeliveryMode`, `JMSPriority`, `JMSExpiration`, `JMSTimestamp`, `JMSRedelivered`, `JMSReplyTo`, and `JMSType`.

#### Message Properties

An `IMessage` 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 JMS select, or filter, messages on its behalf using application-specific criteria.

Property names 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 `ArgumentException` will be thrown.

Property values can be `boolean`, `sbyte`, `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 will likely handle data in a message's body or header field 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 are supported. The unmarked cases will throw a `MessageException`.

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

| boolean | sbyte | short | int | long | float | double | String
--- | --- | --- | --- | --- | --- | --- | --- | ---
boolean | x |  |  |  |  |  |  | x
sbyte |  | 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 `bool`, `sbyte`, `short`, `int`, `long`, `float`, `double`, and `String`. An attempt to use any other class will throw a `MessageFormatException`.

The `GetObjectProperty` method only returns values of class `bool`, `sbyte`, `short`, `int`, `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 JMS API reserves the `JMSX` property name prefix for optional 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[] IConnectionMetaData.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.

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.

#### 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.

JMS supplies a set of message factories with its `ISession` object for creating instances of messages.

#### 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 `IMessageConsumer` being used.

Message selectors cannot reference message body values except via a WebLogic extension for XML text messages.

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 C# 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 C# 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 C# programming language.
  - The boolean literals `TRUE` and `FALSE`.
- Identifiers:
  - An identifier is an unlimited-length sequence of letters and digits, the first of which must be a letter. A letter is any character for which the method `Char.isLetter` returns true. This includes `'_'` and `'$'`. A letter or digit is any character for which the method `Char.isLetterOrDigit` returns true.
  - Identifiers cannot be the names `NULL`, `TRUE`, and `FALSE`.
  - Identifiers cannot be `NOT`, `AND`, `OR`, `BETWEEN`, `LIKE`, `IN`, `IS`, or `ESCAPE`.
  - Identifiers are either header field references or property references. The type of a property value in a message selector corresponds to the type used to set the property. If a property that does not exist in a message is referenced, its value is `NULL`.
  - The conversions that apply to the get methods for properties do not apply when a property is used in a message selector expression. For example, suppose you set a property as a string value, as in the following:

        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"

  - Identifiers are case-sensitive.
  - Message header field references are restricted to `JMSDeliveryMode`, `JMSPriority`, `JMSMessageID`, `JMSTimestamp`, `JMSCorrelationID`, and `JMSType`. `JMSMessageID`, `JMSCorrelationID`, and `JMSType` values may be null and if so are treated as a `NULL` value.
  - Any name beginning with `'JMSX'` is a JMS defined property name.
  - Any name beginning with `'JMS_'` is a provider-specific property name.
  - Any name that does not begin with `'JMS'` is an application-specific property name.
- White space is the same as that defined for the C# 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 C# 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 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)
  - `"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 will result in a `InvalidSelectorException`. 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 use the standard Java `long` millisecond value which is the difference, measured in milliseconds, between a given time time and midnight, January 1, 1970 UTC. When a date or time literal is included in a message selector, it should be an integer literal for a millisecond value. For an example of how to convert between Java millisecond timestamps and .NET times, see the API doc for `IMessage.JMSTimestamp`.

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.

For a list of all members of this type, see IMessage Members.

WebLogic.Messaging.IMessage
IBytesMessage
IMapMessage
IObjectMessage
IStreamMessage
ITextMessage

public interface IMessage

#### Requirements

Namespace: WebLogic.Messaging

Assembly: WebLogic.Messaging (in WebLogic.Messaging.dll)

#### See Also

IMessage Members | WebLogic.Messaging Namespace | Receive() | Receive(long) | ReceiveNoWait() | MessageEventHandler | IBytesMessage | IMapMessage | IObjectMessage | IStreamMessage | ITextMessage