Rollen en begrippen
Het GEMMA Begrippenkader beschrijft de betekenis van belangrijke begrippen binnen de GEMMA. Deze thema-architectuur kent een aantal eigen, specifieke begrippen met betrekking tot eventoriëntatie. Daarbij is met name gebruik gemaakt van begripsdefinities uit:
- de GDI-domeinarchitectuur Gegevensuitwisseling die de algemene architectuur voor het uitwisselen van gegevens voor overheidsorganisaties beschrijft.
- de CloudEvents standaard, en het daarvan afgeleide NL GOV Profile for CloudEvents, die beschrijven hoe informatie over plaatsgevonden gebeurtenissen gestandaardiseerd is vast te leggen.
Rollen in de GDI-domeinarchitectuur Gegevensuitwisseling[bewerken]
De GDI-domeinarchitectuur Gegevensuitwisseling maakt onderscheid in 3 basisrollen die partijen kunnen spelen bij het uitwisselen van gegevens:
- Bronhouder: Verantwoordelijk voor het inwinnen, beheren en het verbeteren van de kwaliteit van gegevens.
- Afnemer: Verantwoordelijk voor het afnemen van gegevens en ervoor zorgen dat aangeboden gegevens beschikbaar zijn voor gebruik.
- Aanbieder: Verantwoordelijk voor het aanbieden van gegevens van bronhouders op een manier die aansluit bij de behoeften en het gebruik van afnemers.
- Intermediair (optioneel): Een tussenliggende partij die toegevoegde waarde levert in de uitwisseling. Een intermediair kan bijvoorbeeld gegevens aanbieden, samenbrengen, combineren, vertalen, afleiden en/of faciliteren van abonneren en notificeren over gebeurtenissen.
In verband met leesbaarheid wordt vaak gesproken over een partij die 'bronhouder', 'afnemer', 'aanbieder' of 'intermediair' is. Daarmee wordt dan feitelijk bedoeld dat het om een partij gaat die een dergelijke rol vervult. Onderstaande Archimate-afbeelding toont om om deze reden geen aparte rol-elementen, maar alleen actor-elementen.
Naast deze 4 rollen zijn ook nog aanvullende rollen mogelijk. Bijvoorbeeld een 'toetsingscommissie' die een onafhankelijk oordeel kan vellen over de wenselijkheid van het uitwisselen van gegevens vanuit het perspectief van privacy en ethiek. Een partij kan 1 of meer rollen invullen.
Rollen in de GEMMA thema-architectuur Eventoriëntatie[bewerken]
De GDI-domeinarchitectuur beschrijft organisatorische rollen die nodig zijn voor gegevensuitwisseling in het algemeen. Deze thema-architectuur beschrijft rollen die applicaties vervullen bij het uitwisselen van gegevens over plaatsgevonden gebeurtenissen. In lijn met wat internationaal gebruikelijk is, maken we daarvoor onderscheid in 3 basisrollen:
- Producer: Een applicatie die events publiceert.
- Consumer: Een applicatie die events ontvangt.
- Intermediairy: Een tussenliggende applicatie die door producers gepubliceerde events verwerkt. Taken zijn contextafhankelijk en kunnen bijvoorbeeld zijn: het bijhouden van abonnementen, het filteren, routeren en verstrekken van events, het afleiden of combineren van events.
Anders dan bij de GDI-rollen geldt voor deze 3 rollen dat ze puur instrumenteel van aard zijn. De rol van producer kan bijvoorbeeld worden vervuld door software op een sensor, een gemeentelijke taakspecifieke applicatie of een landelijke applicatie waarmee basisgegevens worden bijgehouden. De enige eis is dat zij events produceren. Dit in tegenstelling bijvoorbeeld de GDI-rol 'bronhouder' waarvoor geldt dat bij niet alleen gegevens beschikbaar stelt, maar (ook) verantwoordelijk is voor het inwinnen, beheren en verbeteren van de kwaliteit van gegevens.
Het publish-subscribe patroon is een bekend eventgeoriënteerd patroon. Daarbij wordt via een abonnement vastgelegd welke soorten events een consumer wil ontvangen. In plaats van de term 'producer' wordt dan de term 'publisher' gebruikt en in plaats van 'consumer' wordt de term 'subscriber' gebruikt.
Begrippen[bewerken]
Naast begrippen om rollen te beschrijven, zijn er nog meer begrippen nodig om eventoriëntatie helder en eenduidig te beschrijven. We maken daarvoor gebruik van de begrippen uit de CloudEvents-standaard. Een reden daarvoor is dat het een internationale standaard betreft, die al breed wordt ondersteund en toegepast. Het feit dat de standaard, in de vorm van het NL GOV for CloudEvents profiel, overheidsbreed wordt geadopteerd is een extra reden om aan te sluiten bij de terminologie binnen deze standaard.
Voor sommige begrippen gebruiken we de oorspronkelijke Engelstalige term omdat vertalen naar het Nederlands verwarrend werkt en tot misverstanden leidt. Vertalen van een term als 'source' naar 'bron' is bijvoorbeeld verwarrend omdat de term 'bron' al vaak in een andere betekenis wordt gebruikt binnen bestaande, meer gegevens-georiënteerde, architecturen.
Term | Betekenis |
Begrippen voor gebeurtenissen | |
Occurrence | An “occurrence” is the capture of a statement of fact during the operation of a software system. This might occur because of a signal raised by the system or a signal being observed by the system, because of a state change, because of a timer elapsing, or any other noteworthy activity. For example, a device might go into an alert state because the battery is low, or a virtual machine is about to perform a scheduled reboot. |
Event | An “event” is a data record expressing an occurrence and its context. Events are routed from an event producer (the source) to interested event consumers. The routing can be performed based on information contained in the event, but an event will not identify a specific routing destination. Events will contain two types of information: the Event Data representing the Occurrence and Context metadata providing contextual information about the Occurrence. A single occurrence MAY result in more than one event. |
Begrippen voor rollen | |
Producer | The “producer” is a specific instance, process or device that creates the data structure describing the CloudEvent. |
Intermediary | An “intermediary” receives a message containing an event for the purpose of forwarding it to the next receiver, which might be another intermediary or a Consumer. A typical task for an intermediary is to route the event to receivers based on the information in the Context. |
Consumer | A “consumer” receives the event and acts upon it. It uses the context and data to execute some logic, which might lead to the occurrence of new events. |
Begrippen voor het beschrijven van gebeurtenissen binnen events | |
Context | Context metadata will be encapsulated in the Context Attributes. Tools and application code can use this information to identify the relationship of Events to aspects of the system or to other Events. |
Data | Domain-specific information about the occurrence (i.e. the payload). This might include information about the occurrence, details about the data that was changed, or more. See the Event Data section for more information. |
Source | The “source” is the context in which the occurrence happened. In a distributed system it might consist of multiple Producers. If a source is not aware of CloudEvents, an external producer creates the CloudEvent on behalf of the source. |
Event Format | An Event Format specifies how to serialize a CloudEvent as a sequence of bytes. Stand-alone event formats, such as the JSON format, specify serialization independent of any protocol or storage medium. Protocol Bindings MAY define formats that are dependent on the protocol. |
Message | Events are transported from a source to a destination via messages. A “structured-mode message” is one where the event is fully encoded using a stand-alone event format and stored in the message body. A “binary-mode message” is one where the event data is stored in the message body, and event attributes are stored as part of message meta-data. |
Protocol | Messages can be delivered through various industry standard protocol (e.g. HTTP, AMQP, MQTT, SMTP), open-source protocols (e.g. Kafka, NATS), or platform/vendor specific protocols (AWS Kinesis, Azure Event Grid). |
Protocol Binding | Protocol bindings MAY choose to use an Event Format to map an event directly to the transport envelope body, or MAY provide additional formatting and structure to the envelope. For example, a wrapper around a structured-mode message might be used, or several messages could be batched together into a transport envelope body. |