This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Unfortunately your "desired" SOAP request does not comply with the rules for interoperable RPC/literal mode of messaging as specified by WS-I Basic 1.0a which clarifies some ambiguities in SOAP 1.1/ WSDL 1.1.
For rpc-literal SOAP messages, WSDL 1.1 is not clear what namespace, if any, the accessor elements for parameters and return value are a part of. Different implementations make different choices, leading to interoperability problems.
R2735 A MESSAGE described with an rpc-literal binding MUST place the part accessor elements for parameters and return value in no namespace.
Settling on one alternative is crucial to achieving interoperability. The Profile places the part accessor elements in no namespace as doing so is simple, covers all cases, and does not lead to logical inconsistency.
So Axis is in effect enforcing this rule by undeclaring the default namespace to ensure that the part element is in no namespace - which is the correct action to take.
You get more control of the content of the SOAP body by going with the Document/literal mode of messaging. [ November 06, 2007: Message edited by: Peer Reynders ]
Joined: Aug 19, 2005
First convert the WSDL to Document/literal
This leads to the followng Java Interface
and the following Request/Response pairs:
As you will notice the elements corresponding to the operation name have disappeared - this is normal in the document/literal mode of messaging. You are submitting a document- it is up to the service to decide what to do with the document based on its type or content - there is no concept of an operation.