Architectuur plaatje die de communicatie tussen een WOZ client, de WOZ bevragen proxy en de WOZ bevragen API weergeeft
Opened this issue · 13 comments
Zie: https://github.com/VNG-Realisatie/Haal-Centraal-WOZ-bevragen/blob/master/docs/communicatie-client-proxy-woz-api.pdf. Het origineel is ook in de docs map te vinden en is gemaakt met draw.io
@MelvLee duidelijk plaatje. Bij het WOZ team was nog wat onduidelijk of er dus één aansluiting naar een centraal gehoste proxy komt, of dat elke gemeente een proxy maakt. In het overleg zei je dacht ik het eerste, maar uit het plaatje volgt het tweede (proxy zit binnen gemeente). Weet je wat nu precies de bedoeling is? Leveren we alleen een SDK of docker service, of leveren we echt een centraal gehoste service die door alle gemeenten te leveren is?
Het wordt aangeboden in een Docker image. Dan kunnen we alle kanten op. Het kan dan op elke machine (mac, Windows, Linux) worden gehost waarop Docker is geïnstalleerd. Een gemeente kan zelf bepalen hoe zij de image willen hosten, maar ik verwacht centraal binnen een gemeente. Voor de consumers is dit ook het makkelijkste. Er verandert praktisch niets ten opzichte van rechtstreeks aanroepen. Alleen de base-url en authenticatie/autorisatie protocol
Op verzoek een uitwerking van de 2 mogelijke varianten:
- Een waarbij de WOZ bevragen proxy per gemeente wordt geïmplementeerd:
- Een waarbij de WOZ bevragen proxy centraal bij een nog te bepalen partij wordt geïmplementeerd:
Naar verwachting is variant 1 de gewenste, de vraag is dat te bevestigen.
@melsk-r Bedankt, ziet er goed uit. Zou je voor de volle volledigheid ook nog het plaatje willen toevoegen met filtering door Kadaster? Daar kan dan een notitie bij dat die vanwege wetgeving (verrijking/interpretatie) niet gekozen is. Zoals besproken; het wordt nu complexer en duurder vanwege (een interpretatie van?) wetgeving. Dank je!
@KadNielsS Doe ik graag maar het plaatje ziet er dan volgens mij toch heel anders uit.
Er is dan geen sprake van filtering en dus ook niet van een proxy want de API zou in dat geval direct de waarde leveren die nu door de proxy wordt berekend.
Dat kan ik natuurlijk tekenen maar de vraag is dan hoe de gemeenten precies communiceren. Nog steeds d.m.v. 'request + oAuth2' of juist direct d.m.v. 'request + api key + mTLS'? Dat wil ik wel eerst weten voordat ik het ga tekenen.
@melsk-r we weten niet precies hoe elke gemeente het doet, maar in hoofdlijnen zit er normaal gesproken een Security component tussen de client en de buitenwereld (in dit geval Kadaster). Bijvoorbeeld een API gateway. Een API gateway doet de binnengemeentelijke authenticatie en autorisatie (valideren bijv. client certificaat of ip-adres en oauth token) en de buitengemeentelijke authenticatie (client certificaat, api key)
Die component zit er ook in de situatie met proxy tussen, alleen is die in het plaatje van Melvin (en jouw versies) voor het gemak als één gezien met de WOZ proxy.
misschien een idee om de VNG Realisatie architecten hierop te tippen, want ik kan daarover niet snel iets terugvinden in de GEMMA architectuur, of is dit wat ze bedoelen met "servicebuscomponent"?
@fsamwel Nav 'is dit wat ze bedoelen met "servicebuscomponent"' zou mijn antwoord zijn: Nee. Hoewel je daarme technisch van alles kan (bijv. via translatie) is het om allerlei redenen onverstandig om veel businesslogica onder te brengen in een component als een message broker (de component die meestal wordt bedoeld met 'servicebuscomponent'). Zie https://www.martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes voor toelichting waarom.
Gebruik van een aparte component als proxy is netter qua architectuur. Technisch ook goed te realiseren en werkend te krijgen in zowel de 'centrale' als 'per gemeente' opzet Maar het feit dat het Kadaster als smart endpoint zelf niet zorgt voor de gewenste functionaliteit levert je, links- of rechtsom, extra complexiteit op.
M.b..t. de 'proxy per gemeente of centraal' vraag zou ik als architect kiezen voor de 'per gemeente' optie. M.n. omdat die het beste past bij hoe we als overheid/gemeente zijn georganiseerd; maar ik weet dat anderen vanuit de 'Samen Organiseren gedachte' daar soms anders over denken en gemeenschappelijke voorzieningen zien als een middel om effectiever samen te werken.
In termen van 'API management' raakt het de vraag hoe we overheidsbreed willen sturen op de ontwikkeling van systeem, proces en convenience API's. Waarbi zowel overheidspartijen (zoals hier Kadaster) betrokken zijn, maar zeker ook leveranciers. Daar is m.i. nog veel te weinig aandacht aan besteed en zal daarom tijdens uitvoeringsprojecten voorlopig nog tot dit soort vraagstukken blijven leiden.
Op verzoek ook nog de uitwerking van de variant waarin het Kadaster de gewenste berekening uitvoert:
@fsamwel Nav 'is dit wat ze bedoelen met "servicebuscomponent"' zou mijn antwoord zijn: Nee. Hoewel je daarme technisch van alles kan (bijv. via translatie) is het om allerlei redenen onverstandig om veel businesslogica onder te brengen in een component als een message broker (de component die meestal wordt bedoeld met 'servicebuscomponent'). Zie https://www.martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes voor toelichting waarom.
Gebruik van een aparte component als proxy is netter qua architectuur. Technisch ook goed te realiseren en werkend te krijgen in zowel de 'centrale' als 'per gemeente' opzet Maar het feit dat het Kadaster als smart endpoint zelf niet zorgt voor de gewenste functionaliteit levert je, links- of rechtsom, extra complexiteit op.
M.b..t. de 'proxy per gemeente of centraal' vraag zou ik als architect kiezen voor de 'per gemeente' optie. M.n. omdat die het beste past bij hoe we als overheid/gemeente zijn georganiseerd; maar ik weet dat anderen vanuit de 'Samen Organiseren gedachte' daar soms anders over denken en gemeenschappelijke voorzieningen zien als een middel om effectiever samen te werken.
@adgerrits helemaal eens. We leveren een docker container aan gemeenten. Ik ben ook niet voor een centrale proxy anders dan dat het kadaster de gefilterde waarden levert in de API. Dat doet men niet omdat men geen convenience API wil leveren, maar omdat het kadaster conform de vigerende wetgeving geen bewerking/interpretatie van (deze!) data mag uitvoeren.
Conclusie is dat we:
- voor de korte termijn
een docker container leveren aan gemeenten. Zij kunnen deze implementeren als onderdeel van de gemeentelijke proxy zodat zij de WOZ waarden kunnen filteren voor hun gemeentelijke afnemers - voor de lange termijn
in gang zetten dat het kadaster wettelijk de mogelijkheid wordt geboden de WOZ gegevens te interpreteren conform gezamenlijk vastgestelde en voor eenieder navolgbare business logica.
@CathyDingemanse, eens denk ik. Ook besproken intern Kadaster. We zouden die 'service' als Kadaster best willen bieden, maar daarvoor is inderdaad een aanpassing van de wet nodig.
Architectuurplaatje voor de korte termijn is door Melvin opgesteld. Dat gaat Robert ook opnemen in de "getting started" en daarna kan deze issue gesloten worden.