Событийная архитектура

Архитектура, управляемая событиями ( 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») для связи и организации проблем событий. Класс, которому необходимо знать о конкретном событии, просто реализует соответствующий прослушиватель, переопределяет унаследованные методы, а затем добавляется к объекту, который запускает событие. Очень простым примером может быть:

public class FooPanel extends JPanel implements ActionListener {
    public FooPanel() {
        super();

        JButton btn = new JButton("Click Me!");
        btn.addActionListener(this);

        this.add(btn);
    }

    @Override
    public void actionPerformed(ActionEvent ae) {
        System.out.println("Button has been clicked!");
    }
}

Альтернативно, другой вариант реализации — добавить прослушиватель к объекту как анонимный класс и, таким образом, использовать лямбда-нотацию (начиная с Java 1.8). Ниже приведен пример.

public class FooPanel extends JPanel {
    public FooPanel() {
        super();

        JButton btn = new JButton("Click Me!");
        btn.addActionListener(ae -> System.out.println("Button has been clicked!"));
        this.add(btn);
    }
}

JavaScript

(() => {
  'use strict';

  class EventEmitter {
    constructor() {
      this.events = new Map();
    }

    on(event, listener) {
      if (typeof listener !== 'function') {
        throw new TypeError('The listener must be a function');
      }
      let listeners = this.events.get(event);
      if (!listeners) {
        listeners = new Set();
        this.events.set(event, listeners); 
      }
      listeners.add(listener);
      return this;
    }

    off(event, listener) {
      if (!arguments.length) {
        this.events.clear();
      } else if (arguments.length === 1) {
        this.events.delete(event);
      } else {
        const listeners = this.events.get(event);
        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;
    }
  }

  this.EventEmitter = EventEmitter;
})();

Использование:

const events = new EventEmitter();
events.on('foo', () => { console.log('foo'); });
events.emit('foo'); // Prints "foo"
events.off('foo');
events.emit('foo'); // Nothing will happen

Объектный Паскаль

События — один из фундаментальных элементов языка Object Pascal . Здесь используется модель одноадресной рассылки (один к одному), т. е. отправитель отправляет информацию только одному получателю. Преимущество этого ограничения состоит в том, что для него не требуется специальный прослушиватель событий. Само событие является указателем на метод другого объекта. Если указатель не пуст, при возникновении события вызывается обработчик события. События обычно используются в классах, поддерживающих графический интерфейс. Однако это не единственная область применения мероприятий. Следующий код является примером использования событий:

unit MyCustomClass;  

interface

uses
  Classes;
  
type
  {definition of your own event}
  TAccidentEvent = procedure(Sender: TObject; const AValue: Integer) of object;

  TMyCustomObject = class(TObject)
  private
    FData: Integer;              // an example of a simple field in a class
    FOnAccident: TAccidentEvent; // event - reference to a method in some object
    FOnChange: TNotifyEvent;     // event - reference to a method in some object 
    procedure SetData(Value: Integer); // a method that sets the value of a field in the class 
  protected
    procedure DoAccident(const AValue: Integer); virtual; // a method that generates an event based on your own definition 
    procedure DoChange; // a method that generates an event based on a definition from the VCL library 
  public
    constructor Create; virtual;   // class constructor 
    destructor Destroy; override;  // class destructor
  published
    property Data: TAccidentEvent read FData write SetData; // declaration of a property in a class
    property OnAccident: TAccidentEvent read FOnAccident write FOnAccident; // exposing the event outside the class
    property OnChange: TNotifyEvent read FOnChange write FOnChange;         // exposing the event outside the class
    procedure MultiplyBy(const AValue: Integer);  // a method that uses its own definition of the event
  end;
  
implementation

constructor TMyCustomObject.Create;
begin
  FData := 0;
end;

destructor 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;

procedure TMyCustomObject.MultiplyBy(const AValue: Integer);
begin
  FData := FData * AValue;
  if FData > 1000000
   then DoAccident(FData);
end;

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('Data has changed.');
end;

procedure TMyForm.PerformAcident(Sender: TObject; const AValue: Integer);
begin
  if Sender is TMyCustomObject
   then ShowMessage('The data has exceeded 1000000! New value is: ' + AValue.ToString);
end;
...
{declaring a variable that is an object of the specified class}
var
  LMyObject: TMyCustomObject; 
...
{creation of the object}
LMyObject := TMyCustomObject.Create;
...
{assigning a methods to an events}
LMyObject.OnChange := MyForm.ShowCustomInfo;
LMyObject.OnAccident := MyForm.PerformAcident;
...
{removing an object when it is no longer needed}
LMyObject.Free; 
...

См. также

Статьи

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

Ссылки

^ К. Мани Чанди Приложения, управляемые событиями: затраты, преимущества и подходы к проектированию, Калифорнийский технологический институт , 2006 г.
^ Мартин Фаулер, Поиск событий , декабрь 2005 г.
^ Мартин Фаулер, Параллельная модель , декабрь 2005 г.
^ Хэнсон, Джефф (31 января 2005 г.). «Событийно-ориентированные сервисы в SOA» . JavaWorld . Проверено 21 июля 2020 г.
^ Слива, Кэрол (12 мая 2003 г.). «Событийно-ориентированная архитектура готова к широкому внедрению» . Компьютерный мир . Проверено 21 июля 2020 г.
^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж Бренда М. Майкельсон, Обзор архитектуры, управляемой событиями, Patricia Seybold Group , 2 февраля 2006 г.
^ «Онлайн-обработка событий — очередь ACM» . Queue.acm.org . Проверено 30 мая 2019 г.
^ Хасан, Сулейман, Шон О'Риейн и Эдвард Карри. 2012. «Приблизительное семантическое соответствие гетерогенных событий». На 6-й Международной конференции ACM по распределенным системам, основанным на событиях (DEBS 2012), 252–263. Берлин, Германия: ACM. «ДОИ» .

Внешние ссылки

[1] К. Мани Чанди Приложения, управляемые событиями: затраты, преимущества и подходы к проектированию, Калифорнийский технологический институт , 2006 г.

[Fowler1-2] Мартин Фаулер, Поиск событий , декабрь 2005 г.

[Fowler2-3] Мартин Фаулер, Параллельная модель , декабрь 2005 г.

[Hanson1-4] Хэнсон, Джефф (31 января 2005 г.). «Событийно-ориентированные сервисы в SOA» . JavaWorld . Проверено 21 июля 2020 г.

[5] Слива, Кэрол (12 мая 2003 г.). «Событийно-ориентированная архитектура готова к широкому внедрению» . Компьютерный мир . Проверено 21 июля 2020 г.

[Michelson1-6] Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж Бренда М. Майкельсон, Обзор архитектуры, управляемой событиями, Patricia Seybold Group , 2 февраля 2006 г.

[7] «Онлайн-обработка событий — очередь ACM» . Queue.acm.org . Проверено 30 мая 2019 г.

[8] Хасан, Сулейман, Шон О'Риейн и Эдвард Карри. 2012. «Приблизительное семантическое соответствие гетерогенных событий». На 6-й Международной конференции ACM по распределенным системам, основанным на событиях (DEBS 2012), 252–263. Берлин, Германия: ACM. «ДОИ» .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]