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

Question

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

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

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

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

Большое спасибо за любую информацию.

Answer 1

Коротким ответом на вопрос "существует ли четкое различие" было бы "нет".

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

Answer 8

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

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

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

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

Answer 9

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

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