Binnen een IT systeem zijn er gebeurtenissen in overvloed. We schenken er echter meestal slechts als bijzaak enige aandacht aan. Deze blog is een (eerste) oproep om, bij het ontwerpen van software, het Event een centrale plaats te geven, met alle voordelen van dien.

Events

Heel veel zaken binnen een softwaresysteem kunnen worden gemodelleerd als een gebeurtenis, of Event: het aanklikken van een knop, het indrukken van een toets, het verbinden met een server, enz. Een bijzonder interessante vorm van gebeurtenissen zijn daarbij degene die ook op business niveau een betekenis hebben: het inloggen van een gebruiker, het versturen van een aanvraagformulier, het aanmaken van een nieuw record met gegevens, of zelfs het beschikbaar worden van een signaal komende uit een big data analytics platform.

Deze gebeurtenissen zijn er altijd, maar we besteden er niet altijd enorm veel aandacht aan: het verbinden van een server wordt simpelweg het oproepen van een hulpdienst vanuit een ander deel van het programma, de gegevens van een aanvraagformulier worden gewoon gecontroleerd en weggeschreven, het signaal wordt getoond op een dashboard, enz. We doen dus wel iets met de gegevens die samenhangen met het Event, maar we beschouwen het Event zelf niet als volwaardig concept. Eens voorbij, verliezen we dan ook het concept van iets dat zich afspeelt op een bepaald moment in de tijd. De betrokken gegevens worden weggeschreven, vaak als deel van een aggregaat, en de historische context en tijdsgebondenheid gaan verloren.

Wanneer we nu het Event wél gaan beschouwen als een object van eerste klasse (in het Engels ‘first class citizen‘), dan maken we er als het ware een tastbaar, vastgrijpbaar iets van. Het Event wordt als dusdanig “gereïficeerd” (‘écht gemaakt’). Wanneer we dit doen, dan spreken we van Event Driven Engineering. Dit is een brede tak binnen de Software Engineering, die zelf nog uit een aantal verschillende paradigma’s bestaat.

De twee meest eenvoudige van deze paradigma’s, het Publish/Subscribe mechanisme en het bredere concept Event Driven Architecture, zullen we verder uitdiepen in deze blog.

Publish/Subscribe

Het publish/subscribe mechanisme is al erg lang een gekende techniek binnen software-ontwerp, om subsystemen van elkaar los te koppelen.

Het mechanisme speelt zich af tussen drie partijen: de publisher (die een Event kan “publiceren”), de subscriber (die zich voor een event kan “onderschrijven”), en het Event systeem. Deze partijen kunnen verschillende vormen aannemen (van één welbepaald object binnen een applicatie, over subsystemen heen, tot verschillende en volledig op zichzelf staande applicaties of IT-systemen). Van publishers en subscribers kunnen er meerdere zijn. Van het Event systeem is er, althans wat de interacties rond minstens één welbepaalde soort Events betreft, slechts één.

Op een bepaald moment kan een subscriber het Event systeem contacteren om zijn interesse te uiten in een welbepaald Event. Vanaf dan is het zo dat, elke keer dit event voorkomt, de subscriber hiervan op de hoogte zal worden gebracht. Dit laatste gebeurt wanneer een publisher op zijn beurt het Event systeem inlicht over een door hem gegenereerd event. Dit laatste wordt ook wel “to fire an Event” genoemd: een Event wordt als het ware afgevuurd. De subscribers hebben dan de verantwoordelijkheid om het Event af te handelen (to “handle an Event”). Naast inschrijven, is het voor subscribers ook mogelijk zich opnieuw uit te schrijven voor een Event, een beetje zoals met een nieuwsbrief.

Het typische publish/subscribe scenario:

1. Een paar subscribers onderschrijven zich
2. Een publisher publiceert een event
3. Het Event komt terecht in het Event Systeem
4. Het Event wordt verspreid via het Event Systeem
5. Het Event bereikt alle subscribers

 

