Architektura řízená událostmi ( EDA ) je vzor softwarové architektury , který umožňuje vytváření, definici, spotřebu a reakci na události .
Událost lze definovat jako „velkou změnu stavu “ [1] . Když si například zákazník koupí auto, stav vozu se změní z „na prodej“ na „prodáno“. Architektura systému prodejce automobilů může tuto změnu stavu považovat za událost vytvořenou, publikovanou, definovanou a spotřebovanou různými aplikacemi v rámci architektury.
Tento architektonický vzor lze použít při návrhu a implementaci aplikací a systémů, které komunikují události mezi volně propojenými softwarovými komponentami a službami . Systém řízený událostmi obvykle obsahuje zdroje událostí (nebo agenty) a konzumenty událostí (nebo jímky). Sinks jsou zodpovědné za reakci, jakmile dojde k události. Reakce může nebo nemusí být zcela generována jímkou. Například jímka může být odpovědná pouze za filtrování, transformaci a doručení události do jiné komponenty, nebo může vytvořit vlastní reakci na tuto událost. První kategorie propadů může být založena na tradičních komponentách, jako je middleware pro zasílání zpráv, a druhá kategorie propadů (vytvářející vlastní odezvu za běhu) může vyžadovat vhodnější platformu pro provádění transakcí.
Vytváření aplikací a systémů v rámci architektury řízené událostmi umožňuje, aby byly navrženy způsobem, který podporuje lepší interaktivitu, protože systémy řízené událostmi jsou více strukturovány směrem k nepředvídatelným a asynchronním prostředím [2] .
Architektura řízená událostmi odpovídá architektuře orientované na služby (SOA), protože služby lze aktivovat spouštěči spouštěnými z příchozích událostí [2] [3] .
Toto paradigma je zvláště užitečné, když jímka neposkytuje vlastní provádění akcí.
Event Driven Service Oriented Architecture rozvíjí architektury SOA a EDA tak, aby poskytovaly hlubší a robustnější vrstvu služeb využitím dříve neznámých vztahů příčin a následků k vytvoření nového modelu událostí. Tento nový model business intelligence vede k další automatizaci zpracování a dodává podniku dříve nedosažitelnou produktivitu vkládáním cenných informací do rozpoznaného vzorce činností.
Událost se může skládat ze dvou částí: hlavičky události a těla události. Záhlaví události může obsahovat informace, jako je název události, časové razítko události a typ události. Tělo události popisuje, co se skutečně stalo. Tělo události by nemělo být zaměňováno se šablonou nebo logikou, kterou lze použít v reakci na události.
Architektura řízená událostmi se skládá ze čtyř logických vrstev. Začíná to samotným ozvučením, jeho technickým ztvárněním ve formě události a končí neprázdným souborem reakcí na tuto událost. [čtyři]
První logickou vrstvou je generátor událostí, který registruje skutečnost a reprezentuje ji jako událost. Protože prakticky cokoli, co lze vnímat, může být skutečností, může to být i generátor událostí. Generátorem může být například e-mailový klient, systém elektronického obchodování nebo nějaký typ senzoru. Převod dat různých senzorů do jediné, standardizované formy dat, která lze vyhodnotit, je hlavní výzvou při návrhu a implementaci této vrstvy. [4] Vzhledem k tomu, že událost je přísně deklarativní, lze však snadno použít jakékoli transformační operace, čímž se eliminuje potřeba vysoké úrovně standardizace.
Kanál událostí je mechanismus, přes který jsou informace předávány z generátoru událostí do mechanismu zpracování událostí [4] nebo jímky.
Může se jednat o připojení TCP/IP nebo jakýkoli typ vstupního souboru (prostý text, formát XML, e-mail atd.). Současně lze otevřít více kanálů událostí. Typicky, kvůli požadavkům na zpracování událostí v téměř reálném čase, jsou kanály událostí čteny asynchronně. Události se ukládají do fronty a čekají na pozdější zpracování modulem událostí.
Mechanismus zpracování události je místo, kde je událost identifikována a vybrána vhodná reakce na ni, která je následně provedena. To může také vést ke generování řady tvrzení. Pokud například událost, která dorazila do procesoru, hlásí, že „produkt N dochází“, může tato skutečnost vyvolat reakce „Objednat produkt N“ a „Upozornit personál“. [čtyři]
Zde jsou důsledky události. Může se projevovat různými způsoby a formami; například zpráva odeslaná někomu nebo aplikace, která na obrazovce zobrazuje nějaké varování. [4] . V závislosti na úrovni automatizace poskytované dřezem (motor událostí) nemusí být tyto kroky nutné.
Existují tři hlavní styly zpracování událostí: jednoduchý, vláknitý a složitý. Tyto tři styly se často používají společně ve velké architektuře řízené událostmi [4] .
Jednoduché zpracování událostí se týká událostí přímo souvisejících s konkrétními měřitelnými změnami podmínek. Díky jednoduchému zpracování událostí dochází ke známým událostem, které spouštějí následné efekty. Jednoduché zpracování událostí se běžně používá ke správě workflow v reálném čase, čímž se snižuje latence a náklady [4] .
Jednoduché události generuje například senzor, který detekuje změnu tlaku v pneumatikách nebo okolní teploty.
Během zpracování proudu událostí (ESP) dochází k normálním i známým událostem. Pravidelné události (příkazy, přenosy RFID) jsou kontrolovány z hlediska znalostí a předávány předplatitelům informací. Zpracování toku událostí se běžně používá pro řízení toku informací v reálném čase a na podnikové úrovni, což umožňuje včasné rozhodování [4] .
Zpracování komplexních událostí umožňuje uvažovat posloupnosti jednoduchých a běžných událostí a odvodit výskyt složité události. Komplexní zpracování událostí vyhodnotí vzájemné ovlivnění událostí a následně zasáhne. Události (známé nebo běžné) nemusí následovat po zadání a vyskytují se po dlouhou dobu. Korelace událostí může být kauzální, časová nebo prostorová. Zpracování složitých událostí vyžaduje použití interpreterů složitých událostí, vzorování a párování událostí a korelačních metod. Komplexní zpracování událostí se běžně používá k identifikaci a reakci na anomální chování, hrozby a příležitosti [4] .
Architektura řízená událostmi je extrémně volně propojená a dobře distribuovaná. Nejlepší distribuce této architektury je způsobena skutečností, že událostí může být cokoli, co existuje kdekoli. Architektura je extrémně volně propojena, protože událost sama o sobě nezná důsledky jejího výskytu, to znamená, že pokud máme bezpečnostní systém, který zaznamenává informace při otevření vstupních dveří, pak dveře samotné neví, že bezpečnostní systém doplní informaci o otevření dveří. [čtyři]
Knihovna Java Swing je založena na architektuře řízené událostmi. To je obzvláště dobře spojeno s motivací společnosti Swing poskytovat komponenty a funkce související s UI. Rozhraní používá k uspořádání vztahů mezi událostmi konvence pojmenování (jako je „ActionListener“ a „ActionEvent“). Třída, která potřebuje být upozorněna na nějakou událost, jednoduše implementuje příslušný posluchač, přepíše zděděné metody a přidá se k objektu, který událost vyvolá. Níže uvádíme nejjednodušší příklad:
public class FooPanel rozšiřuje JPanel implementuje ActionListener { public FooPanel () { super (); JButton btn = nové JButton ( "Klikni na mě!" ); btn . addActionListener ( this ); toto . přidat ( btn ); } @Override public void actionPerformed ( ActionEvent ae ) { System . ven . println ( "Tlačítko bylo kliknuto!" ); } }Alternativou je vložení posluchače do objektu jako anonymní třída . Níže je uveden příklad.
public class FooPanel extends JPanel { public FooPanel () { super (); JButton btn = nové JButton ( "Klikni na mě!" ); btn . addActionListener ( new ActionListener () { public void actionPerformed ( ActionEvent ae ) { System . out . println ( "Bylo kliknuto na tlačítko!" ); } }); } }Stejný kód funkčního stylu Java 8 s použitím lambda namísto anonymní třídy:
public class FooPanel extends JPanel { public FooPanel () { super (); JButton btn = nové JButton ( "Klikni na mě!" ); btn . addActionListener ( ae -> System . out . println ( "Bylo kliknuto na tlačítko!" )); } }Platforma JavaScript na straně serveru široce využívá generátory událostí ( EventEmitter ). Mnoho objektů v Node generuje události: net.Server vyvolá událost při každém příchozím požadavku, fs.readStream vyvolá událost při otevření souboru. Příklad práce s EventEmitter:
bar.js:
var Foo = vyžadovat ( "./foo.js" ). Foo , foo = nový Foo (); foo . addListener ( "write" , function () { console . log ( "Bar" ); });foo.js:
var EventEmitter = vyžadovat ( "události" ). EventEmitter , Foo = function () { var foo = this ; foo . write = function () { konzole . log ( "foo" ); foo . emitovat ( "zapsat" ); }; setTimeout ( this . write , 3000 ); }; foo . prototyp = new EventEmitter (); exporty . foo = foo ;