Az eseményvezérelt architektúra ( EDA ) egy olyan szoftverarchitektúra minta , amely lehetővé teszi az események létrehozását, meghatározását, felhasználását és reagálását .
Egy esemény "jelentős állapotváltozásként " definiálható [1] . Például amikor egy ügyfél autót vásárol, az autó állapota „eladó”-ról „eladva” állapotra változik. Az autókereskedő rendszerarchitektúrája ezt az állapotváltozást az architektúrán belüli különböző alkalmazások által létrehozott, közzétett, meghatározott és felhasznált eseményként tudja kezelni.
Ez az architektúra minta alkalmazható olyan alkalmazások és rendszerek tervezésében és megvalósításában, amelyek lazán összekapcsolt szoftverkomponensek és szolgáltatások között kommunikálnak eseményeket . Egy eseményvezérelt rendszer jellemzően eseményforrásokat (vagy ügynököket) és eseményfogyasztókat (vagy nyelőket) tartalmaz. A nyelők felelősek a válaszadásért, ha egy esemény megtörtént. A reakciót teljes egészében a nyelő generálja, vagy nem. Például egy nyelő csak egy esemény szűréséért, átalakításáért és egy másik komponenshez való eljuttatásáért felelős, vagy saját reakciót hozhat létre erre az eseményre. A nyelők első kategóriája hagyományos összetevőkön, például üzenetküldő köztes szoftvereken alapulhat, a második kategóriájú fogadók (amelyek futás közben saját választ alkotnak) pedig megfelelőbb tranzakció-végrehajtási platformot igényelhetnek.
Alkalmazások és rendszerek eseményvezérelt architektúrán belüli létrehozása lehetővé teszi azok jobb interaktivitást elősegítő tervezését, mivel az eseményvezérelt rendszerek jobban strukturálódnak a kiszámíthatatlan és aszinkron környezetek felé [2] .
Az eseményvezérelt architektúra megfelel a szolgáltatás-orientált architektúrának (SOA), mivel a szolgáltatások aktiválhatók a bejövő eseményekből kiváltott triggerekkel [2] [3] .
Ez a paradigma különösen akkor hasznos, ha a nyelő nem biztosítja a saját cselekvések végrehajtását.
Az eseményvezérelt szolgáltatásorientált architektúra a SOA és EDA architektúrákat fejleszti, hogy mélyebb és robusztusabb szolgáltatási réteget biztosítson azáltal, hogy a korábban ismeretlen ok-okozati összefüggéseket kihasználva új eseménymodellt alkot. Ez az új üzleti intelligencia -minta a feldolgozás további automatizálásához vezet, és a vállalat korábban elérhetetlen termelékenységét növeli azáltal, hogy értékes információkat juttat be a felismert tevékenységi mintába.
Egy esemény két részből állhat: egy eseményfejlécből és egy eseménytörzsből. Az eseményfejléc olyan információkat tartalmazhat, mint az esemény neve, az esemény időbélyege és az esemény típusa. Az eseménytörzs leírja, hogy mi történt valójában. Az esemény törzsét nem szabad összetéveszteni az eseményekre adott válaszként alkalmazható sablonnal vagy logikával.
Az eseményvezérelt architektúra négy logikai rétegből áll. A tényleges megszólalással kezdődik, annak technikai ábrázolásával egy esemény formájában, és az eseményre adott reakciók nem üres halmazával ér véget. [négy]
Az első logikai réteg az eseménygenerátor, amely egy tényt regisztrál, és azt eseményként jeleníti meg. Mivel gyakorlatilag bármi, ami érzékelhető, tény lehet, így az eseménygenerátor is. Példaként a generátor lehet egy e-mail kliens, egy e-kereskedelmi rendszer vagy valamilyen érzékelő. Ennek a rétegnek a tervezése és megvalósítása során komoly kihívást jelent a különböző szenzoradatok egyetlen, szabványosított, értékelhető adatformává konvertálása. [4] Tekintettel azonban arra, hogy az esemény szigorúan deklaratív jellegű, bármilyen átalakítási művelet könnyen alkalmazható, így nincs szükség magas szintű szabványosításra.
Az eseménycsatorna egy olyan mechanizmus, amelyen keresztül az információ egy eseménygenerátortól egy eseménykezelő mechanizmushoz [4] vagy nyelőhöz jut el.
Ez lehet TCP/IP kapcsolat vagy bármilyen típusú bemeneti fájl (sima szöveg, XML formátum, e-mail stb.) Egyszerre több eseménycsatorna is nyitva lehet. A közel valós idejű eseményfeldolgozás követelményei miatt jellemzően az eseménycsatornák aszinkron olvasása történik. Az eseményeket a rendszer egy sorban tárolja, és az eseménymotor későbbi feldolgozására vár.
Az eseménykezelő mechanizmus az a hely, ahol egy eseményt azonosítanak, és kiválasztják a megfelelő reakciót, amelyet ezután végrehajtanak. Ez számos állítást is eredményezhet. Például, ha egy, a feldolgozómotorhoz érkezett esemény azt jelenti, hogy „N termék kifogy”, ez a tény „N termék rendelése” és „Értesítés a személyzetnek” reakciókat generálhat. [négy]
Íme az esemény következményei. Különféle módon és formában nyilvánulhat meg; például egy valakinek küldött üzenet, vagy egy alkalmazás, amely valamilyen figyelmeztetést jelenít meg a képernyőn. [4] . A mosogató (eseménymotor) által biztosított automatizálási szinttől függően előfordulhat, hogy ezekre a lépésekre nincs szükség.
Három fő eseménykezelési stílus létezik: egyszerű, menetes és összetett. Ezt a három stílust gyakran együtt használják egy nagy eseményvezérelt architektúrában [4] .
Az egyszerű eseménykezelés a körülmények konkrét mérhető változásaihoz közvetlenül kapcsolódó eseményekre vonatkozik. Az egyszerű eseménykezeléssel olyan ismert események fordulnak elő, amelyek utóhatásokat váltanak ki. Az egyszerű eseménykezelést általában a munkafolyamatok valós idejű kezelésére használják, ezáltal csökkentve a késleltetést és a költségeket [4] .
Például egyszerű eseményeket generál egy érzékelő, amely érzékeli az abroncsnyomás vagy a környezeti hőmérséklet változását.
Az eseményfolyam -feldolgozás (ESP) során normál és ismert események egyaránt előfordulnak. A rendszeres események (parancsok, RFID átvitelek) ismeretét ellenőrzik és továbbítják az információ-előfizetőknek. Az eseményfolyam-feldolgozást általában az információáramlás valós idejű és vállalati szintű kezelésére használják, lehetővé téve az időben történő döntéshozatalt [4] .
Az összetett eseményfeldolgozás lehetővé teszi az egyszerű és közönséges események sorozatainak figyelembevételét, és egy összetett esemény bekövetkezésére következtetni. A komplex eseményfeldolgozás értékeli az események kölcsönös hatását, majd intézkedik. Előfordulhat, hogy az események (ismert vagy gyakori) nem követik a gépelést, és hosszú időn keresztül következnek be. Az eseménykorreláció lehet oksági, időbeli vagy térbeli. Az összetett események kezelése összetett eseményértelmezők, eseménymintázat és illesztés, valamint korrelációs módszerek használatát igényli. Az összetett eseményfeldolgozást általában a rendellenes viselkedések, fenyegetések és lehetőségek azonosítására és reagálására használják [4] .
Az eseményvezérelt architektúra rendkívül lazán kapcsolódik és jól elosztott. Ennek az architektúrának a legjobb eloszlása annak a ténynek köszönhető, hogy egy esemény bármi lehet, ami bárhol létezik. Az architektúra rendkívül lazán párosult, hiszen maga az esemény nem ismeri bekövetkezésének következményeit, vagyis ha van olyan biztonsági rendszerünk, amely a bejárati ajtó kinyitásakor információkat rögzít, akkor maga az ajtó nem tudja, hogy a biztonsági rendszer információkat ad az ajtónyitásról. [négy]
A Java Swing könyvtár eseményvezérelt architektúrán alapul. Ez különösen jól illeszkedik a Swing motivációjához, hogy a felhasználói felülettel kapcsolatos összetevőket és funkciókat biztosítsa. Az interfész elnevezési konvenciókat (például "ActionListener" és "ActionEvent") használ az események közötti kapcsolatok megszervezéséhez. Egy osztály, amelyet valamilyen eseményről értesíteni kell, egyszerűen megvalósítja a megfelelő figyelőt, felülbírálja az örökölt metódusokat, és hozzáadódik az eseményt előidéző objektumhoz. Az alábbiakban a legegyszerűbb példa:
public class FooPanel expands JPanel implements ActionListener { public FooPanel ( ) { szuper ( ); JButton btn = new JButton ( "Kattintson rám!" ); btn . addActionListener ( ez ); ezt . add ( btn ); } @Override public void actionPerformed ( ActionEvent ae ) { Rendszer . ki . println ( "A gombra kattintottak!" ); } }Alternatív megoldásként a hallgatót anonim osztályként ágyazzuk be az objektumba . Alább egy példa.
public class FooPanel extends JPanel { public FooPanel () { szuper (); JButton btn = new JButton ( "Kattintson rám!" ); btn . addActionListener ( new ActionListener () { public void actionPerformed ( ActionEvent ae ) { System . out . println ( "A gombra kattintottak!" ); } }); } }Ugyanaz a Java 8 funkcionális stíluskód, névtelen osztály helyett lambda használatával:
public class FooPanel extends JPanel { public FooPanel () { szuper (); JButton btn = new JButton ( "Kattintson rám!" ); btn . addActionListener ( ae -> System . out . println ( "A gombra kattintottak!" )); } }A szerveroldali JavaScript platform kiterjedten használja az eseménygenerátorokat ( EventEmitter ). A Node-ban számos objektum generál eseményeket: a net.Server minden bejövő kérésnél eseményt vet fel, az fs.readStream pedig a fájl megnyitásakor. Példa az EventEmitter használatára:
bar.js:
var Foo = követelmény ( "./foo.js" ). Foo , foo = új Foo (); fú . addListener ( "write" , function () { console . log ( "Bar" ); });foo.js:
var EventEmitter = követelmény ( "események" ). EventEmitter , Foo = function () { var foo = this ; fú . írás = function () { konzol . log ( "foo" ); fú . emit ( "ír" ); }; setTimeout ( this . write , 3000 ); }; fú . prototípus = new EventEmitter (); export . foo = foo ;