Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 2 Messages : Headers

Headers
Headers associate a fixed set of header field names with values. Clients and providers use headers to identify and route messages.
Programs can access header values using the function calls in Table 4.
However, programs can effectively set only three message header properties—Reply To, Correlation ID and Type. For all other header properties, the provider ignores or overwrites values set by client programs.
Correlation ID refers to a related message. For example, when a consumer responds to a request message by sending a reply, it can set the correlation ID of the reply to indicate the request message.
Message ID  A message ID is a unique string that the provider assigns to a message. Programs can use these IDs to correlate messages. For example, a program can link a response to a request by setting the correlation ID of a response message to the message ID of the corresponding request message.
Message ID strings begin with the prefix ID: (which is reserved for this purpose).
String  Programs can also correlate messages using arbitrary strings, with semantics determined by the application.
These strings must not begin with the prefix ID: (which is reserved for message IDs).
Byte Array  This implementation does not support byte array values for the correlation ID property. The JMS specification does not require support.
Delivery Mode instructs the server concerning persistent storage for the message. For detailed information on delivery modes, see the TIBCO Enterprise Message Service User’s Guide.
Sending calls set the destination (queue or topic) of the message in this header and will overwrite any existing value. The value is based on either a property of the producer, or on a parameter to the send call.
All message ID values start with the 3-character prefix ID: (which is reserved for this purpose).
The JMS specification defines ten levels of priority value, from zero (lowest priority) to 9 (highest priority). The specification suggests that clients consider 0–4 as gradations of normal priority, and priorities 5–9 as gradations of expedited priority.
Priority affects the order in which the server delivers messages to consumers (higher values first). The JMS specification does not require all providers to implement priority ordering of messages. (EMS supports priorities, but other JMS providers might not.)
false—The server has not previously attempted to deliver this message to the consumer.
true—It is likely (but not guaranteed) that the server has previously attempted to deliver this message to the consumer, but the consumer did not return timely acknowledgement.
Some JMS providers use a message repository to store message type definitions. Client programs can store a value in this field to reference a definition in the repository. EMS support this header, but does not use it.
Some providers require message type definitions for each application message. To ensure compatibility with such providers, client programs can set this header, even if the client application does not use it.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved