(Dit verzoek is ingediend door gemeente Den Haag en gemeente Amsterdam).
Gevraagde wijziging: In ‘vrije’ berichten wordt toegestaan om geen relatieobjecten te gebruiken.
Toelichting:
Uit gespreken met KING hebben wij geconcludeerd dat StUF ons verplicht om extra relatieobjecten te hebben tussen twee entiteiten. In de relatieobjecten staat veel CRUD gerelateerde informatie, terwijl het maar helemaal de vraag is of een operatie dat nodig heeft. De operatie moet zelf beslissen wat er met een relatie gebeurd, daarin is de operatie autonoom. N.B. deze verplichting hebben wij in de documentatie niet kunnen vienden.
In het document keuzenVerStUFfing RSGB.pdf (meegeleverd in de bg0310 zipfiles) is er sprake van het ‘platslaan’ van meerdere StUF entiteiten. Mag die handelswijze voor ‘vrije’ berichten nagevolgd worden?
CRUD gegevens toevoegen in domein objecten maakt het domein model onnodig ingewikkeld. Het er vanuit gaan van het CRUD semantiek is strijdig met het uitgangspunt van de service oriëntatie, namelijk dat de interactie gebaseerd is op diensten en niet op het uitwisselen van gegevens. Bovendien zijn webservices daardoor nauwelijks te combineren. Één van de eigenschappen van een SOA omgeving is dat de webservices gemaakt zijn volgens het Service Composability Principle . Dit houdt in dat het toevoegen van een persoon in webservices A kan betekent dat deze webservice A de persoon verwijdert in webservice B en C en toevoegt in webservice D. Indien er CRUD gegevens aanwezig zijn in het domein object zelf, leidt dit tot conflicten.
Het staat iedere ontwerper van een sectormodel hoe het domeinmodel wordt vertaald naar een berichtenmodel. StUF biedt de mogelijkheid om hierbij relatie-entiteiten te gebruiken en heeft hiervoor in het kader van het doorgeven van mutaties ook extra functionaliteit gedefinieerd.
De best-practice raadt om bij de vertaling naar berichten zo goed mogelijk aan te sluiten bij de structuur in het informatiemodel. Gemotiveerd kan hier echter altijd van worden afgeweken.
StUF schrijft ook het gebruik van de CRUD-functionaliteit niet voor. Dit element uit de StUF-standaard kan in een sectormodel geheel genegeerd worden. Het is wel een best practice dat bij het communiceren van mutaties wordt aangesloten bij de door StUF geboden functionaliteit en niet eigen functionaliteit wordt ontwikkeld. Hetzelfde geldt bij het definiëren van opvraagfunctionaliteit. Het is niet de bedoeling hiervoor in de vorm van vrije berichten eigen functionaliteit te definiëren, als de door StUF gedefinieerde functionaliteit ook in de behoeften kan voorzien, al dan niet aangevuld in een vrij bericht.
Even een boute uitspraak: StUF is niet service georienteerd, maar gebeurtenis georienteerd. De zendende applicatie vertelt de goegemeente (alle geabonneerde ontvangen systemen) dat het een gebeurtenis heeft verwerkt waarbij het bepaalde gegevens heeft opgevoerd, gewijzigd of overbodig verklaard. Het is aan ieder ontvangend systeem te bepalen wat het vervolgens met deze informatie doet. Service orientatie volgt inderdaad andere uitgangspunten.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0135.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 20-5-2015 is besloten dit RFC af te voeren.