Обмен сообщениями на основе событий - Event-driven messaging

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

Обоснование

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

Чтобы решить эту проблему, шаблон проектирования сообщений, управляемых событиями, предлагает механизм связи издатель-подписчик что обеспечивает своевременное уведомление потребителя услуги о данных о событии,^[2] тем самым устраняя неэффективность, связанную с традиционным механизмом связи на основе опроса.

использование

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

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

Для применения шаблона проектирования обмена сообщениями, управляемого событиями, требуется диспетчер событий, с которым поставщик услуг регистрирует свои события. Затем потребители услуг регистрируют свой интерес к некоторым или всем рекламируемым событиям. При возникновении события поставщик услуг информирует диспетчер событий, который затем немедленно уведомляет всех зарегистрированных потребителей услуг.^[3] Этот механизм коммуникации имеет общие корни с Образец наблюдателя применяется традиционно в объектно-ориентированный Мир.^[3] Этот шаблон проектирования также заимствует некоторые концепции из Событийная архитектура поскольку фундаментальное обоснование этого шаблона проектирования - реагирование на события.^[4]

Фактическая реализация такого механизма связи на основе издателя и подписчика требует архитектурных расширений для обеспечения такого сложного механизма отслеживания и пересылки сообщений. Зрелый ESB продукт обычно должен обеспечивать такую ​​функциональность. Применение этого шаблона помогает еще больше отделить^[5] потребителей услуг от поставщиков услуг и увеличивает общую надежность композиции услуг.

Соображения

Применение этого шаблона зависит от наличия базовых расширений платформы, которые, если они еще не присутствуют, повлекут за собой дополнительные расходы и, следовательно, повлияют на ИТ-бюджет. Также следует отметить, что модель издатель-подписчик основана на асинхронный обмен сообщениями, поэтому передача сообщения от диспетчера событий может происходить в любое время, что может означать, что если диспетчер событий транслирует сообщение с уведомлением о событии, то нет необходимости, чтобы потребитель службы был онлайн для его получения. Таким образом, применение этого шаблона проектирования не решает проблемы недоступности. Однако эту проблему можно решить, применяя асинхронная организация очереди^[6] и надежный обмен сообщениями^[7] шаблоны проектирования, которые гарантируют, что переданное сообщение всегда будет получено предполагаемым получателем вместе с сообщениями подтверждения.

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

Рекомендации

• Эрл и др., (2009).Шаблоны проектирования SOA. Прентис Холл. ISBN  0-13-613516-1.
• Михаил Сталь.Использование архитектурных шаблонов и чертежей для сервис-ориентированной архитектуры [Online]. Дата обращения: 1 мая 2010 г.

внешняя ссылка

• Концепции SOA
• Глоссарий терминов SOA
• Шаблоны проектирования SOA