Event Driven Architecture (EDA) is niet meer weg te schrijven uit moderne software-architectuur. Maar wanneer ben je nu effectief EDA aan het gebruiken? Soms kan het zijn dat dit paradigma in je software-systeem zit, zonder dat je er erg in hebt. En daarnaast gebeurt het ook vaak dat een architect zegt dat zijn systeem EDA gebruikt, maar dat de toehoorders zich daar iets heel anders bij voorstellen dan wat die architect eigenlijk bedoelt. Meestal ontstaat deze verwarring doordat er een aantal verschillende patronen bestaan, die allemaal onder dezelfde noemer van EDA vallen. In deze blog laten we ons licht schijnen op de 4 belangrijkste vormen van EDA.

Alle 4 deze vormen van EDA, zullen natuurlijk gebruik maken van de basis: een set van Event producers kan Events genereren en aan een of ander kanaal geven, waarna de Events worden afgeleverd aan een set van Event consumers. Zowel producers als consumers communiceren enkel met het kanaal (typisch een Event Broker) en hoeven elkaar voor de rest niet te contacteren (althans wat het versturen en ontvangen van de Events betreft).

Event Notification

De eerste manier om aan EDA te doen is de meest eenvoudige: een Event wordt hier simpelweg verstuurd om aan te geven dat er iets is gebeurd. Bijvoorbeeld een ‘CustomerChangedEvent’ om aan te geven dat er iets werd aangepast aan een klantenfiche, of een ‘OrderPlacedEvent’ om aan te geven dat er een nieuw order is.

Belangrijk in dit patroon, is dat de Events verder geen toestand bevatten. Als de ontvangers van het event dus willen weten wát er precies is veranderd aan de klantenfiche, of wát er besteld werd in het order, dan zullen ze toch actief initiatief moeten nemen om aan deze informatie te geraken. Typisch zullen er dan, na het ontvangen van een event, API calls moeten worden gedaan naar het systeem dat rond de bron van het Event ligt, om meer details te bekomen.

De voordelen van dit patroon liggen voornamelijk in de eenvoud ervan: de Events zijn heel erg ‘lightweight’ en eenvoudig te implementeren. Een ander voordeel is dat het systeem dat Events verstuurt, niet hoeft te weten welke systemen er allemaal in de informatie zijn geïnteresseerd: ze zullen de informatie wel komen halen eens ze het Event ontvangen. Er wordt dus al een zekere mate van ‘louse coupling‘ en ‘Inversion of Control‘ bereikt.

Het nadeel van dit patroon is dat het aantal communicaties dat nodig is om bepaalde informatie te verspreiden naar de plaatsen waar ze nodig is, wordt verdubbeld: één keer om het Event te sturen, een tweede maal wanneer er extra informatie wordt gevraagd. Bovendien bestaat er nog steeds een afhankelijkheid in één richting, omdat de systemen die extra informatie nodig hebben, zullen moeten weten waar ze te gaan halen.

Het zal niet verbazen dat deze eenvoudige manier van werken met Events, met overwicht nog steeds de meest gebruikte vorm is, en dat, wanneer er wordt gezegd “ons systeem maakt gebruik van EDA”, er dus meestal Event Notification wordt bedoeld. Dit is echter lang niet de meest krachtige en voordelige manier om van het paradigma gebruik te maken…

Event-Carried State Transfer

Deze tweede manier van werken is de gouden middenweg tussen het toepassen van de volledige kracht van EDA, en het loslaten van de bijhorende complexiteit op een systeem. Het is ook hetgeen de echte voorstanders van EDA begrijpen, wanneer ze van een architect horen dat het paradigma wordt toegepast.

De naam Event-carried State Transfer (EST ?) is gekozen om een beetje te contrasteren met REST (Representational State Transfer). Er is dus sprake van het overbrengen van toestand, t.t.z. effectieve gegevens, tussen systemen. Als we het vorige voorbeeld hernemen, dan zal er aan het CustomerChangedEvent effectief zijn toegevoegd wát er precies is veranderd: minimum wat het nieuwe gegeven is, eventueel ook wat het oude gegeven was, en mogelijks zelfs een hele resem extra gegevens over de klant. Dit vormt meteen ook de moeilijkste evenwichtsoefening bij het ontwerp: hoeveel data zullen we precies toevoegen aan het Event? De bedoeling is natuurlijk dat de ontvanger van het Event alles heeft wat er nodig is om verder te kunnen, zonder nog extra gegevens te moeten gaan opvragen.

