Note that the SOAP 1.2 spec doesn't apply here, because Apache SOAP
and JWSDP don't support SOAP 1.2. They support SOAP 1.1.
A better reference is the WS-I Basic Profile, although it defines
behavior for RPC/literal, but not for RPC/encoded. JWSDP follows the
guidelines prescribed by the WS-I Basic Profile (although Apache SOAP
does not).
Unfortunately, the SOAP 1.1 and WSDL 1.1 specs are ambiguous and
underspecified in many areas. The proper format of an RPC response
message is one such area.
According to the WS-I BP:
<wsibpExcerpt>
4.7.19 Response Wrappers
WSDL 1.1 Section 3.5 could be interpreted to mean the RPC response
wrapper element must be named identical to the name of the
wsdl:operation.
R2729 An ENVELOPE described with an rpc-literal binding that is a
response MUST have a wrapper element whose name is the corresponding
wsdl:operation name suffixed with the string "Response".
</wsibpExcerpt>
and
<wsibpExcerpt>
4.7.20 Part Accessors
For rpc-literal envelopes, 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 An ENVELOPE described with an rpc-literal binding MUST place the
part accessor elements for parameters and return value in no
namespace.
R2755 The part accessor elements in a MESSAGE described with an
rpc-literal binding MUST have a local name of the same value as the
name attribute of the corresponding wsdl:part element.
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.
</wsibpExcerpt>
So, given the following WSDL type and message descriptions:
(assume elementFormDefault="qualified")
<xsd:complexType name="response">
<xsd:sequence>
<xsd:element name="responseElement" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<wsdl:message name="msgOut">
<wsdl:part name="return" type="ns1:response"/>
</wsdl:message>
The response message should be formatted thus:
<env:Body>
<ns0:methodNameResponse>
<return>
<ns1:responseElement xsi:type="xsd:string" />
</return>
</ns0:methodNameResponse>
</env:Body>
Note, though, that there is no requirement that the accessor element
be called "return". This accessor element is generated from the
<wsdl:part> name, which is of type ns1:response, which is defined as a
sequence containing the <ns1:responseElement>. The following is
equally valid:
Given the following WSDL type and message descriptions:
(assume elementFormDefault="qualified")
<xsd:complexType name="response">
<xsd:sequence>
<xsd:element name="bar" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<wsdl:message name="msgOut">
<wsdl:part name="foo" type="ns1:response"/>
</wsdl:message>
The response message should be formatted thus:
<env:Body>
<ns0:methodNameResponse>
<foo>
<ns1:bar xsi:type="xsd:string" />
</foo>
</ns0:methodNameResponse>
</env:Body>
In other words, the proper format of the response message is
determined by the WSDL. Apache SOAP and Apache Axis always generate
response messages according to their own convention rather than
according to a specified WSDL.
So ... I can't tell you which implementation is working properly until
you show me the WSDL and the SOAP response message. But, if the WSDL
specifies something other than this WSDL message definition:
<wsdl:message name="[message name]">
<wsdl:part name="return" type="[response type]"/>
</wsdl:message>
then you shouldn't have an element called <return> in the response message.
[1]
http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html
Anne
On 4/17/05, Alessio Cervellin <alessio.cervellin_at_sun-cs-italy.com> wrote:
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>