Событийно-ориентированная архитектура — Википедия

Архитектура, управляемая событиями (англ. event-driven architecture, EDA) является шаблоном архитектуры программного обеспечения, позволяющим создание, определение, потребление и реакцию на события.

Событие можно определить как «существенное изменение состояния»^[1]. Например, когда покупатель приобретает автомобиль, состояние автомобиля изменяется с «продаваемого» на «проданный». Системная архитектура продавца автомобилей может рассматривать это изменение состояния как событие, создаваемое, публикуемое, определяемое и потребляемое различными приложениями в составе архитектуры.

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

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

Архитектура, управляемая событиями, соответствует сервисно-ориентированной архитектуре (SOA), поскольку сервисы могут активироваться триггерами, срабатывающими от входящих событий^[2][3].

Эта парадигма особенно полезна в случае, когда сток не предоставляет собственного исполнения действий.

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

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

Архитектура, управляемая событиями, состоит из четырёх логических слоев. Она начинается с фактического зондирования, его технического представления в форме события и заканчивается непустым множеством реакций на это событие.^[4]

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

Канал событий — механизм, по которому передаётся информация от генератора событий к обрабатывающему события механизму^[4] или стоку.

Это может быть соединение TCP/IP или входной файл любого типа (простой текст, формат XML, e-mail, и т. д.) В одно и тоже время может быть открыто несколько каналов событий. Обычно из-за требований обработки событий в режиме, приближенном к реальному времени, каналы событий считываются асинхронно. События сохраняются в очереди, ожидая последующей обработки механизмом обработки событий.

Механизм обработки событий является местом, где событие идентифицируется и выбирается соответствующая реакция на него, которая затем выполняется. Это также может привести к созданию ряда утверждений. Например, если пришедшее в механизм обработки событие сообщает, что «Продукт N заканчивается», этот факт может породить реакцию «Заказать продукт N» и «Уведомить персонал».^[4]

Здесь проявляются последствия события. Оно может проявляться различными способами и формами; к примеру, сообщение, посланное кому-либо, или приложение, выводящее какое-либо предупреждение на экран.^[4]. В зависимости от предоставляемого стоком (механизмом обработки событий) уровня автоматизации эти действия могут не потребоваться.

Существует три основных стиля обработки событий: простой, потоковый и сложный. Часто эти три стиля используются совместно в большой событийно-управляемой архитектуре^[4].

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

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

При обработке потока событий (event stream processing — ESP) происходят как обычные, так и известные события. Обычные события (команды, передачи RFID) проверяются на известность и передаются информационным подписчикам. Обработка потока событий обычно используется для управления потоком информации в реальном времени и на уровне предприятия, позволяя своевременное принятие решений^[4].

Обработка сложных событий позволяет рассматривать последовательности простых и обычных событий и делать вывод о наступлении сложного события. Обработка сложных событий оценивает взаимное влияние событий и затем предпринимает действия. События (известные или обычные) могут не соблюдать типизацию и возникать на протяжении длительных временных периодов. Корреляция событий может быть причинной, временной или пространственной. Обработка сложных событий требует использования сложных интерпретаторов событий, определения паттернов событий и их сопоставления, а также корреляционных методов. Обработка сложных событий обычно используется для определения и реакции на аномальное поведение, угрозы и возможности^[4].

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

Библиотека Java Swing основана на архитектуре, управляемой событиями. Это особенно хорошо сочетается с мотивацией Swing предоставить компоненты и функциональность, относящуюся к пользовательскому интерфейсу. Интерфейс использует соглашения о наименовании (например, «ActionListener» и «ActionEvent») для организации отношений между событиями. Класс, нуждающийся в оповещении о некотором событии, просто реализует соответствующего слушателя, переопределяет наследуемые методы и добавляется к объекту, порождающему событие. Ниже приведен простейший пример:

public class FooPanel extends JPanel implements ActionListener {     public FooPanel() {         super();          JButton btn = new JButton("Click Me!");         btn.addActionListener(this);          this.add(btn);     }      @Override     public void actionPerformed(ActionEvent ae) {         System.out.println("Button has been clicked!");     } } 

Альтернативой является внедрение слушателя в объект в виде анонимного класса. Ниже представлен пример.

public class FooPanel extends JPanel {     public FooPanel() {         super();          JButton btn = new JButton("Click Me!");         btn.addActionListener(new ActionListener() {             public void actionPerformed(ActionEvent ae) {                 System.out.println("Button has been clicked!");             }         });     } } 

Тот же код в функциональном стиле Java 8, с применением лямбда выражения вместо анонимного класса:

public class FooPanel extends JPanel {     public FooPanel() {         super();         JButton btn = new JButton("Click Me!");         btn.addActionListener(ae -> System.out.println("Button has been clicked!"));     } } 

Серверная JavaScript платформа активно использует генераторы событий (EventEmitter). Множество объектов в Node генерируют события: net.Server вызывает событие при каждом поступающем запросе, fs.readStream вызывает событие при открытии файла. Пример работы с EventEmitter:

bar.js:

var Foo = require("./foo.js").Foo,     foo = new Foo();  foo.addListener("write", function() {     console.log("Bar"); }); 

foo.js:

var EventEmitter = require("events").EventEmitter,     Foo = function() {         var foo = this;         foo.write = function() {             console.log("Foo");             foo.emit("write");         };         setTimeout(this.write, 3000);     };  Foo.prototype = new EventEmitter();  exports.Foo = Foo; 

• Событийно-ориентированное программирование
• Сервисно-ориентированная архитектура
• en:Event-driven SOA
• en:Space based architecture
• Обработка сложных событий
• Обработка потоков событий
• en:Staged event-driven architecture (SEDA)

• Статья, определяющая различия между EDA и SOA: How EDA extends SOA and why it is important by Jack van Hoof.
• Реальный пример потока бизнес-событий в SOA: SOA, EDA, and CEP — a winning combo by Udi Dahan.

• Industry website on Event Processing
• Website for the Event Processing Technical Society
• 5th Anniversary Edition: Event-Driven Architecture Overview, Brenda M. Michelson

Для улучшения этой статьи желательно: Найти и оформить в виде сносок ссылки на независимые авторитетные источники, подтверждающие написанное. Добавить иллюстрации. Оформить список литературы. После исправления проблемы исключите её из списка. Удалите шаблон, если устранены все недостатки.