De voordelen van dit patroon zijn uiteraard precies de nadelen van het vorige: als het Event het juiste ‘gewicht’ heeft, kan extra communicatie tussen alle partijen worden vermeden, en zijn de systemen dus bijgevolg ook wederzijds onafhankelijk van elkaar: ze hoeven enkel nog met het kanaal te praten via welke Events worden beheerd. Elk systeem kan direct aan de slag met de juiste informatie die door het Event wordt aangeleverd.

Een bijkomend voordeel is dat de Events volgens dit paradigma een grotere mate van herbruikbaarheid hebben: men kan een catalogus aanleggen van Events die beschikbaar zijn in een ecosysteem van applicaties als primaire manier om gegevens over te brengen: een volwaardig alternatief voor RESTful APIs. Elke nieuwe applicatie die de aangeboden informatie kan gebruiken, kan zich dan inschrijven om het desbetreffende Event te ontvangen.

Nadeel is dat deze manier van werken met Events iets meer werk vraagt: men zal moeten nadenken over welke Events het meest nuttig zijn en hoeveel informatie deze best bevatten. Men zal de Events moeten opnemen in een catalogus, zodat ze optimaal worden hergebruikt. Daarnaast krijgt men soms wat overbodig dataverkeer omdat de Events mogelijks meer informatie bevatten dan de ontvanger nodig heeft. De architecturale complexiteit is echter slechts een weinig hoger dan bij Event Notifications (voor de applicties die Events versturen blijft het b.v. gewoon “iets extra doen op sommige momenten”).

Een laatste aandachtspunt is dat het inzetten van EDA om toestand te verspreiden overheen systemen de notie van Eventual Consistency neigt te activeren. Dit kan zowel voordelen als nadelen hebben.

Event-Carried State Transfer komt dan wel al wat vaker voor dan vroeger (en ligt ook meestal aan de basis van het populair geworden event streaming), maar er ligt nog heel wat onaangeroerd potentieel om met deze manier van werken grote voordelen te behalen in sommige applicatie-ecosystemen.

Event Sourcing

Nu komen we bij de echte kern van het paradigma, waarbij we radicaal voor EDA kiezen doorheen het volledige ontwerp van ons systeem. Waar de vorige manieren van werken nog weinig intrusief waren in de architectuur, is dit bij Event Sourcing niet langer het geval: de architectuur is nu volledig op Events gebaseerd.

Bij Event Sourcing zal een systeem niet meer op de normale manier zijn toestand gaan bepalen of bewaren, maar zal de huidige toestand steeds gezien worden als gevolg van het ontvangen van een reeks van Events, die elk een kleine toestandswijziging teweegbrengen. Je kan het zien als een bankrekening: het huidige saldo is simpelweg het resultaat van alle voorbije verrichtingen. Een ander goed voorbeeld betreft versiecontrolesystemen zoals git: bij zo’n systeem is de huidige toestand samengesteld uit alle voorbije ‘commits’. Er zijn nog heel wat meer zaken te vertellen over Event Sourcing, maar we bespraken deze manier van werken reeds uitgebreid in een aantal vorige blogs.

Het grote nadeel van Event Sourcing is de sterk verhoogde complexiteit van de software die volgens dit paradigma is gebouwd. Men zal dus goed moeten overwegen of de krachtige mogelijkheden die door het gebruik ervan ontstaan, deze complexiteit waard zijn. Het feit dat Event Sourcing zelden wordt gebruikt en er daardoor slechts weinig architecten voldoende ervaring mee hebben, maakt dit echter erger dan het zou moeten zijn: eens men deze andere manier van werken in de vingers heeft, kan men pas goed de voordelen ervan appreciëren.

De voordelen van Event Sourcing bevatten namelijk de voordelen van Event-carried State Transfer, en breiden deze nog uit: men heeft nu toegang tot de volledige geschiedenis van de applicatie, en niet enkel de huidige toestand. Hierdoor kan men stukken uit het verleden ‘terug gaan afspelen’, wat goed van pas kan komen bij testing en debuggen, of wat veel mogelijkheden geeft bij analytics van deze gegevens. Een event sourced systeem is door deze geschiedenis ook heel geschikt voor audit logs.

