Beste mensen,
In de expertgroep is aan de orde geweest dat het wenselijk is om ook documenten (binaire informatie) te kunnen meesturen in/bij een StUF-bericht. Ik wil graag inventariseren hoe de verschillende leveranciers hiertegenover staan.
Om jullie gedachten hierover te vormen kan ik jullie de volgende link aanraden:
http://www.webservices.org/weblog/website_editor/becoming_attached_to_soap
Op grond van deze link lijkt een keuze voor MTOM en XOP voor de hand te liggen. Dit wordt ondersteund door het feit dat bijvoorbeeld Axis2 dit ondersteunt, zie bijv.
http://ws.apache.org/axis2/1_0/mtom-guide.html
http://www.it-eye.nl/weblog/2006/12/13/javapolis-axis-2/
evenals de .Net omgeving.
Graag jullie mening of MTOM en XOP het te volgen pad is voor StUF. Mochten jullie meer voelen voor alternatieven, dan hoor ik dat natuurlijk ook graag.
Met vriendelijke groet,
Maarten
Maarten,
Het toepassen van XOP ligt inderdaad voor de hand met de huidige stand van technologie.
Het gebruik van base64 encoding is tot op heden altijd best een pragmatische oplossing geweest, maar ik denk dat deze manier niet houdbaar is als we straks een ZKN03.10 sectormodel krijgen waar documenten een belangrijke rol in spelen.
Er is alleen een hele grote MAAR. SOAP 1.1, file en ebMS bindings ondersteunen dit niet. Voor deze protocolbindings moeten dus andere afspraken gemaakt worden.
Het zou al kunnen helpen om StUF3.01 niet meer aan SOAP1.1 te binden. Voor file en ebMS moet dan nog wel een oplossing geboden worden (file:base64, ebMS:SOAP with attachments?).
Om het nog complexer te maken, stel we moeten via de OSB attachments uitwisselen. Kan de OSB Gateway de brug slaan tussen WUS lite/JMS intern en ebMS/WUS extern?
Overigens staat in de OSB ebMS Best Practise het volgende:
Hier maak ik uit op dat de WUS en ebMS binding van de OSB beiden gebaseerd worden op base64!
Groet,
Rolf
LS,
In hoeverre wordt het door jullie acceptabel geacht om bijlagen in StUF berichten voorlopig op te nemen in de vorm van (standaard of extra) elementen tót het moment dat er voor alle bindingen een goede (volledige) oplossing op transportprotocol nivo is ?
Groet, John Rooijakkers
LS,
bijgaand (zie attachment) een forum-discussie uit het archief over het vezenden van binaire bestanden (met StUF). Doe er je voordeel mee.
Mvg,
Henri
Hallo Rolf en anderen,
De OSB heeft inmiddels de koppelvlakstandaard voor versie 2.0 gepubliceerd (http://www.overheidsservicebus.nl/koppelvlakken/).
Onderdeel hiervan is een specificatie voor het opnemen van bijlagen buiten het XML-bericht zelf. De OSB heeft hiermee een keuze gemaakt voor zowel WUS als ebMS.
Voor WUS is de keuze gevallen op MTOM/xop. Je opmerking over het niet compatibel zijn van MTOM en SOAP1.1 snap ik niet. De OSB ziet hier in elk geval geen probleem.
Het lijkt me goed om als StUF aan te sluiten bij de keuzen van de OSB. Een extra aandachtspunt voor StUF is mogelijk nog wel het definiëren van wat extra metagegevens bij een digitale bijlage, als bijvoorbeeld de filenaam e.d. Hier moeten we maar eens over nadenken. Het lijkt zinnig om een en ander te definiëren in een StUF-complexType met elementen voor de metagegevens van de bijlage en de elementen tbv MTOM/xop.
Maarten
Het aansluiten op/overnemen van OSB koppelvlakdefinities op dit vlak is een prima keuze!
Dan zijn de SOAP en ebMS bindings ingevuld. Blijft nog de bestandsuitwisseling over. Daar moet dan nog iets voor besloten worden worden. Base64 zou hier m.i. een goed alternatief voor zijn.
Rolf
Voor uitwisseling van bestanden wordt binnen het Technisch Overleg Digikoppeling gewerkt aan standaardaardisatie van 'grote berichten'. Dit gaat een soort van 'out-of-band' overdracht bieden waarbij het grote stuk uit het bericht via een apart kanaal als bestand overgedragen wordt. Het totale bericht blijft hierbij aan de betrouwbaarheid en veiligheidsniveaus van de huidige Digikoppeling voldoen.
Interessant! Is er al een working draft waar we naar kunnen kijken?
Ondersteunt de gateway straks ook 'grote berichten'?
Het uitgangspunt van de melding is dat SOAP with Attachment (SwA) wordt ondersteund door Dotnet. Dit is echter zeker niet het geval! Ik denk dat Maarten op het verkeerde been is gebracht doordat MTOM wel wordt ondersteund.
Microsoft adverteert niet met wat ze niet ondersteunen, maar het gebrek aan ondersteuning van SwA is op vele forum's terug te vinden (bijv http://forums.asp.net/t/1226872.aspx/1)
Aansluitend bij bovenstaande opmerking van Tom Peelen zien we veel meer in het via een apart kanaal toevoegen van binaire data. Hiermee is het ook mogelijk te maken dat bij een onderbreking verder wordt gegaan vanaf het vorige punt, wat met WsA sowieso niet mogelijk is. Ook zien wij bij deze standaard graag opgenomen dat na het verzenden de SHA1 hash wordt teruggestuurd/opvraagbaar is, zodat er een laatste controle mogelijk is of alles goed is gegaan.
Hallo Wouter,
Ik snap je verwijzing naar SOAP with attachments niet zo goed. Er in StUF gekozen voor het gebruik van MTOM en dat is bij mijn weten een alternatief voor SOAP with attachments of ben ik hier helemaal abuis.
Maarten, de info over SwA en DotNet geef ik als reactie op: 'of MTOM en XOP het te volgen pad is voor StUF'. Ik las het alsof de afweging tussen MTOM en SwA (wat dus idd een alternatief is) nog een keuze moment zou krijgen en de SwA info is bedoeld als input voor deze keuze.
Er is nu voor MTOM gekozen dus dat is, wat ons als leverancier van een DotNet product betreft, prima.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0114.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
In november 2009 is reeds gesproken over de oplossing van dit probleem. Uiteindelijk is het in patch 3 meegenomen. Toendertijd is verzuimd dit onderhoudsverzoek om te zetten naar een erratum. Bij deze dus alsnog. Het is terug te vinden als ERR0385.