Архитектура, управляемая событиями ( EDA ), — это парадигма архитектуры программного обеспечения, касающаяся создания и обнаружения событий . Архитектуры, управляемые событиями, эволюционны по своей природе и обеспечивают высокую степень отказоустойчивости , производительности и масштабируемости . Однако они сложны и по своей сути сложны для тестирования . EDA хороши для сложных и динамических рабочих нагрузок. [1]
Событие можно определить как «значительное изменение состояния ». [2] Например, когда потребитель покупает автомобиль, состояние автомобиля меняется с «продается» на «продано». Архитектура системы автодилера может рассматривать это изменение состояния как событие, возникновение которого может быть сообщено другим приложениям в архитектуре. С формальной точки зрения то, что производится, публикуется, распространяется, обнаруживается или потребляется, — это (обычно асинхронное) сообщение, называемое уведомлением о событии, а не само событие, которое является изменением состояния, вызвавшим отправку сообщения. События не перемещаются, они просто происходят. Однако термин « событие» часто используется метонимически для обозначения самого сообщения-уведомления, что может привести к некоторой путанице. Это связано с тем, что архитектуры, управляемые событиями, часто разрабатываются поверх архитектур, управляемых сообщениями , где такой шаблон коммуникации требует, чтобы один из входов был только текстовым, сообщением, чтобы различать, как следует обрабатывать каждое сообщение.
Этот архитектурный шаблон может применяться при проектировании и реализации приложений и систем, которые передают события между слабосвязанными программными компонентами и службами . Управляемая событиями система обычно состоит из излучателей событий (или агентов), потребителей событий (или приемников) и каналов событий. Излучатели несут ответственность за обнаружение, сбор и передачу событий. Излучатель событий не знает потребителей события, он даже не знает, существует ли потребитель, а если он существует, он не знает, как событие используется или обрабатывается далее. Приемники несут ответственность за применение реакции, как только событие представлено. Реакция может быть или не быть полностью предоставлена самим приемником. Например, приемник может просто нести ответственность за фильтрацию, преобразование и пересылку события другому компоненту или он может предоставлять самостоятельную реакцию на такое событие. Каналы событий являются проводниками, по которым события передаются от излучателей событий к потребителям событий. Знание о правильном распределении событий присутствует исключительно в канале событий. [ необходима цитата ] Физическая реализация каналов событий может быть основана на традиционных компонентах, таких как промежуточное программное обеспечение, ориентированное на сообщения , или связь точка-точка, для которых может потребоваться более подходящая транзакционная исполнительная структура [ уточнить ] .
Построение систем на основе событийно-управляемой архитектуры упрощает горизонтальную масштабируемость в распределенных вычислительных моделях и делает их более устойчивыми к сбоям. Это происходит потому, что состояние приложения может быть скопировано на несколько параллельных снимков для обеспечения высокой доступности. [3] Новые события могут быть инициированы в любом месте, но, что более важно, распространяются по сети хранилищ данных, обновляя каждое по мере поступления. Добавление дополнительных узлов также становится тривиальным: вы можете просто взять копию состояния приложения, передать ей поток событий и работать с ним. [4]
Архитектура, управляемая событиями, может дополнять архитектуру, ориентированную на сервисы (SOA), поскольку сервисы могут активироваться триггерами, запускаемыми при входящих событиях. [5] [6] Эта парадигма особенно полезна, когда приемник не предоставляет никакого автономного исполнителя [ уточнить ] .
SOA 2.0 развивает выводы, которые архитектуры SOA и EDA обеспечивают на более богатом и надежном уровне, используя ранее неизвестные причинно-следственные связи для формирования новой модели событий. [ неопределенно ] Эта новая модель бизнес-аналитики запускает дальнейшую автономную человеческую или автоматизированную обработку, которая добавляет экспоненциальную ценность для предприятия, вводя в распознанную модель информацию с добавленной стоимостью, чего нельзя было достичь ранее. [ неопределенно ]
Архитектура, управляемая событиями, имеет две основные топологии: «топология брокера», в которой компоненты транслируют события всей системе без какого-либо оркестратора. Она обеспечивает наивысшую производительность и масштабируемость. В то время как в «топологии медиатора» есть центральный оркестратор, который управляет рабочим процессом событий. Она обеспечивает лучшие возможности управления и обработки ошибок. Вы также можете использовать гибридную модель и комбинировать эти две топологии. [1]
Событие может состоять из двух частей: заголовка события и тела события. Заголовок события может включать такую информацию, как имя события, временная метка для события и тип события. Тело события предоставляет сведения об обнаруженном изменении состояния. Тело события не следует путать с шаблоном или логикой, которые могут быть применены в ответ на возникновение самого события.
Архитектура, управляемая событиями, может быть построена на четырех логических уровнях, начиная с восприятия события (т. е. значимого временного состояния или факта), переходя к созданию его технического представления в форме структуры события и заканчивая непустым набором реакций на это событие. [7]
Первый логический уровень — это производитель событий, который воспринимает факт и представляет этот факт как сообщение о событии. Например, производителем событий может быть почтовый клиент, система электронной коммерции, агент мониторинга или какой-либо тип физического датчика.
Преобразование данных, собранных из столь разнообразного набора источников данных, в единую стандартизированную форму данных для оценки является важной задачей при проектировании и реализации этого первого логического уровня. [7] Однако, учитывая, что событие является строго декларативным фреймом, любые информационные операции могут быть легко применены, тем самым устраняя необходимость в высоком уровне стандартизации. [ необходима цитата ]
Это второй логический уровень. Канал событий — это механизм распространения информации, собранной от генератора событий, к механизму событий [7] или приемнику. Это может быть соединение TCP/IP или любой тип входного файла (плоский, формат XML, электронная почта и т. д.). Несколько каналов событий могут быть открыты одновременно. Обычно, поскольку механизм обработки событий должен обрабатывать их в режиме, близком к реальному времени, каналы событий будут считываться асинхронно. События сохраняются в очереди, ожидая последующей обработки механизмом обработки событий.
Механизм обработки событий — это логический уровень, отвечающий за идентификацию события, а затем выбор и выполнение соответствующей реакции. Он также может инициировать ряд утверждений. Например, если событие, которое поступает в механизм обработки событий, — это идентификатор продукта, который находится на складе, это может инициировать такие реакции, как «Заказать идентификатор продукта» и «Уведомить персонал». [7]
Это логический уровень, на котором показаны последствия события. Это можно сделать разными способами и в разных формах; например, кому-то отправляется электронное письмо, а приложение может вывести на экран какое-то предупреждение. [7] В зависимости от уровня автоматизации, предоставляемого приемником (движком обработки событий), нисходящая активность может не потребоваться.
Существует три общих стиля обработки событий: простой, потоковый и сложный. Эти три стиля часто используются вместе в зрелой архитектуре, управляемой событиями. [7]
Простая обработка событий касается событий, которые напрямую связаны с конкретными, измеримыми изменениями состояния. При простой обработке событий происходит заметное событие, которое инициирует последующие действия. Простая обработка событий обычно используется для управления потоком работы в реальном времени, тем самым сокращая время задержки и стоимость. [7]
Например, простые события могут быть созданы датчиком, обнаруживающим изменения давления в шинах или температуры окружающей среды. Неправильное давление в шинах автомобиля сгенерирует простое событие от датчика, которое включит желтый свет, информирующий водителя о состоянии шины.
В обработке потока событий (ESP) происходят как обычные, так и заметные события. Обычные события (заказы, передачи RFID) проверяются на значимость и передаются подписчикам на информацию. Обработка потока событий обычно используется для управления потоком информации в реальном времени внутри и вокруг предприятия, что позволяет принимать решения вовремя. [7]
Обработка сложных событий (CEP) позволяет рассматривать шаблоны простых и обычных событий, чтобы сделать вывод о том, что произошло сложное событие. Обработка сложных событий оценивает слияние событий, а затем предпринимает действия. События (заметные или обычные) могут пересекать типы событий и происходить в течение длительного периода времени. Корреляция событий может быть причинной, временной или пространственной. CEP требует использования сложных интерпретаторов событий, определения и сопоставления шаблонов событий, а также методов корреляции. CEP обычно используется для обнаружения и реагирования на аномалии, угрозы и возможности в бизнесе. [7]
Онлайновая обработка событий (OLEP) использует асинхронные распределенные журналы событий для обработки сложных событий и управления постоянными данными. [8] OLEP позволяет надежно составлять связанные события сложного сценария в гетерогенных системах. Тем самым он обеспечивает очень гибкие шаблоны распределения с высокой масштабируемостью и предлагает сильную согласованность. Однако он не может гарантировать верхние границы времени обработки.
Архитектура, управляемая событиями, чрезвычайно слабосвязана и хорошо распределена. Большое распространение этой архитектуры существует потому, что событие может быть почти чем угодно и существовать почти где угодно. Архитектура чрезвычайно слабосвязана, потому что само событие не знает о последствиях своей причины. Например, если у нас есть система сигнализации, которая записывает информацию, когда открывается входная дверь, сама дверь не знает, что система сигнализации добавит информацию, когда дверь открывается, а знает только то, что дверь была открыта. [7]
Архитектуры, управляемые событиями, имеют слабую связь в пространстве, времени и синхронизации, обеспечивая масштабируемую инфраструктуру для обмена информацией и распределенных рабочих процессов. Однако архитектуры событий тесно связаны, через подписки на события и шаблоны, с семантикой базовой схемы событий и значений. Высокая степень семантической неоднородности событий в крупных и открытых развертываниях, таких как умные города и сенсорная сеть, затрудняет разработку и поддержку систем, основанных на событиях. Для решения проблемы семантической связи в системах, основанных на событиях, использование приблизительного семантического соответствия событий является активной областью исследований. [9]
Синхронные транзакции в EDA могут быть достигнуты с помощью парадигмы запрос-ответ , и это может быть реализовано двумя способами: [1]
Java Swing API основан на архитектуре, управляемой событиями. Это особенно хорошо работает с мотивацией Swing предоставлять компоненты и функциональность, связанные с пользовательским интерфейсом. API использует соглашение о номенклатуре (например, «ActionListener» и «ActionEvent») для связи и организации событий. Класс, которому необходимо знать о конкретном событии, просто реализует соответствующий прослушиватель, переопределяет унаследованные методы и затем добавляется к объекту, который запускает событие. Очень простой пример может быть таким:
открытый класс FooPanel расширяет JPanel и реализует ActionListener { открытый FooPanel () { super (); JButton btn = new JButton ( " Нажми меня!" ) ; btn.addActionListener ( this ); это . добавить ( кнопка ); } @Override public void actionPerformed ( ActionEvent ae ) { System . out . println ( "Кнопка была нажата!" ); } } Альтернативный вариант реализации — добавить слушателя к объекту как анонимный класс и, таким образом, использовать лямбда-нотацию (начиная с Java 1.8). Ниже приведен пример.
открытый класс FooPanel расширяет JPanel { открытый FooPanel () { super (); JButton btn = new JButton ( " Нажми меня!" ) ; btn.addActionListener ( ae - > System.out.println ( " Кнопка была нажата!" ) ) ; this.add ( btn ) ; } } (() => { 'использовать строго' ; класс EventEmitter { конструктор () { этот . события = новая Карта (); } on ( event , listener ) { if ( typeof listener ! == ' function' ) { throw new TypeError ( ' Слушатель должен быть функцией ' ) ; } let listeners = this.events.get ( event ) ; if ( ! listeners ) { listeners = new Set ( ) ; this.events.set ( event , listeners ) ; } listeners.add ( listener ) ; return this ; } off ( событие , прослушиватель ) { if ( ! arguments.length ) { this.events.clear ( ) ; } else if ( arguments.length === 1 ) { this.events.delete ( событие ) ; } else { const прослушиватели = this.events.get ( событие ) ; if ( listeners ) { listeners.delete ( listener ) ; } } return this ; } emit ( event , ... args ) { const listeners = this.events.get ( event ) ; if ( listeners ) { for ( let listener of listeners ) { listener.apply ( this , args ) ; } } return this ; } } это .Emitter = EventEmitter ; })() ; Использование:
const events = new EventEmitter (); events.on ( ' foo' , ( ) => { console.log ( 'foo' ); } ); events.emit ( ' foo' ); // Выводит "foo" events.off ( 'foo' ) ; events.emit ( 'foo' ) ; // Ничего не произойдет События являются одним из основных элементов языка Object Pascal . Здесь используется модель uni-cast (один к одному), т. е. отправитель отправляет информацию только одному получателю. Это ограничение имеет то преимущество, что ему не нужен специальный прослушиватель событий. Само событие является указателем на метод в другом объекте. Если указатель не пустой, при возникновении события вызывается обработчик событий. События обычно используются в классах, поддерживающих GUI. Однако это не единственная область применения событий. Следующий код является примером использования событий:
единица МойПользовательскийКласс ; интерфейсиспользует классы ; тип { определение собственного события} TAccidentEvent = процедура ( Отправитель : TObject ; const AValue : Integer ) объекта ; TMyCustomObject = class ( TObject ) private FData : Integer ; // пример простого поля в классе FOnAccident : TAccidentEvent ; // событие - ссылка на метод в некотором объекте FOnChange : TNotifyEvent ; // событие - ссылка на метод в некотором объекте procedure SetData ( Value : Integer ) ; // метод, устанавливающий значение поля в классе protected procedure DoAccident ( const AValue : Integer ) ; virtual ; // метод, генерирующий событие на основе вашего собственного определения procedure DoChange ; // метод, генерирующий событие на основе определения из библиотеки VCL public constructor Create ; virtual ; // конструктор класса destructor Destroy ; override ; // деструктор класса published property Data : TAccidentEvent read FData write SetData ; // объявление свойства в классе property OnAccident : TAccidentEvent read FOnAccident write FOnAccident ; // предоставление события за пределами класса property OnChange : TNotifyEvent read FOnChange write FOnChange ; // предоставление события за пределами класса procedure MultiplyBy ( const AValue : Integer ) ; // метод, который использует собственное определение события end ; implementation конструктор TMyCustomObject . Создавать ; начать FData := 0 ; конец ; деструктор TMyCustomObject .Destroy ; begin FData : = 0 ; inherited Destroy ; end ; procedure TMyCustomObject.DoAccident ( const AValue : Integer ) ; begin if Assigned ( FOnAccident ) then FOnAccident ( Self , AValue ) ; end ; procedure TMyCustomObject.DoChange ; begin if Assigned ( FOnChange ) then FOnChange ( Self ) ; end ; процедура TMyCustomObject . MultiplyBy ( const AValue : Integer ) ; начать FData := FData * AValue ; если FData > 1000000 , то DoAccident ( FData ) ; конец ; procedure TMyCustomObject.SetData ( Value : Integer ) ; begin if FData < > Value then begin FData : = Value ; DoChange ; end ; end . Созданный класс можно использовать следующим образом:
... procedure TMyForm.ShowCustomInfo ( Sender : TObject ) ; begin if Sender is TMyCustomObject then ShowMessage ( 'Данные изменились . ' ) ; end ; procedure TMyForm.PerformAcident ( Sender : TObject ; const AValue : Integer ) ; begin if Sender is TMyCustomObject then ShowMessage ( 'Данные превысили 1000000! Новое значение: ' + AValue.ToString ) ; end ; ... { объявление переменной, которая является объектом указанного класса} var LMyObject : TMyCustomObject ; ... { создание объекта } LMyObject := TMyCustomObject.Create ; ... { назначение методов событиям} LMyObject.OnChange : = MyForm.ShowCustomInfo ; LMyObject.OnAccident : = MyForm.PerformAcident ; ... { удаление объекта, когда он больше не нужен } LMyObject.Free ; ... Одной из проблем использования архитектуры, управляемой событиями, является обработка ошибок. Одним из способов решения этой проблемы является использование отдельного процессора обработчика ошибок. Таким образом, когда потребитель событий сталкивается с ошибкой, он немедленно и асинхронно отправляет ошибочное событие процессору обработчика ошибок и продолжает работу. Процессор обработчика ошибок пытается исправить ошибку и отправляет событие обратно в исходный канал. Но если процессор обработчика ошибок выходит из строя, то он может отправить ошибочное событие администратору для дальнейшей проверки. Обратите внимание, что если вы используете процессор обработчика ошибок, ошибочные события будут обрабатываться вне последовательности при их повторной отправке. [1]
Еще одной проблемой использования архитектуры, управляемой событиями, является потеря данных. Если какой-либо из компонентов выходит из строя до успешной обработки и передачи события следующему компоненту, то событие отбрасывается и никогда не попадает в конечный пункт назначения. Чтобы свести к минимуму вероятность потери данных, вы можете сохранять транзитные события и удалять/выводить из очереди события только после того, как следующий компонент подтвердит получение события. Эти функции обычно известны как «режим подтверждения клиента» и «поддержка последнего участника». [1]