Bij gebruik van Event Sourcing kan men de applicatie zelfs ontwerpen zonder echte database: men kan de huidige toestand gewoon in het werkgeheugen plaatsen, zolang de Events zelf goed worden gepersisteerd. Bij falen kan men dan steeds de toestand terug opbouwen op basis van de Event Store (in de praktijk gecombineerd met snapshots van de toestand op geregelde tijdstippen).

Wanneer men al gebruik maakt van Event Sourcing, dan moet men ervoor opletten niet automatisch ook de volgende stap te nemen…

Command Query Responsibility Segregation

De meeste applicaties worden opgebouwd rond een CRUD (create, read, update, delete) systeem. Soms kan het echter interessant zijn om een applicatie op te splitsen in meerdere componenten: degene die schrijven naar de datastore en degene die er in gaan lezen. Je hebt hier dus verschillende modellen waarmee wordt gewerkt: één dat updates behandelt en één (of meerdere) dat queries behandelt. Deze opsplitsing noemen we Command Query Responsibility Segregation (CQRS). Ook CQRS bespraken we reeds in eerdere blogs.

In theorie kan deze manier van werken zonder EDA, maar in de praktijk zullen Events altijd de beste manier vormen voor de communicatie tussen de verschillende subsystemen. Commando’s resulteren dan in Events met bepaalde inputs, die op hun beurt resulteren in Events betreffende toestands-wijzigingen. Query systemen die kort op de bal moeten spelen, schrijven zich in voor deze events en passen bij elk Event onmiddellijk hun uit te lezen toestand aan.

CQRS introduceert enorm veel complexiteit in een systeem. Het is dus zaak van te kijken of het echt serieuze voordelen kan opleveren. Sommige erg complexe business domeinen hebben baat bij deze opsplitsing, omdat het kan resulteren in een kleinere hoeveelheid logica per deelsysteem, indien dat deelsysteem is toegespitst op slechts één verantwoordelijkheid (update of query). In de meerderheid van de gevallen is er echter grote overlap tussen de logica voor updates en deze voor queries, waardoor het delen van een model efficiënter is. De principes van Domain Driven Design kunnen hier helpen.

Een andere reden om CQRS te gebruiken vinden we in performantie en beschikbaarheid: een systeem dat zelden wordt geüpdated en vaak queries krijgt (of omgekeerd) kan baat hebben bij het splitsen van deze verantwoordelijkheden, zodat de componenten apart kunnen worden geschaald (maar ook hier zijn er, naast CQRS, eventueel alternatieve architecturen mogelijk).

Kort samengevat: CQRS kan heel krachtig zijn, maar is ook erg complex. Use with Caution.

Conclusie

Nu we de vier voornaamste manieren hebben onderscheiden om gebruik te maken van Event Driven Architecture, zijn we in staat om preciezer te communiceren over het paradigma, en voor elk project een weloverwogen keuze te maken tussen de verschillende werkwijzen.

Event Notification kunnen we zien als beginnelingen-EDA, en is het makkelijkst toe te voegen aan een bestaand systeem. Het kan reeds meerwaarde brengen en de betrokkenen ‘opwarmen’ voor het echte werk. Event Carried State Transfer is een krachtiger mechanisme, met een complexiteit die nog goed onder controle blijft. Deze twee eerste methoden om Events te gebruiken, spelen vooral in op de interactie tussen verschillende systemen, en hebben iets minder invloed op de interne werking ervan.

De zaken veranderen wanneer we kijken naar Event Sourcing en CQRS. Deze paradigma’s werken echt in op de kern van de architectuur binnen een welbepaald systeem, en voegen een behoorlijke dosis complexiteit toe. In bepaalde gevallen is dit het echter waard, vanwege de krachtige en unieke voordelen die op deze manier worden verkregen.

Disclaimers…

Eerst en vooral een aantal disclaimers: de auteur is geen expert op vlak van het business domein, en er zijn dus geen garanties betreffende de juistheid van wat er verteld wordt rond deze zaken. Integendeel, er zullen sterke vereenvoudigingen worden gemaakt, en zelfs kleine aanpassingen, om beter te kunnen dienen als voorbeeld voor de technologische principes die we hier in de verf willen zetten. Het is dus eerder te beschouwen als “geïnspireerd door” en niet “gebaseerd op” hoe de sociale zekerheidssector werkt, en deze laatste moet bovendien heel breed worden genomen: mogelijks zouden sommige van de voorbeeldapplicaties eerder bij werkgevers of sociale secretariaten uitgerold zijn dan bij een instelling van de sociale zekerheid.

