Beste community leden,
De gehele discussie over het al dan niet gebruiken van de choice binnen de StUF berichten definities, is voortgekomen uit de wens om:
- StUF berichten scherper te kunnen definiëren in de vorm van xsd schemas per sectormodel en
- StUF berichten vervolgens geautomatiseerd te kunnen valideren tegen de definities binnen deze schemas.
Wensen waar eigenlijk niemand tegenstander van lijkt te kunnen zijn.
De laatste wijzigingen die als gevolg van bovenstaande in de StUF definitie zijn aangebracht, brengen echter een zeer zware consequentie van dit geheel aan het licht. Dit wordt duidelijk door het noodzakelijk schrappen van paragraaf 3.1.5 (Robuuste berichtverwerking) in de StUF standaard versie 03.01.
Deze paragraaf zorgde ervoor dat twee applicaties die beide werken met dezelfde major versie van een sectormodel (bv bg0204) maar daarbinnen een afwijkende minor versie hanteren (bv bg0204.01 versus bg0204.08), toch berichten met elkaar kunnen uitwisselen. Dit ondanks het feit dat de definities van de berichten in beide minor versies (de xsd schemas) van elkaar afwijken.
Door het schrappen van deze paragraaf, wat nodig is om het valideren van berichten tegen een (minor) versie van een xsd sxhema van een sectormodel mogelijk te maken, is het dus niet meer mogelijk om de volgende wijzigingen binnen een major versie van een sectormodel door te voeren:
- Toevoegen van een nieuw element (anders dan door extraElementen)
- Uitbreiden of beperken van een enumeratie
- Uitbreiden of beperken van een choice
- Wijzigen van de lengte van een element
- et cetera
Gedurende de afgelopen jaren hebben we kunnen constateren dat het regelmatig noodzakelijk is om fouten en ongemakken in een StUF sectormodel versie (bg0204) te kunnen herstellen zonder dat dit moet leiden tot een nieuwe major versie van dit sectormodel. Ook de afgelopen maanden hebben wederom aangetoond dat ook het nieuwe sectormodel bg0310 regelmatig aanpassingen behoeft. Wij hebben tijdens de laatste bijeenkomst ook vastgesteld dat het RSGB, de vertaling hiervan naar het sectormodel bg0310 en de mapping tussen bg0204 en bg0310 zeer complex. Daardoor staat het nagenoeg vast dat tijdens het implementeren van dit nieuwe sectormodel en de bijbehorende mapping binnen applicaties van de diverse leveranciers, ook nog onvolkomenheden aan het licht gaan komen.
Indien geconstateerde onvolkomenheden in een sectormodel niet opgelost kunnen worden binnen één en dezelfde major versie van het sectormodel, dan is de implementatie en het gebruik van zon sectormodel ons inziens praktisch onmogelijk omdat:
- het niet reëel is om te eisen dat bij een gemeente iedere applicatie op hetzelfde moment overgaat op de nieuwe minor versie van een sectormodel (big bang implementatie) en
- het niet reëel is om te eisen dat iedere applicatie berichten tegen alle xsds van alle (lagere) minor versies van een sectormodel kan valideren.
Onze conclusie is dat het valideren van berichten op een te gespannen voet staat met de noodzakelijke compatibiliteit van verschillende minor versies van een sectormodel en het is in onze ogen onacceptabel om de huidige compatibiliteit te verliezen door deze in te wisselen voor de validatie van berichten tegen de xsd schemas. Dit wordt nog eens versterkt door de constatering tijdens de laatste community bijeenkomst dat het valideren van berichten tegen xsds in een productieve omgeving waarschijnlijk niet zal plaatsvinden omdat dit de performance van de verwerking te negatief zal beïnvloeden.
Wij hopen dat iedereen bovenstaande keuze evenals wij zorgvuldig wil afwegen. Niet alleen vanuit het perspectief van de leveranciers, maar zeker ook vanuit het perspectief van de uiteindelijke gebruikers.
Met vriendelijke groet,
Rolf, Henk en John
Beste John, Henk en Rolf,
Minor versies zijn uitsluitend bedoeld voor het verhelpen van fouten en niet voor enige functionele uitbreiding of wijziging. Dit is voorbehouden aan een major versie wijziging. Fouten dienen in nieuwe minorversie zodanig verholpen te worden dat berichten, die volgens voorgaande minorversies geldig zijn, ook geldig blijven. Er wordt niet geeist dat de berichten volgens een hogere minorversie ook geldig zijn in lagere minorversies. Een systeem dat berichten in een hogere versie aanmaakt zal dus moeten weten op welke minorversie zijn ontvanger zit en zonodig moeten differentiëren. Een en ander lijkt het wenselijk te maken om de minor versie in de stuurgegevens op te nemen, want dan kan een broker in het midden waar nodig transformeren tussen minor versies.
Deze strenge regels zijn noodzakelijk, omdat het binnen een ESB heel normaal is om alle berichten te valideren. Daarnaast wordt in de SOA-wereld de software veelal gegenereerd op basis van de WSDL en niet meer onafhankelijk van de WSDL gecodeerd. Een fout in de WSDL leidt dus automatisch tot een fout in de software.
We kunnen vanuit StUF geen beperkingen gaan opleggen aan zaken die in de SOA-wereld heel normaal gevonden worden. Dit belemmert de acceptatie van StUF als standaard in een SOA-architectuur. Dit heeft inderdaad wel forse consequenties voor de mogelijkheden om fouten te verbeteren en stelt hoge eisen aan de brokers.
Beste Maarten,
Ik ben van mening dat je de zaak nu toch enigszins bagatelliseert. Een minor versie is inderdaad bedoeld voor het verhelpen van fouten. Ik beschouw de wijzigingen in de laatste patch van bg0204 daarom ook als zodanig. Echter door het verwijderen van paragraaf 3.1.5 (robuustheid berichtverwerking) uit StUF 0301, zouden nagenoeg geen van deze fouten middels een minor versie op bg0310 verholpen kunnen worden !
Indien een systeem (zoals een synchronisatiesysteem) bij het verzenden van berichten niet alleen meerdere major versies moet ondersteunen (wat nodig is om een big bang implementatie bij gemeenten te voorkomen) maar ook meerdere minor versies daarbinnen en per ontvanger het bericht daarop af te stemmen, dan vraag ik me oprecht af of dit nog commercieel rendabel te realiseren is.
De vergelijking die je maakt met de ESB en de SOA wereld doet me direct terugdenken aan de vele discussies die we hadden met o.a. de gemeente Den Haag. Zij wilden ook per dienst een specifiek koppelvlak waarbij het inderdaad gewenst is om hier een keihard contract aan ten grondslag te leggen. Een wijziging van het contract is daarmee direct een nieuwe service. Dit is juist wat we met StUF NIET willen. We willen generieke services voor het uitwisselen van gegevens en we willen niet bij iedere wijziging een nieuwe service, met andere woorden we willen flexibiliteit.
Groet, John
Hallo John,
Het is niet mijn bedoeling om zaken te bagatelliseren. In geval van errata, dient er zoveel mogelijk naar gestreefd te worden dat de foute berichten in de gecorrigeerde schema's ook geldig zijn, dat wil zeggen te vervangen elementen worden in een choice opgenomen, waarbij een van de takken van de choice deprecated is en in een volgende versie verwijderd zal worden. Inperkingen in domeinen worden niet doorgevoerd, maar alleen uitbreidingen, etc.
Het volgen van deze strategie impliceert natuurlijk wel dat verwerkende systemen rekening dienen te houden met berichten met een 'foutieve' inhoud en naar bevind van zaken hiermee om dienen te gaan, bijvoorbeeld door het bericht niet te verwerken. Voor deze situaties kan de StUF foutafhandeling gebruikt worden.
Als we op deze manier met errata omgaan, dan is er nooit sprake van een big bang en hoeft een broker in het midden ook geen rekening te houden met verschillende versies van een schema ivm errata.
Denk je dat dit een werkbare strategie is?
Met vriendelijke groet,
Maarten
Maarten,
creatief voorstel! Het blijf echter wel schipperen tussen gedachten. Op deze manier maak je de 'controle aan de poort' minder zwaar, waardoor applicaties weer meer rekening moeten houden met 'foute gegevens'. En dat staat toch weer enigszins haaks op de gedachte om XSD validaties uit te voeren.
Anderzijds wil je applicaties ook niet belasten met detailkennis over andere applicaties waarmee StUF berichten uitgewisseld moeten worden. Het inzetten van middleware is dan eigenlijk de enige manier om dit fatsoenlijk op te kunnen lossen, met alle gevolgen van dien voor de implementatie inspanning die nodig is om applicaties op basis van StUF met elkaar te kunnen laten praten.
Eigenlijk komen we tot de conclusie dat we de minorversie nodig hebben in de berichten om te kunnen differentieren en indien gewenst transformaties uit te kunnen voeren. Het is niet fijn, maar eigenlijk ook niet te voorkomen bij het toepassen van WSDL/XSD/XML.
Alle schema's die in een bericht gebruikt worden dienen met een minorversie uitgerust te worden, ook het StUF schema zelf. Het lijkt me daarom beter om deze informatie in de namespace URI's op te nemen, bijv:
'http://www.egem.nl/StUF/sector/bg/0310_00'
En om het voor verwerkende software eenduidig te maken waar de versie informatie te vinden is, lijkt het verstandig vanuit de StUF standaard conventies op te stellen voor de opmaak van de URI's:
'http:/[domein beheerder sectormodel]/StUF/sector/[sectormodelnaam]/[major versie]_[minor versie]'
Groet,
Rolf
Hoi Rolf,
in jouw voorstel verandert de namespace van het schema bij elke patch. Echter een patch hoeft niet altijd een aanpasing te zijn van het schema. In dat geval is het onnodig en zonde om de namespace te veranderen. Bovendien denk ik dat men voorzichtig moet zijn met het wijzigen van namespace URI's. Vaak leidt dit tot vervelende aanpassingen in software. Hoewel ik deze laatste uitspraak nu nog niet hard kan maken.
Ik zou eerder het stuurgegeven "StUF:versieSectormodel" in ere hersteld zien. Wel met zes cijfers in plaats van vier zodat ook de minor-versie (patch-nummer) kan worden meegenomen. Dan kunnen berichtverwerkers ook van elk binnenkomend StUF-bericht de exacte versie bepalen.
Henri,
vanuit versiebeheer gezien is het m.i. juist wenselijk om alle wijzigingen in de xsd's in de namespace tot uitdrukking te laten komen. Stel je voor dat vanuit sectormodel WOZ het NPS object uit BG gebruikt wordt. In het NPS object zit een fout die met een patch gefixed wordt in BG. Vanaf dat moment gaan er 2 minor versies van BG door het leven. Gebruikers van het WOZ sectormodel weten zonder aanpassing van de bg-namespace niet meer met welke versie van BG gewerkt wordt. Sterker nog ze mogen in het kader van WOZ zelfs door elkaar heen gebruikt worden. Hierdoor komt de verwerkende software voor onvoorspelbare situaties te staan.
Door de minorversie in de namespace expliciet te maken dient elk sectormodel ook expliciet de keuze te maken voor de betreffende minorversie.
Groet,
Rolf
Hallo Rolf,
Ik heb een paar dagen geleden in bg0300 op aangeven van Gilian K nog een paar fouten verbeterd:
Deze wijzigingen hebben geen invloed op het geldig zijn van functioneel zinnige berichten. Voor deze errata een nieuwe namespace uitgeven gaat mijns inziens toch wel ver, want het heeft nogal wat consequenties voor iedereen.
Het lijkt mij verstandig nog eens goed na te denken over het begrip erratum. Ik kan namelijk wel met je mee gaan dat voor wijzigingen in functionaliteit altijd een nieuwe namespace nodig is. De errata op bg0204 hadden in deze visie dus een nieuwe namespace nodig, omdat er entiteittypen en berichten zijn toegevoegd. Een erratum zou zich moeten beperken tot het verbeteren van fouten, waarvan eenvoudig is in te zien dat de foute situatie nooit de bedoeling had kunnen zijn. Zeker in de beginfase, als er nog dit soort fouten aan het licht komen en er nog maar weinig implementaties zijn, lijkt het me verstandig om deze wijzigingen niet steeds tot namespace wijzigingen te laten leiden.
Met vriendelijke groet,
Maarten