Publish-subscribe patroon

Category:Eventorientatie
__NOTOC__
Het publish-subscribe patroon (pub/sub) is een veelgebruikt patroon binnen event-driven architecturen. Het patroon scheidt zenders (publishers) van events van ontvangers (subscribers) van events. Toepassing van dit patroon maakt het mogelijk om flexibele en schaalbare systemen te maken waarmee informatie over plaatsgevonden gebeurtenissen is uit te wisselen. 
Het patroon is een bekend voorbeeld van toepassing van eventoriëntatie. Vooral toegepast in situaties waarin meerdere applicatie graag op de hoogte willen worden gebracht ('genotificeerd') als er bepaalde gebeurtenissen hebben plaatsgevonden (zie Notificeren introductie).
==Terminologie==
Binnen deze thema-architectuur gebruiken we de temen 'producer' en 'consumer' voor het aanduiden van de rol die applicaties spelen bij het uitwisselen van events. Vanwege de belangrijke rol die 'abonneren' speelt binnen het patroon spreekt het publish-subscribe patroon over de rollen:
* Publisher: de rol verantwoordelijk voor het publiceren ('publish') van events, en
* Subscriber: de rol verantwoordelijk voor het abonneren ('subscribe') op het ontvangen van bepaalde soorten events.
'Publisher' is te zien als 'producer' (waarbij vaak aanvullende eisen gelden voor publishers). 'Subscriber' is een 'consumer' die via een abonnement aangeeft welke events hij wil ontvangen. 
Net als bij andere vormen van event-uitwisseling wordt vaak gebruik gemaakt van een 'intermediairy': een tussenliggende applicatie die door producers gepubliceerde events verwerkt. In de praktijk wordt bij toepassing van het publish-subscribe protocol ook vaak een meer specifieke aanduiding gebruikt, zoals 'message broker' of 'event broker'. 
==Werking ==
Subscribers geven via een abonnement ('subscription') aan over welke soorten plaatsgevonden gebeurtenissen zij events willen ontvangen. Publishers publiceren events naar een intermediair, die zorgt voor verstrekking van de juiste events aan geabonneerde consumers. Subscribers ontvangen zo de events waarin zij zijn geïnteresseerd. 
 
