Eseményvezérelt architektúra

Ez a cikk vagy az azt követő szakasz nem rendelkezik megfelelően az igazoló dokumentumokkal ( pl. Egyedi bizonyítékokkal ). A megfelelő bizonyítékokkal nem rendelkező információk hamarosan eltávolíthatók. Kérjük, segítse a Wikipédiát az információk kutatásával és jó bizonyítékokkal.

Az eseményvezérelt architektúra , egyben az eseményvezérelt architektúra , olyan szoftverarchitektúra , amelyben az összetevők interakcióját események vezérlik.

Események

Az események kívülről jöhetnek, pl. B. felhasználói bemenetek vagy szenzorértékek, valamint maga a rendszer (pl. Változásértesítések).

Egy esemény kiválthatja az eseménykezelést, amellyel a rendszer reagál. Egy eseményvezérelt architektúra kevéssé vezérli az adatok feldolgozását. Egyszerű példa a grafikus felhasználói felület : Itt a felhasználó műveletek végrehajtásával és ezáltal események kiváltásával határozza meg, hogy mely adatokat és mikor dolgozzák fel.

Ennek az architektúrának a használata megköveteli, hogy minden, az esemény kezelésében részt vevő rendszer kommunikálni tudjon egymással a tervezés és a fejlesztés során. Általában az eseményvezérelt architektúra megköveteli annak meghatározását, hogy mi tekintendő eseménynek. Ehhez számítógépes rendszerek vagy érzékelők figyelik az objektumok állapotát, és szükség esetén eseményt indíthatnak. Ezt követi az esemény meghatározott szabályok szerinti feldolgozása és az esemény következménye. Ha az esemény feldolgozása során nem lehet azonnal elérni az esemény meghatározott sorrendjét, akkor az esemény ideiglenesen abban az állapotban kerül tárolásra, amelyet elért, és csak akkor folytatódik, amikor a sorrend elérhető.

Az eseményvezérelt architektúrának akkor van a legnagyobb előnye, ha már a tervezés szakaszában figyelembe veszik. A meglévő szoftverek eseményvezérelt architektúrává alakítása elfogadhatatlan erőfeszítéseket eredményezhet a szükséges interfészek hiánya miatt.

Az eseményvezérelt architektúra kiegészíti a szolgáltatásorientált architektúrát , mivel a szolgáltatásokat események válthatják ki. Az eseményvezérelt architektúra alapján különösen eseményvezérelt folyamatláncok rendszerei fejleszthetők.

Eseményfolyam

Egy esemény általában három információt tartalmaz: a létrehozás idejét ( időbélyeg ), a kiváltó összetevőt (forrás) és az esemény típusát (típus), amely meghatározza, hogy mi történt lényegében. Az eseménytípust gyakran nem az adott programozási nyelv meghatározott típusa határozza meg , hanem az esemény hierarchikus témája , például pszeudo URI formájában , mint pl.topic://OptionsDialog/Controls/AcceptButton/Click

Az események eseménykezelői ( eseménykezelők ) elfogták, hogy az objektumorientálást módszerekben vagy saját osztályokban valósítsák meg. Ha egy rutin felelős az elfogott eseménytípusért, megfelelő feldolgozási lépéseket kezdeményez. Ettől függetlenül a rutin átadhatja az eseményt más rutinoknak, vagy megjelölheti készként, vagy eldobhatja.

Az események nem olyan üzenetek, amelyeket célzottan küldenek el bizonyos komponenseknek, hanem inkább úgymond „vakon” továbbítják a rendszernek. Egy esemény kiválthatja a műveleteket a rendszer egy vagy több pontján, de teljesen észrevétlenül el is dobható (mert egyetlen eseményt sem jelöltek meg felelősnek az eseményért). Mivel kezdetben nincs meghatározva az idő és a sorrend, amelyben egy esemény eléri a különböző összetevőket, a rutinok független, befejezett feladatokat dolgoznak fel. Az eseményvezérelt architektúrát alapvetően párhuzamos feldolgozásra tervezték .

