Question

Why are the createMessage, createTextMessage etc methods defined on the the Session interface in JMS? I can understand why when you send or received a message you would need the session but not why would you want to create the message you are going to send from it. Why when the designers of JMS were creating the interfaces for it did they decide messages should be created from the session rather than just newed up?

Answer 1

(Great API design question.)

You are conceptually confusing a “JMS message” with your message content.

Yes. It appears to a bit a conflated to address message life-cycle via the session. But if you consider the case of a disconnected node, it isn’t that strange a design decision.

The salient point is to note “why would a client want to create messages if not connected?” while considering the question of “what is a ‘message’ if stripped off of JMS metadata”? (Example of message metadata: message order.)

So, basically, it should be clear that minus the metadata (which is very much bound to both the session and the provider) your ‘user content’ really has nothing to do with JMS. In other words, conceptually you have the tuple:

{ [meta-data] : [user-content] }

So a “message” is really the above tuple. user-content is really just your data. I.e., if you are provided a generic (non-bound/disconnected) interface to generically “create messages”, all that is gained is the (un-necessary) creation of ‘generic’ ‘messages’ (which really just wrap your content) and lacks all the necessary ‘meta-data’ that would make it a proper “JMS Message”. At some point, that generic off-band message needs to be ‘converted’ to a proper JMS message, e.g. ordering metadata is added, timestamp is added, etc.

What did you gain from having those ‘generic’ “JMS” messages? (Nothing, it appears.)

As it is, creating messages from the session is both conceptually clearer and more efficient to implement.