Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Управляемая событиями архитектура ( 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]

Реализации и примеры [ править ]

Java Swing [ править ]

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 ( « Нажата кнопка!» );  } }

В качестве альтернативы другой вариант реализации - добавить слушателя к объекту как анонимный класс . Ниже приведен пример.

открытый  класс  FooPanel  расширяет  JPanel  {  общедоступный  FooPanel ()  {  super (); JButton  btn  =  new  JButton ( «Нажми меня!» );  БТН . addActionListener ( новый  ActionListener ()  {  public  void  actionPerformed ( ActionEvent  ae )  {  System . out . println ( " Нажата кнопка!" );  }  });  это . добавить ( btn );  } }

JavaScript [ править ]

(()  =>  {  'использовать строгое' ; класс  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" . выкл ( 'фу' ); события . испускать ( 'фу' );  // Ничего не случится

См. Также [ править ]

  • Событийно-ориентированное программирование
  • Служба обмена сообщениями, управляемая процессами
  • Сервис-Ориентированная Архитектура
  • SOA, управляемая событиями
  • Космическая архитектура
  • Обработка сложных событий
  • Обработка потока событий
  • Техническое общество обработки событий
  • Поэтапная событийная архитектура (SEDA)
  • Схема реактора
  • Автономная периферийная работа

Статьи [ править ]

  • Статья Джека ван Хофа, определяющая различия между EDA и SOA: Как EDA расширяет SOA и почему это важно .
  • Реальный пример бизнес-событий, протекающих в SOA: SOA, EDA и CEP - выигрышная комбинация от Уди Дахана.
  • Статья Мишель Ветцлер, описывающая концепцию данных событий: аналитика для хакеров, как думать о данных событий . (Интернет-архив)

Ссылки [ править ]

  1. ^ K. Mani Chandy Event-Driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology , 2006.
  2. ↑ Мартин Фаулер, Event Sourcing , декабрь 2005 г.
  3. ↑ Мартин Фаулер, Параллельная модель , декабрь 2005 г.
  4. ↑ Хэнсон, Джефф (31 января 2005 г.). «Событийно-ориентированные сервисы в SOA» . JavaWorld . Проверено 21 июля 2020 .
  5. ^ Слива, Carol (12 мая 2003). «Архитектура, управляемая событиями, готова к широкому внедрению» . Компьютерный мир . Проверено 21 июля 2020 .
  6. ^ a b c d e f g h i j Бренда М. Майкельсон, Обзор событийно-ориентированной архитектуры, Patricia Seybold Group , 2 февраля 2006 г.
  7. ^ «Обработка событий онлайн - очередь ACM» . queue.acm.org . Проверено 30 мая 2019 .
  8. ^ Хасан, Сулейман, Шон O'Riain, и Эдвард Карри. 2012. «Приблизительное семантическое соответствие разнородных событий». На 6-й Международной конференции ACM по распределенным системам, основанным на событиях (DEBS 2012), 252–263. Берлин, Германия: ACM. «ДОИ» .

Внешние ссылки [ править ]

  • Событийно-ориентированные приложения: затраты, преимущества и подходы к проектированию
  • Отраслевой веб-сайт по комплексной обработке событий и аналитике в реальном времени
  • Веб-сайт Технического общества обработки событий
  • Выпуск к 5-й годовщине: Обзор событийно-ориентированной архитектуры, Бренда М. Майкельсон
  • Сложная обработка событий и сервис-ориентированная архитектура
  • Как EDA расширяет SOA и почему это важно , Джек ван Хоф
  • Как реализовать управляемую событиями архитектуру (со спецификой RabbitMQ)
  • Архитектура, управляемая событиями, события и асинхронные API. Какая вилка?
  • CloudEvents: спецификация с открытым исходным кодом для описания данных событий общим способом.