CODEWITHSUNDEEP
javajms
Chris
Chris

Reputation: 240

Why is createMessage method on the Session interface in JMS?

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?

Upvotes: 1

Views: 479

Answers (4)

alphazero
alphazero

Reputation: 27224

(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.

Upvotes: 1

AlexR
AlexR

Reputation: 115328

Each JMS provider has its own specific implementation, message properties etc. that are initialized by message factory. So, you need some kind of message factory anyway.

They could probably put factory methods on Connection instead of Session but they decided that it is easier that the same entity (session in our case) will be responsible on both creating and sending of messages.

I think that these are the main reasons.

Upvotes: 0

user964970
user964970

Reputation:

It's more or less a factory pattern for constructing messages. This allows implementations to decide how a message is constructed, it might need a lot of information from the current session, and allows that information to be pre-populated, and it'll be up to the implementation how to accomplish that. As the docs says:

"Each JMS provider supplies a set of message factories with its Session object for creating instances of messages. This allows a provider to use message implementations tailored to its specific needs."

Upvotes: 0

Peter Lawrey
Peter Lawrey

Reputation: 533492

There is a standard interface for TextMessage and other Messages, but not a standard implementation. This means you have more than one JMS provider you will have different implementations for these classes.

Upvotes: 0

Related Questions