(Dit verzoek is ingediend door gemeente Den Haag en gemeente Amsterdam).
Gevraagde wijziging: In ‘vrije’ berichten wordt toegestaan om geen stuurgegevens te gebruiken. Voor de implementatie van foutafhandelingen worden de WS-* standaarden gevolgd.
Toelichting:
In de vrije berichten moeten volgens de StUF standaard altijd stuurgegevens staan. Stuurgegevens gaan over routering van berichten. Voor vrije berichten is dit geminimaliseerd, maar nog altijd aanwezig. In de stuurgegevens element moet minimaal beschreven worden om wat voor type bericht het gaat: synchroon/asynchoon en ingaand/uitgaand en wat de naam is van het bericht. Deze gegevens zijn overbodig, omdat deze gegevens gewoon zichtbaar zijn in de operatie in een WSDL.
Het gebruik van stuurgegevens in de “payload” van berichten is in strijd met de geest van de wereldwijde standaarden. Het zelf implementeren van routering informatie in een bericht, maakt de implementatie van een webservice of consument onnodig ingewikkeld. Het uitgangspunt van de service orientatie is dat een dienst wordt afgenomen op een bepaald adres en het routeren is strikt verborgen in de infrastructuur.
Voor uitzonderlijke soorten interacties (die in webservices praktijk zeer zelden voorkomen) zijn er bovendien de WS-* standaarden die dan ook worden toegepast op het infrastructurele niveau. Het gebruik van WS-* standaarden heeft veel voordelen. Het is veel gemakkelijker voor een ontwikkelaar, want de tooling kan standaard omgaan met WS-* standaarden. De ontwikkelaar hoeft deze functionaliteit niet zelf te ontwikkelen, omdat de tooling deze al ondersteund. Daarnaast ondersteunen alle XML-Gateways en ESB’s WS-* standaarden en is het gebruik er van gemakkelijk. Als er gebruik gemaakt wordt van berichtspecifieke stuurgegevens, dan wordt het een stuk lastiger. Er zal maatwerk door ontwikkelaars ontwikkeld moeten worden om hetzelfde resultaat te bereiken als bij de WS-* standaarden.
Wanneer een operatie van een webservice een foutmelding wil retourneren aan de consument, moet dat volgens StUF d.m.v. meldingen. Deze meldingen zijn geïmplementeerd als onderdeel van de stuurgegevens. Dit is een eigen implementatie, terwijl de webservice specificatie daar m.b.v. faults een standaard voor biedt. Het is onverstandig om hier vanaf te wijken. Door ook hier gebruik te maken van standaarden, krijgt een ontwikkelaar of beheerder veel ondersteuning van tooling, XML-Gateways en ESB’s.
Deze RFC sluit aan op ontwikkelingen rondom Digikoppeling en in bijvoorbeeld SuwiML, zie de SuwiML Transactiestandaard, § 4.8:
“In vorige versies van de SuwiML Transactiestandaard werd er alleen de custom-made SuwiML Header gebruikt. Inmiddels ontstaan er ook internationale standaarden voor bepaalde soorten stuurgegevens, zoals WS-Addressing en WS-ReliableMessaging. Waar mogelijk zullen we in deze en toekomstige versies van de SuwiML Transactiestandaard onderdelen uit de SuwiML Header vervangen door soortgelijke headers van de relevante WS-* en/of andere algemeen geldende standaarden”
Ik kan me heel goed voorstellen dat voor synchrone webservices de verplichting om stuurgegevens te gebruiken wordt heroverwogen.
Doorredenerend zou voor asynchrone communicatie het gebruik van referetntienummer en crossref voldoende zijn.
Maar in beide gevallen verliezen we een stuk gemak bij het inrichten van routering in situaties anders dan point-to-point: nu kunnen berichten gedistribueerd en gerouteerd worden op basis van stromen: van zendend naar ontvangend systeem met betrekking tot entiteiten en desgewenst berichtttype en naam. Dat gemal verliezen we dan, oftewel in alle behalve triviale situaties wordt het een behoorlijke configuratie nachtmerrie in een distributiesysteem.
Het achterliggende punt is wil StUF echt een open standaard zijn, dan moet ze ook zoveel mogelijk aansluiten bij open standaarden, zoals de WS-*-standaarden. Dan kan er zowel voor synchrone als asynchrone webservices gebruik gemaakt wordt van standaard tooling in ESB en webservice gateways. Alleen op deze manier kunnen de berichten goed gemonitord worden en gedistribueerd, zonder dat er eigen implementatie ontwikkeld moet worden op de stuurgegevens te ondersteunen.
@Han: Waarom zouden we niet de WS-standaard voor routering gebruiken die de rest van de wereld gebruikt?
Ik ben het eens dat de verplichting om stuurgegevens te gebruiken heroverwogen kan worden voor alle berichten. Dit is ingrijpend. Deze post is nu alleen voor vrije berichten opgesteld. Het is me niet duidelijk of dit alleen voor 'vrije' berichten gehonoreerd kan worden. Zo ja, is mijn voorstel:
- in 'vrije' berichten toestaan om geen stuurgegevens te gebruiken
andere RFC's op te stellen voor:
- heroverwegen van de verplichting om voor 'synchrone webservices' stuurgegevens te gebruiken
- heroverwegen van de verplichting om voor 'asynchrone webservices' ALLE stuurgegevens te gebruiken
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0134.
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 door te schuiven naar een versie van StUF volgend op StUF 3.02.
Tijdens de StUF Expertgroep van 16 december 2015 is dit RFC, hoewel het was doorgeschoven naar een volgende versie van de StUF onderlaag, alsnog behandeld ihkv de 3.02 versie van de StUF onderlaag. Dit n.a.v. het SIG rapport.
Tijdens de vergadering is benadrukt dat eerst goed gekeken moet worden naar de architectuur van de oplossing voordat je hierover een beslissing gaat nemen.
Men staat niet negatief tegenover het voorstel hoewel de huidige stuurgegevens een veel rijkere invulling geven.
Ook is niet iedereen er voor om 2 verschillende oplossingen in de architectuur te introduceren. Uiteindelijk is iedereen het er over eens om de stuurgegevens in principe uit de standaard te verwijderen. Er zal een uitgewerkt voorstel worden gemaakt.
Tijdens de StUF Expertgroep van 16-3-2016 is naar aanleiding van de vraag om stuurgegevens weg te laten gediscussieerd over de mogelijkheid om 'niet StUF' berichten toe te voegen aan een koppelvlak. Niet alle leden konden zich daarin echter vinden.
Daarnaast heeft Sid nog gewezen op het feit dat het voorstel wil dat we WS standaarden gaan volgen en heeft hij zich de vraag gesteld of we dan nog wel via bestanden uit kunnen wisselen.
In geval van synchrone dienstberichten (Di02 / Du02) kunnen we de stuurgegevens op de volgende manier optioneel maken. Bij een aanroep van de VerwerkSynchroonBericht webservice voor een bericht waarin de berichtsoort en/of de functie ontbreekt als default voor de berichtsoort uit te gaan van Di02 en als default voor de functie uit te gaan van de elementnaam van het bericht. Je hoeft deze stuurgegevens dan niet meer in het bericht te specificeren. Voor het responsbericht op een Di02 is de default voor de berichtsoort Du02 en de functie weer de elementnaam.
Teneinde de RFC waarmee 'het niet gebruiken van stuurgegevens in vrije berichten' wordt toegestaan te scheiden van de RFC waarmee 'het gebruik van WS-addressing' wordt toegestaan is RFC0434 aangemaakt.
Tijdens de StUF Expertgroep van 18 mei 2016 heeft Henri op een vraag van Annemiek (mbt RFC0134) aangegeven dat alle stuurgegevens in het voorstel optioneel zijn en dat de berichtcode een defaultwaarde krijgt. Daarnaast is vermeldt dat functie af te leiden is. Op de vragen van Sid (Hoe kan je straks weten in welke administratie een bericht verwerkt moet worden?) en Mark (Hoe zit het met foutberichten?) is aangegeven dat er niets verandert t.o.v. nu. Alles wat nu kan, kan straks ook.
Tijdens de StUF Expertgroep van 15 juni 2016 is door Sid Brouwer aangegeven dat zij er geen voorstander van zijn. Mark Paanakker gaf aan dat de stuurgegevens voor hen een bron van volgordelijkheid zijn. Cyriel Hak (Gemeente Haarlem) beschouwt de stuurgegevens ook als een handig instrument maar wil op basis daarvan het RFC niet tegenhouden. Ton Timmermans had geen bezwaar aangezien er uiteindelijk in de koppelvlakken wordt besloten of er wel of geen gebruik van gemaakt gaat worden. Voor Sid is dat juist een reden om niet akkoord te gaan. Straks zullen er bij de koppelvlakken steeds discussies volgen op dit onderwerp. Henri Korver gaf aan dat we daar juist naartoe gaan.
De StUF Expertgroep heeft het RFC uiteindelijk goedgekeurd.
Bijgaand (zie bijlage) de uitwerking van RFC0134. In het bijgevoegde document zijn alleen de wijzingen m.b.t. dit RFC zichtbaar. Deze uitwerking zal in de aankomende EG-meeting als hamerstuk behandeld worden. In geval van bezwaar, graag ruim van te voren melden via dit forum.
Bijlage
Bijgaand (zie bijlage) de Word-versie van de uitwerking van bovenstaande RFC. In Word is het voor sommigen handiger om van de ene revisie naar de andere te springen dan in PDF. Ook zijn er mogelijk nog een paar verbeteringen doorgevoerd. Dus graag deze word-versie gebruiken voor de review.
Bijlage
Tijdens de StUF Expertgroep van 16 november 2016 is besloten de uitwerking van dit RFC (RFC0134) goed te keuren.
Tijdens de StUF Expertgroep van 21 december 2016 is Andre vd Nouweland gevraagd met een concreet voorstel te komen m.b.t. RFC0434.
Wel is gesteld dat een StUF bericht zelf moet vertellen wat er met hem moet gebeuren zonder dat er tussen de end-to-end points gerommeld wordt met de stuurgegevens. Je zou dus WS-* toe kunnen passen zonder wijzigingen aan te brengen op de stuurgegevens.
De discussie ging over het volgende : "Het gebruik van stuurgegevens in de “payload” van berichten is in strijd met de geest van de wereldwijde standaarden. Het zelf implementeren van routering informatie in een bericht, maakt de implementatie van een webservice of consument onnodig ingewikkeld. Het uitgangspunt van de service orientatie is dat een dienst wordt afgenomen op een bepaald adres en het routeren is strikt verborgen in de infrastructuur"
Als we vasthouden aan "een StUF bericht zelf moet vertellen wat er met hem moet gebeuren zonder dat er tussen de end-to-end points gerommeld wordt met de stuurgegevens" kan ik geen WS-* discussie starten. Dit is geen service oriëntatie maar meer EDI berichtenverkeer. Ik sta niet achter de stelling "Je zou dus WS-* toe kunnen passen zonder wijzigingen aan te brengen op de stuurgegevens." WS-* standaarden zijn er om je te helpen, niet om je extra werk te bezorgen. Waar ik nog wel wat mee kan is de essentie van deze discussie "Het gebruik van stuurgegevens in de “payload” van berichten is in strijd met de geest van de wereldwijde standaarden". Vandaar mijn nieuwe voorstel "Plaats stuurgegevens in SOAP header ipv payload"
Tijdens de StUF Expertgroep van 15 februari 2017 is RFC0434 afgevoerd.