From 87eba6e495be883630c1b32c24e670d555e13dd6 Mon Sep 17 00:00:00 2001 From: Danny Greefhorst <46052032+dgreefhorst@users.noreply.github.com> Date: Fri, 10 May 2024 08:40:29 +0200 Subject: [PATCH] tekstuele aanpassingen --- .../Representation_id-1d2d4327d948422eadfcd5208208ec3a.xml | 2 +- .../WorkPackage_id-dd34cf416ee84ab8a5a6ead202d3fa0b.xml | 5 +++++ 2 files changed, 6 insertions(+), 1 deletion(-) create mode 100644 model/implementation_migration/id-4c29ccf3c5f946bf97f0dfb709aa3301/WorkPackage_id-dd34cf416ee84ab8a5a6ead202d3fa0b.xml diff --git a/model/business/id-7836becd6f33424a983b4eb7df958d98/Representation_id-1d2d4327d948422eadfcd5208208ec3a.xml b/model/business/id-7836becd6f33424a983b4eb7df958d98/Representation_id-1d2d4327d948422eadfcd5208208ec3a.xml index 11c31e4b..9ea1c798 100644 --- a/model/business/id-7836becd6f33424a983b4eb7df958d98/Representation_id-1d2d4327d948422eadfcd5208208ec3a.xml +++ b/model/business/id-7836becd6f33424a983b4eb7df958d98/Representation_id-1d2d4327d948422eadfcd5208208ec3a.xml @@ -2,7 +2,7 @@ xmlns:archimate="http://www.archimatetool.com/archimate" name="Verdieping: uitwisselprotocollen" id="id-1d2d4327d948422eadfcd5208208ec3a" - documentation="<p>Het is belangrijk om gegevensuitwisseling te standaardiseren, waar mogelijk. Overheidsbreed is hiervoor de Digikoppeling standaard gedefinieerd. In dit deel van de architectuur wordt eerst ingegaan op de verschillende vormen gegevensuitwisseling en hun toepassingsgebied. Vervolgens wordt de Digikoppeling standaard beschreven en een doorkijk gegeven op de gewenste doorontwikkeling van Digikoppeling.</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 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. publicatie op het web. Daarmee zijn het paradigma’s om te kijken naar gegevensuitwisseling. In onderstaande paragrafen vergelijken we de verschillende basisvormen en benoemen we de belangrijkste uitwisselprotocollen. Vervolgens geven we een overzicht van de toepassingsgebieden. </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. In het verleden werd voor service-oriëntatie veel gebruik gemaakt van Web Services op basis van de SOAP standaard. We zien tegenwoordig dat veel HTTP-gebaseerde API’s deels ook service-georiënteerd worden opgezet. Daarbij is dus vooral de functionaliteit belangrijk. Daarnaast is het een manier om te voorkomen dat er veel fijnmazige gegevensbewerkingen nodig zijn en is het dus een manier om de performance te verbeteren. </p><p> <b>Resource-oriëntatie</b>: Tegenwoordig is er toenemende aandacht voor integratie op basis van API’s, dat je kunt zien als onderdeel van het paradigma 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 resource-oriëntatie wordt typisch gebruik gemaakt van RESTful API’s, waarbij de standaard HTTP centraal staat en ervan wordt uitgegaan dat de server geen toestand bijhoudt. Daarnaast krijgt de GraphQL standaard veel aandacht, die het eenvoudiger maakt om geïntegreerde vragen te stellen over meerdere onderliggende RESTful API’s. </p><p> <b>Eventoriëntatie</b>: Bij eventoriëntatie (ook wel: Event Driven Architecture - EDA) vormen gebeurtenissen de initiator voor uitwisseling van data. 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. Voor eventoriëntatie zijn standaarden zoals CloudEvents, ASyncAPI en Linked Data Event Streams relevant. </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, maar is vaak in de vorm van bestanden. Het kan bijvoorbeeld gaan over downloads via HTTP of FTP, protocollen voor Big Data zoals HDFS of meer protocollen die gebruikt worden in de context van datawarehousing en/of business intelligence. </p><p> <b>Berichtoriëntatie</b>: Bij berichtoriëntatie staat het bericht centraal en zijn de precieze aanleiding en de verwerking ervan zijn daarbij minder belangrijk. Vaak gaat het om verwerkingen die uitgesteld verwerkt kunnen worden, en veelal zijn dat periodieke batchprocessen. De nadruk ligt dan vooral op het betrouwbaar verzenden van (vaak grote) berichten met Message Oriented Middleware, typisch op basis van queueing mechanismen. Door de ontkoppeling van de zender en de ontvangen met een queue is het eenvoudiger om het aantal gelijktijdige verwerkingen op te schalen. Bij deze vorm zijn standaarden van belang zoals MQTT, AQMP en Jakarta Messaging. </p><p> <b>Weboriëntatie</b>: Bij weboriëntatie staat het betekenisvol publiceren van gegevens op het wereldwijde web centraal. Dat betekent dat het beschikbaar stellen conform webstandaarden belangrijk is. 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. Daarbij wordt gebruik gemaakt van Linked Data standaarden zoals RDF, RDFS, OWL, SHACL, SKOS en SPARQL. SPARQL is vooral het uitwisselprotocol, waarmee complexe zoekvragen kunnen worden gesteld, ook federatief over meerdere bronnen. </p><p> In onderstaande tabel wordt een overzicht gegeven van de verschillende vormen van gegevensuitwisseling en hun primaire toepassingsgebied. </p><p> <table class="table table-striped"> <tr><td><b>Vorm van gegevensuitwisseling</b></td><td><b>Toepassingsgebied</b></td></tr> <tr><td>Service-oriëntatie</td><td><ul><li>Complexe functionaliteit</li><li>Samenstellingen van verschillende gegevensbewerkingen</li></ul></td></tr> <tr><td>Resource-oriëntatie</td><td><ul><li>Eenvoudige functionaliteit</li><li>Nadruk op eenvoudige bewerking van gegevens</li></ul></td></tr> <tr><td>Eventoriëntatie</b></td><td><ul><li>Afhandelen van gebeurtenissen</li><li>Snel inspringen op gebeurtenissen</li></ul></td></tr> <tr><td>Gegevensoriëntatie</b></td><td><ul><li>Periodieke batchprocessen en bulkverwerkingen</li><li>Datawarehousing en business intelligence</li></ul></td></tr> <tr><td>Berichtoriëntatie</b></td><td><ul><li>Betrouwbaar en schaalbaar verwerken van mutaties</li><li>Integratie met legacy systemen</li></ul></td></tr> <tr><td>Weboriëntatie</b></td><td><ul><li>Betekenisvol publiceren van gegevens op het web</li><li>Wereldwijd verbindingen leggen tussen gegevens</li><li>Publicatie van metagegevens</li></ul></td></tr> </table> </p> <p>De volgende figuur geeft een overzicht van de verschillende vormen van gegevensuitwisseling door ze te positioneren in de context van de belangrijkste soorten verwerkingen tussen bepaalde soorten systemen</p> <p><img src="https://minbzk.github.io/gdi-gegevensuitwisseling/images/vormen.svg"></p> <h3>Digikoppeling</h3> <p> 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 Grote Berichten - voor synchrone gegevensuitwisseling met resources;</li> <li>Digikoppeling Koppelvlakstandaard REST-API - 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 voor 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. Als snelheid belangrijker is dan betrouwbaarheid dan is het gebruik van de REST API of WUS koppelvlakstandaarden logischer. 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 en encryptie dan zijn alleen de WUB en ebMS koppelvlakstandaarden geschikt. 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 kunnen kiezen welk interactiepatroon nodig is voor gegevensuitwisseling. Partijen bepalen in onderling overleg welke Digikoppeling profiel ze gebruiken. Providers, zoals Basisregistraties en landelijke voorzieningen, bepalen welke koppelvlakstandaard gebruikt wordt voor een door hun geleverde dienst. Per dienst kunnen ook meerdere koppelvlakstandaarden aangeboden worden. </p> <h3>Doorontwikkeling</h3> <p> In deze paragraaf schetsen we een aantal inzichten en ontwikkelingen die invloed hebben op de Digikoppeling standaard. Ons algemene advies is om Digikoppeling als brede standaard te positioneren, ook voor communicatie met bedrijven, binnen sectoren en voor open data. Dat draagt bij aan maximale standaardisatie, hogere interoperabiliteit en maakt het uiteindelijk voor organisaties dus alleen maar eenvoudiger. Dit vraagt wel een bredere positionering, 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> De koppelvlakstandaard REST API is op dit moment heel beperkt ingevuld. Het biedt ook geen ondersteuning voor signing en encryptie. Tegelijkertijd zijn ze inmiddels de standaard manier van gegevensuitwisseling voor veel organisaties. Doorontwikkeling en uitbreiding van deze standaard is dus aanbevolen. 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 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 nieuwe uitwisselprotocollen opkomen 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 een logisch protocol om te gebruiken 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. Mogelijk kan de huidige koppelvlakstandaard REST API generieker worden opgezet om een aantal van dit soort protocollen ook te ondersteunen. </p> "> + documentation="<p>In dit deel van de architectuur wordt ingegaan op de verschillende vormen gegevensuitwisseling en hun toepassingsgebied. Vervolgens wordt de Digikoppeling standaard beschreven en een doorkijk gegeven op de gewenste doorontwikkeling van Digikoppeling.</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 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. publicatie op het web. Daarmee zijn het paradigma’s om te kijken naar gegevensuitwisseling. In onderstaande paragrafen vergelijken we de verschillende basisvormen en benoemen we de belangrijkste uitwisselprotocollen. Vervolgens geven we een overzicht van de toepassingsgebieden. </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. In het verleden werd voor service-oriëntatie veel gebruik gemaakt van Web Services op basis van de SOAP standaard. We zien tegenwoordig dat veel HTTP-gebaseerde API’s deels ook service-georiënteerd worden opgezet. Daarbij is dus vooral de functionaliteit belangrijk. Daarnaast is het een manier om te voorkomen dat er veel fijnmazige gegevensbewerkingen nodig zijn en is het dus een manier om de performance te verbeteren. </p><p> <b>Resource-oriëntatie</b>: Tegenwoordig is er toenemende aandacht voor integratie op basis van API’s, dat je kunt zien als onderdeel van het paradigma 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 resource-oriëntatie wordt typisch gebruik gemaakt van RESTful API’s, waarbij de standaard HTTP centraal staat en ervan wordt uitgegaan dat de server geen toestand bijhoudt. Daarnaast krijgt de GraphQL standaard veel aandacht, die het eenvoudiger maakt om geïntegreerde vragen te stellen over meerdere onderliggende RESTful API’s. </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. Voor eventoriëntatie zijn standaarden zoals CloudEvents, ASyncAPI en Linked Data Event Streams relevant. Een combinatie tussen eventoriëntatie en berichtoriëntatie komt wel vaker voor. Message oriented middleware biedt dan functionaliteit voor publish/subscribe of er is sprake van zogenaamde event streams, een opslag van de opgetreden events. </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, maar is vaak in de vorm van bestanden. Het kan bijvoorbeeld gaan over downloads via HTTP of FTP, protocollen voor Big Data zoals HDFS of meer protocollen die gebruikt worden in de context van datawarehousing en/of business intelligence. </p><p> <b>Berichtoriëntatie</b>: Bij berichtoriëntatie staat het bericht centraal en zijn de precieze aanleiding en de verwerking ervan zijn daarbij minder belangrijk. Vaak gaat het om verwerkingen die uitgesteld verwerkt kunnen worden, en veelal zijn dat periodieke batchprocessen. De nadruk ligt dan vooral op het asynchroon en betrouwbaar verzenden van (vaak grote) berichten met Message Oriented Middleware, typisch op basis van queueing mechanismen. Door de ontkoppeling van de zender en de ontvangen met een queue is het eenvoudiger om het aantal gelijktijdige verwerkingen op te schalen. Bij deze vorm zijn standaarden van belang zoals MQTT, AQMP en Jakarta Messaging. </p><p> <b>Weboriëntatie</b>: Bij weboriëntatie staat het betekenisvol publiceren van gegevens op het wereldwijde web centraal. Dat betekent dat het beschikbaar stellen conform webstandaarden belangrijk is. 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. Daarbij wordt gebruik gemaakt van Linked Data standaarden zoals RDF, RDFS, OWL, SHACL, SKOS en SPARQL. SPARQL is vooral het uitwisselprotocol, waarmee complexe zoekvragen kunnen worden gesteld, ook federatief over meerdere bronnen. </p><p> In onderstaande tabel wordt een overzicht gegeven van de verschillende vormen van gegevensuitwisseling en hun primaire toepassingsgebied. </p><p> <table class="table table-striped"> <tr><td><b>Vorm van gegevensuitwisseling</b></td><td><b>Toepassingsgebied</b></td></tr> <tr><td>Service-oriëntatie</td><td><ul><li>Complexe functionaliteit</li><li>Samenstellingen van verschillende gegevensbewerkingen</li></ul></td></tr> <tr><td>Resource-oriëntatie</td><td><ul><li>Eenvoudige functionaliteit</li><li>Nadruk op eenvoudige bewerking van gegevens</li></ul></td></tr> <tr><td>Eventoriëntatie</b></td><td><ul><li>Afhandelen van gebeurtenissen</li><li>Snel inspringen op gebeurtenissen</li></ul></td></tr> <tr><td>Gegevensoriëntatie</b></td><td><ul><li>Periodieke batchprocessen en bulkverwerkingen</li><li>Datawarehousing en business intelligence</li></ul></td></tr> <tr><td>Berichtoriëntatie</b></td><td><ul><li>Betrouwbaar en schaalbaar verwerken van mutaties</li><li>Integratie met legacy systemen</li></ul></td></tr> <tr><td>Weboriëntatie</b></td><td><ul><li>Betekenisvol publiceren van gegevens op het web</li><li>Wereldwijd verbindingen leggen tussen gegevens</li><li>Publicatie van metagegevens</li></ul></td></tr> </table> </p> <p>De volgende figuur geeft een overzicht van de verschillende vormen van gegevensuitwisseling door ze te positioneren in de context van de belangrijkste soorten verwerkingen tussen bepaalde soorten systemen</p> <p><img src="https://minbzk.github.io/gdi-gegevensuitwisseling/images/vormen.svg"></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 Grote Berichten - voor synchrone gegevensuitwisseling met resources;</li> <li>Digikoppeling Koppelvlakstandaard REST-API - 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 voor 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. Als snelheid belangrijker is dan betrouwbaarheid dan is het gebruik van de REST API of WUS koppelvlakstandaarden logischer. 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 en encryptie dan zijn alleen de WUB en ebMS koppelvlakstandaarden geschikt. 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 kunnen kiezen welk interactiepatroon nodig is voor gegevensuitwisseling. Partijen bepalen in onderling overleg welke Digikoppeling profiel ze gebruiken. Providers, zoals Basisregistraties en landelijke voorzieningen, 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 algemene advies is om Digikoppeling als brede standaard te positioneren, ook voor communicatie met bedrijven, binnen sectoren en voor open data. Dat draagt bij aan maximale standaardisatie, hogere interoperabiliteit en maakt het uiteindelijk voor organisaties dus alleen maar eenvoudiger. Dit vraagt wel een bredere positionering, 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> De koppelvlakstandaard REST API is op dit moment heel beperkt ingevuld. Het biedt ook geen ondersteuning voor signing en encryptie. Tegelijkertijd zijn ze inmiddels de standaard manier van gegevensuitwisseling voor veel organisaties. Doorontwikkeling en uitbreiding van deze standaard is dus aanbevolen. 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 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 nieuwe uitwisselprotocollen opkomen 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 een logisch protocol om te gebruiken 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. Mogelijk kan de huidige koppelvlakstandaard REST API generieker worden opgezet om een aantal van dit soort protocollen ook te ondersteunen. </p> "> diff --git a/model/implementation_migration/id-4c29ccf3c5f946bf97f0dfb709aa3301/WorkPackage_id-dd34cf416ee84ab8a5a6ead202d3fa0b.xml b/model/implementation_migration/id-4c29ccf3c5f946bf97f0dfb709aa3301/WorkPackage_id-dd34cf416ee84ab8a5a6ead202d3fa0b.xml new file mode 100644 index 00000000..c328a2a4 --- /dev/null +++ b/model/implementation_migration/id-4c29ccf3c5f946bf97f0dfb709aa3301/WorkPackage_id-dd34cf416ee84ab8a5a6ead202d3fa0b.xml @@ -0,0 +1,5 @@ +