2010/05/11 22:47:42

Event Driven Architecture

EDA (Event Driven Architecture) – архитектура, управляемая событиями. Это архитектура, в которой события начинают обмен сообщениями в реальном времени между свободными приложениями. EDA базируется на так называемые программы-агенты, которые обрабатывают события, чтобы находить события на предприятии и, воспользовавшись толкающим подходом, ставить в известность все другие приложения, которые нужно известить о данных событиях. Все это происходит в реальном времени. Заказ на восполнение запасов в EDA, который невозможно выполнить, обнаруживается и определяется системой обработки сложных событий как возможный дефицит для сервисной акции. Источники опубликовывают события, а подписчики получают их в процессе поступления. В архитектуре EDA публикация событий, подписка на события с поддержкой их буферизации в очередях и фильтрации, залог предоставления доставки событий в случае выхода из строя оборудования или сети должны иметь поддержку интеграционного программного обеспечения. Можно сказать, это целое научное направление, основоположником которого считается профессор Дэвид Лукхэм.

Предметом рассмотрения EDA является механизм доставки сообщений (т.е. событий, имеющих конкретную форму). Несмотря на то, что чаще встречаются случаи гибко настраиваемой под изменения среды логики маршрутизации, траектории следования сообщений могут быть четко определены принципами взаимодействия в клиент-серверном стиле. Таким образом, она может базироваться на современном устройстве оркестровки или маршрутизации на основе контента (content-based routing, CBR) каждого из сообщений. Важным является тот факт, что SOA не ограничивает рамок связанности систем. На основании этого часто говорят, что модель SOA является «слабо связанной». В результате взаимодействие с сервисами может быть прямым и опосредованным, т.е. выполняется при помощи всевозможных программных средств промежуточного слоя. К ним относятся такие интеграционные брокеры как (enterprise application integration, EAI) и очереди сообщений (message-oriented middleware, MOM).

Назначение EDA

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

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

Ключевые особенности

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

События и EDA

Сообщения о событиях, которые поступают в систему, распространяются по списку, а получателей таких сообщений называют подписчиками (subscriber); в роли подписчика может быть представлен челове или автомат. У всех этих сообщений имеется заголовок (header) и тело (event body). Заголовок состоит из относящихся к событию метаданных, в том числе: идентификатора спецификации события, указателя типа, имени события, отметки времени и источника. Тело события включает в себя описание самого события. Для того чтобы получатель мог предпринимать какие-то действия, не делая дополнительных запросов используя предоставленные данные, тело должно быть достаточно содержательным, а также оно должно содержать описание, подготовленное на принятом в бизнесе языке, или полную онтологию, чтобы смысл события был понятен подписчику. В EDA сообщение о последнем распределяется между подписчиками, которые каким-либо образом на него реагируют. Это может быть как вызов определенного сервиса так и перестройка бизнес-процесса, а также дальнейшее распространение сведений о событии, в том числе дополнительных. Архитектура такого плана является не просто слабо связанной, а очень слабосвязанной (extreme loose coupling) и распределенной. Источник или создатель сообщения знает только то, что сообщение передано, не участвуя при этом в его дальнейшей судьбе. По правде говоря, отследить траекторию отработки сообщения в условиях его распространения по подписке, практически невозможно. Вот почему наличие асинхронных потоков работ и входных данных подразумевается в EDA. Большое количество входных данных способны содержать только значимые события, которые оформлены в виде сообщений и готовы к отправке подписчикам, потоки единичных событий (такие как сведения, считанные с меток RFID), и потоки сложных событий. В зависимости от того, что входит в состав потоков событий архитектуры, EDA может быть систематизирована по стилю обработки. В одном случае происходит простое обрабатывание событий (simple event processing), которое подразумевает прямую передачу событий из входного потока в процессор обработки событий. В другом случае, в процессе многочисленной обработки событий (stream event processing), единичные события в первую очередь поступают в генератор, где из них с помощью фильтрации или иной предварительной обработки формируются значимые события, которые в свою очередь передаются в процессор событий. Третий случай - это обработка сложных событий (complex event processing). Он отличается тем, что единичные события не являются однородными. Система, которая строится по принципу архитектуры EDA, должна состоять из четырех основных компонентов:

Генератор событий (event generator). Имеет своей отличительной особенностью функциональность, которая зависит от стиля обработки событий; задачей этого компонента является первичная обработка, выделение из входного потока значимых событий.
Канал событий (event channel). Является внутренней магистралью, которая способна обезопасить транспортировку значимых событий из генератора в процессор.
Процессор событий (event processor). Соотносит полученные события с имеющимися правилами обработки, оценивает их, вырабатывает правильные решения, в том числе запуск определенных сервисов и бизнес-процессов, осуществляет прямые пересылки сведений о событиях и архивирование, а также направляет сообщения подписчикам,.
Управление последующими событиями (downstream event-driven activity). Необходимы соответствующие средства для управления, поскольку одно вводное событие может потребовать выполнения целого комплекса последующих действий.