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

Question

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

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

Но есть разница в контексте ИНТЕГРАЦИЯ промежуточного/СОА/приложения? (уровень архитектуры). Я пытаюсь проконсультироваться с такими источниками, как wikipedia (here и here), но я все еще несколько смущен. Когда разработчик предпочитает одно решение над другим?

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

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

Answer 1

Короткий ответ на вопрос «есть ли четкое различие», было бы «нет».

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

Answer 5

См. Здесь Typesafe/Reactive Точка зрения на вопрос от Jonas Bonér. Из третьего абзаца от this blog post: «Разница заключается в том, что сообщения направлены, события не являются - сообщение имеет явный адресуемый получатель, а событие для других (0-N) происходит, чтобы наблюдать за ним».

Answer 6

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

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

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

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

Answer 7

Этот вопрос был задан давно. Я думаю, что более современный и ясный ответ дается Reactive Manifesto в Message-Driven (in contrast to Event-Driven):

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