Ontbrekende Bv01-operations in wsdl-files

Dit erratum is opgevoerd in de onderhoudsverzoeken als ERR276.
De lijst met onderhoudsverzoeken vind je op: 
​www.wikixl.nl/wiki/basisgemeente/index.php/StUF-Expertgroep#Documenten

Je vraag over Bv03 en Fo03 berichten heb ik hier beantwoord.

Wat betreft het Bv01 bericht het volgende. Zojuist heb ik de stuf0301 standaard erop nagelezen en daar wordt het Bv01 bericht als bevestiging van succesvolle verwerking van een Lk01 bericht niet verplicht gesteld. Of dit een bewuste keuze is weet ik niet.  Ook weet ik niet of het een bewuste keuze is geweest dat Bv01 niet is opgenomen in bg0310 en zkn0310. Reden genoeg om deze onduidelijkheid te bespreken in de a.s. StUF expertgroep.

In de StUF Expertgroep van 21 augustus 2013 is dit erratum besproken. Er bleek nog onduidelijkheid te bestaan in welke situatie de Bv01 berichten gemist werden. Aangezien Bv01 berichten nooit na een kennisgeving gestuurd mogen worden moet eerst onderzocht worden of het hier wel echt een omissie betreft. Overigens geldt ook dat een Bv01 bericht niet in de gerelateerde WSDL bestanden van een sectormodel gedefinieerd hoeft te worden als het niet in dat sectormodel gespecificeerd is.

Ik heb lange tijd gedacht dat ik de concepten in StUF voor synchrone en asynchrone communicatie, eventueel in combinatie met één of meerdere intermediaire nodes, heb begrepen. Maar als ik deze post (en de gelinkte post mbt StUF ZKN) lees en de antwoorden in deze twee posts en de StUF 03.01 onderlaag herlees, dan bekruipt mij het gevoeld dat ik er niets meer van snap. Als voorbeelde het volgende citaat uit StUF 03.01 dd 21-06-2013, paragraaf 4.4.1, pagina 45: (begin citaat) Wanneer een Bv01-bevestigingsbericht functioneel de respons is op een asynchroon bericht wordt eerst synchroon een Bv03-bevestigingsbericht verstuurd om aan te geven dat het bericht in goede orde ontvangen is en vervolgens asynchroon een Bv01-bevestigingsbericht om aan te geven dat de verwerking van het bericht functioneel geslaagd is. (einde citaat). Is Bv03 nu een bericht of een reponse? Of een methode? En wat moet een intermediaire node doen met een Bv03? Duidelijke terminologie (end-node, intermediaire node, bericht, request, response, synchrone cq asynchrone berichten; synchrone cq asynchrone verwerking; store and forward, push/pull/trigger) Onderscheid in ondersteunde scenario's (bijvoorbeeld direct gekoppelde end nodes; één intermediaire node die asynchrone berichten synchroon afhandeld; één intermediaire node die asynchrone berichten met store-and-forward afhandeld) Sequence diagrams (ik weet niet hoe ik di hier kwijt zou kunnen, maar kijk maar eens rond in de ebMS specificatie; daar staan leuke voorbeelden). Dat lijken mij de ingrediënten om veel verwarring weg te nemen.

Mij is gevraagd een beschrijving te geven van een scenario waarin behoefte bestaat aan de ontvangst van Bv01 berichten. Enige tijd geleden werkten wij aan een koppeling met een serviceprovider die vrij summiere Fo01 berichten stuurde bij foutsituaties. Er was om die reden behoefte om de beheerder van onze applicatie bij deze Fo01 berichten ook de originele kennisgeving te tonen. Daarmee ontstond de noodzaak alle kennisgevingsberichten te bewaren tot het moment waarop ze waren verwerkt. Als naast de Fo01 berichten ook de Bv01 berichten worden ondersteund dan kunnen de originele berichten direct worden verwijderd als een van beide berichten wordt ontvangen. Zeer recent liepen we tegen een andere situatie aan bij het testen van van onze Zaak-Documentservices tegen het StUF testplatform. Het platform stuurt direct na een asynchrone kennisgeving een synchroon vraagbericht om de verwerking van de kennisgeving te controleren. Het bleek dat het antwoord op de vraag eerder werd samengesteld dan de kennisgeving was verwerkt. De oplossing is nu dat er aan de kant van het testplatform een geringe wachttijd tussen beide requests wordt ingebouwd. Het zou echter fraaier zijn als het testplatform kan wachten op de ontvangst van een Bv01-bericht voordat het vraagbericht wordt verstuurd.

Bij het opstellen van de StUF-standaard is het altijd mijn intentie geweest, dat er na het correct verwerken van een asynchrone kennisgeving geen Bv01 wordt verstuurd. De StUF-standaard zwijgt om die reden ook hierover en de huidige wsdl's (die niet normatief zijn, maar voorbeelden) bevatten daarom ook geen Bv01-berichten. Niet verplicht of niet besproken hoeft natuurlijk nog niet te zeggen verboden. Wat mij betreft staat het iedereen vrij om wel een Bv01-bevestiging te sturen, maar de StUF-standaard geeft je niet de mogelijkheid om een verwerker van asynchrone kennisgevingen hiertoe te verplichten. Het is iets dat twee partijen met elkaar kunnen afspreken, maar niet kunnen afdwingen. Wat mij betreft zijn er geen wijzigingen in StUF of de wsdl's nodig.

Implementatie-afhankelijk met andere (respons)berichten werken is m.i. niet handig voor softwareontwikkeling in het SOA-denken. Het betekent namelijk dat je andere WSDL's moet hebben en in de software moet inbouwen voor alle implementatie varianten. Waarom wordt er niet gestreefd naar één fout/bevestigingsbericht met daarin de aard van de fout/bevestiging (dus wat je nu wilt afleiden van het berichttype)? Er is verder toch geen enkel verschil qua inhoud? En als er wel verschillen zijn, dan nóg zou dat prima in de structuur te ondervangen zijn. Idem voor het werken met 'voorbeeld WSDL's' in plaats van prescriptieve WSDL's: 'voorbeeld' heeft een impliciete vaagheid van 'je kunt er niet vanuit gaan dat het specifiek zo is'. Zijn er leveranciers die dit kunnen bevestigen danwel tegenspreken?

In de StUF Expertgroep van 19 september 2014 is besloten de ontbrekende Bv01 operation toe te voegen aan de relevante WSDL's maar tegelijkertijd moet er in de begeleidende documentatie beschreven worden dat niet alle operations verplicht geimplementeerd hoeven te worden. Als de operations ondersteund worden dan moet dat wel zoals is beschreven in de WSDL's. Wijziging mag mee in patch 21.