Обмен сообщениями, управляемыми событиями
Сообщения , управляемые событиями, — это шаблон проектирования , позволяющий потребителям услуг, заинтересованным в событиях, происходящих на периферии поставщика услуг, получать уведомления об этих событиях по мере их возникновения, не прибегая к традиционному неэффективному опросе. механизму, основанному на . [1]
Важно различать сервисы, управляемые событиями, и сервисы , управляемые сообщениями (то есть управляемые очередью) : сервисы, управляемые событиями (например, AWS SNS ), отделены от своих потребителей. В то время как сервисы, управляемые очередями/сообщениями (например, AWS SQS ), связаны со своими потребителями. [2]
Обоснование
[ редактировать ]Взаимодействие между потребителем услуги и поставщиком услуги обычно инициируется потребителем услуги , поскольку ему необходимо отреагировать на событие, которое происходит внутри границ самого потребителя услуги, например, запрос некоторых данных из внешнего ресурса (т. е. поставщика услуг). для выполнения расчета, результаты которого необходимо передать обратно в пользовательский интерфейс в ответ на действие, выполненное пользователем. [3] Однако бывают ситуации, когда потребителю услуги необходимо дождаться возникновения события в границах самого поставщика услуг. В этих обстоятельствах потребитель услуг каким-то образом должен быть проинформирован о событии, когда и когда оно произойдет. Один из способов — запрограммировать потребителя службы на регулярный опрос поставщика услуг, чтобы он мог проверить, произошло событие или нет. Такой подход демонстрирует не только неэффективность, но и непредсказуемость поведения. Неэффективность, поскольку потребитель услуг и поставщик услуг вовлечены в непродуктивное взаимодействие, и ненадежность, поскольку может случиться так, что событие действительно произошло более одного раза, прежде чем потребитель услуг сможет опросить поставщика услуг, тем самым пропуская предыдущие события и связанные с ними данные. Помимо этих проблем, такой метод также приводит к задержке, поскольку интервал, с которым потребитель службы выполняет опрос, фиксирован и, следовательно, он будет получать данные о событии только в тот момент, а не тогда, когда событие действительно произошло. Весь этот сценарий ухудшается еще больше, если несколько потребителей услуг зависят от конкретного поставщика услуг.
Чтобы решить эту проблему, шаблон проектирования обмена сообщениями, управляемый событиями, предлагает механизм связи между издателем и подписчиком , который обеспечивает своевременное уведомление о данных, связанных с событиями, потребителю услуги. [4] тем самым устраняя неэффективность, связанную с традиционным механизмом связи на основе опроса.
Использование
[ редактировать ]
Чтобы узнать, произошло определенное событие или нет, потребитель службы через регулярные промежутки времени опрашивает поставщика услуг, что приводит к неэффективному взаимодействию служб.
Менеджер событий автоматически уведомляет всех заинтересованных потребителей услуг о наступлении того или иного события в момент его фактического возникновения.
Для применения шаблона проектирования обмена сообщениями, управляемого событиями, требуется менеджер событий, с помощью которого поставщик услуг регистрирует свои события. Потребители услуг затем регистрируют свой интерес к некоторым или всем рекламируемым событиям. При возникновении события поставщик услуг информирует об этом диспетчер событий, который затем мгновенно уведомляет всех зарегистрированных потребителей услуг. [5] Этот механизм связи имеет общие корни с шаблоном Observer , традиционно применяемым в объектно-ориентированном мире. [5] Этот шаблон проектирования также заимствует некоторые концепции из архитектуры, управляемой событиями , поскольку фундаментальным обоснованием этого шаблона проектирования является реагирование на события. [6]
Фактическая реализация такого механизма связи на основе издателя и подписчика требует архитектурных расширений, чтобы обеспечить такой сложный механизм отслеживания и пересылки сообщений. Зрелый продукт ESB обычно должен обеспечивать такую функциональность. Применение этого шаблона помогает еще больше отделить [7] потребителей услуг от поставщиков услуг и повышает общую надежность состава услуг.
Ссылки
[ редактировать ]- ^ Ваджид Хаттак, Виджай Нараянан. Сообщения, управляемые событиями [онлайн]. Дата обращения: 27 апреля 2010 г.
- ^ Доменно-ориентированное проектирование с использованием Java — Руководство для практикующего . 2022. ISBN 9781800564763 .
- ^ «Полное руководство по проверке компьютерной системы (CSV): что это такое и зачем оно нам?» . Группа QbD . Проверено 23 мая 2023 г.
- ^ Мауро. и др. Сервис-ориентированная интеграция устройств – анализ шаблонов проектирования SOA. Архивировано 3 февраля 2011 г. в Wayback Machine [Онлайн], стр. 1–10, 2010 г., 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата обращения: 4 апреля 2010 г.
- ^ Перейти обратно: а б Мауро и др. Стандартизированные службы устройств — шаблон проектирования для сервис-ориентированной интеграции медицинских устройств [онлайн]. Дата доступа: 4 апреля 2010 г.
- ^ Томас Эрл . Знакомство с шаблонами проектирования SOA. Архивировано 13 сентября 2010 г. на Wayback Machine [Онлайн]. Дата доступа: 4 апреля 2010 г.
- ^ Типы соединений
- Эрл и др. (2009). Шаблоны проектирования SOA . Прентис Холл. ISBN 0-13-613516-1 .
- Михаил Сталь. Использование архитектурных шаблонов и чертежей для сервис-ориентированной архитектуры [Онлайн]. Дата доступа: 1 мая 2010 г.