Voor het publish/subscribe mechanisme is het echter nog niet expliciet vereist om de events te reïficeren. Men kan ook gebruik maken van het principe van callbacks: de subscriber geeft aan wat hij wil dat er gebeurt, indien een bepaalde gebeurtenis voorkomt. De publisher kan dan via het event systeem aangeven dat iets gebeurd is, zonder verdere details te geven, en de callback wordt uitgevoerd. Daarnaast is het zelfs mogelijk dat er geen event systeem is, maar dat subscribers zich rechtstreeks tot publishers richten.

Indien we de Events echter expliciet modelleren, biedt dit mechanisme veel meer opties: publishers kunnen het Event dan verrijken met details over het gebeurde, en deze gegevens kunnen door de subscribers worden gebruikt om het Event beter af te handelen. Bovendien hebben we de optie om het Event voor later hergebruik op te slaan. Daarnaast krijgen we door het invoeren van een event systeem een vorm van indirectie, die toelaat dat publishers en subscribers elkaar niet meer te hoeven kennen.

Een typisch voorbeeld zien we bij de ondersteuning van Grafische User Interfaces (GUI). Grafische elementen zullen daar Events afvuren die door de eindgebruiker werden veroorzaakt (‘er werd op een knop geklikt’, ‘een veld werd ingevuld’, …). De achterliggende applicatiecode zal zich op deze Events hebben ingeschreven en er aldus op kunnen reageren om de applicatie (en GUI) aan te passen.

Event Driven Architecture

Binnen een Event Driven Architecture (EDA), hebben we ook publish/subscribe, maar dan op een veel grotere schaal. Meestal gaat het nu om communicatie tussen verschillende applicaties en systemen op een zo robuust mogelijke manier. Het Event systeem zal nu worden geïmplementeerd a.d.h.v. een BUS systeem, en we zullen het de Event Bus noemen.

EDA kan nuttig worden aangewend wanneer men een heel aantal applicaties heeft, die dezelfde of gerelateerde Business Events behandelen. Gebeurtenissen binnen één applicatie zullen daarbij vaak relevant zijn voor andere applicaties. De Event Bus zal binnen zo’n geheel de verantwoordelijkheid op zich nemen om een Event, door één applicatie gecreëerd, tot bij alle geïnteresseerde applicaties te krijgen. De applicaties hoeven van elkaars bestaan niet af te weten: het is voldoende dat ze van het bestaan van bepaalde Events afweten, en dat ze kunnen communiceren met de Event Bus.

Deze vorm van architectuur laat een grote loskoppeling toe van de betrokken systemen en applicaties, en zorgt er ook voor dat er snel gereageerd kan worden op voorkomende business events, zelfs op plaatsen waar, en op manieren waarop dit niet initiëel werd voorzien. Men kan zich namelijk inbeelden dat men, eens een bepaald Event bestaat en men weet dat het over de bus passeert, nieuwe ideeën kan krijgen om deze Events aan te wenden en erop te reageren, zowel in bestaande als nieuwe applicaties.

Communicatie via Events zal natuurlijk niet de enige communicatie zijn die er tussen verschillende systemen moet bestaan: soms heeft één systeem ook historische informatie nodig, die reeds lang via een andere applicatie is verwerkt en opgeslagen. Het eventuele event, indien het al zou bestaan, dat tot die informatie heeft geleid, is op dat moment natuurlijk reeds lang gepasseerd. Normaal gezien gaat dit echter altijd om read-only operaties. Hier moeten we dus, binnen het geheel van applicaties, nog iets voor voorzien (b.v. een collectie RESTful APIs). Communicatie die schrijfoperaties veroorzaakt, moet echter in principe altijd via Events kunnen worden gemodelleerd (wanneer er een gegeven moet worden aangepast, kan men desnoods deze wijziging op zich óók modelleren als een gebeurtenis).

Conclusie en Vervolg

De Event Driven Architecture is veelbelovend: het laat een sterk loskoppelen toe van de betrokken applicaties en systemen, wat het onderhoud van het softwarepark een stuk eenvoudiger maakt. Maar indien we de Events die op de bus binnenkomen permanent gaan bewaren en voor nog allerlei andere zaken gaan (her-)gebruiken, ontketenen we pas echt de kracht van Event Driven Engineering. Daarover meer in een volgende blog!