Ontwerppatronen Notificeren
Deze pagina is onderdeel van de Architectuur Notificeren in het Federatief Datastelsel. Op deze pagina zijn een aantal patronen voor het delen van gegevens over gebeurtenissen beschreven. Ze laten zien hoe verantwoordelijkheden van softwarecomponenten kunnen worden verdeeld tussen producers, intermediary's en consumers.
- Consumer vraagt: De consumer stelt periodiek vragen aan de producer om geïnformeerd te worden over opgetreden gebeurtenissen.
- Producer notificeert: De producer verzorgt het notificeren zelf en eventueel ook aanvullende functies zoals garanderen aflevering en filtering.
- Eenvoudige intermediary: De producer wordt ontzorgd door een tussenliggend softwarecomponent (ook wel: intermediary of eventbroker) dat mechanismen biedt voor abonneren, notificeren en eenvoudige vormen van filtering.
- Complexe intermediary: De producer wordt volledig ontzorgt door een tussenliggend softwarecomponent, dat naast abonneren en notificeren ook andere functies biedt zoals het garanderen van aflevering en complexe filtering.
Merk op dat het eerste patroon niet over notificeren gaat, maar toch opgenomen is om te laten zien wat de afwegingen zijn om hier wel of niet voor te kiezen. Merk verder op dat de patronen "eenvoudige intermediary" en "complexe intermediary" vooral als extremen in een spectrum moeten worden gezien, met toenemende complexiteit in het tussenliggende softwarecomponent.
De volgende figuur laat zien hoe de belangrijkste functies in de patronen anders zijn toegekend aan de verschillende rollen.

