Událostmi řízená architektura

Událostmi řízená architektura (z engl. Event-driven Architecture, EDA) je přístup k architektuře softwarových systémů pomocí vytváření, detekce, zpracování a reakcí na události.

Událost může být definována jako "významná změna stavu".^[1] Příkladem události může být nákup vozidla zákazníkem, při této události se mění stav vozidla z "k nákupu" na "prodáno". Architektura systému podporujícího prodej vozidel vyhodnotí nastalou změnu stavu vozidla jako událost, kterou má publikovat, a předá dalším aplikacím v systému informaci, že událost nastala, případně dodá další informace.

Tento architektonický vzor může být použit pro návrh a implementaci aplikací a systémů, které přenášení události mezi volně svázanými softwarovými komponentami nebo službami. Událostmi řízené systémy se typicky skládají z producentů (vydavatelů) událostí a konzumentů (zpracovatelů) událostí. Zpracovatelé mají zodpovědnost za včasnou reakci na událost. Zpracovatel může vykonávat reakci na událost sám, ale také nemusí. Například zpracovatel může mít odpovědnost pouze za filtrování, transformaci a přeposlání události jiné komponentě, nebo může sám o sobě poskytovat reakci na událost. První kategorie zpracovatelů může být založena na tradičních komponentách jako je message oriented middleware, zatímco druhá kategorie zpracovatelů (obsahující vlastní reakci) může vyžadovat více sofistikovaný framework pro zpracování transakcí.

Tvorba aplikací a informačních systémů za pomoci událostmi řízené architektury umožňuje, aby byly vytvářeny způsobem dovolujícím snazší odezvy, protože událostmi řízené systémy jsou více normalizované v nepředvídatelném a asynchronním prostředí.^[2]

Událostmi řízená architektura může doplňovat servisně orientovanou architekturu, protože služby mohou být spouštěny na základě příchozích událostí. ^[2][3] Tento vzor je zvlášť vhodný pokud konzument události sám neprovádí žádnou činnost, ale pouze deleguje.

Událostmi řízená servisně orientovaná architektura SOA 2.0 vznikla spojením událostmi řízené a servisně orientované architektury, díky tomu může poskytovat bohatší, odolnější řešení s využitím dříve neznámých příčinných vztahů.

Mezi jednotlivými částmi systému (třídy, komponenty, služby) jsou slabé vazby. Části o sobě ví pouze to, co potřebují znát, aby mohly správně fungovat.

Jelikož je událost ze své definice velmi obecná a může být za ni považováno téměř cokoliv, tak je možné stávající systém postavený na architektuře řízené událostmi snadno rozšířit. Dalším aspektem z pohledu rozšiřitelnosti je velmi snadné přidání druhého a dalšího konzumenta události k producentovi události.

Architektura řízená událostmi je postavena na čtyřech logických vrstvách. Tok začíná tím, že producent zpozoruje fakt, že nějaký stav se změnil a končí reakcí neprázdné množiny zpracovatelů událostí.^[4]

První logickou vrstvou je producent události, který snímá fakta a převádí je na události. Vzhledem k tomu, že faktem může být téměř cokoliv, tak producent může produkovat různé události. Příkladem producenta událostí může být: emailový klient, CRM systém, nebo nějaké čidlo. Konvertování různých shromážděných informací ze senzorů do jednotného standardizovaného datového formuláře může být významným problémem v této vrstvě. Správný návrh a implementace producenta událostí může významně ovlivnit celkovou architekturu systému.^[4]

Transportní kanál je nástrojem pro přenos události z producenta k zpracovateli události^[4]. Transportním kanálem může být TCP/IP, libovolný soubor (textový, XML, e-mail, apod.), případně to může být volání metody. Může být použito několik transportních kanálů. Obvykle z důvodu, že zpracovatel událostí zpracovává události v reálném nebo téměř reálném čase, a transportní kanály mohou být čteny asynchronně. Události mohou být postoupeny do fronty a čekají než budou později zpracovány zpracovatelem událostí.

Zpracovatel události je prvkem v architektuře, kde je na událost je rozpoznána a na základě informací z události a svém stavu provádí příslušnou reakci. Tato vlastnost vede k různým reakcím na stejnou událost např. zpracovatel dostane událost "produktu je na skladě málo", z toho může být vyvolány činnosti "Objednej produkt" a "Upozorni personál". ^[4]

V rámci následné činnosti jsou zpracovány důsledky činnosti, která byla prováděna u zpracovatele události. To může být realizováno rozličnými způsoby. Např. email je odeslán na určitou adresu a aplikace může následně zobrazit uživateli na obrazovce varován.^[4] V závislosti na stupni automatizace zpracovatele událostí může být následná činnost volitelnou součástí událostmi řízené architektury.

Existují tři základní způsoby zpracování událostí: jednoduché, proudové a složené. V pokročilých systémech, které jsou založené na událostmi řízené architektuře, jsou často používány společně. ^[4]

Jednoduché zpracování událostí provádí zpracování událostí, které jsou přímo spojeny s měřitelnou a konkrétní změnou stavu. Při jednoduchém zpracování událostí je pozorovaná změna stavu dává přímo podnět k zahájení nějaké akce, nebo akcí. Běžně se používá v reálném světě např. pro řízení toku práce, čímž snižuje prodlevy a náklady.^[4]

Příkladem jednoduché události může být detekce změny tlaku v pneumatikách, nebo teploty. V informatice může být příkladem jednoduché události změna jednoho atributu, či přerušení elektrického obvodu.

