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

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

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

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

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

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

Ответ 1

Короткий ответ на "есть ли четкое различие" будет "нет".

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

В первой статье вы ссылаетесь на низкоуровневую сантехнику, MOM или pub-sub "bus", которая переносит сообщения от вашего имени. Архитектура, управляемая событиями, - это то, что вы строите поверх этой структуры.

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

Концепция сообщения является абстрактной, более конкретными типами сообщений являются Event и Command.

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