In het Federatief Datastelsel ligt het gebruik van een tussenliggend softwarecomponent (intermediary, eventbroker) voor de hand, omdat er in potentie een groot aantal onbekende consumers zijn met een grote verscheidenheid aan behoeften. Van het tussenliggende softwarecomponent wordt vaak wel een vorm van gegarandeerde aflevering verwacht.
Consumer vraagtbewerken
Context
Er is een behoeft aan het delen van gegevens over opgetreden gebeurtenissen, en deze moeten zo eenvoudig mogelijk gedeeld worden. Er zijn potentieel veel consumers. De frequentie van het optreden van gebeurtenissen en het bevragen van producers ligt in dezelfde orde grootte.
Oplossing
De consumer stelt periodiek vragen aan de producer om geïnformeerd te worden over opgetreden gebeurtenissen (polling). Er is geen notificatiemechanisme om consumers te informeren over het optreden van deze gebeurtenissen.
Voordelen
- Relatief eenvoudig te realiseren.
- Er is geen abonnement- of notificatiemechanisme nodig en ook geen centrale infrastructuur.
- Producers zijn ontkoppeld van consumers, waardoor eenvoudig nieuwe consumers toegevoegd kunnen worden.
- Consumers bepalen zelf wanneer ze klaar zijn voor het verwerken van gebeurtenissen; er zijn geen mechanismen tegen overbelasting van consumers nodig.
- Het is relatief eenvoudig om autorisaties in te richten.
- De producer kan met PKI gevoelige gegevens versleutelen per consumer.
Nadelen
- IT-infrastructuur wordt potentieel belast met overbodige bevragingen.
- De quality of service kan niet goed gegarandeerd worden; de producer kan overbelast raken door vragen van consumers.
- Past minder goed bij hoge real-time eisen; er zit tijd tussen het optreden van de gebeurtenis en de bevraging.
- Er is standaard geen controle over of consumers al geïnformeerd zijn over recente gebeurtenissen.
- Als er meerdere producers van notificaties over hetzelfde gebeurtenistype zijn, dan moeten consumers al die producers bevragen.
- Het is niet goed schaalbaar naar veel producers en consumers.
Typische toepassingsgebieden
- Afnemers die niet in staan zijn om notificaties te ontvangen
- Hoge mate van vertrouwen tussen partijen gewenst
Producer notificeertbewerken
Context
Er is een behoeft aan het delen van gegevens over opgetreden gebeurtenissen, en deze moeten zo op eenvoudige wijze worden gedeeld. Er zijn een beperkt aantal producers en consumers, die elkaar ook kennen.
Oplossing
Producers bieden zelf een notificatiemechanisme (en mogelijk niet meer dan dat).
Voordelen
- Relatief eenvoudig te realiseren, maar complexer dan alleen bevraging door consumer.
- Er is geen abonnementmechanisme of centrale infrastructuur nodig.
- Directe notificatie, dus hoge actualiteit en weinig vertraging.
- Volledige controle bij de producer over wie wat ontvangt.
- Het is relatief eenvoudig om autorisaties in te richten.
- De producer kan met PKI gevoelige gegevens versleutelen per consumer.
Nadelen
- Iedere producer moet zelf mechanismen bieden voor notificeren (en mogelijk ook voor andere functies).
- Als er meerdere producers van notificaties over hetzelfde gebeurtenistype zijn, dan moeten consumers bij al die producers geregistreerd zijn.
- Er zijn mogelijk throttling mechanismen nodig ter voorkoming van overbelasting van consumers.
- Het toevoegen van consumers vraagt aanpassing bij de producer.
- Het is niet goed schaalbaar naar veel producers en consumers.
Typische toepassingsgebieden
- Gebeurtenissen die slechts incidenteel optreden
- Bilaterale afspraken
- Hoge mate van vertrouwen tussen partijen gewenst
Eenvoudige intermediarybewerken
Context
Er is een behoeft aan het delen van gegevens over opgetreden gebeurtenissen. Er zijn een groot aantal producers en consumers van notificaties. Er zijn mogelijk meerdere producers van gegevens over hetzelfde gebeurtenistype. Consumers hebben een relatief gelijksoortige informatiebehoefte. Ontkoppeling tussen producers en consumers is belangrijk. De afleverzekerheid van notificaties is niet belangrijk.
Oplossing
Er is een tussenliggend softwarecomponent (ook wel: intermediary of eventbroker) met functionaliteit die is beperkt tot het aanbieden van abonnementen, het routeren van notificaties naar abonnees en eenvoudige vormen van filtering.
Voordelen
- Producers en consumers hoeven elkaar niet te kennen.
- Producers worden ontzorgd op het gebied van abonneren en notificeren.
- Relatief eenvoudig te realiseren t.o.v. complexe intermediary.
- Het tussenliggende softwarecomponent is relatief eenvoudig en daardoor relatief goedkoop en eenvoudig in te richten, te beheren en op te schalen.
- Directe notificatie, dus hoge actualiteit.
Nadelen
- Het laat veel verantwoordelijkheid bij de consumer voor het filteren van notificaties.
- Past slecht op situaties waarbij consumers een grote diversiteit aan informatiebehoeften hebben omdat er geen uitgebreide filtermechanismen zijn.
- Het tussenliggende softwarecomponent introduceert extra risico's m.b.t. beschikbaarheid.
- Het is lastiger om autorisaties goed in te richten, omdat bij het tussenliggende component geen domeinkennis zit.
- De producer kan gevoelige gegevens niet met PKI versleutelen, omdat deze de consumers niet kent.
Typische toepassingsgebieden
- Groot aantal, relatief gelijksoortige partijen
- Domeinen met gedeelde verantwoordelijkheden en lichte vormen van standaardisatie
Complexe intermediarybewerken
Context
Er is een behoeft aan het delen van gegevens over opgetreden gebeurtenissen. Er zijn meerdere producers en consumers van notificaties, met hele verschillende informatiebehoefen. Ontkoppeling tussen producers en consumers is belangrijk. Er worden hoge eisen gesteld aan beveiliging, privacy, betrouwbaarheid en onweerlegbaarheid.
Oplossing
Er is een tussenliggend softwarecomponent (ook wel: intermediary of eventbroker) met rijke functionaliteit voor autorisatie, filtering, logging, gegarandeerde aflevering, sequencing en throttling.
Voordelen
- Consumers worden maximaal ontzorgd.
- Consumers ontvangen alleen notificaties waar ze echt in geïnteresseerd zijn.
- De netwerkbelasting wordt beperkt doordat er geen onterechte notificaties naar consumers worden verstuurd.
- Er is vertrouwen dat gegevens rechtmatig worden ontvangen en verwerkt.
- Directe notificatie, dus hoge actualiteit.
Nadelen
- Er is een complexere infrastructuur nodig en daarmee leidt het tot hogere kosten.
- Het tussenliggende softwarecomponent moet domeinspecifieke kennis en logica bevatten.
- Het tussenliggende softwarecomponent introduceert extra risico's m.b.t. beschikbaarheid.
- Het is lastiger om autorisaties goed in te richten, omdat bij het tussenliggende component geen domeinkennis zit.
- De producer kan gevoelige gegevens niet met PKI versleutelen, omdat deze de consumers niet kent.
Typische toepassingsgebieden
- Complexe ecosystemen
- Uitwisseling van persoonsgegevens
- Sterke centrale governance
13 maart 2026 15:15:11
27 november 2025 07:27:59
13 maart 2026 15:15:11
100
Informatief