Управляемая событиями архитектура ( EDA ) - это парадигма архитектуры программного обеспечения, способствующая производству, обнаружению, потреблению и реакции на события .
Событие может быть определено как «значительные изменения в состоянии ». [1] Например, когда потребитель покупает автомобиль, состояние автомобиля меняется с «продается» на «продано». Архитектура системы автосалона может рассматривать это изменение состояния как событие, о возникновении которого можно сообщить другим приложениям в этой архитектуре. С формальной точки зрения то, что создается, публикуется, распространяется, обнаруживается или потребляется, является (обычно асинхронным) сообщением, называемым уведомлением о событии, а не самим событием, которое является изменением состояния, вызвавшим отправку сообщения. События не путешествуют, они просто происходят. Однако термин « событие» часто используется метонимически.для обозначения самого сообщения уведомления, которое может привести к некоторой путанице. Это связано с тем, что архитектуры, управляемые событиями, часто проектируются на основе архитектур , управляемых сообщениями , где такой шаблон связи требует, чтобы один из входных данных был только текстовым, сообщением, чтобы различать, как следует обрабатывать каждое сообщение.
Этот архитектурный шаблон может применяться при разработке и реализации приложений и систем, которые передают события между слабо связанными программными компонентами и службами.. Система, управляемая событиями, обычно состоит из источников (или агентов) событий, потребителей (или приемников) событий и каналов событий. Эмитенты несут ответственность за обнаружение, сбор и передачу событий. Генератор событий не знает потребителей события, он даже не знает, существует ли потребитель, и, если он существует, он не знает, как событие используется или обрабатывается. Раковины несут ответственность за применение реакции, как только событие представлено. Реакция может быть или не может быть полностью обеспечена самой раковиной. Например, приемник может просто отвечать за фильтрацию, преобразование и пересылку события другому компоненту или может обеспечивать автономную реакцию на такое событие. Каналы событий - это каналы, по которым события передаются от источников событий к потребителям событий.Знание о правильном распределении событий присутствует исключительно в канале событий.[ необходима цитата ] Физическая реализация каналов событий может быть основана на традиционных компонентах, таких как ориентированное на сообщения промежуточное программное обеспечение или двухточечная связь, для чего может потребоваться более подходящая исполнительная структура транзакций [ пояснить ] .
Построение систем на основе архитектуры, управляемой событиями, упрощает горизонтальную масштабируемость в моделях распределенных вычислений и делает их более устойчивыми к сбоям. Это связано с тем, что состояние приложения может быть скопировано в несколько параллельных моментальных снимков для обеспечения высокой доступности. [2] Новые события могут быть инициированы где угодно, но, что более важно, они распространяются по сети хранилищ данных, обновляя каждое из них по мере их поступления. Добавление дополнительных узлов также становится тривиальным: вы можете просто взять копию состояния приложения, передать ему поток событий и запустить с ним. [3]
Архитектура, управляемая событиями, может дополнять сервис-ориентированную архитектуру (SOA), поскольку сервисы могут быть активированы триггерами, срабатывающими при входящих событиях. [4] [5] Эта парадигма особенно полезна, когда приемник не предоставляет никаких автономных исполнительных механизмов [ пояснить ] .
SOA 2.0 развивает последствия, предоставляемые архитектурами SOA и EDA, на более богатый и надежный уровень за счет использования ранее неизвестных причинно-следственных связей для формирования нового паттерна событий. [ расплывчато ] Этот новый шаблон бизнес-аналитики запускает дальнейшую автономную человеческую или автоматизированную обработку, которая увеличивает экспоненциальную ценность для предприятия, вводя дополнительную информацию в распознанный шаблон, чего раньше нельзя было достичь. [ расплывчато ]
Событие может состоять из двух частей: заголовка события и тела события. Заголовок события может включать такую информацию, как имя события, отметка времени для события и тип события. В теле события содержатся подробные сведения об обнаруженном изменении состояния. Тело события не следует путать с шаблоном или логикой, которые могут применяться в ответ на возникновение самого события.
Архитектура, управляемая событиями, может быть построена на четырех логических уровнях, начиная с восприятия события (т. Е. Значимого временного состояния или факта), переходя к созданию его технического представления в форме структуры события и заканчивая отсутствием -пустой набор реакций на это событие. [6]
Этот раздел может сбивать с толку или непонятно читателям . В частности, некоторые термины непонятны новичкам в EDA. ( Июль 2013 г. ) |
Первый логический уровень - это генератор событий, который распознает факт и представляет этот факт как сообщение о событии. Например, генератором событий может быть клиент электронной почты, система электронной коммерции, агент мониторинга или какой-либо физический датчик.
Преобразование данных, собранных из такого разнообразного набора источников данных, в единую стандартизированную форму данных для оценки - важная задача при разработке и реализации этого первого логического уровня. [6] Однако, учитывая, что событие является строго декларативным фреймом, любые информационные операции могут быть легко применены, что устраняет необходимость в высоком уровне стандартизации. [ необходима цитата ]
Это второй логический уровень. Канал событий - это механизм распространения информации, собранной из генератора событий, в механизм событий [6] или приемник. Это может быть TCP / IP-соединение или любой тип входного файла (плоский, формат XML, электронная почта и т. Д.). Одновременно можно открыть несколько каналов событий. Обычно, поскольку механизм обработки событий должен обрабатывать их почти в реальном времени, каналы событий будут считываться асинхронно. События хранятся в очереди, ожидая обработки позже механизмом обработки событий.
Механизм обработки событий - это логический уровень, отвечающий за идентификацию события, а затем за выбор и выполнение соответствующей реакции. Он также может вызвать ряд утверждений. Например, если событие, которое поступает в механизм обработки событий, является идентификатором продукта, имеющегося на складе, это может вызвать такие реакции, как «Код продукта заказа» и «Уведомить персонал». [6]
Это логический слой, на котором показаны последствия события. Это можно сделать разными способами и формами; например, кому-то было отправлено электронное письмо, и приложение может отображать на экране какое-то предупреждение. [6] В зависимости от уровня автоматизации, обеспечиваемого приемником (механизмом обработки событий), последующие действия могут не потребоваться.
Существует три основных стиля обработки событий: простой, потоковый и сложный. Эти три стиля часто используются вместе в зрелой событийно-ориентированной архитектуре. [6]
Простая обработка событий касается событий, которые напрямую связаны с конкретными измеримыми изменениями состояния. При простой обработке событий происходит заметное событие, которое инициирует последующие действия. Простая обработка событий обычно используется для управления потоком работы в реальном времени, тем самым сокращая время задержки и затраты. [6]
Например, простые события могут быть созданы датчиком, обнаруживающим изменения давления в шинах или температуры окружающей среды. Неправильное давление в шинах автомобиля вызовет простое событие от датчика, которое включит желтый свет, сообщающий водителю о состоянии шины.
При обработке потока событий (ESP) происходят как обычные, так и заметные события. Обычные события (заказы, передачи RFID) проверяются на заметность и передаются подписчикам информации. Обработка потока событий обычно используется для управления потоком информации в реальном времени внутри предприятия и вокруг него, что позволяет своевременно принимать решения. [6]
Обработка сложных событий (CEP) позволяет рассматривать шаблоны простых и обычных событий, чтобы сделать вывод о том, что сложное событие произошло. Обработка сложных событий оценивает совокупность событий и затем принимает меры. События (заметные или обычные) могут пересекать типы событий и происходить в течение длительного периода времени. Корреляция событий может быть причинной, временной или пространственной. CEP требует использования сложных интерпретаторов событий, определения и сопоставления шаблонов событий, а также методов корреляции. CEP обычно используется для обнаружения бизнес-аномалий, угроз и возможностей и реагирования на них. [6]
Онлайн-обработка событий (OLEP) использует асинхронные распределенные журналы событий для обработки сложных событий и управления постоянными данными. [7] OLEP позволяет надежно составлять связанные события сложного сценария в разнородных системах. Таким образом, он обеспечивает очень гибкие схемы распределения с высокой масштабируемостью и обеспечивает высокую согласованность. Однако он не может гарантировать верхнюю границу времени обработки.
Архитектура, управляемая событиями, чрезвычайно слабо связана и хорошо распределена. Эта архитектура имеет большое распространение, потому что событие может быть практически любым и существовать практически где угодно. Архитектура чрезвычайно слабо связана, потому что само событие не знает о последствиях своей причины. Например, если у нас есть система сигнализации, которая записывает информацию при открытии входной двери, сама дверь не знает, что система сигнализации добавит информацию при открытии двери, а только о том, что дверь была открыта. [6]
Архитектуры, управляемые событиями, имеют слабую связь в пространстве, времени и синхронизации, обеспечивая масштабируемую инфраструктуру для обмена информацией и распределенных рабочих процессов. Однако архитектуры событий тесно связаны с семантикой базовой схемы событий и значений через подписки на события и шаблоны. Высокая степень семантической неоднородности событий в крупных и открытых развертываниях, таких как умные города и сенсорная сеть, затрудняет разработку и обслуживание систем, основанных на событиях. Для решения проблемы семантической связи в системах, основанных на событиях, использование приблизительного семантического сопоставления событий является активной областью исследований. [8]
Java Качели API основан на управляемых событиями архитектуры. Это особенно хорошо сочетается с мотивацией Swing предоставлять компоненты и функции, связанные с пользовательским интерфейсом. API использует соглашение о номенклатуре (например, «ActionListener» и «ActionEvent») для связи и организации проблем, связанных с событиями. Класс, которому необходимо знать о конкретном событии, просто реализует соответствующий слушатель, переопределяет унаследованные методы и затем добавляется к объекту, запускающему событие. Очень простой пример:
открытый класс FooPanel расширяет JPanel реализует ActionListener { общедоступный FooPanel () { super (); JButton btn = new JButton ( «Нажми меня!» ); БТН . addActionListener ( это ); это . добавить ( btn ); } @Override public void actionPerformed ( ActionEvent ae ) { System . из . println ( « Нажата кнопка!» ); } }
В качестве альтернативы, другой вариант реализации - добавить слушателя к объекту как анонимный класс и, таким образом, использовать лямбда-нотацию (начиная с Java 1.8). Ниже приведен пример.
открытый класс FooPanel расширяет JPanel { общедоступный FooPanel () { super (); JButton btn = new JButton ( «Нажми меня!» ); БТН . addActionListener ( ae -> System . out . println ( " Нажата кнопка!" )); это . добавить ( btn ); } }
(() => { 'использовать строгое' ; класс EventEmitter { конструктор () { это . события = новая карта (); } on ( событие , слушатель ) { if ( typeof listener ! == 'function' ) { throw new TypeError ( 'Слушатель должен быть функцией' ); } let listeners = this . события . получить ( событие ); если ( ! слушатели ) { слушатели = новый набор (); это . события . набор ( событие, слушатели ); } слушатели . добавить ( слушатель ); вернуть это ; } off ( событие , слушатель ) { если ( ! аргументы . длина ) { это . события . clear (); } else if ( arguments . length === 1 ) { this . события . удалить ( событие ); } else { const listeners = это . события . получить ( событие); если ( слушатели ) { слушатели . удалить ( слушатель ); } } вернуть это ; } emit ( событие , ... аргументы ) { const listeners = this . события . получить ( событие ); если ( слушатели ) { для ( пусть слушателя из слушателей ) { слушателя . применить ( это , аргументы ); } } вернуть это ; } } это . EventEmitter = EventEmitter ; }) ();
Использование:
const events = новый EventEmitter (); события . on ( 'foo' , () => { console . log ( 'foo' ); }); события . испускать ( 'фу' ); // Выводит события "foo" . выкл ( 'фу' ); события . испускать ( 'фу' ); // Ничего не случится