Modellezés

Az eseményvezérelt architektúra négy logikai szintre épül. Ez egy esemény kiváltásával kezdődik, és az eseményre adott bármilyen reakcióval végződik. Az ilyen rendszerek tervezéséhez szekvenciadiagramokat és hasonló folyamatábrákat használnak.

Rendezvény producere ( eseménygenerátor )

Ennek az architektúrának az első logikai szintje az esemény előállítója ( eseménygenerátor ) , amely figyeli az objektum állapotát. Az eseményeket bármilyen szoftver előállíthatja, amely felhasználható állapotfigyelésre. Üzleti intelligencia megoldások, e-mail kliens, CRM rendszerek, illetve DMS rendszerek példái . Ezenkívül érzékelők - például hőmérséklet-érzékelők, tachométerek vagy mikrofonok - is kiválthatják az eseményt. Ennek a szintnek a kialakításában és megvalósításában a legnagyobb kihívás a rendezvény producereitől különböző adatok felhasználható egységes formátumra konvertálása.

Eseményhordozó ( eseménycsatorna )

Azt a médiumot, amely az eseményről információt továbbítja az esemény szabályrendszeréhez, eseményhordozónak nevezzük. Ez az adathordozó gyakran egyszerűen egy terület a számítógép fő memóriájában (vagyis az eseményt kezelő módszer vagy rutin belépési címe). Lehet azonban kábel (pl. Érzékelők számára), adatbázis, TCP / IP kapcsolat vagy bármilyen fájl (lapos, XML stb.) Is használható. Bármennyi eseményhordozó lehet és lehet aktív egyidejűleg.

Eseményfeldolgozási szabályok ( eseményfeldolgozó motor )

Az eseményszabálykészlet azonosítja, osztályozza és feldolgozza az eseményt. Az azonosításhoz szükséges, hogy a szabályok és előírások figyelemmel kísérjék az események előfordulását. Ezután az eseményt az esemény típusa alapján osztályozzák. Minden besorolt ​​eseményhez szabálykészlet van hozzárendelve, amelyet az adott esemény bekövetkezése után hajtanak végre. A szabályokat programkóddal hajtják végre, de tárolhatók relációs adatbázisokban SQL utasítások segítségével, speciális munkafolyamat-kezelő rendszerekben vagy speciális vezérlő szoftverekben is. Ennek a rétegnek a kialakításakor biztosítani kell a lehető legnagyobb fokú automatizmus elérését. A szabályhalmaz végigfutása után új esemény merülhet fel, amely viszont - mint más esemény - egy további szabályhalmazon fut át.

Eseménytevékenység ( downstream eseményvezérelt tevékenység )

Ebben a váltásban az eseményre reagál, például levél küldésére, hangjelzés kiváltására, egy gép vészleállítására stb.

Az eseményvezérelt feldolgozás típusai

Az eseményvezérelt architektúra háromféle folyamatot különböztet meg: egyszerű, folyamatos és összetett. Általános szabály, hogy mindhárom típusú folyamat eseményvezérelt rendszerekben fordul elő.

Egyszerű eseményfeldolgozás ( egyszerű eseményfeldolgozás )

Az egyszerű eseményvezérelt folyamatok közvetlenül kiváltják a konkrét eredményeket. Ha például minden ügyfélnek születésnapi kártyát kell kapnia, akkor az összes érintett ügyfelet kiválaszthatja egy SQL lekérdezéssel, a címadatokat összekapcsolhatja egy űrleveles sablonnal és megkezdheti a nyomtatást.

Eseményfolyamok feldolgozása ( eseményfolyam-feldolgozás )

Az Event Stream Processing (röviden: ESP, németül: „ Event Streaming feldolgozása ”) az események vizualizálására és tárolására, az eseményvezérelt köztes szoftverekre és az eseményfeldolgozási nyelvekrevonatkozó számos technológia átfogó kifejezése.