Toelichting: 
*Abonnementsgegevens worden veelal handmatig ingebracht. Het kan ook (deels) geautomatiseerd plaatsvinden. Daarvoor is nog geen standaard. Er wordt hiervoor gewerkt aan een een internationale standaard.
*De rollen van publisher, intermediair en subscriber kunnen worden ingevuld door 1 of meerdere applicaties (en eigendom zijn van 1 of meer organisaties).
*Door gebruik te maken van een aparte applicatie in de rol van intermediair kunnen publishers en subscribers los van elkaar functioneren. Publishers hoeven dan bijvoorbeeld niet te weten welke soorten gepubliceerde events aan welke 'subscribers' events moeten worden verstrekt.
*De rol van intermediair wordt vaak vervuld door gespecialiseerde applicaties ('middleware') waarmee events veilig en betrouwbaar zijn uit te wisselen.
* Bij het uitwisselen van events wordt meestal asynchroon gecommuniceerd, zodat applicaties zo onafhankelijk mogelijk van elkaar kunnen werken.
*Bij het uitwisselen van events kan een keten aan betrokken applicaties ontstaan. Bijvoorbeeld als meerdere intermediairs met elkaar communiceren of als een applicatie in de rol van subscriber een ontvangen event in de rol van publisher of intermediair naar andere applicaties doorstuurt. Met name in cloudomgevingen wordt veel gebruik gemaakt van events die door verschillende soorten applicaties worden verwerkt.
==Voorbeelden==
Het publish-subscribe patroon is toe te passen in uiteenlopende situaties, zoals: 
*Een nieuwssite publiceert een event met gegevens over een plaatsgevonden sportwedstrijd. De intermediair stuurt het event vervolgens als pushbericht naar de smartphones van gebruikers die zijn geabonneerd op events in de categorie 'sport'.
*Een overheidsportaal publiceert een event met gegevens over een aangevraagde vergunning. De intermediair verstrekt het event vervolgens aan een betaalsysteem, een vergunningenapplicatie en een klantnotificatiesysteem.
*Het Kadaster publiceert een event met informatie over een plaatsgevonden perceelsplitsing, zoals vastgelegd in de Basisregistratie Kadaster (BRK). De applicatie Digilevering verstrekt in de rol van intermediair het event aan alle op dit soort events geabonneerde applicaties.
==Mogelijke voordelen==
Gebruik van het patroon kan veel voordelen opleveren: 
*Losse koppeling: Publishers en subscribers kunnen onafhankelijk van elkaar functioneren.
*Schaalbaarheid: Het aantal subscribers kan eenvoudig toenemen, zonder dat dit gevolgen heeft voor de publisher.
*Asynchrone verwerking: Events hoeven niet allemaal direct verwerkt te worden, waardoor systemen niet overbelast raken. 
*Realtime updates: Gebruikers of systemen kunnen snel op de hoogte worden gebracht van plaatsgevonden gebeurtenissen.
*Modulariteit: Door de scheiding tussen eventproductie en eventconsumptie kunnen nieuwe functionaliteiten worden toegevoegd, zonder dat de bestaande infrastructuur moet worden aangepast.
Het publish-subscribe patroon is heel geschikt voor gebruik binnen gedistribueerde omgevingen waarin registraties en applicaties over meerdere organisaties verspreid zijn. Omdat gemeenten met veel partijen samenwerken, daarmee intensief gegevens uitwisselen en belang hebben bij snelle informering over bepaalde gebeurtenissen, is het voor hen een patroon dat vaak bruikbaar is. 
==Mogelijke nadelen ==
Net als bij andere patronen geldt ook voor het publish-subscribe patroon dat gebruik ervan ook een aantal nadelen kan kennen:
*Verlies van berichten: events kunnen verloren gaan. Bijvoorbeeld als een verstrekking van een event aan een subscriber niet is gelukt.
*Onjuiste volgorde: afhankelijk van de implementatie kunnen berichten in een andere volgorde bij subscribers aankomen dan ze zijn verstuurd. Dit kan bij sommige toepassingen tot problemen leiden.
*Vertraging: events kunnen vertraagd worden verwerkt. Bijvoorbeeld als het gaat om grote volumes aan events of als een betrokken applicatie tijdelijk offline is.
*Complexiteit: het is moeilijker om fouten te traceren dan bij directe communicatie tussen publishers en subscribers. Debugging en monitoring is uitdagender.
*Abonnementsbeheer: het kan ingewikkeld zijn om in abonnementen vast te leggen aan welke subscribers welke events moeten worden verstrekt.
De genoemde nadelen zijn via de juiste maatregelen op te heffen. De inzet van gespecialiseerde applicaties voor de rol van intermediair is een voorbeeld daarvan. Via bijvoorbeeld queuing en (tijdelijke of permanente) opslag van events kunnen optredende fouten of verstoringen dan goed worden afgehandeld. Naast lokale voorzieningen om nadelen op te heffend wordt in toenemende mate gebruik gemaakt van door cloudproviders aangeboden voorzieningen. Uitdagingen en maatregelen gaat hier meer in detail op in.
==Opmerkingen==
In de praktijk wordt niet altijd hetzelfde bedoeld met 'het publish-subscribe patroon':
*Soms wordt asynchrone verwerking gezien als een voorwaarde om te kunnen spreken over gebruik van het publish-subscribe patroon. Synchrone communicatie kan echter ook een rol spelen. Bijvoorbeeld als een publisher snelle terugkoppeling nodig heeft en daarvoor wacht op feedback van de intermediair of als een intermediair na verstrekking van een event bereid is te wachten op feedback van een consumer.
*Bij gebruik van het patroon is gebruik te maken van zowel push- als pull-mechanismen en een combinatie van beide:
**Push: het meest toegepaste mechanisme, waarbij nieuwe events actief richting subscribers worden gestuurd. Bijvoorbeeld via het webhook-patroon, waar afnemers bij abonneren opgeven welke service kan worden aangeroepen om events af te leveren (zie ook de handreiking voor gestandaardiseerd gebruik van webhooks).
**Pull: bijvoorbeeld toegepast als subscribers geen push-mechanisme kunnen ondersteunen of als het voor consumers niet nodig is om events snel te ontvangen. Een publisher kan dan bijvoorbeeld events vastleggen die subscribers later, op een zelf te kiezen moment, via een service ophalen.
**Push en pull: een voorbeeld hiervan is de situatie dat een subscriber het initiatief neemt om een verbinding op te zetten met een publisher ('pull'), waarna de publisher de verbinding gebruikt om beschikbaar komende events direct te verstrekken ('push'). Protocollen die dit mechanisme ondersteunen zijn bijvoorbeeld het Advanced Message Queuing Protocol (AMQP) en Server-sent events.
*Uitwisseling van events via een publish-subscribe patroon kan plaatsvinden met gebruik van verschillende gegevensformaten, transportprotocollen en technologiecomponenten. Qua protocol kan bijvoorbeeld gebruik worden gemaakt van een breed toepasbaar protocol zoals HTTP of van specifiek voor event-verwerking ontwikkelde protocollen zoals AMQP of MQTT. Door gebruik te maken van een standaard zoals CloudEvents,, en het daarvan afgeleide NL GOV for Cloudevents profiel, wordt het mogelijk om met events te werken binnen een divers technologisch landschap.
Category:Eventorientatie
__NOTOC__