11.3 Choosing what format to use within JMS messages
The choice of physical format within a JMS message is a key decision in architecting a messaging solution. In small messaging applications, using the various JMS message types...
...can be sufficient. It is often the case in enterprise solutions for a javax.jms.BytesMessage or javax.jms.TextMessage to be used in addition to physical formatting in order to facilitate more complex data structures.
The effect of an efficient physical format is not vital for performance; however, small gains can be achieved with efficient and effective message representation. The subject is covered here for completeness.
The size of a message body is also a performance consideration. A modest gain in performance may be gained from reducing the size of a heavily used JMS message in an application. In general, a series of small messages each with a specific purpose can perform better then a single verbose message. JMS 1.1 added BytesMessage.getBodyLength() which may prove useful in logging message payloads.
The following physical formats are the most common:
- XML
This is the most common message representation. It is an open standard which can be used by many modern platforms and enterprise systems. XML can be mapped to nearly any data representation using XSLT. It is popular for its ability to represent data in a format which both computer systems and people can read with standard tools.
However, there is a trade-off in additional payload associated with XML. It is text based with verbose, tagged formatting which is not an efficient physical format.
- Tagged delimited
A tagged delimited physical format uses a delimiter such as a colon to separate text fields. A tag, which is often a keyword, is used to identify the type of data a field contains. An example of a tagged delimited physical format is SWIFT which has been used in many large-scale enterprise applications.
- Record-oriented
A record-oriented physical format contains different types of fields with variable length. For example, a message may include an integer spanning two bytes and a string spanning 24 bytes. A struct in C is an example of a record-oriented physical format. A record-oriented message can provide the most efficient message, but comes at the cost of readability, maintainability, and inter-operability.
For a complete discussion of message formatting see the book Enterprise Messaging Using JMS and IBM WebSphere by Kareem Yusuf, Ph.D.. An excerpt on physical message formatting is available online at:
http://www.htmltr.com/articles/article.asp?p=170722