Basispatronen Notificeren

Deze pagina is onderdeel van de Architectuur Notificeren in het Federatief Datastelsel. Op deze pagina zijn drie basispatronen voor het delen van gegevens over gebeurtenissen beschreven.

Consumer vraagt: De consumer stelt periodiek vragen aan de producer om geïnformeerd te worden over opgetreden gebeurtenissen.

Producer notificeert: De producer notificeert consumers bij het optreden van gebeurtenissen.

Tussenliggend component: De producer wordt ontzorgd door een tussenliggend softwarecomponent (ook wel: intermediary of eventbroker).

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.

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. Dit staat overigens los van de keuze of hier een landelijke voorziening voor beschikbaar zou moeten zijn.

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.
Het past niet goed op situaties waarbij meerdere producers notificaties over eenzelfde gebeurtenistype produceren.

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 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

Tussenliggend componentbewerken

Context

Er is een behoeft aan het delen van gegevens over opgetreden gebeurtenissen. Er zijn meerdere producers en consumers van notificaties, met potentieel verschillende informatiebehoefen. Ontkoppeling tussen producers en consumers is belangrijk.

Oplossing

Er is een tussenliggend softwarecomponent (ook wel: intermediary of eventbroker) dat mechanismen biedt voor abonneren en publiceren en producers en consumers van elkaar ontkoppelt.

Voordelen

Producers en consumers hoeven elkaar niet te kennen.
Producers en 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 tussenliggend component 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 met veel partijen
Uitwisseling van persoonsgegevens
Sterke centrale governance