Verder is dit voorbeeld “greenfield IT”, en houdt het geen rekening met reeds bestaande toepassingen, legacy software en de in de voorbije jaren, zelfs decennia, opgebouwde complexiteit van de systemen die dit business domein reeds ondersteunen. Daarenboven maken we hier gebruik van geavanceerde Event Driven Architecture concepten, zoals Event Sourcing en CQRS, ook weer ter illustratie van deze technologieën; in de werkelijkheid zijn deze paradigma’s echter soms van een te grote technische complexiteit om te overwegen, en zullen ze enkel daar worden ingezet waar specifieke, moeilijk te behalen niet-functionele vereisten er om vragen.

Het voorbeeld: De arbeidsmotor voor de Sociale Zekerheid

In het voorbeeld krijgen we een aantal applicaties en diensten rond arbeid en zal er voor de integratie gebruikgemaakt worden van APIs en Event Driven Architecture (EDA). Werkgevers zullen gegevens doorgeven die verband houden met arbeidsrelaties die ze hebben met hun personeel: de aanvang en het stopzetten van contracten, data die verband houdt met geleverde prestaties (“werkuren”), en zaken rond het salaris en het uitbetalen ervan. Applicaties voor werkgevers zullen hen helpen te bepalen hoe hoog het loon is dat ze moeten uitkeren en in welke delen het is opgedeeld, en verder zullen ze zien waar ze staan betreffende de sociale zekerheidsbijdragen die ze verschuldigd zijn. Werknemers krijgen een applicatie om een overzicht te krijgen op hun carrière, en de fiscus (als externe partner in dit ecosysteem) kan informatie krijgen betreffende de inkomsten van de werknemers en de bedrijfsvoorheffing. De KSZ, ten slotte, kan waken over de toegang tot gegevens.

In Fig. 1 zien we een collectie van IT services die dit business domein zouden kunnen ondersteunen (om de complexiteit te beperken zijn noch alle systemen, noch alle communicaties tussen de weergegeven systemen, opgenomen; het doorsturen van gegevens naar de fiscus is hier b.v. niet te zien).

Links op de figuur staan een aantal APIs (altijd ondersteund door hun implementerende services) die vooral zullen worden gebruikt om gegevens binnen te krijgen van de werkgevers: alle data die verband houdt met arbeidsrelaties, geleverde prestaties en uitbetaalde salarissen (de Salary Suggest & Payment API kan ook worden gebruikt om een suggestie te krijgen van het salaris dat moet worden betaald, berekend volgens de regels van de kunst).

Meer naar het midden vinden we de systemen die deze data eerder zullen verwerken: deze staan los van de “input” systemen en krijgen hun data van deze laatste via events. We volgen hier dus op macroniveau het principe CQRS, in die zin dat we het verzamelen van de gegevens (welke tot een “command” tot verwerking ervan zullen leiden) scheiden van de verwerking ervan (die zal leiden tot nieuwe, via “query” raadpleegbare gegevens).

Het betreft ten eerste het consolideren van veranderingen in arbeidsrelaties, om zo altijd een up-to-date beeld te hebben van de huidige bestaande relaties, maar ook op de historiek. Ten tweede is er een berekeningsmodule voor salarissen, die ten gepasten tijde kan geactiveerd worden om de salarisvoorstellen te maken en uit te sturen. Het derde systeem is de WorkTime engine: deze krijgt een event binnen, telkens er gegevens binnenkomen betreffende prestaties, en zal deze consolideren tot een up-to-date view van wat er op dat moment gekend is betreffende deze gegevens (er kunnen bijvoorbeeld ook correcties van vorige data binnenkomen, die dan in rekening worden gebracht). Als voorlaatste zien we dan een systeem dat effectief uitbetaalde salarissen zal opvolgen en verwerken, en ten slotte hebben we nog de contribution engine, die op basis van heel wat gegevens uit de andere systemen en regelgeving, voorzien door een “Contribution & Tax Rules System”, de contributies berekent die de werkgevers zullen moeten volstorten. Ook dit laatste kan een real-time optelsom laten zien van wat tot dan gekend is, maar evengoed kunnen we hier maandelijks of driemaandelijks een event laten genereren om het saldo voor die periode mee te delen.

