Компромиссы, реализующие управление версиями сервисов, к которым обращается надежный асинхронный обмен сообщениями? - PullRequest
Новая
       11

Компромиссы, реализующие управление версиями сервисов, к которым обращается надежный асинхронный обмен сообщениями?

5 голосов
/ 16 июня 2009

Клиенты HTTP-сервисов могут указать версию (и формат), которую они понимают, запрашивая или публикуя данные с определенным типом контента. Протокол HTTP определяет коды ошибок для сообщения о том, что тип содержимого не понят.

Системы обмена сообщениями (например, JMS, MQ Series и т.п.) не имеют стандартного способа описания версий протокола сообщений и форматов контента.

Как вы реализовали управление версиями для сервисов, доступ к которым осуществляется через надежный асинхронный обмен сообщениями?

Некоторые возможности:

  • Отправитель указывает версию в качестве свойства сообщения
  • Имена очередей или тем включают версию протокола сообщений, принятых в этом месте назначения
  • Версия находится в полезной нагрузке сообщения

Я уверен, что есть другие способы. Как ты сделал это? Какие преимущества и недостатки вы нашли?

1 Ответ

1 голос
/ 16 июня 2009

Одно преимущество для указания версии вне полезных нагрузок состоит в том, что может быть легче выяснить, какой бит кода может справиться с полезной нагрузкой. Это также позволяет вам радикально изменить содержимое полезной нагрузки с новыми версиями. Это также может упростить маршрутизацию сообщений.

В целом, я не думаю, что здесь есть правильный или неправильный ответ, со всеми опциями, которые вы указали, можно работать, и ваша любимая шина обмена сообщениями может иметь "наилучшую практику", которой вы должны следовать.

...