Geavanceerd Event Driven Engineering

Event2Een Event Driven Architecture (EDA) is een sterke architectuur om de communicatie tussen IT-systemen te organizeren. EDA is echter niet het enige wat je met Events kan doen. In deze blog bekijken we een aantal geavanceerde mogelijkheden binnen de ruimere context van Event Driven Engineering.

 

In een vorige blog bespraken we reeds de basis van Event Driven Engineering: de definitie van wat Events juist zijn, het publish/subscribe mechanisme, en de Event-Driven Architecture, gebaseerd op de Event Bus. Nu zullen we het gaan hebben over Event Sourcing: het bouwen van applicaties, volledig gebaseerd op het concept van Events, en over Complex Event Processing: een techniek waarmee, in real-time, intelligente beslissingen kunnen worden genomen.

Event Sourcing

De meeste webapplicaties die we kennen, hebben één of andere toestand die evolueert doorheen de tijd, en die doorgaans opgeslagen wordt in een achterliggende database. Wanneer we b.v. inloggen op online banking, zien we het huidige saldo van onze rekeningen. Wanneer we morgen geld van onze rekening halen, dan zal deze toestand overmorgen zijn veranderd.

Wanneer we even afstand nemen van deze gang van zaken, dan kunnen we de bedenking maken, dat elke huidige toestand in feite het gevolg is van een hele reeks van historische toestandsveranderingen, startende bij één of andere begintoestand, wanneer de applicatie voor het eerst online ging.

Welnu, elke toestandsverandering binnen een systeem kunnen we perfect modelleren als… een Event! Wanneer we dit daadwerkelijk doen, kunnen we het computersysteem op zo’n manier laten werken, dat de huidige toestand “berekend wordt” op basis van alle in chronologische volgorde gezette toestandsveranderingen, die we als Events in de applicatie laten binnenkomen. Wanneer we daarnaast ook nog deze Events opslaan – i.p.v. de huidige toestand – dan spreken we van “Event Sourcing“. Dit wil dus letterlijk zeggen dat de broncode van de applicatie gebaseerd is op Events.

Event Sourcing in het schaakspel: de huidige toestand van het spel wordt bekomen door de opeenvolgende zetten toe te passen op het bord in de begintoestand. Door de zetten op te slaan in plaats van enkel het bord krijgen we een veel rijker inzicht in hoe dit spel is geëvolueerd.

Event Sourcing in het schaakspel: de huidige toestand van het spel wordt bekomen door de opeenvolgende zetten toe te passen op het bord in de begintoestand. Door de zetten op te slaan in plaats van enkel het bord, krijgen we een veel rijker inzicht in hoe dit spel is geëvolueerd.

Een bedenking die iedereen snel zal maken, is natuurlijk dat dit na verloop van tijd zeer onefficiënt zou worden: hoe meer Events er zijn, hoe zwaarder de berekening wordt om de huidige toestand te bekomen! Om die reden zullen er uiteraard steeds bepaalde optimizaties aanwezig zijn in de applicatie, zonder wezenlijk de Event-Sourced eigenschappen ervan te veranderen. Zo is het natuurlijk zaak om de huidige toestand in een cache of buffer te houden, zodat enkel nieuwe Events in rekening gebracht moeten worden om de toestand te laten evolueren. Daarnaast is het ook handig om van deze toestand af en toe een backup weg te schrijven, zodat ook bij het eventuele uitvallen van de toepassing, slechts een deel van de toestand opnieuw berekend dient te worden aan de hand van Events.

Met het bewaren van Events in plaats van enkel de huidige toestand, krijgt men een aantal interessante mogelijkheden. Zoals in de vorige paragraaf gezegd, kunnen we de toestand terug heropbouwen. Sterker nog: we kunnen de toestand van eender welk moment in de geschiedenis van de applicatie terugbrengen (handig om te weten wat er op een bepaald moment aan de hand was). Daarnaast kunnen we nieuwe versies van de applicatie testen door Events opnieuw af te laten spelen voor een testversie: zo krijgt men erg realistische tests. Ten slotte laat de rijkheid aan gegevens binnen de Events ons toe om temporele queries te gaan uitvoeren; dit soort data zouden we bij een standaard aanpak vaak kwijt zijn.

Er zijn een aantal speciale vormen van temporele gegevens die automatisch beschikbaar zijn, indien men Event Sourcing goed aanpakt. Zo kunnen Events erg eenvoudig gelogd worden en op die manier deel gaan uitmaken van een rijkere applicatielogging. Ook audit logs kunnen vaak (deels) uit de Events worden afgeleid. Ten slotte vormen de Events van een Event-Sourced applicatie automatisch ook een goede backup van de gegevens, gezien men de toestand van de applicatie ermee kan heropbouwen.

Complex Event Processing (en Analytics)

Complex Event Processing (CEP) systemen zijn een belangrijke schakel wanneer men applicaties tijdige intelligente beslissingen wil laten nemen, op basis van wat er aan het gebeuren is. Dit soort systemen zal naar binnenkomende Events luisteren (zoals andere applicaties die zich ervoor inschrijven), en zal specifiek letten op het voorkomen van bepaalde patronen in Events die zich afspelen. Wanneer het CEP systeem zo’n opeenvolging van Events heeft opgemerkt, zal het reageren. Dit kan het doen door zelf een nieuw, “complex” Event te publiceren, waar weer andere systemen op zullen kunnen reageren. Op die manier transformeren zulke systemen een bepaalde reeks van elkaar opvolgende Events dus in een nieuw, complex Event; dit alles op basis van een set van complexe regels, die door programmeurs, maar vaak ook door een “(zelf-)lerend” systeem, zijn ingegeven.

Op die manier zijn CEP systemen ook belangrijk in Big Data Analytics, waarbij de Big Data bestaat uit zaken die doorheen de tijd gebeuren (plus uiteraard andere vormen van verwante data). Deze vorm van Big Data is bijvoorbeeld interessant bij het detecteren van fraudepatronen, waarbij fraudeurs gedurende een bepaalde tijd een aantal handelingen uitvoeren die uiteindelijk tot fraude leiden. Het herkennen en vervolgens detecteren van de juiste patronen in een hele reeks van handelingen (waar uiteraard ook niet-verdachte handelingen en zelfs niet-gerelateerde handelingen tussen zitten), is daarbij cruciaal.

Complex Event Processing: patronen van eenvoudige Events worden herkend op basis van regel en leiden tot "complexe Events". Alle Events samen kunnen via Analytics leiden tot de juiste regels voor patroonherkenning.

Complex Event Processing: patronen van eenvoudige Events worden herkend op basis van regels en leiden tot “complexe Events”. Alle Events samen kunnen via Analytics leiden tot betere regels voor patroonherkenning.

CEP laat in deze use case toe de resultaten van analytics – de herkende patronen van zaken die gebeuren doorheen de tijd – rechtstreeks toe te passen op een systeem dat live is, waardoor ze in real-time kunnen worden gedetecteerd en er dus veel sneller op kan worden gereageerd. Daarnaast genereren de CEP systemen nieuwe, complexe Events, die de reeds aanwezige Events in de Big Data kunnen verrijken. Hierdoor vergroot de hoeveelheid data waaruit de analytische applicaties zullen kunnen putten om weer nieuwe Event-patronen aan te leren.

Besluit

Events zijn niet alleen nuttig als loskoppelend communicatiesysteem tussen applicaties, maar zijn op zich ook een erg krachtig paradigma als bouwsteen voor sommige individuele applicaties, of als gegevensbron voor Big Data Analytics en real-time intelligente systemen.

Leave a Reply

Your email address will not be published.