V proudovém zpracování událostí detekuje jak normální (jednoduché) události, tak významné. Z normálních událostí (objednávky, RFID přenosy) jsou vytvářeny události významné, které jsou následně přenášeny do informačních systémů, konkrétním zpracovatelům událostí, kteří chtějí dostávat tyto informace. Proudové zpracování událostí se běžně používá pro detekci událostí v reálném čase v podnicích a jejich okolí, čímž umožňuje velmi rychlé rozhodování.^[4]

Příkladem tohoto zpracování může být detekce podvodů, monitorování procesů, geolokace v telekomunikacích a další.

Složené zpracování událostí umožňuje vytvářet vzory pro detekci složených událostí. Složené události se skládají z jednoduchých a normálních událostí, které se průběžně vyhodnocují. Události, ze které jsou podnětem pro vytvoření složené události, mohou být různých typů a mohou nastat během velmi dlouhého časového úseku. Korelace událostí může být kauzální, časová nebo prostorová. Složené zpracování událostí vyžaduje použití sofistikovaného systému pro zpracování událostí skládající ho se z interpretů událostí, definicí událostních vzorů a jejich vyhodnocování, a také z korelačních nástrojů. Používá se pro reakci na obchodní výjimky, hrozby a příležitosti.^[4]

V informačních systémech je používáno v grafickém uživatelském rozhraní pro detekování složených událostí. Příkladem takovéto události může být kliknutí myší. Tato událost nastane, pokud je tlačítko myši stisknuto a uvolněno v určitém časovém rozpětí.

V případě potřeby ukládat nebo manipulovat s událostí je událost rozkládaná na hlavičku a tělo události. Hlavička události může obsahovat následující informace: název události, časové razítko a typ události. Tělo události pak popisuje samotnou událost, tzn. co se ve skutečnosti stalo. Tělo události nesmí být zaměňováno s tím jak na událost reagovat, tudíž nesmí obsahovat žádné vzory reakcí nebo rozhodovací logiku.

Java AWT a Java Swing je založeno na událostmi řízené architektuře. Událostmi řízená architektura podporuje motivaci Swingu je vytvářet uživatelské rozhraní, kde jsou komponenty a funkce svázány slabou vazbou. AWT a Swing používá ve svém API názvosloví, kdy třídy představujíc událost končí na "Event" a rozhraní , které musí implementovat třída chtějící být informována, že událost nastala, má koncovku "Listener".

Pokud chce být instance třídy (Zpracovatel události) informována o tom, že nějaká událost nastala, musí třída implementovat rozhraní příslušného "Listenera". Následně se je nutné, aby se instance zaregistrovala u objektu poskytující události (Producent události). Pokud událost nastane tak objekt poskytující událost zavolá na instanci třídy metodu, kterou třída přeřídila z rozhraní. U jedné instance producenta události se může zaregistrovat více Listenerů.

Konkrétní použití může vypadat následovně:

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JButton;
import javax.swing.JWindow;

/**
 * Třída okno je v roli konzumenta události. 
 * Chce být informována o tom, že se tlačítko "Zavřít" kliklo.
 * V případě, že na tlačítko bylo kliknuto tak je okno zavřeno.
 */
public class Okno extends JWindow {
 
    /**
     * Konstruktor pro vytvoření instance třídy Okno.
     */
    public Okno() {
        super();
        
        //Vytvoření tlačítka, které produkuje událost. 
        JButton zavřít = new JButton("Zavřít!");
        //Vytvoření Listenera, který zpracovává událost
        ActionListener konecListener = new KonecListener(this);
        //Registrace Listenera u producenta události 
        zavřít.addActionListener(konecListener);
    }

    /**
     * Třída implementující rozhraní ActionListener a implementuje metodu 
     * actionPerformed(ActionEvent e) při jejímž zavolání je ukončeno 
     * okno, které bylo předáno jako parametr při vytváření instance.
     */
    private class KonecListener implements ActionListener {

        /**
         * Reference na instanci okna, které chce být zavřeno, když nastane událost.
         */
        JWindow okno; 
        
        /**
         * Konstruktor pro vytvoření objektu třídy KonecListener.
         * @param okno reference na instanci třídy JWindow, která má být ukončeno
         */
        public KonecListener(JWindow okno) {
            this.okno = okno;
        }

        /**
         * Metoda, která při zavolání ukončí okno. 
         * Je volána pokaždé když událost nastane.
         * @param e událost
         */
        @Override
        public void actionPerformed(ActionEvent e) {
            okno.dispose();
        }
    }
}

Windows Presentation Foundation (WPF) a uživatelské rozhraní Silverlightu je založeno na událostmi řízené architektuře. Implementace událostmi řízené architektury ve WPF je realizována pomocí volání metod s předepsanou signaturou, která obsahuje parametr typu "object" a "EventArgs", což jsou parametry události, na objektu, který chce být informován o tom, že událost nastala. V této implementaci může být o události informován pouze jeden konzument (Event Handler).

Ukázka implementace:

Xaml definující okno

<Window x:Class="Test.Okno"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Okno" Height="350" Width="525" x:Name="okno">
    <Grid>
        <Button x:Name="konec" Content="Zavřít" Click="konec_Click"/>
    </Grid>
</Window>

Obalující třída okna

namespace Test
{
    public partial class Okno : Window
    {
        public Okno()
        {
            InitializeComponent();
        }

        private void konec_Click(object sender, RoutedEventArgs e)
        {
            okno.Close();
        }
    }
}

• Článek definující odlišnosti mezi událostmi řízenou architekturou a servisně orientovanou: How EDA extends SOA and why it is important od Jack van Hoof.

• Příklad skutečného využití obchodních událostí v servisně orientované architektury: SOA, EDA, and CEP - a winning combo od Udi Dahan.