Почему вы используете систему на основе сообщений?

Ответ 1

Существует множество преимуществ использования систем на основе сообщений.

• Сообщения образуют четко определенный технологический нейтральный интерфейс между приложениями.
• Позволяет свободно связывать приложения.
• Множество вариантов производительности, настройки и масштабирования:
  • Разверните запросчик и процесс обслуживания на другом оборудовании
  • Несколько запросов, которые используют общий сервер
  • Несколько запросов, которые используют несколько серверов
• Различные средства обмена сообщениями реализуют общие шаблоны обмена сообщениями независимо от вашего приложения.
  • Запрос/Ответ
  • Пожар и анонимные обновления.
  • Publish/Subscribe
• Многие из продуктов промежуточного программного обеспечения обрабатывают преобразование сообщений (например, SWIFT в SWIFTXML).
• Многие из продуктов промежуточного программного обеспечения могут разложить один большой запрос на несколько меньших запросов.
• Они почти все поддерживают несколько платформ.

Кстати, двумя лидерами рынка в этой области являются IBM с их Websphere MQ и сопутствующими продуктами, а TIBCO - с корпоративной служебной шиной.

Ответ 2

Один из вариантов использования - это когда у вас есть пул ресурсов, которые могут работать на данном элементе, и список работ, которые необходимо распределять масштабируемым образом.

У меня когда-то был проект, где мне приходилось интегрировать мэйнфреймы с несколькими 3270 скреперами экрана (все медленно). Я мог бы открыть не более 10 из этих процессов на коробке за раз. У меня было тысячи учетных записей для очистки экрана и обновления, поэтому я поставил работу в очередь, и мои машины (у меня было около 3 из них) просто взяли рабочие элементы из очереди сообщений (MSMQ) и сделали очистку экрана, и все. Я мог бы легко развернуть новую машину или дезактивировать старые, не прерывая поток работы, так что это было хорошо.

Ответ 3

Архитектура, основанная на сообщениях, отменяет создание производителей и потребителей сообщений как во времени, так и в пространстве. Это имеет много преимуществ:

• производители и потребители могут работать на разных машинах.
• производители и потребители могут работать в разное время.
• производители и потребители могут работать на разных аппаратных/программных платформах (им нужно только понимать один и тот же протокол сообщений)
• легко координировать работу нескольких производителей/потребителей (например, для интенсивных вычислений, требующих нескольких машин, как описал Дейв Маркл)
• более высокая стабильность, когда услуги временно недоступны (например, при обработке заказов, использование системы обмена сообщениями может помочь избежать "отбрасывания" заказов)

Вы теряете большинство этих преимуществ, когда выполняете связь в стиле RPC (т.е. когда вы блокируете пока ожидаете ответа на обслуживание)

Ответ 4

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

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

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

Не думайте, что для архитектуры передачи сообщений требуются модные (и дорогостоящие!) продукты промежуточного программного обеспечения, хотя Windows работает на архитектуре передачи сообщений - каждое сообщение WM_ *, переданное в окно, - это... ну, сообщение, и я думаю, что показывает лучший пример архитектуры - ни одна часть системы не должна знать о какой-либо другой части, вы можете бесконечно расширять ее, поскольку вы можете обрабатывать столько элементов управления, сколько захотите, в любом диалоге и т.д. и т.д.

Передача сообщений - невероятная архитектура, хотя она может быть медленнее, чем плотное связывание приложения вместе, что не слишком важно для использования в настоящее время, особенно если вы уже используете скрипты или приложения .net.

Ответ 5

Я помог разработать его для системы, которая использовала С# и Remoting, клиент (служба или графический интерфейс) мог отправить сообщение в комплекте с некоторыми пользовательскими данными, и получатели (получатели) получили бы его либо при следующем подключении, либо в мгновение ока). Затем они могли обработать сообщение (взяв его владельцы в случае услуг балансировки нагрузки). Он также использовался для обновления графических интерфейсов, когда завершились длительные процессы.

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

• Хранение (создание/сохранение сообщения в базе данных)
• Маршрутизация (разработанная там, где нужно отправить сообщение)
• Безопасность (разработан, если клиенту разрешено его получать)
• Удалить (работает, если сообщение необходимо удалить из системы, что означает, что клиенты должны быть уведомлены, а сообщение удалено из него и помечено в БД).
• TakeOwnership (имеет дело с тем, что только один клиент может изменять состояние сообщения за раз, поскольку могут быть изменены только сообщения, которые находятся в собственности)

Таким образом, в ответ на ваш вопрос системы обмена сообщениями являются отличным средством отправки информации о том, когда вы не знаете или не заботитесь о том, кто является клиентом.

Ответ 6

Система, ориентированная на сообщения, обычно хороша для определенных классов задач интеграции. Другие альтернативы имеют общий хранилище данных (возможно, на основе файла или базы данных) для приложений, с которыми можно связаться, или приложений, интегрируемых через RPC.

Преимущества обмена сообщениями по этим шаблонам интеграции заключаются в том, что вы не связываете оба приложения с одной и той же схемой хранилища данных, и вы не привязываете приложения к сценарию интеграции с точкой в ​​точку RPC (который становится более сложным, чем больше приложений участие).

Также преимущества асинхронной связи (например, электронная почта или онлайн-чат), а также возможности маршрутизации сообщений и трансформации.