En begivenhedsdrevet arkitektur ( EDA ) er et softwarearkitekturmønster , der tillader oprettelse, definition, forbrug og reaktion på begivenheder .
En hændelse kan defineres som en "større tilstandsændring " [1] . For eksempel, når en kunde køber en bil, ændres bilens tilstand fra "til salg" til "solgt". Bilforhandlerens systemarkitektur kan behandle denne tilstandsændring som en hændelse, der er oprettet, offentliggjort, defineret og forbrugt af de forskellige applikationer i arkitekturen.
Dette arkitektoniske mønster kan anvendes i design og implementering af applikationer og systemer, der kommunikerer hændelser mellem løst koblede softwarekomponenter og tjenester . Et hændelsesdrevet system indeholder typisk hændelseskilder (eller agenter) og hændelsesforbrugere (eller sinks). Dræn er ansvarlige for at reagere, når en hændelse er indtruffet. Reaktionen kan eller kan ikke være fuldstændig genereret af vasken. For eksempel kan en vask kun være ansvarlig for at filtrere, transformere og levere en hændelse til en anden komponent, eller den kan skabe sin egen reaktion på denne hændelse. Den første kategori af dræn kan være baseret på traditionelle komponenter såsom meddelelsesmiddleware, og den anden kategori af dræn (der danner sit eget svar, mens den kører) kan kræve en mere passende platform for transaktionsudførelse.
At skabe applikationer og systemer inden for en begivenhedsdrevet arkitektur gør det muligt at designe dem på en måde, der fremmer bedre interaktivitet, da begivenhedsdrevne systemer er mere strukturerede mod uforudsigelige og asynkrone miljøer [2] .
En hændelsesdrevet arkitektur svarer til en serviceorienteret arkitektur (SOA), fordi tjenester kan aktiveres af triggere, der udløses fra indkommende hændelser [2] [3] .
Dette paradigme er især nyttigt, når vasken ikke giver sin egen udførelse af handlinger.
Event Driven Service Oriented Architecture udvikler SOA- og EDA-arkitekturer for at give et dybere og mere robust lag af tjenester ved at udnytte tidligere ukendte årsags- og virkningsforhold til at danne en ny hændelsesmodel. Dette nye business intelligence -mønster fører til yderligere automatisering af behandlingen, hvilket tilfører virksomheden en hidtil uopnåelig produktivitet ved at injicere værdifuld information i det anerkendte aktivitetsmønster.
En begivenhed kan bestå af to dele: en begivenhedsoverskrift og en begivenhedstekst. Begivenhedsoverskriften kan indeholde oplysninger såsom navnet på begivenheden, tidsstemplet for begivenheden og begivenhedens type. Begivenhedsteksten beskriver, hvad der faktisk skete. Brødteksten af en hændelse må ikke forveksles med skabelonen eller logikken, der kan anvendes som svar på hændelser.
Den begivenhedsdrevne arkitektur består af fire logiske lag. Den starter med selve lyden, dens tekniske repræsentation i form af en begivenhed og slutter med et ikke-tomt sæt reaktioner på denne begivenhed. [fire]
Det første logiske lag er hændelsesgeneratoren, som registrerer et faktum og repræsenterer dette faktum som en hændelse. Da stort set alt, der kan opfattes, kan være en kendsgerning, kan en begivenhedsgenerator også være det. Som et eksempel kan generatoren være en e-mail-klient, et e-handelssystem eller en eller anden type sensor. Konvertering af de forskellige sensordata til en enkelt, standardiseret form for data, der kan evalueres, er en stor udfordring i designet og implementeringen af dette lag. [4] Men da begivenheden er strengt deklarativ, kan enhver transformationsoperation let anvendes, hvilket eliminerer behovet for et højt standardiseringsniveau.
En hændelseskanal er en mekanisme, hvorigennem information sendes fra en hændelsesgenerator til en hændelseshåndteringsmekanisme [4] eller sink.
Dette kan være en TCP/IP-forbindelse eller en hvilken som helst type inputfil (almindelig tekst, XML-format, e-mail osv.) Flere begivenhedskanaler kan være åbne på samme tid. På grund af kravene til nær-realtidshændelsesbehandling læses hændelseskanaler typisk asynkront. Hændelser gemmes i en kø og venter på senere behandling af hændelsesmotoren.
Hændelseshåndteringsmekanismen er det sted, hvor en hændelse identificeres, og en passende reaktion på den vælges, som derefter udføres. Dette kan også resultere i, at der genereres en række påstande. For eksempel, hvis en hændelse, der er ankommet til behandlingsmotoren, rapporterer, at "Produkt N er ved at løbe tør", kan denne kendsgerning generere reaktionerne "Bestil produkt N" og "Underret personale". [fire]
Her er konsekvenserne af begivenheden. Det kan vise sig på forskellige måder og former; for eksempel en besked sendt til nogen, eller et program, der viser en form for advarsel på skærmen. [4] . Afhængigt af automatiseringsniveauet, der leveres af vasken (hændelsesmotor), er disse trin muligvis ikke nødvendige.
Der er tre hovedstile til håndtering af begivenheder: enkel, trådet og kompleks. Ofte bruges disse tre stilarter sammen i en stor begivenhedsdrevet arkitektur [4] .
Simpel hændelseshåndtering vedrører hændelser direkte relateret til specifikke målbare ændringer i forhold. Med simpel hændelseshåndtering opstår kendte hændelser, der udløser eftervirkninger. Simpel hændelseshåndtering bruges almindeligvis til at styre workflow i realtid, hvorved ventetiden og omkostningerne reduceres [4] .
For eksempel genereres simple hændelser af en sensor, der registrerer en ændring i dæktryk eller omgivende temperatur.
Under hændelsesstrømbehandling (ESP) forekommer både normale og kendte hændelser. Regelmæssige hændelser (kommandoer, RFID-transmissioner) kontrolleres for viden og sendes til informationsabonnenter. Hændelsesflowbehandling bruges almindeligvis til at styre informationsstrømmen i realtid og på virksomhedsniveau, hvilket muliggør rettidig beslutningstagning [4] .
Kompleks hændelsesbehandling giver dig mulighed for at overveje sekvenser af simple og almindelige hændelser og udlede forekomsten af en kompleks hændelse. Kompleks hændelsesbehandling evaluerer den gensidige indflydelse af hændelser og skrider derefter til handling. Hændelser (kendte eller almindelige) følger muligvis ikke indtastningen og forekommer over lange tidsperioder. Hændelseskorrelation kan være kausal, tidsmæssig eller rumlig. Håndtering af komplekse hændelser kræver brug af komplekse hændelsestolke, hændelsesmønstre og -matchning og korrelationsmetoder. Kompleks hændelsesbehandling bruges almindeligvis til at identificere og reagere på unormal adfærd, trusler og muligheder [4] .
Den begivenhedsdrevne arkitektur er ekstremt løst koblet og godt fordelt. Den bedste fordeling af denne arkitektur skyldes, at en begivenhed kan være hvad som helst, der eksisterer hvor som helst. Arkitekturen er ekstremt løst koblet, da begivenheden ikke selv kender konsekvenserne af sin forekomst, det vil sige, hvis vi har et sikkerhedssystem, der registrerer information, når hoveddøren åbnes, så ved døren ikke selv, at sikkerhedssystemet vil tilføje oplysninger om åbningen af døren. [fire]
Java Swing- biblioteket er baseret på en begivenhedsdrevet arkitektur. Dette hænger særligt godt sammen med Swings motivation for at levere UI-relaterede komponenter og funktionalitet. Grænsefladen bruger navngivningskonventioner (såsom "ActionListener" og "ActionEvent") til at organisere relationer mellem begivenheder. En klasse, der skal underrettes om en eller anden hændelse, implementerer simpelthen den passende lytter, tilsidesætter nedarvede metoder og føjes til det objekt, der rejser hændelsen. Nedenfor er det enkleste eksempel:
public class FooPanel udvider JPanel implementerer ActionListener { public FooPanel () { super (); JButton btn = ny JButton ( "Klik mig!" ); btn . addActionListener ( dette ); dette . tilføje ( btn ); } @Override public void actionPerformed ( ActionEvent ae ) { System . ud . println ( "Knappen er blevet klikket!" ); } }Et alternativ er at indlejre lytteren i objektet som en anonym klasse . Nedenfor er et eksempel.
public class FooPanel udvider JPanel { public FooPanel () { super (); JButton btn = ny JButton ( "Klik mig!" ); btn . addActionListener ( ny ActionListener () { public void actionPerformed ( ActionEvent ae ) { System . out . println ( "Knappen er blevet klikket!" ); } }); } }Den samme Java 8 funktionelle stilkode, der bruger en lambda i stedet for en anonym klasse:
public class FooPanel udvider JPanel { public FooPanel () { super (); JButton btn = ny JButton ( "Klik mig!" ); btn . addActionListener ( ae -> System . out . println ( "Knappen er blevet klikket!" )); } }JavaScript-platformen på serversiden gør udstrakt brug af hændelsesgeneratorer ( EventEmitter ). Mange objekter i Node genererer begivenheder: net.Server rejser en begivenhed ved hver indkommende anmodning, fs.readStream rejser en begivenhed, når en fil åbnes. Eksempel på arbejde med EventEmitter:
bar.js:
var Foo = require ( "./foo.js" ). Foo , foo = ny Foo (); foo . addListener ( "skriv" , funktion () { konsol . log ( "Bar" ); });foo.js:
var EventEmitter = require ( "hændelser" ). EventEmitter , Foo = function () { var foo = this ; foo . skriv = funktion () { konsol . log ( "foo" ); foo . udsende ( "skriv" ); }; setTimeout ( dette .skrive , 3000 ) ; }; foo . prototype = ny EventEmitter (); eksport . foo = foo ;