I'm not so sure this is a WSDL-related problem: since both client &
server are generated from the same WSDL, they should be able to
understand the soap messages exchanged between each other.
So, is the SOAP-Apache/Axis implementation wrong, or the JWSDP one?
By carefully reading the SOAP 1.2 Specifications, Part II, Paragraph
4.2.2: SOAP Body RPC Response [1], this is what it says about RPC
webservices responses:
"A non-void return value is represented as follows:
1.There MUST be an outbound edge with a local name of *result* and a
namespace name of "
http://www.w3.org/2003/05/soap-rpc" which terminates
in a terminal node"
And this how the Apache-SOAP generated server acts: if the WSDL defines
an operation "methodName" which returns an element "responseElement",
then the server "wraps" this element in another element named "result",
as the above specification says. So the response will be something like
this:
<SOAP-ENV:Body>
<ns0:methodName>
<return>
<responseElement xsi:type="xsd:string"/>
</return>
</ns1:methodName>
</SOAP-ENV:Body>
But the JWSDP-generated client refuses to accpet this SOAP: is doesn't
accept the *return* element but it expects _only_ *responseElement*.
Of course the WSDL does not define the *result* element, but AFAIU this
element MUST be added by the RPC-service to wrap return elements, and
the client MUST understand it... am I wrong?
If not, is the Axis implementaion wrong or the JWSDP one?
[1]
http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#rpcsoapbdy
Anne Thomas Manes wrote:
> I suggest you ask this question on the Apache SOAP list. The problem
> is that the WSDL for your service doesn't match the response supplied
> by the service. If you edit the WSDL so that it does, in fact,
> accurately describe the response message supplied by the service, then
> other clients will have not problem communicating with the service.
>
> Anne
>
> On 4/15/05, Alessio Cervellin <alessio.cervellin_at_sun-cs-italy.com> wrote:
>
>>this is the issue:
>>On the server side there's a webservice developed *using Apache SOAP*, and it exposes a WSDL.
>>A client has been then generated starting from this WSDL *using JWSDP 1.4*.
>>This client sends correctly the request to the service, but the soap message received as response can't be parsed because the response element in the soap body (which is fine according to the schema in the wsdl) is enclosed within another tag named "return".
>>
>>Example of the response:
>>
>><SOAP-ENV:Body>
>> <ns0:methodName>
>> <return>
>> <responseElement xsi:type="xsd:string"/>
>> </return>
>> </ns1:methodName>
>></SOAP-ENV:Body>
>>
>>The client complains it finds the element "return" instead of the element "responseElement".
>>
>>Since the element "return" is not defined anywhere in the wsdl, why is it being added? By "googling", I noticed this behaviour is typical of Apache SOAP / Axis responses, whilst by generating the server-side with JWSDP - starting from the same wsdl - the element "return" is not added in the soap responses.
>>
>>So, given a WSDL, a JWSDP-generated client can't talk to an ApacheSOAP-generated server... I wonder: is there any option to pass to wscompile so that the generated client can accept this "return" element?
>>
>>PS: a client generated upon the same wsdl but with Axis works fine.