<p>In dit deel van de architectuur wordt ingegaan op de verschillende vormen van gegevensuitwisseling. Er wordt specifiek ingegaan op de Digikoppeling standaard en de gewenste doorontwikkeling ervan. Daarna worden andere communicatieprotocollen en standaarden benoemd en wordt ook de nieuwe FSC standaard toegelicht.</p> <h3>Vormen van gegevensuitwisseling</h3> <p> Het is belangrijk om te onderkennen dat er heel veel verschillende vormen van gegevensuitwisseling bestaan, op allerlei abstractieniveaus, met allemaal hun eigen specifieke focus. Veel van deze vormen hebben een eigen bestaansrecht. Het is dan vooral ook de vraag wanneer je ze zou moeten toepassen. Het onderscheidende bij al deze vormen van uitwisseling is vooral dat wat centraal staat (de focus heeft). Dat kan zijn 1. de service, 2. de resource, 3. het event, 4. de gegevens, 5. het bericht of 6. de betekenis. </p><p> <b>Service-oriëntatie</b>: Bij service-oriëntatie (ook wel: Service Oriented Architecture - SOA) bieden applicaties hun functionaliteit aan in de vorm van services. Een applicatieservice is een logisch afgebakend stuk functionaliteit waarmee een bedrijfsfunctie ondersteund wordt. Het is te zien als een doorontwikkeling van wat eerder Remote Procedure Calls werden genoemd, in combinatie met ideeën uit componentgebaseerde software-ontwikkeling. Service-oriëntatie is min of meer synoniem geworden aan het gebruik van Web Services op basis van de SOAP standaard, alhoewel je het ook met andere communicatieprotocollen kunt realiseren. </p><p> <b>Resource-oriëntatie</b>: Tegenwoordig is er toenemende aandacht voor integratie op basis van RESTful API’s, dat je kunt zien als onderdeel van resource-oriëntatie. Bij resource-oriëntatie ligt de nadruk niet op de service maar op de te benaderen resource (bijvoorbeeld een klantobject). Elke resource heeft daartoe een eigen adres (URL) en kent standaard operaties voor het creëren, lezen, wijzigen en verwijderen van gegevens. Bij RESTful API’s staat de standaard HTTP centraal en wordt ervan uitgegaan dat de server geen toestand bijhoudt. Het is daardoor relatief goed schaalbaar. </p><p> <b>Eventoriëntatie</b>: Bij eventoriëntatie (ook wel: Event Driven Architecture - EDA) vormen gebeurtenissen de initiator voor uitwisseling van gegevens. Denk aan de geboorte van een kind, een huwelijk en een verhuizing. Bij event-oriëntatie wordt veel gewerkt met het publish-and-subscribe mechanisme, waarbij applicaties zich kunnen abonneren op bepaalde typen gebeurtenissen, die vervolgens worden genotificeerd bij het optreden van deze gebeurtenissen. Een combinatie tussen eventoriëntatie en berichtoriëntatie komt wel vaker voor. Message oriented middleware biedt dan functionaliteit voor publish-and-subscribe. Een specifieke vorm van eventoriëntatie is eventstreaming, waarbij events in een persistente stroom worden geplaatst en er ook zoekvragen aan de stroom zelf kunnen worden gesteld. Eventoriëntatie is vooral relevant als snel moet kunnen worden ingesprongen op gebeurtenissen. </p><p> <b>Gegevensoriëntatie</b>: Bij de uitwisseling van gegevens kunnen ook de gegevens zelf centraal staan. Je zou dit gegevensoriëntatie kunnen noemen. De functionaliteit en de rol van de gegevens in een proces zijn daarbij van ondergeschikt belang. Het belangrijkste is dat er een aanbieder is van gegevens en een afnemer van deze gegevens. De precieze vorm van de gegevens en de manier waarop de gegevens worden uitgewisseld kan sterk variëren. Het kan gaan om de uitwisseling van bestanden, het bevragen van gegevensbronnen of het synchroniseren van gegevensbronnen. Synchronisatie van gegevensbronnen maakt typisch gebruik van Change Data Capture technologie, waarbij elke wijziging zoals vastgelegd in de transactielog van een database wordt uitgewisseld. Hiermee kan een volledige replica (of subset ervan) van een gegevensbron worden gemaakt op een andere locatie. Gegevensoriëntatie leent zich in het algemeen goed voor periodieke (batch)processen. </p><p> <b>Berichtoriëntatie</b>: Bij berichtoriëntatie staat het bericht centraal, die typisch ook asynchroon wordt gecommuniceerd. Dat betekent dat de zender niet wacht op een antwoord. Vaak gaat het om verwerkingen die uitgesteld verwerkt kunnen worden, zoals periodieke batchprocessen. De nadruk ligt dan vooral op het asynchroon en betrouwbaar verzenden van berichten met Message Oriented Middleware, typisch op basis van queueing mechanismen. Door de ontkoppeling van de zender en de ontvanger met een queue is het eenvoudiger om het aantal gelijktijdige verwerkingen op te schalen. </p><p> <b>Betekenisoriëntatie</b>: Bij betekenisoriëntatie staat het betekenisvol publiceren van gegevens op het wereldwijde web centraal. Dat betekent dat het formeel beschrijven van de betekenis van de gegevens en het beschikbaar stellen van deze gegevens conform webstandaarden belangrijk is. Betekenisoriëntatie leent zich dan ook erg goed voor het publiceren van metagegevens. Gegevens krijgen ook meer betekenis door relaties te leggen naar andere begrippen en gegevens. Het op een efficiënte manier verwerken van de gegevens is daarbij minder belangrijk. In deze context wordt ook gesproken over het semantische web, waarbij gegevens betekenisvol beschikbaar zijn op het web en aan elkaar verbonden. Webstandaarden zoals HTTP staan daarbij centraal. Met het SPARQL protocol kunnen complexe zoekvragen worden gesteld, ook federatief over meerdere bronnen. </p> <h3>Digikoppeling</h3> <p> Het is belangrijk om gegevensuitwisseling te standaardiseren, waar mogelijk. Overheidsbreed is hiervoor de Digikoppeling standaard gedefinieerd. De Digikoppeling standaard maakt veilige gegevensuitwisseling tussen overheden mogelijk. De standaard beschrijft afspraken om gegevens juist te adresseren, leesbaar en uitwisselbaar te maken en veilig en betrouwbaar te verzenden. Het bevordert de interoperabiliteit tussen overheidsorganisaties. De standaard bestaat uit een viertal koppelvlakspecificaties voor gestructureerd gegevensuitwisseling met en tussen overheidsorganisaties: </p> <ul> <li>Digikoppeling Koppelvlakstandaard WUS - voor synchrone uitwisseling van gestructureerde berichten;</li> <li>Digikoppeling Koppelvlakstandaard ebMS2 - voor asynchrone uitwisseling voor betrouwbaar berichtenverkeer.</li> <li>Digikoppeling Koppelvlakstandaard REST-API - voor synchrone gegevensuitwisseling met resources;</li> <li>Digikoppeling Koppelvlakstandaard Grote Berichten - voor het uitwisselen van grote bestanden.</li> </ul> <p> Zoals beschreven in de <a href="https://gitdocumentatie.logius.nl/publicatie/dk/architectuur/2.0vv/">architectuur Digikoppeling</a> is Digikoppeling gericht op de beveiligde uitwisseling van gestructureerde gegevens tussen systemen van Nederlandse overheidsorganisaties en instellingen uit de (semi-)publieke sector. Het zegt niets over de toepassing van de standaard buiten deze afbakening: met bedrijven, van open data of van ongestructureerde gegevens. Het is verplicht om te gebruiken bij gesloten diensten, de uitwisseling met GDI-voorzieningen en bij sector-overstijgende uitwisseling. Uitwisseling van geografische gegevens is uitgesloten van het functioneel toepassingsgebied. </p> <p> Synchrone uitwisseling kan worden ingericht op basis van de Digikoppeling-koppelvlakstandaard WUS en het Digikoppeling REST API profiel. Digikoppeling Koppelvlakstandaard ebMS2 biedt specifieke ondersteuning voor asynchrone uitwisseling en betrouwbare aflevering. Digikoppeling Grote Berichten is gericht op de veilige bestandsoverdracht van berichten groter dan 20 MB, met name in de context van ebMS en WUS. Als er behoefte is aan signing en/of encryptie dan zijn alleen de WUS en ebMS koppelvlakstandaarden geschikt (er is wel een voorstel hierover voor de koppelvlakstandaard REST API). Dat is bijvoorbeeld relevant als zich tussen aanbieder en afnemer een niet vertrouwde intermediair bevindt. Er is in de huidige versie van de Digikoppeling architectuur geen onderscheid meer tussen 'WUS voor bevragingen' en 'ebMS voor meldingen'. In de praktijk bleek dit onderscheid niet altijd goed te werken. </p><p> Partijen bepalen in onderling overleg welke Digikoppeling profiel ze gebruiken. Aanbieders bepalen welke koppelvlakstandaard gebruikt wordt voor een door hun geleverde dienst. Per dienst kunnen ook meerdere koppelvlakstandaarden aangeboden worden. </p> <h3>Doorontwikkeling van Digikoppeling</h3> <p> In deze paragraaf schetsen we een aantal inzichten en ontwikkelingen die invloed hebben op de Digikoppeling standaard. Ons advies is om te onderzoeken of Digikoppeling als bredere standaard kan worden gepositioneerd, ook voor communicatie met bedrijven, binnen sectoren en mogelijk zelfs voor open data. Dat draagt bij aan maximale standaardisatie, hogere interoperabiliteit en maakt het uiteindelijk voor organisaties dus alleen maar eenvoudiger. Dit vraagt wel aandacht voor aansluitvoorwaarden en een stringenter vorm van lifecyclemanagement van de Digikoppeling standaard. </p><p> Digikoppeling is ontwikkeld voor toepassing op nationaal niveau. Voor gegevensuitwisseling op EU-niveau gelden EU-standaarden, waarvan e-Delivery op dit moment de dominante is. Voor gegevensuitwisseling met Europese overheden is gebruik van de e-Delivery standaard dus aanbevolen. Het zou goed zijn als de Digikoppeling-standaarden zoveel mogelijk afgestemd zijn op de e-Delivery standaard. Dat zou het eenvoudiger maken voor Nederlandse overheidsorganisaties om gegevens via Digikoppeling automatisch ook internationaal beschikbaar te kunnen stellen. Daarnaast zou de e-Delivery standaard zelf mogelijk ook als Digikoppeling koppelvlakstandaard kunnen worden gedefinieerd. Het vraagt nader onderzoek om te bepalen of dit meerwaarde heeft. </p> <p> Er is inmiddels een vervanger van de ebMS2 standaard zoals onderdeel van het koppelvlakprofiel ebMS, namelijk de ebMS3 standaard. Wij adviseren om migratie naar deze ebMS3 standaard in te zetten, zeker ook gegeven dat deze standaard ook Europees wordt gebruikt als onderdeel van de e-Delivery standaard. Aandachtspunt is dat ebMS3 niet backwards compatible is met ebMS2. Het is dan ook belangrijk om een implementatie- en migratieplan op te stellen waarin deze aandachtspunten nader zijn uitgewerkt.</p> <p> De Digikoppeling standaard is ontwikkeld voor gegevensuitwisseling tussen organisaties, maar het zou beter zijn als deze standaard ook voor uitwisseling met bedrijven ingezet kan worden. Gegevensuitwisseling met overheidsorganisaties is niet fundamenteel anders dan met bedrijven. De inzet voor bedrijven is al grotendeels mogelijk, maar een expliciete toets hierop en eventuele aanpassing van de standaard is wenselijk. Met name de kosten die verbonden zijn aan de beveiligingscertificaten zijn een mogelijke drempel. </p><p> Er is een voorgestelde uitbreiding van de koppelvlakstandaard REST API met signing en encryptie, waardoor het beter geschikt is voor beveiligde uitwisseling van gegevens. Vanuit het Common Ground initiatief bij gemeenten is inmiddels de FSC-standaard ontwikkeld, die een aantal functies biedt die in meer algemene zin waardevol zijn bij het gebruik van (HTTP-gebaseerde) API’s. Zo biedt het bijvoorbeeld mechanismen om partijen te machtigen voor het gebruik van API’s van derden. We zien het als een logische stap, die ook inmiddels al is ingezet, om deze FSC standaard te combineren met de Digikoppeling API koppelvlak standaard en om daarmee om te vormen tot een landelijke standaard. </p><p> De koppelvlakstandaard REST API is nu specifiek gericht op RESTful API’s. Tegelijkertijd zien we het belang van andere uitwisselprotocollen zoals GraphQL en SPARQL. Deze protocollen bieden meer specifieke mogelijkheden dan RESTful API’s, bijvoorbeeld om mogelijke performanceproblemen die kunnen optreden bij het gebruik ervan te voorkomen. Het gebruik van RESTful API’s kan namelijk tot relatief veel kleine verzoeken leiden, wat tot performanceproblemen kan leiden. GraphQL is bijvoorbeeld mogelijk een beter bruikbaar protocol als er sprake is van complexe bevragingen, mogelijk ook over meerdere endpoints. We denken dat Digikoppeling ook rekening zou moeten houden met het gebruik van dit soort protocollen. </p> <h3>Andere communicatieprotocollen en standaarden</h3> <p>Zoals beschreven heeft de Digikoppeling standaard een voorgeschreven functioneel toepassingsgebied. We denken dat het waardevol is om de Digikoppeling standaard ook buiten het huidige inzetgebied te gebruiken als dat meerwaarde heeft. Tegelijkertijd onderkennen we dat er ook andere communicatieprocotollen en standaarden zijn die mogelijk relevant zijn en een eigen logisch toepassingsgebied hebben. In de volgende tabel benoemen we een aantal relevante standaarden en het functionele toepassingsgebied. Voor een deel zijn dit soort standaarden ook opgenomen in de lijsten van Forum Standaardisatie. Voor die standaarden hebben we het functioneel toepassingsgebied overgenomen over de betreffende lijst en geven we aan welke status de standaard bij het Forum Standaardisatie heeft. Functioneel toepassingsgebieden die we zelf voorstellen geven we schuingedrukt weer. </p> <p> <table class="table table-striped"> <tr><td valign="top"><b>Standaard</b></td><td valign="top"><b>Functioneel toepassingsgebied</b></td><td valign="top"><b>Status</b></td></tr> <tr><td valign="top">Geo-standaarden</td><td valign="top">Geo-standaarden moeten worden toegepast op de uitwisseling van geografische informatie tussen organisaties, waarbij de ruimtelijke dimensie van significant belang is.</td><td valign="top">Verplicht</td></tr> <tr><td valign="top">OData</td><td valign="top">OData kan worden toegepast voor het bouwen en gebruiken van REST APIs met als doel het gestructureerd ontsluiten van (statistische) open datasets.</td><td valign="top">Aanbevolen</td></tr> <tr><td valign="top">GraphQL</td><td valign="top"><i>Het flexibel bevragen van meerdere resources.</i></td><td valign="top">geen</td></tr> <tr><td valign="top">SPARQL</td><td valign="top"><i>Het bevragen van Linked Data resources.</i></td><td valign="top">geen</td></tr> <tr><td valign="top">IIIF</td><td valign="top"><i>Het bevragen van multimediale web resources.</i></td><td valign="top">geen</td></tr> <tr><td valign="top">AMQP</td><td valign="top"><i>Het realtime en/of betrouwbaar uitwisselen van berichten.</i></td><td valign="top">geen</td></tr> </table> </p> <h3>Federated Service Connectivity</h3> <p> De Federated Service Connectivity (FSC) standaard is ontwikkeld in de context van het Common Ground programma voor gemeenten. Het standaardiseert de werking van tussenliggende componenten die het gebruik van API’s vereenvoudigen. De standaard wordt inmiddels ondersteund door verschillende leveranciers en is gepositioneerd als een brede standaard die door alle overheidsorganisaties kan worden gebruikt. Het is voorgesteld als onderdeel van het Digikoppeling profiel voor REST API’s, maar kan in bredere zin worden gebruikt voor gegevensuitwisseling tussen systemen over HTTP. </p> <p> De kern van de FSC standaard is dat het een vertrouwensnetwerk kan creëren tussen systemen door het creëren van contracten tussen partijen. De API's die worden aangeboden en de bijbehorende contracten worden geregistreerd in een directory, waarvan er meerdere kunnen zijn. In een directory kunnen API's worden gezocht en op basis daarvan kunnen ze worden aangroepen door systemen, waarbij het resulterende berichtenverkeer verloopt over tussenliggende FSC componenten. Er is een tussenliggend component bij het zendende systeem (outway) en een tussenliggend component bij het ontvangende systeem (inway). In deze componenten kan ook extra functionaliteit worden aangeroepen, zoals het loggen van de berichten. Hiervoor wordt een transactie-identificatie gegenereerd, die bij elkaar behorende berichten kan correleren. Daarnaast zijn er manager componenten die vooral verantwoordelijk zijn voor de contractafhandeling. Het is mogelijk om machtigingen tussen systemen toe te kennen. Hierdoor kan een systeem van een derde partij (bijvoorbeeld een SaaS leverancier) een machtiging ontvangen om namens een overheidsorganisatie gebruik te maken van een ander systeem. Dit voorkomt dat er sleutels van certificaten aan deze derde partij moeten worden verstrekt, wat vanuit beveiligingsperspectief onwenselijk is. </p> <p><img src="https://minbzk.github.io/gdi-gegevensuitwisseling/images/fsc.jpg" width=640></p>