Trade-offs implementing versioning of services accessed by reliable async messaging?

Question

Clients of HTTP services can specify the version (and format) they understand by requesting or posting data with a specific content type. The HTTP protocol defines error codes for reporting that the content type is not understood.

Messaging systems (e.g. JMS, MQ Series and the like) do not have a standard way of describing message protocol versions and content formats.

How have you implemented versioning for services accessed over reliable, asynchronous messaging?

Some possibilities:

• The sender indicates the version as a message property
• Queue or Topic names include the protocol version of the messages accepted at that destination
• The version is in the payload of the message

I'm sure there are other ways. How did you do it? What advantages and disadvantages did you find?

Answer 1

One advantage for specifying the version outside of payloads is that it can be easier to figure out which bit of code can cope with the payload. It also allows you to radically change the payload contents with new versions. It can also make it easier to route messages.

Overall I don't think there is a right or wrong answer here, all the options you specified can be worked with, and your favourite messaging bus may have a "best practice" that you should follow.