Архитектура, управляемая событиями ( EDA ) — это парадигма архитектуры программного обеспечения , касающаяся создания и обнаружения событий .
Событие можно определить как «значительное изменение состояния ». [1] Например, когда потребитель покупает автомобиль, его состояние меняется с «продается» на «продано». Архитектура системы автосалона может рассматривать это изменение состояния как событие, о возникновении которого можно сообщить другим приложениям в архитектуре. С формальной точки зрения то, что создается, публикуется, распространяется, обнаруживается или потребляется, представляет собой сообщение (обычно асинхронное), называемое уведомлением о событии, а не само событие, которое представляет собой изменение состояния, которое вызвало отправку сообщения. События не путешествуют, они просто происходят. Однако термин «событие» часто используется метонимически для обозначения самого сообщения уведомления, что может привести к некоторой путанице. Это связано с тем, что архитектуры, управляемые событиями, часто разрабатываются поверх архитектур, управляемых сообщениями , где такой шаблон связи требует, чтобы один из входных данных был только текстовым, сообщением, чтобы различать способ обработки каждого сообщения.
Этот архитектурный шаблон может применяться при проектировании и реализации приложений и систем, которые передают события между слабосвязанными программными компонентами и службами . Система, управляемая событиями, обычно состоит из источников событий (или агентов), потребителей событий (или приемников) и каналов событий. Излучатели несут ответственность за обнаружение, сбор и передачу событий. Генератор событий не знает потребителей события, он даже не знает, существует ли потребитель, а в случае его существования он не знает, как событие используется или обрабатывается дальше. Приемники несут ответственность за применение реакции сразу после появления события. Реакция может быть полностью обеспечена самой раковиной, а может и не быть. Например, приемник может просто отвечать за фильтрацию, преобразование и пересылку события другому компоненту или может обеспечивать самостоятельную реакцию на такое событие. Каналы событий — это каналы, по которым события передаются от источников событий к потребителям событий. Знания о правильном распределении событий присутствуют исключительно внутри канала событий. [ нужна цитация ] Физическая реализация каналов событий может быть основана на традиционных компонентах, таких как промежуточное программное обеспечение, ориентированное на сообщения , или двухточечная связь, что может потребовать более подходящей исполнительной структуры транзакций [ уточнить ] .
Построение систем на основе архитектуры, управляемой событиями, упрощает горизонтальное масштабирование моделей распределенных вычислений и делает их более устойчивыми к сбоям. Это связано с тем, что состояние приложения можно копировать в несколько параллельных снимков для обеспечения высокой доступности. [2] Новые события могут быть инициированы где угодно, но, что более важно, они распространяются по сети хранилищ данных, обновляя каждое из них по мере их поступления. Добавление дополнительных узлов также становится тривиальным: вы можете просто взять копию состояния приложения, передать ей поток событий и работать с ней. [3]
Архитектура, управляемая событиями, может дополнять сервис-ориентированную архитектуру (SOA), поскольку службы могут активироваться триггерами, запускаемыми при входящих событиях. [4] [5] Эта парадигма особенно полезна, когда приемник не предоставляет какой-либо автономной исполнительной системы [ уточнить ] .
SOA 2.0 развивает возможности архитектур SOA и EDA на более богатом и надежном уровне за счет использования ранее неизвестных причинно-следственных связей для формирования нового шаблона событий. [ расплывчато ] Этот новый шаблон бизнес-аналитики запускает дальнейшую автономную человеческую или автоматизированную обработку, которая увеличивает ценность предприятия в геометрической прогрессии за счет введения дополнительной информации в признанный шаблон, чего невозможно было достичь ранее. [ нечеткий ]
Событие может состоять из двух частей: заголовка события и тела события. Заголовок события может включать такую информацию, как имя события, отметку времени события и тип события. Тело события предоставляет подробную информацию об обнаруженном изменении состояния. Тело события не следует путать с шаблоном или логикой, которая может применяться в ответ на возникновение самого события.
Архитектура, управляемая событиями, может быть построена на четырех логических уровнях, начиная с восприятия события (т. е. значимого временного состояния или факта), переходя к созданию его технического представления в форме структуры событий и заканчивая -пустой набор реакций на это событие. [6]
Первый логический уровень — это производитель событий, который распознает факт и представляет этот факт как сообщение о событии. Например, источником событий может быть почтовый клиент, система электронной коммерции, агент мониторинга или какой-либо физический датчик.
Преобразование данных, собранных из такого разнообразного набора источников данных, в единую стандартизированную форму данных для оценки, является важной задачей при разработке и реализации этого первого логического уровня. [6] Однако, учитывая, что событие представляет собой строго декларативный фрейм, любые информационные операции могут быть легко применены, что устраняет необходимость в высоком уровне стандартизации. [ нужна цитата ]
Это второй логический уровень. Канал событий — это механизм распространения информации, собранной от генератора событий, к обработчику событий [6] или приемнику. Это может быть соединение TCP/IP или любой тип входного файла (плоский, формат XML, электронная почта и т. д.). Одновременно можно открыть несколько каналов событий. Обычно, поскольку механизму обработки событий приходится обрабатывать их практически в реальном времени, каналы событий считываются асинхронно. События сохраняются в очереди, ожидая последующей обработки механизмом обработки событий.
Механизм обработки событий — это логический уровень, отвечающий за идентификацию события, а затем выбор и выполнение соответствующей реакции. Это также может вызвать ряд утверждений. Например, если событием, которое поступает в механизм обработки событий, является низкий идентификатор продукта на складе, это может вызвать такие реакции, как «Заказать идентификатор продукта» и «Уведомить персонал». [6]
Это логический уровень, на котором показаны последствия события. Это можно сделать разными способами и формами; например, кому-то отправлено электронное письмо, и приложение может отобразить на экране какое-то предупреждение. [6] В зависимости от уровня автоматизации, обеспечиваемого приемником (механизмом обработки событий), последующие действия могут не потребоваться.
Существует три основных стиля обработки событий: простой, потоковый и сложный. Эти три стиля часто используются вместе в зрелой, управляемой событиями архитектуре. [6]
Простая обработка событий касается событий, которые напрямую связаны с конкретными, измеримыми изменениями состояния. При простой обработке событий происходит заметное событие, которое инициирует последующие действия. Простая обработка событий обычно используется для управления потоком работы в реальном времени, тем самым сокращая время задержки и затраты. [6]
Например, простые события могут создаваться датчиком, обнаруживающим изменения давления в шинах или температуры окружающей среды. Неправильное давление в шинах автомобиля вызовет простое событие от датчика, в результате которого загорится желтый свет, информирующий водителя о состоянии шин.
При обработке потока событий (ESP) происходят как обычные, так и заметные события. Обычные события (заказы, передачи RFID) проверяются на предмет заметности и передаются подписчикам информации. Обработка потока событий обычно используется для управления потоком информации в реальном времени внутри и вокруг предприятия, что позволяет своевременно принимать решения. [6]
Обработка сложных событий (CEP) позволяет учитывать закономерности простых и обычных событий, чтобы сделать вывод о том, что произошло сложное событие. Сложная обработка событий оценивает стечение событий и затем принимает меры. События (примечательные или обычные) могут быть разных типов и происходить в течение длительного периода времени. Корреляция событий может быть причинной, временной или пространственной. CEP требует использования сложных интерпретаторов событий, определения и сопоставления шаблонов событий, а также методов корреляции. CEP обычно используется для обнаружения бизнес-аномалий, угроз и возможностей и реагирования на них. [6]
Онлайн-обработка событий (OLEP) использует асинхронные распределенные журналы событий для обработки сложных событий и управления постоянными данными. [7] OLEP позволяет надежно составлять связанные события сложного сценария в гетерогенных системах. Таким образом, это обеспечивает очень гибкие модели распределения с высокой масштабируемостью и обеспечивает высокую согласованность. Однако он не может гарантировать верхние границы времени обработки.
Архитектура, управляемая событиями, чрезвычайно слабо связана и хорошо распределена. Широкое распространение этой архитектуры обусловлено тем, что событие может быть практически чем угодно и существовать практически где угодно. Архитектура крайне слабосвязана, поскольку само событие не знает о последствиях своей причины. Например, если у нас есть система сигнализации, которая записывает информацию при открытии входной двери, сама дверь не знает, что система сигнализации добавит информацию при открытии двери, а просто знает, что дверь была открыта. [6]
Архитектуры, управляемые событиями, имеют слабую связь в пространстве, времени и синхронизации, обеспечивая масштабируемую инфраструктуру для обмена информацией и распределенных рабочих процессов. Однако архитектуры событий тесно связаны через подписки и шаблоны событий с семантикой базовой схемы событий и значений. Высокая степень семантической неоднородности событий в крупных и открытых объектах, таких как умные города и сенсорная сеть, затрудняет разработку и поддержку систем, основанных на событиях. Чтобы решить проблему семантической связи в системах, основанных на событиях, использование приблизительного семантического сопоставления событий является активной областью исследований. [8]
API Java Swing основан на архитектуре, управляемой событиями. Это особенно хорошо сочетается с мотивацией Swing предоставлять компоненты и функциональные возможности, связанные с пользовательским интерфейсом. API использует соглашение о номенклатуре (например, «ActionListener» и «ActionEvent») для связи и организации проблем событий. Класс, которому необходимо знать о конкретном событии, просто реализует соответствующий прослушиватель, переопределяет унаследованные методы, а затем добавляется к объекту, который запускает событие. Очень простым примером может быть:
общественный класс FooPanel расширяет JPanel реализует ActionListener { public FooPanel () { super (); JButton btn = новая JButton ( «Нажмите на меня!» ); кнопка . addActionListener ( это ); этот . добавить ( кнопка ); } @Override public void actionPerformed ( ActionEvent ae ) { System . вне . println ( "Кнопка нажата!" ); } } Альтернативно, другой вариант реализации — добавить прослушиватель к объекту как анонимный класс и, таким образом, использовать лямбда-нотацию (начиная с Java 1.8). Ниже приведен пример.
общественный класс FooPanel расширяет JPanel { общественный FooPanel () { супер (); JButton btn = новая JButton ( «Нажмите на меня!» ); кнопка . addActionListener ( ae -> System.out.println ( " Кнопка была нажата! " ) ) ; этот . добавить ( кнопка ); } } (() => { 'use strict' ; класс EventEmitter { конструктор () { this . события = новая карта (); } on ( событие , прослушиватель ) { if ( typeof прослушиватель !== 'функция' ) { throw new TypeError ( 'Слушатель должен быть функцией' ); } пусть слушатели = это . события . получить ( событие ); если ( ! слушатели ) { слушатели = новый набор (); этот . события . установить ( событие , слушатели ); } слушатели . добавить ( слушатель ); вернуть это ; } off ( событие , прослушиватель ) { if ( ! аргументы . длина ) { this . события . прозрачный (); } Еще если ( аргументы . длина === 1 ) { this . события . удалить ( событие ); } Еще { const слушатели = это . события . получить ( событие ); если ( слушатели ) { слушатели . удалить ( слушатель ); } } верните это ; } излучать ( событие , ... args ) { const прослушиватели = this . события . получить ( событие ); if ( слушатели ) { for ( let прослушиватель слушателей ) { lister . _ применить ( это , аргументы ); } } верните это ; } } этот . EventEmitter = EventEmitter ; })(); Использование:
константные события = новый EventEmitter (); события . on ( 'foo' , () => { console . log ( 'foo' ); }); события . излучать ( 'фу' ); // Печатает события "foo" . выкл ( «фу» ); события . излучать ( 'фу' ); // Ничего не случится События — один из фундаментальных элементов языка Object Pascal . Здесь используется модель одноадресной рассылки (один к одному), т. е. отправитель отправляет информацию только одному получателю. Преимущество этого ограничения состоит в том, что для него не требуется специальный прослушиватель событий. Само событие является указателем на метод другого объекта. Если указатель не пуст, при возникновении события вызывается обработчик события. События обычно используются в классах, поддерживающих графический интерфейс. Однако это не единственная область применения мероприятий. Следующий код является примером использования событий:
единица MyCustomClass ; интерфейсиспользует классы ; введите { определение вашего собственного события} TAccidentEvent = процедура ( Отправитель : TObject ; const AValue : Integer ) объекта ; TMyCustomObject = класс ( TObject ) Private FData : Integer ; // пример простого поля в классе FOnAccident : TAccidentEvent ; // событие - ссылка на метод в каком-то объекте FOnChange : TNotifyEvent ; // событие-ссылка на метод в некотором объекте процедура SetData ( Value : Integer ) ; // метод, который устанавливает значение поля в защищенной процедуре класса DoAccident ( const AValue : Integer ) ; виртуальный ; // метод, генерирующий событие на основе вашей собственной процедуры определения DoChange ; // метод, генерирующий событие на основе определения из публичного конструктора библиотеки VCL Create ; виртуальный ; // конструктор класса -деструктор Destroy ; переопределить ; // опубликованное свойство деструктора класса Data : TAccidentEvent read FData write SetData ; // объявление свойства в классе property OnAccident : TAccidentEvent read FOnAccident write FOnAccident ; // выставляем событие за пределы свойства класса OnChange : TNotifyEvent read FOnChange write FOnChange ; // выставляем событие за пределы процедуры класса MultiplyBy ( const AValue : Integer ) ; // метод, использующий собственное определение события end ; выполнение конструктор TMyCustomObject . Создавать ; начать FData := 0 ; конец ; деструктор TMyCustomObject . Разрушать ; начать FData := 0 ; унаследовано Уничтожить ; конец ; процедура TMyCustomObject . DoAccident ( const AValue : Integer ) ; начать , если назначено ( FOnAccident ), затем FOnAccident ( Self , AValue ) ; конец ; процедура TMyCustomObject . СделатьИзменить ; начать , если назначено ( FOnChange ), затем FOnChange ( Self ) ; конец ; процедура TMyCustomObject . MultiplyBy ( const AValue : Integer ) ; начать FData := FData * AValue ; если FData > 1000000 , то DoAccident ( FData ) ; конец ; процедура TMyCustomObject . SetData ( значение : целое число ) ; начать , если FData <> Значение , затем начать FData := Значение ; СделатьИзменить ; конец ; конец . Созданный класс можно использовать следующим образом:
... процедура TMyForm . ShowCustomInfo ( Отправитель : TObject ) ; начать , если отправителем является TMyCustomObject , то ShowMessage ( 'Данные изменились.' ) ; конец ; процедура TMyForm . PerformAcident ( Отправитель : TObject ; const AValue : Integer ) ; начать, если отправителем является TMyCustomObject, затем ShowMessage ( «Данные превысили 1000000! Новое значение: ' + AValue . ToString ) ; конец ; ... {объявление переменной, которая является объектом указанного класса} var LMyObject : TMyCustomObject ; ... {создание объекта} LMyObject := TMyCustomObject . Создавать ; ... {назначение методов событиям} LMyObject . ПриИзменении := МояФорма . ПоказатьПользовательскуюИнформацию ; ЛМойОбъект . При Аварии := МояФорма . ВыполнитьАцид ; ... {удаление объекта, когда он больше не нужен} LMyObject . Бесплатно ; ...