Creating a messaging-based application involves more than establishing communication channels between participants. Players in a message-driven system need to understand the content of the messages and know what to do with them.
Native messaging systems, such as WebSphere MQ or Microsoft MQ (MSMQ), define their own proprietary formats for messages. JMS attempts to bridge these native messaging systems by defining its own standard message format. All JMS clients can interact with any messaging system that supports JMS. “Supports” in this case can mean one of two things. The messaging system can be implemented in a native, proprietary architecture, with a JMS bridge that maps the JMS message formats (and other aspects of the JMS specification) to the native scheme and back again. Or the messaging system can be written to use the JMS message format as its native format.
JMS messages are made up of a set of standard header fields,
optional client-defined properties, and a body. JMS also provides a
set of subclasses of
support various types of message bodies.
Table 11-1 lists the standard header fields that any JMS message can have. The table indicates the name and type of the field, when the field is set in the message delivery process, and a short description of the semantics of the field.
Table 11-1. Standard JMS message headers