Take the 2-minute tour ×

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?

share|improve this question

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

share|improve this answer
I agree there's no right or wrong answer. Neither is there such a thing as a "best practice". That's why I asked for concrete experience. So, what mechanism did you use? In what context? What worked well? What problems did you encounter? –  Nat Jun 18 '09 at 21:31

Your Answer


