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