| To make a messaging scheme work, all participants must agree on just what a message is. The JMS API defines a basic message structure that is not only simple, but also very flexible, allowing messages to be created to match formats suitable for non-JMS applications on heterogeneous platforms. As illustrated in Figure 15.4, a JMS message object is composed of Header fields, a set of application-specific properties, and a message body. Figure 15.4. The structure of a JMS message. Message Header Fields A header contains values used by both clients and providers to identify and route messages, for example the destination, a reply-to destination, the message type, and the message expiration time. All messages support the same standard set of header fields as described in Table 15.2. Table 15.2. JMS Supported Message Types | Header Field | Description | Defined By | | JMSCorrelationID | A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message. | Client application | | JMSDestination | Contains the destination (queue or topic) to which the message is to be delivered. When a message is sent, this value is ignored. After completion of the send, it holds the destination object specified by the sending method. When a message is received, its destination value must be equivalent to the value assigned when it was sent. | send() method | | JMSDeliveryMode | Contains the delivery mode ( PERSISTENT or NON_PERSISTENT ) specified when the message was sent. | send() method | | JMSDeliveryTime | Defines the earliest absolute time at which a message can be delivered to a consumer. | send() method | | JMSExpiration | When a message is sent, its expiration time is calculated as the sum of the time-to-live value specified on the send method and the current GMT. | send() method | | | If the time-to-live is specified as zero, expiration is set to zero, which indicates the message does not expire. | | | | When GMT is later than an undelivered message's expiration time, the message should be destroyed . WebLogic JMS removes expired messages from the system to prevent their delivery. | | | JMSMessageID | Contains a string value that uniquely identifies each message sent by a provider. When a message is sent, this value is ignored. When the message is received, it contains a provider-assigned value. | send() method | | JMSPriority | Contains the message's priority. When a message is sent, this value is ignored. After completion of the send, it holds the value specified by the method sending the message. JMS defines a 10-level 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. | Message consumer | | | JMS 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. | | | JMSRedelivered | Specifies a flag set when a message is redelivered because no acknowledgement was received. | JMS provider | | JMSReplyTo | The JMSReplyTo header field contains a queue or topic to which reply messages should be sent. | Client application | | | This feature can be used with the JMSCorrelationID header field to coordinate request/response messages. | | | JMSTimestamp | Contains the time a message was handed off to a provider to be sent. | Message consumer | | | It is not the time the message was actually transmitted because the actual send may occur later due to transactions or other client-side queuing of messages. | | | | (The value stored in this field is a Java millis time value.) | | | JMSType | Contains a message type identifier supplied by a client when a message is sent. | Client application | Message Property Fields (Optional) These fields contain a set of application-defined name /value pairs that are accessible via the getter and setter methods on the Message object. Although message property fields may be used for application-specific purposes, JMS provides them primarily for use in conjunction with message selectors for filtering messages by the consumer. Message Body A JMS message body contains the content being delivered from a producer to a consumer. JMS provides five types of message bodies that extend javax.jms.Message , which consists of message headers and properties, but no message body. The message types supported by WebLogic JMS are described in Table 15.3. Table 15.3. JMS Supported Message Types | Message Type | Description | | StreamMessage | A message containing a stream of Java primitives. | | MapMessage | Similar to HashTable , contains name-value pairs. | | TextMessage | Message containing a String; this includes XML strings. | | ObjectMessage | Message containing a serialized Java object. | | BytesMessage | Message containing a byte stream. Can be used to implement binary format messages for non-Java clients. | | XMLMessage | Not part of the JMS standard. However, WebLogic includes this message type to allow an application to construct and deconstruct an XML message using a DOM tree. XMLMessage extends the TextMessage message type. | |