Rechts op de tekening zijn er dan de integraties met verdere backend systemen te zien: Work Task Control vangt events op om de werkprocessen van de medewerkers uit de Sociale Zekerheid te informeren, Human Notifications kan naar events luisteren die via een ander communicatiekanaal aan mensen moeten worden meegedeeld, Process Orchestrator ontvangt en verstuurt events om op die manier iets complexere processen vooruit te helpen (b.v. trimestriële of maandelijkse afrekeningen), Realtime Analytics kan live de eventstroom in de gaten houden en op basis van wat er binnenkomt intelligente beslissingen nemen en verdere signalen (events) uitsturen, en Audit Logging, ten slotte, zal elk event ontvangen dat relevant is betreffende het loggen van de toegang tot, of wijziging aan gegevens (zelfs elk opvragen van data via één van de APIs kan een event veroorzaken dat dan kan worden gelogd als “entiteit X (iets of iemand) kreeg toegang tot een bepaald gegeven”). Dit laatste systeem kan in principe bij de KSZ staan, die onder andere dit soort opdracht hebben.

Een Business event-verhaal doorheen dit ecosysteem

Laten we op zoek gaan naar een aantal Events die van belang zijn in dit business domein (de techniek “event storming” begint hier ook mee; we zullen hier echter al direct een wat technischer bril op zetten, en tegelijk het gegevensverkeer binnen het ecosysteem meevolgen). We doen dit via het voorbeeld van werknemer Willy C, die wordt aangenomen door het bedrijf Acme NV.

• Eerst wordt Willy aangeworven als arbeider; hij krijgt een contract. Een aantal gegevens hiervan worden doorgegeven aan de Contracts API, en dit leidt tot een WorkRelationStartedEvent.
• Dit event wordt opgevangen door de Relationship Engine, die de gegevens via API ter beschikking zal stellen, en door de Process Orchestrator, die een schedule zal starten om acties te ondernemen wanneer het tijd wordt om b.v. Willy zijn salaris te betalen.
• Na een tijdje zal Willy beginnen werken en uren kloppen. WorkTimePerformed Events worden gegenereerd na gebruik van de WorkTime API. We laten in het midden hoe granulair deze events zijn. Technisch kan alles, wettelijk moet dit pas na een bepaalde termijn gebeurd zijn. Het kan echter ook nuttig zijn voor de werkgever om dit eerder door te sturen: degenen die b.v. elke dag, of na elke shift, de gewerkte uren doorgeven, hebben een betere “live view” bij het consulteren van hun gegevens via een dashboard, dan werkgevers die de gegevens pas doorgeven op het einde van de maand.
• De WorkTimePerformed Events worden hoofdzakelijk verwerkt, en goed bewaard (d.m.v. Event Sourcing) door de WorkTime Engine. Deze zal alle gegevens netjes samenvoegen zodat men steeds een correct beeld heeft op hoeveel totale prestaties er reeds zijn geleverd door welke werknemer, voor welk bedrijf, gedurende eender welke periode. Dit wordt dan opnieuw via een API aangeboden, en aldus is dit dus een voorbeeld van CQRS: de gegevens komen binnen via de WorkTime API (en bijhorende service) en kunnen worden geraadpleegd via de Consolidated View API van de WorkTime Engine. Voor het gemak zullen de APIs echter via eenzelfde webadres worden geraadpleegd (de APIs kunnen apart worden ontwikkeld en onderhouden, om daarna samen te worden aangeboden door een API management oplossing).
• Ook correcties in arbeidstijd (b.v. door laattijdig aanvragen van verlof) komen het ecosysteem binnen via WorkTimePerformed Events, waarin de correctie staat. De WorkTime Engine zal alle events netjes opslaan en met correcties rekening houden in het afgeleide datamodel.
• In Willy’s contract staat dat Acme om de 2 weken zijn loon zal uitkeren, rekening houdend met de effectief gewerkte uren. De Payment Suggest Engine zal voorafgaand aan de uitbetaling ervan de huidige stand van zaken opvragen bij de WorkTime Engine (dit op commando van de Process Orchestrator). Op basis hiervan, en via de salarisgegevens verkregen van de Current Contracts API, kan de Payment Suggest Engine dan een brutoloon berekenen. In dit voorbeeld lijkt het heel eenvoudig, maar deze dienst zou kunnen worden uitgebreid met alle mogelijke vormen van loon (b.v. cafetariaplan, mobiliteitsvergoeding, maaltijdcheques, etc.). Wanneer de berekening klaar is wordt een BruteSalaryProposal Event verstuurd.
• Dit laatste event wordt opgevangen door een dashboard voor de werkgever of zijn sociaal secretariaat. Er zal data in staan waarmee de werkgever zijn volledige “payslip” kan invullen: in dit vereenvoudigde voorbeeld kennen we dan het brutoloon, de werknemersbijdrage, het belastbaar loon, de bedrijfsvoorheffing en het nettoloon. Het loon kan dan door de werkgever worden uitbetaald: hoe dit precies gebeurt, laten we buiten beschouwing.
• Uiteindelijk zal dus op de een of andere manier een betaling van het salaris gebeuren (al dan niet overeenkomend met de suggestie). Ook dit komt als data ons systeem binnen via een API die de werkgever of het sociaal secretariaat moet aanroepen: De Payment API (die in de tekening deel uitmaakt van de Salary Suggest & Payment API) en gaat dan als een SalaryPayed Event naar de Salary Engine om de gegevens te verwerken. Een niet afgebeelde Banking Monitoring Service zal daarnaast monitoren wanneer er betalingen binnenkomen van de RSZ bijdragen, welke zullen resulteren in EmployeeContributionPayed Events, die ook naar diezelfde Engine kunnen worden gestuurd. Via de Consolidate Salary Info API kan men al deze gegevens historisch raadplegen.
• Dashboard services voor de werkgever, zowel als voor de werknemer, kunnen eveneens van deze gegevens gebruik maken om ze te laten zien aan de eindgebruiker.
• Na een kwartaal zal Acme zijn werkgeversbijdragen moeten betalen. Hiertoe zal de Contribution Engine in actie komen, in opdracht van de Process Orchestrator. Deze engine zal, door allerlei gegevens te raadplegen van een aantal APIs binnen het ecosysteem, de bijdrage berekenen en een event uitsturen. Op deze manier kan de informatie dan in het dashboard van de werkgever terechtkomen, maar ze wordt eveneens door Human Notifications opgevangen om een factuur naar de eBox te kunnen sturen. Daarnaast zal ook Work Task Control ingeschreven zijn op dit event, zodat processen en dossiers rond de werkgever Acme kunnen worden geüpdated.

