управляемые сообщениями и управляемые событиями подходы к интеграции приложений

Question

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

Также очевидно, что обмен сообщениями поддерживает системы, основанные на публикации / подписке, синхронной или асинхронной связи, транзакциях и т. Д.

Но есть ли разница в контексте интеграции middleware / soa / application? (уровень архитектуры). Я пытаюсь обратиться к источникам, таким как Википедия ( здесь , и здесь ), но я все еще в некотором замешательстве. Когда разработчик должен предпочесть одно решение другому?

Существуют ли примеры или случаи, когда один подход имеет больше смысла, чем другой? Или какие-либо исчерпывающие ресурсы и руководства по реализации каждого из них?

Большое спасибо за понимание.

Answer 1

Вот точка зрения Typesafe / Реактивная на вопрос Йонаса Бонера. Из третьего абзаца этого блога :

Разница в том, что сообщения направлены, а события нет - у сообщения есть четко адресуемый получатель, в то время как событие просто происходит для других (0-N), чтобы его наблюдать.

Answer 2

Этот вопрос был задан давно. Я думаю, что более современный и ясный ответ дает Реактивный Манифест в Управляемом сообщениями (в отличие от Управляемого событиями) :

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

Answer 3

Коротким ответом на «есть четкое различие» будет «нет».

Термины не совсем взаимозаменяемы, но подразумевают одну и ту же базовую архитектуру, особенно в том, что вы будете запускать события или сообщения.

Первая статья, на которую вы ссылаетесь, посвящена низкоуровневой сантехнике, MOM или «шине pub-sub», которая передает сообщения от вашего имени. Основанная на событиях архитектура - это то, что вы строите поверх этой инфраструктуры.

Термин управляемый событиями, хотя и применяется к коду GUI, на самом деле не на том же уровне абстракции. В этом случае это небольшой шаблон по сравнению с построением всего предприятия по линиям, управляемым сообщениями / событиями.

Answer 4

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

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

Answer 5

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

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

• Управляемый сообщениями : при размещении заказа служба заказов отправляет запрос на авторизацию в вашу платежную службу. Ваш сервис обрабатывает запрос и возвращает успех / неудачу в службу заказа. Первоначальный запрос и результат могут быть отправлены синхронно или асинхронно.
• Управляемый событиями : при размещении заказа служба заказа публикует событие NewOrder. Ваш платежный сервис подписывается на этот тип события, поэтому он запускается. Ваша служба обрабатывает запрос и публикует событие AuthorizationAccepted или AuthorizationDeclined. Служба заказа подписывается на эти типы событий. Все события асинхронны.

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

Недостатком подхода, основанного на событиях , является то, что систему в целом становится немного сложнее для понимания. Например, скажем, команда, работающая над сервисом Order, просит вас заменить событие AuthorizationDeclined другими событиями в зависимости от того, почему была отклонена кредитная карта (нет средств, счет закрыт, неверный адрес выставления счета и т. Д.). Если вы прекратите публиковать события AuthorizationDeclined, это нарушит какой-либо другой сервис? Если у вас есть много событий и услуг, это может быть трудно отследить.

Answer 6

Как хорошо сказано в этой статье, чтобы понять дизайн, управляемый событиями, вместо того, чтобы смотреть на то, что он представляет, мы должны наблюдать за тем, что он скрывает, и это не более чем основа программирования ; «стек вызовов».

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

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

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

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

Answer 7

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

Архитектура, управляемая событиями, фокусируется на том, как система функционирует. Большинство триггеров, которые рассматриваются как события в контексте EDA, являются событиями, генерируемыми другими способами, кроме клавиатуры и мыши. Это EDA, если это заставляет нас явно думать о генераторе событий, канале событий, механизме обработки событий.

Клавиатура и мышь являются очевидными генераторами событий, однако обработка этих событий уже обеспечивается различными средами или средами исполнения, и как Архитектор нам не нужно беспокоиться об этом. Есть другие события, которые являются определенными для определенной области - это то, что архитектор должен думать. Пример - события управления цепочками поставок - отбор, упаковка, отправка, распространение, продажа, продажа и т. Д. С технической точки зрения для приложений промышленного IoT такие события - считывание RFID, считывание биометрических данных, данные датчика, сканирование штрих-кода, генерируемые системой события события, о которых нужно явно позаботиться, потому что эти события определяют функциональность системы.

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

Answer 8

Если мы используем подход, управляемый событиями, мы обычно хотим отправлять исходный объект в этом событии - компонент, который опубликовал событие. Так что в подписчике мы можем получить не только данные, но и узнать, кто опубликовал это событие. Например. в мобильной разработке мы получаем вид, который может быть кнопкой, изображением или каким-то другим видом. И в зависимости от типа этого представления мы можем использовать различную логику в подписчике. В этом случае мы можем даже добавить некоторую обратную обработку, изменить исходный компонент - например, добавить анимацию к этим источникам View.

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