logius-standaardenbeheer
commented
3 years ago Over de toepassing (PTOLU) van DK
Het gaat dus altijd om het uitwisselen van gestructureerde berichten. Wissel je iets anders uit, dan is (de verplichting van) DK niet van toepassing.
Ik weet niet zeker of het Forum dit zo ook bedoeld heeft (in 2009) Ik denk dat dat we hier wel expliciet aandacht aan moeten besteden.
Je zou dit probleem kunnen oplossen door het gebruik van gestructureerde berichten (o.b.v. XML of JSON) verplicht te stellen binnen DK.
Je hebt hier wel een goed punt. De definitie van gestructureerd is sowieso niet kraakhelder. Een JSON object (gestructureerd) wordt immers in een HTTP response (gestructureerd) geretourneerd, maar door het onderscheid in de Architectuur tussen gestructureerde berichten en “op resources gebaseerd” maken we het er misschien niet duidelijker op.
Dat is een inperking die m.i. wel zinvol is.
Doel je op een inperking voor het toepassingsgebied van Digikoppeling? of is dit een inperking voor gebruikers (zodat ze DK ook moeten gebruiken voor REST verkeer tussen closed G2G)
Overigens is de SOA bij NORA al buiten beeld.
Ja, het is mijn niet duidelijk of het door een ander paradigma is vervangen.
Bij een REST API conform DK is er dus geen vraagbericht maar wel altijd een gestructureerd antwoordbericht?
Ik besef dat we hier expliciet aandacht aan moeten besteden, of ieder geval definiëren waarom we dit zo opgeschreven hebben. Ik denk bij ongestructureerd berichtenverkeer aan het uitwisselen van ‘blobs zoals een document in PDF of een plaatje. Maar dat hebben we niet consequent beschreven
Er zijn geen eisen aan berichten in combinatie met een REST API, zoals een beschrijving van de structuur?
Ja, die zijn er wel. Een OAS (Open API Specificatie) geeft aan wat de response is van een request. Die is voor REST API uitwisseling verplicht in de NL G2G context
Principe 3 luidt: (…) Dit kan wel lastig worden. Overheidsdiensten zijn namelijk in bepaalde situaties verplicht om gegevens uit basisregisters op te halen (en niet zelf te vragen aan de burger of het bedrijf). De aanbieder bepaalt dan wat hij aanbiedt, maar de afnemer moet nagaan of dat voldoet aan de AVG. Wat te doen als het niet voldoet? Zou er ook een verplichting moeten zijn aan de kant van de aanbieder?
Dit principe is ongewijzigd in de nieuwe versie overgenomen. NORA basisprincipe “VERTROUWELIJK” zegt het wat algemener: Afnemers kunnen erop vertrouwen dat informatie niet wordt misbruikt. Is de aanbieder er vanuit zijn AVG verplichting niet al aan gebonden?
Over betrouwbaarheid
Het is de aanbieder die bepaalt wanneer het nodig is (in lijn met uitgangspunt 4)? Misschien goed om dat er bij te zetten.
Ook deze is gehandhaafd uit de oude versie. We zullen er naar kijken.
Over services in de NORA:
… Als jij hem wel hebt gevonden, wil je dan een expliciete verwijzing toevoegen? Dat zou mij ook helpen…
We kunnen deze vraag alleen terugleggen bij NORA. Zullen we doen
Over meldingen, transacties, ‘bewerken van resources’ en ‘met/zonder impact’:
Deze begrippen worden allemaal gebruikt, zie bijvoorbeeld ‘Koppelvlakstandaarden en voorschriften’. Ik vroeg me af wat het verschil is….
We zullen hier nog goed naar kijken
... de toepassing van een REST API profiel niet (betrouwbaarheid is blijkbaar niet nodig?
Hier speelt ook het begrip business transactie een rol, waarin een afnemer een mutatierequest doet en later een bericht krijgt dat het is verwerkt. Dit hoeft dus niet op transportlaag te gebeuren (ebMS) maar kan ook met synchrone requests.
NB Er zijn twee tabellen met het nummer 7.2
Thx, zullen we fixen
DK Grote Berichten.
Dit kan dus niet met REST. Waarom niet?
Het patroon is wel met REST te doen. We hebben er voor gekozen om vooralsnog geen REST profiel voor DK GB te beschrijven
Zie ook de figuur boven in het hoofdstuk Koppelvlakstandaarden en voorschriften, , daar is ook een combinatie van REST API met Grote Berichten opgenomen.
Ja, je hebt gelijk. Dat is dan niet consequent. Zullen we even naar kijken
Over verplichte toepassing van profielen en koppelvlakstandaarden:
Begrijp ik goed dat de keuze van de koppelvlakstandaard en het profiel nu dus volledig vrij is? Misschien goed om dat dan niet alleen bij de use cases te vermelden. Ook in het hoofdstuk over implementatie zie ik geen verplichting.
Ja dit is vrij, We suggereren met de scenario’s en use cases welke koppelvlak de meeste voordelen biedt voor een uitwisseling
NORA principes:
Deze moet je even nakijken, AP37 is in de NORA vervangen door AP43. Misschien zijn er zo nog meer.
Goed punt. Gaan we doen. Ik hoop dat de schade beperkt blijft :smiley:
Volgend commentaar kwam per email binnen:
Over de toepassing (PTOLU) van DK:
Het Forum benoemd het organisatorisch werkgebied:
Het gaat dus altijd om het uitwisselen van gestructureerde berichten. Wissel je iets anders uit, dan is (de verplichting van) DK niet van toepassing. Uitgangspunt 2 zegt:
Blijkbaar is ‘op resources gebaseerde uitwisseling’ geen berichtenverkeer. Gestructureerde (gedefinieerde) berichten zijn dus ook geen uitgangspunt (meer) voor DK. Zie ook het implementatie hoofdstuk waar enerzijds wordt gevraagd ‘Zijn de berichten gedefinieerd?’ en anderzijds uitgegaan wordt van berichtenverkeer (paragraaf Servicebeschrijvingen). Dit is dus niet helemaal in lijn met het organisatorisch werkgebied dat het Forum aangeeft. Als je gestructureerde berichten uitwisselt dan is DK verplicht, maar als je ‘op resources gebaseerde uitwisseling wilt dan is DK niet verplicht. Je zou dit probleem kunnen oplossen door het gebruik van gestructureerde berichten (o.b.v. XML of JSON) verplicht te stellen binnen DK. Dat is een inperking die m.i. wel zinvol is. Ik denk dat met ‘op resources gebaseerd’ bedoeld wordt de REST aanroepen met alleen parameters in de vorm van name-value-pairs en zonder gestructureerd bericht. Die zorgen parameters voor een harde koppeling tussen bron en doel, wat niet conform SOA is. Overigens is de SOA bij NORA al buiten beeld.
Na bovenstaande zoektocht lees ik dit in het hoofdstuk Implementatie:
Bij een REST API conform DK is er dus geen vraagbericht maar wel altijd een gestructureerd antwoordbericht? Hierna volgen dan eisen aan WUS en EBMS berichten. Er zijn geen eisen aan berichten in combinatie met een REST API, zoals een beschrijving van de structuur?
Over de verantwoordelijkheid voor informatiebeveiliging:
Uitgangspunt 4 luidt:
Principe 3 luidt: (…)
Dit kan wel lastig worden. Overheidsdiensten zijn namelijk in bepaalde situaties verplicht om gegevens uit basisregisters op te halen (en niet zelf te vragen aan de burger of het bedrijf). De aanbieder bepaalt dan wat hij aanbiedt, maar de afnemer moet nagaan of dat voldoet aan de AVG. Wat te doen als het niet voldoet? Zou er ook een verplichting moeten zijn aan de kant van de aanbieder?
Over betrouwbaarheid:
Principe 4 luidt: (…)
Het is de aanbieder die bepaalt wanneer het nodig is (in lijn met uitgangspunt 4)? Misschien goed om dat er bij te zetten.
Over services in de NORA:
In het hoofdstuk over de Digikoppeling Keten staat:
Ik kan geen specificatie vinden in de NORA (www.noraonline.nl). Het woord Service komt voor in Service Level Agreement, in Denial of Service, in Software as a Service, in Service Management, maar een beschrijving zoals in de SOA architectuur staat er niet meer in (ook gezocht op woorden als ‘Dienstgericht’ of ‘Dienstgebaseerd’). Als jij hem wel hebt gevonden, wil je dan een expliciete verwijzing toevoegen? Dat zou mij ook helpen…
Over meldingen, transacties, ‘bewerken van resources’ en ‘met/zonder impact’:
Deze begrippen worden allemaal gebruikt, zie bijvoorbeeld ‘Koppelvlakstandaarden en voorschriften’. Ik vroeg me af wat het verschil is. Zijn het niet allemaal acties die mutaties in de bron veroorzaken? En die dan toch allemaal ‘betrouwbaar’ zouden moeten zijn. Betrouwbaarheid moet gegarandeerd worden door een betrouwbaar profiel (zie tabel). Een betrouwbaar profiel is ‘geschikt voor meldingen’ (zie opsomming). EBMS is de enige koppelvlakstandaard voor ‘betrouwbaar berichtenverkeer’, zie ook de laatste use case. Zie ook de use cases, tabel 7.2: de toepassing van EBMS levert betrouwbaarheid, de toepassing van een REST API profiel niet (betrouwbaarheid is blijkbaar niet nodig?). NB Er zijn twee tabellen met het nummer 7.2, ik bedoel hier de eerste.
DK Grote Berichten
Hier staat (‘Koppelvlakstandaarden en voorschriften’):
Over verplichte toepassing van profielen en koppelvlakstandaarden:
Bij de use cases staat:
Begrijp ik goed dat de keuze van de koppelvlakstandaard en het profiel nu dus volledig vrij is? Misschien goed om dat dan niet alleen bij de use cases te vermelden. Ook in het hoofdstuk over implementatie zie ik geen verplichting.
NORA principes:
Deze moet je even nakijken, AP37 is in de NORA vervangen door AP43. Misschien zijn er zo nog meer.