Compromises that implement version control of services accessed by reliable asynchronous messaging?

Question

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

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

How did you implement version control for accessing services through reliable asynchronous messages?

Some features:

• The sender indicates the version as a property of the message
• The names of the queues or names include the protocol version of the messages received at this destination
• Version is in message payload

I am sure there are other ways. How did you do that? What advantages and disadvantages have you found?

Answer 1

One advantage to specifying a version outside the payload is that it can be easier to determine which bit of code can handle the payload. It also allows you to radically change the contents of the payload with new versions. It also facilitates message routing.

In general, I don’t think there is a right or wrong answer here, all the parameters that you specified can be worked out, and your favorite messaging bus may have the “best practice” that you should follow.