We kunnen uiteraard blijven doorgaan met uit te leggen welke events er zijn en waarvoor deze allemaal nuttig kunnen zijn, maar we gaan ons beperken tot dit nog relatief eenvoudige voorbeeld. Deze manier van werken is eindeloos flexibel: elke service binnen dit ecosysteem kan, indien nodig, reageren op bepaalde gebeurtenissen en de nodige acties ondernemen, en dit kan dan zowel gaan om standaard business processen, als om ondersteunende zaken zoals audit logging en realtime analytics.

We hebben hier een globaal overzicht geschetst van een ecosysteem van applicaties. Dit zegt natuurlijk nog niet in detail hoe elk van deze systemen intern zullen werken (en verder opgedeeld zijn in modules). Event Sourcing kan een logische keuze zijn om de CQRS die we hier voorzien te ondersteunen, maar dit is niet noodzakelijk de beste keuze. Event Sourcing kan daarnaast b.v. ook van pas komen indien we “herspeelbaarheid” van wat er zich in een applicatie heeft afgespeeld willen bekomen. De meeste applicaties hebben echter voldoende lichte niet-functionele vereisten om een eenvoudiger intern ontwerp toe te laten. Wat we wel zien is dat een basis gebruik van EDA, ook zonder deze geavanceerde concepten, maar wel verdergaand dan enkel lege notificaties, het systeem erg gemakkelijk her- en uitbreidbaar maakt (met nieuwe events en nieuwe consumerende services die elkaar “kruisbestuiven” zonder van elkaar afhankelijk te worden).

Besluit

Event Driven Architecture en het gebruik van APIs vormen samen het bindweefsel van communicatie tussen diensten in een applicatie ecosysteem. Het fictieve voorbeeld in deze blog laat zien hoe ze elk in hun kracht staan: APIs voor de onmiddellijke ontsluiting en het beschikbaar stellen van bestaande gegevens (vaak zelfs als “authentieke” bron) en EDA voor het realtime en transparant consumeren van alle mogelijke informatie van zodra deze beschikbaar wordt, op een manier die de agiliteit en beschikbaarheid van het volledige ecosysteem sterk verhoogt.

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.

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.

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.