I wonder if the three soap messages above can be consumed by the same flow service implemented with this method.
I have the impression that when I send a message to the flow service example.flow:createOrderWrapper, it must contain a prefix for the definition of the namespace.
Is it true ?
If my assertion is true, the interface contract between the client and the IS must define if messages will come with prefixes or not.
Those messages are not actually the same. Message 1 is usually a default namespace which means everything under troubleticket is qualified with the namespace you have given. In message 2 and 3, only troubleticket belongs to the namespace, everything else is consider a local element and they do not belong to the namespace.
As a general rule, it is considered a best practice to fully qualifly your elements. This would be defined in your XML schema and your WSDL doc. Here is some more detail on namespaces and webMethods - [URL=“wmusers.com”]wmusers.com
That means that there’s an implementation in webMethods to decode a message with default namespace (message 1) and an other implementation to decode a qualified message (message 2 & 3) ?
Well yes and no. A default namespace will act a lot like a fully qualified one. A default namespace like you have defined in message 1 means every local element that doesn’t have a prefix pointing it to some other namespace will belong to the default namespace which means its qualified to that namespace. If you were to put a prefix in your namespace definition and then put that prefix on each element it would be the same as the default namespace. Those messages would be identical, one with the prefix shorthand and one with not. But both still qualified to the namespace.
The same web service in webMethods IS will handle both. Your message 2 and message 3 however are not fully qualified. Only the root node belongs to a namespace, the local elements are unqualified. That is a slightly different implementation in webMethods IS. You will need a wrapper doc in that case.
My recommendation is to always fully qualify your elements. And this really should be driven by the WSDL and XML schemas. It’s a little more painful in webMethods IS to do that because of the way it handles prefixes.
The W3C is working towards a databinding standard to help with a minimal level of interoperability with folks who exchange XML especially with Web Services, here is the link [url]http://www.w3.org/TR/2008/WD-xmlschema-patterns-20080328[/url] . One of the recommendations is qualification of all local elements.
What I mean in my question is : do I change the Webmethod consumer’s implementation if the client change the way it generates the soap request (message n°1 to message n°2). My opinion is yes because when I change the prefix of the request for the example provided by Mark Carlson, the wrapper service (xmlNodeToDocument) doesn’t work anymore.
So, I think that the prefix policy must be “hard-encoded” in this service.
Yes the service provider (not consumer) is slightly different from mess 1 and mess 2 because of the namespace qualification. The client should not however change the way it generates the SOAP message because it is bound to the interface definition (The WSDL) and should comply with that. You service provider implementation should also comply with the WSDL.
If you are going to qualify everything, again the WSDL should tell you this, then prefixes are a requirement within webMethods IS. If not then only the root node or wrapper doc need be qualified, again the WSDL should dictate which way to implement.