Összetett események feldolgozása ( összetett események feldolgozása )

Ha több, oksági, térbeli vagy rövid távú összefüggéssel rendelkező esemény kombinálódik egy közös folyamatban, akkor egy komplex eseményvezérelt folyamatról beszélünk. Egy összetett eseményvezérelt folyamatban olyan struktúrára van szükség, amely azonosítja a listából a döntő eseményt, és feldolgozza azt a szabálykészlet következő lépéséig. Az esemény-gyártók, eseményhordozók fejlesztése és a komplex eseményvezérelt folyamatok szabályainak meghatározása általában kihívást jelent. A CEP potenciális alkalmazási területe az operatív gyakorlatban pl. B. az ellenőrző funkcióját ellátási lánc menedzsment esemény (SCEM) rendszerek: CEP segítségével a vállalatok elemzésével növekvő adatmennyiség az ellátási lánc menedzsment (beleértve a fokozott használata a fejlett tervezési és ütemezési - Rendszerek, nyomkövető rendszerek, RFID infrastruktúrák stb.) Az ellátási lánc kritikus eltéréseinek felderítésére.

Az alkatrészek leválasztása

Ha a szoftverkomponensek lazán vannak összekapcsolva, akkor az A komponens, amely egy további B komponens funkcionalitását használja , nem "tud" semmit az interfész közzétételének belső működéséről, vagyis a B komponens funkcionalitásának konkrét megvalósításáról, de valamit az aláírásokról az e funkciókat biztosító módszerek közül. Tisztán eseményorientált rendszerben ezekre az ismeretekre már nincs szükség, mivel az események, amint fentebb látható, „vakon” és „a levegőbe” válthatók. Az esemény producere azonban nem támaszkodhat arra, hogy az eseményt a rendszer bárhol másutt figyelembe veszik, rögzítik és feldolgozzák, amennyiben az esemény producere programfolyamatának függetlennek kell lennie az esemény bármilyen kezelésétől. (Ez a követelmény független attól a ténytől, hogy egy esemény be nem tartása károsíthatja a szoftver termék működését.)

A rendszerek univerzális összekapcsolása

Az eseményvezérelt architektúra lehetővé teszi a rendszerek kompakt összekapcsolását és univerzálisan használható. Ennek a nyitott architektúrának az előnye: Egy esemény bármi lehet és bárhol előfordulhat. Amikor egy esemény bekövetkezik, gyakran nem szabályozzák, hogyan kell kezelni az eseményt. Az üzleti folyamatok okának keresése speciálisan meghatározott eseményeken rengeteg lehetőséghez vezet, amelyekből célorientált szervezeti modellek származhatnak.

irodalom

  • Ralf Bruns, Jürgen Dunkel: Eseményalapú építészet. Szoftverarchitektúra eseményvezérelt üzleti folyamatokhoz , X.pert Press (Springer) 2010, ISBN 978-3-642-02438-2
  • Thomas Buckel: Az eseményvezérelt architektúra komplex vállalati hálózatokban rejlő lehetőségeiről , in: Dirk Christian Mattfeld, Susanne Robra-Bissantz (Szerk.): Multikonferenz Wirtschaftsinformatik 2012, az MKWI 2012 eljárásai
  • Josef Schiefer, Rozsnyai Szabolcs, Christian Rauscher, Gerd Saurer: Eseményalapú szabályok az üzleti helyzetek érzékeléséhez és reagálásához . In: DEBS '07 Az elosztott eseményalapú rendszerekről szóló 2007. évi alakuló nemzetközi konferencia anyagai . ACM, New York 2007, ISBN 978-1-59593-665-3 , pp. 198–205 ( online a CiteSeer oldalon - egy „szabálykezelő rendszer” bemutatása az EDA-ban).