Beste leden van de StUF Expertgroep,
Tijdens de Expertgroep van 17 april hebben we gesproken over de Zaak,- en Documentservices. Hierbij was er discussie over twee punten namelijk het gebruik van specifieke danwel generieke StUF ZKN berichten en de ondersteuning van synchrone danwel asynchrone StUF berichten. Gezien er weinig tijd was om deze discussie goed te voeren is voorgesteld om hiervoor een forumdiscussie te starten.
Doelstelling van de Zaak Document services is op applicatieniveau voorschrijven hoe koppelvlakken ingericht moeten worden. Dit betekent dat we scherp willen definieren welke applicaties bepaalde services bieden, welke applicaties deze services moeten gebruiken, welke berichten gebruikt moeten worden voor het uitwisselen van (zaak)gegevens en welke elementen in de berichten mogen en moeten voorkomen.
Uitgangspunt bij het opstellen van de specificatie is het gebruik van generieke StUF ZKN berichten. Bijvoorbeeld voor het creeeren van een zaak wordt gebruik gemaakt van een zakLk01 kennisgeving met mutatiesoort T. Binnen de specificatie stellen we extra eisen aan dit bericht (bovenop StUF ZKN) zoals de verplichting dat bepaalde elementen als Zaakidentificatie, startdatum en Zaaktypecode altijd aanwezig zijn en gevuld met een (volgens RGBZ) geldige waarde. Dit wordt niet afgedwongen door de StUF ZKN schema’s.
Volgens een aantal leden van de StUF Expertgroep zouden de extra eisen die gesteld worden door de specificatie afgedwongen moeten worden d.m.v. aanvullende schema’s. Echter, dit kan alleen indien nieuwe berichttypes gedefinieerd worden zoals een ‘zakLk01_creeerZaak’ . Dit heeft tot gevolg dat in de basis gelijke berichten ontstaan met hetzelfde doel. Applicaties die de Zaak Document services ondersteunen moeten bijvoorbeeld een zakLk01_creeerZaak bericht ontvangen om een zaak te creeeren terwijl applicaties die alleen StUF ZKN ondersteunen een zakLk01 verwachten. De inhoud van beide berichten is gelijk. In het eerste geval wordt er alleen gevalideerd tegen scherpere schema’s.
Vraag is hoe de StUF Expertgroep hier tegen aankijkt? Is het definieren van nieuwe berichttypes wenselijk of zelfs een harde eis bij het opstellen van een koppelvlakspecificatie?
Tweede punt wat ik wil inbrengen: Door de StUF Expertgroep is besloten door het aannemen van erratum 232 dat voor elk asynchroon bericht altijd een sychrone variant gespecificeerd moet worden binnen koppelvlakspecificaties. Het is echter niet scherp beschreven in welke gevallen een ontvangende applicatie de synchrone danwel de asynchrone variant kan verwachten. Dit kan leiden tot interoperabiliteitsproblemen (tenzij we als eis opnemen dat een ontvangende applicatie zowel de synchrone als asynchrone variant van een bericht ondersteunt wat onwenselijk is)
Ik wil binnen de specificatie exact voorschrijven welke berichten verstuurd en ontvangen moeten worden in bepaalde situaties. Daarom mijn vraag aan de Expertgroep: in welke situaties gebruik ik een synchrone variant van een bericht en in welke situaties de asynchrone variant?
Bij een koppelvlakspecificatie op basis van een WSDL en XSD's zou het streven moeten zijn om deze WSDL en XSD's zo te maken dat ze de interface van het koppelvlak 'volledig' beschrijven. De WSDL zou in principe voldoende moeten zijn om te achterhalen hoe de interface precies werkt. Oftwel als een atribuut required is dan is het ook required in de XSD, wanneer een attribuut vaste waardes heeft dan is het een enumeratie in de XSD enz. En indien nodig, en eigenlijk ook wel wenselijk, bevatten de WSDL en XSD's ook documentatie t.a.v. de betekenis van atributen en de werking van methodes. Kort samengevat moet de WSDL de interface volledig 'dicht timmeren' waarmee ik bedoel dat de WSDL geen ruimte laat voor interpretatie.
In mijn ogen is het definieren van nieuwe berichttypes een harde eis bij het opstellen van een koppelvlakspecificatie
Ten aanzien van synchroon en asynchroon. In vraag/antwoord situaties, dus bij het opvragen van informatie, is asynchrone bericht verwerking niet echt zinvol. Een applicatie stelt een vraag en wacht vervolgens op het antwoord. Wanneer dat antwoord niet komt heeft dat gevolgen voor de verdere werking. In geval van het verzenden van een mutatie is het vaak niet zinvol om perse te moeten wachten op een antwoord. Oftewel er zijn situaties waarbij synchrone communicatie zinvol is en situaties waarbij asynchrone situatie zinvol is. Wat toepasselijk is hangt af van de situatie. Het lijkt me daarom niet perse nodig om voor elke situatie zowel synchroon als asynchroon te ondersteunen.
Het lijkt mij niet zinvol om twee verschillende services te hebben, een zaklk01 volgens de stuf-standaarden en een zaklk01_creeerzaak die exact hetzelfde doet. Dit maakt de ontwikkeling, het beheer en de uitleg naar aansluitende partijen niet eenvoudig. Ik ben voorstander van het gebruik van de StUF-Zaken standaard zodat ook onderhoud en beheer van deze specifieke berichten niet gedaan hoeft te worden, maar de patchrondes van stuf-zaken volgen.
Alternatief is om de iets strictere eisen van de zaak-documentservices te verwerken in de volgende patch van StUF-Zaken. iedereen die dan op de laatste patch van StUF-Zaken zit, voldoet daarmee ook meteen aan de zaak-document services.
Daarnaast vind ik het een goed idee om naast de ZakLk01 berichten ook de ZakLk02 berichten te ondersteunen, zodat de zaakserviceconsumer een keuze heeft of zij synchroon of asynchroon willen werken.
Waarom zou dit onwenselijk zijn?
Ik ben het eens met Rene. Voor een service provider zou het niet veel moeten uitmaken of er een synchroon of een asynchroon bericht verwerkt moet worden. Tegenover deze geringe extra inspanning staat wel 2 voordelen.
Het lijkt mij een goed idee de extra eisen die in deze specificaties worden gesteld te vertalen naar striktere schema's. Het lijkt mij echter niet nodig en ook zeer ongewenst hiervoor de rootnodes van de berichten aan te passen omdat dit de interoperabiliteit niet ten goede komt. Service consumers zullen dan immers beide standaarden moeten ondersteunen. Indien de berichtypes niet worden gewijzigd, kunnen zij volstaan met ondersteuning van de meest strikte standaard.
De keuze tussen synchroon en asynchroon verwerken hangt niet alleen af van de bereidheid van de consumer op een antwoord te wachten. Waar asynchrone communicatie wordt ingezet is dat met name ook omdat de provider niet in staat is het bericht direct (en binnen de ingestelde timeout van de consumer) te verwerken. Ik meen dat om die reden eigenlijk al de regel bestaat vraag/antwoordberichten synchroon worden gecommuniceerd en kennisgevingen asynchroon. Dat lijkt mij een goed uitgangspunt.
@andy: Ik snap je redenatie en ik zie ook zeker de voordelen van zoveel mogelijk ‘dichtgetimmerde’ WSDL/XSD’s. Echter, dit komt de interoperabliteit niet ten goede. In ieder geval zolang er applicaties zijn die niet aan de Zaak en document services voldoen maar wel aan StUF ZKN.
V.w.b. synchroon/asynchroon, eens. Ik wil echter wel voorkomen dat we straks applicaties hebben die alleen de synchrone varianten ondersteunen of alleen de asynchrone varianten. Daarom zou ik willen voorstellen: applicaties ondersteunen iig asynchroon. Een leverancier mag synchrone varianten ondersteunen maar hiervoor is geen verplichting vanuit de Zaak- en Document services.
@Rene: Ook in geval van specifieke berichttypes (zakLk01_creeerZaak) worden de patchrondes van StUF ZKN gevolgd. De nieuwe berichttypes worden namelijk als berichtcatalogus onder StUF ZKN gehangen. Dit neemt niet weg dat meer berichttypes ook zorgen voor meer beheerlast.
Je alternatief om de eisen op te nemen in de algemene StUF ZKN schema’s lijkt me onhaalbaar aangezien de berichten in meerdere contexten gebruikt moeten kunnen worden waarin telkens andere eisen gelden.
Mbt synchroon/asynchroon: onwenselijk omdat we dan serviceproviders verplichten om beide te ondersteunen wat in veel gevallen onnodig is.
@Han: “Voor een service provider zou het niet veel moeten uitmaken of er een synchroon of een asynchroon bericht verwerkt moet worden” Ik heb daar geen zicht op. Indien leveranciers aangeven dat het een zeer geringe inspanning is dan zouden we dit als extra eis kunnen opnemen. Hoe zien andere leveranciers dit?
@Roel: “ Service consumers zullen dan immers beide standaarden moeten ondersteunen”; Ze moeten idd beide berichttypes ondersteunen (niet standaarden) indien de service consumer met meerdere applicaties communiceert die niet allemaal aan de Zaak- Document services voldoen.
“Indien de berichtypes niet worden gewijzigd, kunnen zij volstaan met ondersteuning van de meest strikte standaard.” Eens. Dat was precies het idee achter deze specificatie en mijn argument om gebruik te maken van de algemente StUF ZKN berichttypes.
Mbt synchroon/asynchroon: synchroon voor V/A en asynchroon voor kennisgeving is zoals het nu is beschreven in de specificatie. Zie ook reactie van Han waarom wellicht a,- als syncroon ondersteund zou moeten worden.
Het lijkt ons (PinkRoccade) wenselijk om de restricties die de zaak- en documentservices met zich meebrengen te specificeren in een nieuwe versie van het sectormodel ZKN (ZKN03.20?). Tot de tijd dat deze nieuwe versie beschikbaar is kunnen de bestaande koppelvlakken, gebaseerd op ZKN03.10, door de leveranciers
scherper gedefinieerd worden door het opstellen van aanvullende specificaties.
Verder moet het volgens PinkRoccade geen algemene regel worden dat ieder bericht zowel asynchroon als synchroon aangeboden moet kunnen worden. Het ondersteunen van synchrone services is alleen gewenst als er een functionele reden voor is.
Wij als Roxit hebben ook absoluut de voorkeur om op basis van bestaande StUF ZKN0310 xsd's te blijven werken, naast alle genoemde redenen van interoperabiliteit, ontwikkel inspanning, onderhoud, etc, om de volgende reden: in onze beleving is de StUF ZKN standaard bedoeld om juist de communicatie van document en hun relatie naar zaken te faciliteren (en daarmee de functionaliteit in de ZKN-DMS standaard). Als dit er niet goed mee kan, waarom zou je de standaard niet aanpassen?
Wat betreft synchroon of asynchrone berichten: de StUF standaard beschrijft al lange tijd beide bericht-typen, zonder voorkeur.
De gewenste functionaliteit van synchrone berichten voor dit koppelvlak is haast vanzelfsprekend: het is de standaard in alle bestaande DMS koppelingen, heeft dus bewezen goed te werken en werkt al zo in alle Consumer apps. Het is juist uitzondering dat deze nieuwe standaard sowieso de mogelijkheid beschrijft om asynchrone berichten te kunnen gebruiken in een DMS koppelvlak. Het is in onze beleving dus ongewenst om asynchroon te werken binnen dit koppelvlak: het vereist allerlei technische ingewikkelde constructies aan zowel de verzendende als ontvangende kant. Zou asynchroon de standaard zijn, dan verplicht je elke Consumer applicatie die een zaakdocument in het DMS wil opslaan, in het objectmodel/opslagniveau op te nemen dat een object verstuurd is en er asynchrone bevestiging verwacht wordt. Ook verplicht je hiermee een luisterende webservice voor het uberhaupt kunnen ontvangen van asynchrone bevestigings berichten. De impact is vele malen groter voor alle consumer applicaties (versus een paar zaaksystemen die synchrone communicatie moeten ondersteunen), dan wanneer synchrone berichten gebruikt worden, en de noodzaak hiervan is lastig te verklaren, juist omdat synchrone berichten zich inmiddels wel bewezen hebben.
In de bijeenkomst van de werkgroep dd 11 februari 2014 hebben we vastgesteld dat deze discussie nog niet afgerond was in concrete besluiten. Op basis van het bovenstaande stel ik vast dat, heel beknopt, een meerderheid van deelnemers vindt dat: - het stricter maken van de toepassing van generieke berichten de voorkeur geniet, en waar nodig zaken opgelost moeten worden in (een nieuwe versie van) de generieke berichten van StUF ZKN. - de meningen over synchroon en asynchroon verdeeld zijn en dat we dit in de werkgroep moeten bespreken. Beide zaken kunnen alleen in een major release goed aangepakt worden, ongeacht de uitkomst, maar het aanscherpen van de toepassing van bestaande berichten zal zeker in de tussenliggende versies rondom de patch releases opgepakt kunnen worden. Met dat uitgangspunt in gedachten denk ik dat we de discussie in een volgende werkgroep bijeenkomst moeten voeren met het oog op de volgende major release van ZS-DMS (conform afspraak in werkgroep jaarlijks rondom de 1 oktober release van StUF ZKN). Wat vindt iedereen hiervan: eens/oneens?
Eens, discussie voeren in volgende overleg met oog op de volgende major release.