Java Tutorial - Java Scipt :
Message-Design Considerations
We’ve seen how JMS fits into the enterprise picture and have written some JMS clients. In fact, we’ve covered many areas of messaging and JMS, but until now we’ve neglected the actual message itself. What kinds of considerations are involved in designing messages? A message consists of the following parts:
The header: The header contains useful information about the message delivery. The JMSPriority in the header is of greatest interest to us here. By tweaking this, you can vary the quality of service. Bump up the priority of administration messages and drop down less critical messages. Good prioritization is critical for maintaining responsiveness under load.
The message properties section: Message selectors use message properties to select messages to consume. By carefully using the properties, we can avoid wasting resources on processing a message we’re not interested in. Be sure to use message selectors to filter your messages, because using your own code to filter within message consumers is inefficient. In the same vein, avoid creating multiple queues or topics when it makes more sense to use message selectors. A good rule of thumb is that the more consumption overlap, either physically or logically, the more likely you should be using selectors.
The message body: The message body is pretty much dependent on the message type. In our examples, we’ve encountered the TextMessage type. The other types are: BytesMessage, MapMessage, ObjectMessage, and StreamMessage, which is one of the neatest types. StreamMessage is very useful for encoding a playback sequence into a single message. It does use Java serialization, so be aware that it is more resource-intensive
than the other message types.
Designing a good message is not too complicated. Try to stay as lightweight as possible. Usually a minimal message is all that’s needed. You can always create a second message with more detail for those cases that do require additional information.
Keep in mind that a message could potentially be published to many subscribers, so an increase in overhead multiplied many times over is a very real possibility.
