Войти
Управляемая событиями архитектура (EDA ) - это архитектура программного обеспечения парадигма, способствующая производству, обнаружению, потреблению и реакции на события.
Событие может быть определено как «значительное изменение в состоянии ». Например, когда потребитель покупает автомобиль, состояние автомобиля меняется с «продано» на «продано». Архитектура системы автосалона может рассматривать это изменение состояния как событие, о возникновении которого можно сообщить другим приложениям в этой архитектуре. С формальной точки зрения, то, что создается, публикуется, распространяется, обнаруживается или потребляется, является (обычно асинхронным) сообщением, называемым уведомлением о событии, а не самим событием, которое является изменением состояния, вызвавшим отправку сообщения. События не путешествуют, они просто происходят. Однако термин «событие» часто используется метонимически для обозначения самого уведомления, что может привести к некоторой путанице. Это связано с тем, что архитектуры, управляемые событиями, часто проектируются поверх архитектур, управляемых сообщениями, где такой шаблон взаимодействия требует, чтобы один из входов был только текстовым, сообщением, чтобы различать, как следует обрабатывать каждый обмен данными.
Этот архитектурный шаблон может применяться при разработке и реализации приложений и систем, которые передают события между слабо связанными программными компонентами и службами. Система, управляемая событиями, обычно состоит из источников (или агентов) событий, потребителей (или приемников) событий и каналов событий. Эмитенты несут ответственность за обнаружение, сбор и передачу событий. Генератор событий не знает потребителей события, он даже не знает, существует ли потребитель, и, если он существует, он не знает, как событие используется или обрабатывается. Раковины несут ответственность за применение реакции, как только событие представлено. Реакция может полностью или не может быть обеспечена самой раковиной. Например, приемник может просто нести ответственность за фильтрацию, преобразование и пересылку события другому компоненту или может обеспечивать автономную реакцию на такое событие. Каналы событий - это каналы, по которым события передаются от источников событий к потребителям событий. Знание о правильном распределении событий присутствует исключительно в канале событий. Физическая реализация каналов событий может быть основана на традиционных компонентах, таких как ориентированное на сообщения промежуточное программное обеспечение или двухточечная связь, для чего может потребоваться более подходящая исполнительная структура транзакций.
Построение систем на основе архитектуры, управляемой событиями, упрощает горизонтальную масштабируемость моделей распределенных вычислений и делает их более устойчивыми к сбоям. Это связано с тем, что состояние приложения может быть скопировано в несколько параллельных моментальных снимков для обеспечения высокой доступности. Новые события могут быть инициированы где угодно, но, что более важно, они распространяются по сети хранилищ данных, обновляя каждое по мере их поступления. Добавление дополнительных узлов также становится тривиальным: вы можете просто взять копию состояния приложения, передать ему поток событий и запустить с ним.
Управляемая событиями архитектура может дополнять сервис-ориентированную архитектуру (SOA), поскольку службы могут быть активированы триггерами, срабатывающими при входящих событиях. Эта парадигма особенно полезна, когда раковина не обеспечивает автономного управления.
SOA 2.0 развивает последствия, предоставляемые архитектурами SOA и EDA, до более богатого и надежного уровня за счет использования ранее неизвестных причинно-следственных связей для формирования нового паттерна событий. Этот новый шаблон бизнес-аналитики запускает дальнейшую автономную человеческую или автоматизированную обработку, которая экспоненциально увеличивает ценность предприятия за счет введения дополнительной информации в распознанный шаблон, чего раньше не могли достичь.
Событие может состоять из двух частей, заголовок события и тело события. Заголовок события может включать такую информацию, как имя события, отметка времени для события и тип события. В теле события содержатся подробные сведения об обнаруженном изменении состояния. Тело события не следует путать с шаблоном или логикой, которые могут применяться в ответ на возникновение самого события. CloudEvents предоставляет спецификацию с открытым исходным кодом для описания данных событий обычным способом.
Архитектура, управляемая событиями, может быть построена на четырех логических уровнях, начиная с обнаружения события (т. Е. Значимого временного состояния или факта), переходя к созданию его техническое представление в виде структуры события и заканчивается непустым набором реакций на это событие.
Первый логический уровень - это генератор событий, который определяет факт и представляет этот факт как сообщение о событии. Например, генератором событий может быть клиент электронной почты, система электронной коммерции, агент мониторинга или какой-либо физический датчик.
Преобразование данных, собранных из такого разнообразного набора источников данных, в единую стандартизированную форму данных для оценки - важная задача при разработке и реализации этого первого логического уровня. Однако, учитывая, что событие является строго декларативным фреймом, любые информационные операции могут быть легко применены, что устраняет необходимость в высоком уровне стандартизации.
Это второй логический слой. Канал событий - это механизм распространения информации, собранной от генератора событий, на механизм событий или приемник. Это может быть TCP / IP-соединение или любой тип входного файла (плоский, формат XML, электронная почта и т. Д.). Одновременно можно открыть несколько каналов событий. Обычно, поскольку механизм обработки событий должен обрабатывать их почти в реальном времени, каналы событий будут считываться асинхронно. События хранятся в очереди, ожидая обработки позже механизмом обработки событий.
Механизм обработки событий - это логический уровень, отвечающий за идентификацию события, а затем за выбор и выполнение соответствующей реакции. Он также может вызвать ряд утверждений. Например, если событие, которое поступает в механизм обработки событий, является идентификатором продукта, имеющегося на складе, это может вызвать такие реакции, как «Код продукта заказа» и «Уведомить персонал».
Это логический уровень, на котором показаны последствия события. Это можно сделать разными способами и формами; например, кому-то было отправлено электронное письмо, и приложение может отображать на экране какое-то предупреждение. В зависимости от уровня автоматизации, обеспечиваемого приемником (механизмом обработки событий), последующие действия могут не потребоваться.
Существует три основных стиля обработки событий: простой, потоковый и сложный. Эти три стиля часто используются вместе в зрелой управляемой событиями архитектуре.
Простая обработка событий касается событий, которые напрямую связаны с конкретными, измеримыми изменениями состояния. При простой обработке событий происходит заметное событие, которое инициирует последующие действия. Простая обработка событий обычно используется для управления потоком работы в реальном времени, тем самым сокращая время задержки и затраты.
Например, простые события могут создаваться датчиком, обнаруживающим изменения давления в шинах или температуры окружающей среды. Неправильное давление в шинах автомобиля вызовет простое событие от датчика, которое включит желтый свет, информирующий водителя о состоянии шины.
В обработке потока событий (ESP) происходят как обычные, так и заметные события. Обычные события (заказы, передачи RFID) проверяются на заметность и передаются подписчикам информации. Обработка потока событий обычно используется для управления потоком информации в реальном времени внутри и вокруг предприятия, что позволяет принимать своевременные решения.
Обработка сложных событий (CEP) позволяет рассматривать шаблоны простых и обычных событий, чтобы сделать вывод о том, что произошло сложное событие. Обработка сложных событий оценивает совокупность событий и затем принимает меры. События (заметные или обычные) могут пересекать типы событий и происходить в течение длительного периода времени. Корреляция событий может быть причинной, временной или пространственной. CEP требует использования сложных интерпретаторов событий, определения и сопоставления шаблонов событий, а также методов корреляции. CEP обычно используется для обнаружения бизнес-аномалий, угроз и возможностей и реагирования на них.
Онлайн-обработка событий (OLEP) использует асинхронные распределенные журналы событий для обработки сложных событий и управления постоянные данные. OLEP позволяет надежно составлять связанные события сложного сценария в гетерогенных системах. Тем самым он обеспечивает очень гибкие схемы распределения с высокой масштабируемостью и обеспечивает высокую согласованность. Однако он не может гарантировать верхнюю границу времени обработки.
Архитектура, управляемая событиями, чрезвычайно слабо связана и хорошо распределена. Эта архитектура широко распространена, потому что событие может быть почти любым и существовать практически где угодно. Архитектура чрезвычайно слабо связана, потому что само событие не знает о последствиях своей причины. например Если у нас есть система сигнализации, которая записывает информацию при открытии входной двери, сама дверь не знает, что система сигнализации добавит информацию, когда дверь открывается, только то, что дверь была открыта.
Управляемые событиями архитектуры имеют слабую связь в пространстве, времени и синхронизации, обеспечивая масштабируемую инфраструктуру для обмена информацией и распределенных рабочих процессов. Однако событийные архитектуры тесно связаны с семантикой базовой схемы событий и значений через подписки на события и шаблоны. Высокая степень семантической неоднородности событий в крупных и открытых развертываниях, таких как умные города и сенсорная сеть, затрудняет разработку и обслуживание систем, основанных на событиях. Для решения проблемы семантической связи в системах, основанных на событиях, использование приблизительного семантического сопоставления событий является активной областью исследований.
API Java Swing основан на архитектуре, управляемой событиями. Это особенно хорошо сочетается с мотивацией Swing предоставлять компоненты и функции, связанные с пользовательским интерфейсом. API использует условные обозначения (например, «ActionListener» и «ActionEvent»), чтобы связывать и организовывать проблемы, связанные с событиями. Класс, которому необходимо знать о конкретном событии, просто реализует соответствующий слушатель, переопределяет унаследованные методы и затем добавляется к объекту, запускающему событие. Очень простой пример:
открытый класс FooPanel расширяет JPanel реализует ActionListener {public FooPanel () {super (); JButton btn = new JButton («Нажми меня!»); btn.addActionListener (это); this.add (btn); } @Override public void actionPerformed (ActionEvent ae) {System.out.println ("Нажата кнопка!"); }}Другой вариант реализации - добавить слушателя к объекту как анонимный класс. Ниже приведен пример.
открытый класс FooPanel расширяет JPanel {общедоступный FooPanel () {super (); JButton btn = новый JButton («Нажми меня!»); btn.addActionListener (new ActionListener () {public void actionPerformed (ActionEvent ae) {System.out.println ("Нажата кнопка!");}}); this.add (btn); }}(() =>{'use strict'; class EventEmitter {constructor () {this.events = new Map ();} on (событие, слушатель) {if (typeof listener! = = 'функция') {throw new TypeError ('Слушатель должен быть функцией');} let listeners = this.events.get (событие); if (! listeners) {listeners = new Set (); this.events. set (событие, слушатели);} listeners.add (listener); return this;} off (event, listener) {if (! arguments.length) {this.events.clear ();} else if (arguments.length = == 1) {this.events.delete (событие);} else {const listeners = this.events.get (событие); if (listeners) {listeners.delete (listener);}} return this;} emit (event,... аргументы) {const listeners = this.events.get (событие); if (listeners) {for (let listener of listeners) {listener.apply (this, args);}} return this;}} this. EventEmitter = EventEmitter;}) ();Использование:
const events = new EventEmitter (); events.on ('foo', () =>{console.log ('foo');}); events.emit ('фу'); // Выводит "foo" events.off ('foo'); events.emit ('фу'); // Ничего не произойдет