axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil McCarthy <p...@dessicated.org>
Subject WSDL for no-arg operation in document style
Date Fri, 27 Aug 2004 11:10:23 GMT

Hello,

I'm trying to figure out what the correct way is to represent a zero-parameter
operation in a document-style webservice (for instance, a getCartContents() call
to a stateful e-commerce webservice). I haven't found anything explicit in the
docs, or in the list archives, though there is some special-case code in
providers.java.RPCProvider that suggests it's a legitimate thing to do:

    // special case code for a document style operation with no
    // arguments (which is a strange thing to have, but whatever)

Seems to me that the client should send an empty soap:Body, since any content
would be a document to be passed as a parameter to the method by Axis. That's
exactly what the special-case code in RPCProvider handles - a null body.

The WSDL to represent this could be:

<wsdl:operation name="getCart"> 
    <wsdl:input message="impl:getCartRequest" /> 
    <wsdl:output message="impl:getCartResponse"/> 
</wsdl:operation> 
 
<wsdl:message name="getCartRequest"> 
</wsdl:message> 
 
(A request-response operation requires an input element, but a message 
has minOccurs="0" for part, so can be empty).

I'm using the .NET SDK's wsdl.exe tool to create client stubs, and this WSDL
does indeed produce a nice zero-argument getCart() method in the generated code.

However, there's a slight problem when a request with an empty body is sent to Axis:

Request:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body></soap:Body>
</soap:Envelope>

Response:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
 <soapenv:Body>
  <getCartReturn xmlns=""><stuffInTheCart.../></getCartReturn>
 </soapenv:Body>
</soapenv:Envelope>

The problem here is that the namespace on the getCartReturn is "", so the client
doesn't see the {http://foobar/}getCartReturn it expects.

(Incidentally, RPCProvider routes this call by looking up the first zero-arg
method it can find on the service, and calling it - a problem if there's more
than one. The SOAPAction header gets ignored).

Looking for a workaround, I tried sending an empty getCart request to Axis (no
code changes), and this gets a saner response:

Request:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
  <getCart xmlns="http://foobar/"></getCart>
  </soap:Body>
</soap:Envelope>

Response:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
 <soapenv:Body>
  <getCartReturn xmlns="http://foobar/"><stuffInTheCart.../></getCartReturn>
 </soapenv:Body>
</soapenv:Envelope>

So, doing it this way the namespace on the returned document is set correctly.

But ... what's the WSDL for the operation now?

<wsdl:message name="getCartRequest">
    <wsdl:part element="impl:getCart" name="in0"/>
</wsdl:message>

There are two suggestions I've seen for implementing this "void" getCart element:

1:
<element name="getCart" type="xsd:anyType" nillable="true"/>

If I go with the first approach, my problem is that the generated client stub
for this method expects to take an single, nullable parameter. So I have to call
it from client code with getCart(null) - a little clumsy,

2:
<element name="getCart" type="impl:voidType"/>
<complexType name="voidType>
    <complexContent>
        <restriction base="anyType"/>
    </complexContent>
</complexType>

Now wsdl.exe creates an extra, empty class definition called voidType, and the
getCart method signature requires a single parameter of type voidType.

IMHO, wdsl.exe is not at fault here - it seems to be doing exactly the right
thing in both cases. What I really want to be able to do is send an empty Body
and have Axis behave properly, not use nasty workarounds like this.

So, does anyone know how to send an empty soap:Body to Axis, and have it return
a response in the correct namespace?  I suspect I'm trying to do something a bit
weird here, and the spec/ implementation is a bit fuzzy. 

Cheers,
Phil

Mime
View raw message