WS-I apparently allows it:
R2210 If a document-literal binding in a DESCRIPTION does not specify the |parts| attribute on a |soapbind:body| element, the corresponding abstract |wsdl:message| MUST define zero or one |wsdl:part|s.
R2202 A |wsdl:binding| in a DESCRIPTION MAY contain |soapbind:body| element(s) that specify that zero parts form the |soap:Body|.
This surprises me, because I think dispatching a request with an empty body would be problematic. You'd have to use null or an empty string as the "key" to determine which method to dispatch to. This could be made to work, but only with the additional stipulation that only one such empty-body operation could be defined per service in the WSDL - a stipulation that WS-I neglected to make. So I can see why Axis chose not to allow empty body requests, and I think Apollo's wsdl2java and provider ought to follow suit.
Michael, does this sound reasonable to you? You'll notice that using an empty complex type as the input part for parameterless operations, as Sam suggested, is commonly done throughout WSRF and other spec WSDLs.
Ian
That's really a axis problem. While wsdl allows you to have a message with no parts Axis requires at least one body element (not sure what/if WS-I says here). So for the below the workaround is:
<xs:element name="OrderCartRequest"> <xs:complexType/> </xs:element>
and
<message name="OrderCartRequest">
<part name="Order" element="tns:OrderCartRequest"/>
</message>
/Sam
On Wed, 2005-02-16 at 16:32 +0100, Michael Marks wrote:
Hello Sam,
I meant to say, if I choose to generate my Service with WSDL2Java from
Apollo, no messages with zero elements are allowed at the moment.
If the Service-Description (wsdl) defines messages with zero elements,
the generation with the apollo-Wsdl2Java fails and no Service-Classes
are generated. In my case the "OrderCartRequest" in the wsdl listed
below.
<types>
<xs:schema ...>
...
<xs:element name="OrderCart_IgnoredInput" type="xs:boolean"/>
<xs:element name="OrderCart_Boolean" type="xs:boolean"/>
...
</xs:schema>
</types>
<message name="OrderCartRequest"/>
<message name="OrderCartResponse">
<part name="Ordered" element="tns:OrderCart_Boolean"/>
</message>
<portType name="ShoppingCartPortType"
wsrp:ResourceProperties="tns:ResourceProperties">
...
<operation name="OrderCart">
<input message="tns:OrderCartRequest"/>
<output message="tns:OrderCartResponse"/>
</operation>
</portType>
<binding name="ShoppingCartSoapHttpBinding"
type="tns:ShoppingCartPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="OrderCart">
<soap:operation style="document"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="ShoppingCartService">
<port name="ShoppingCart" binding="tns:ShoppingCartSoapHttpBinding">
<soap:address location=
"http://localhost:8080/wsrf/services/ShoppingCart"; />
</port>
</service>
</definitions>
(I tried it with ant using "org.apache.ws.resource.tool.Wsdl2JavaTask".)
It seems there is no way to generate a Service that handles messages
with zero arguments at this time.
My second try was to generate a correct Apollo-Service and adapt it to my needs. I generated an Apollo-Service with valid message-definitions and changed the generated Service-Classes. Three steps were necessary:
1. I corrected the service description by adding one message element to the OrderCartRequest-Message and generated the Service-Classes.
For service-generation with apollo's Wsdl2Java I uncommented the
part-element of the message below and everything works fine.
<message name="OrderCartRequest">
<part name="Input" element="tns:OrderCart_IgnoredInput"/>
</message>
2. I changed the Operation-Signatures in the interface- and the implementation-classes by removing the parameter of the OrderCart-Operation.
3. I extended the methodNameMap in the generated AbstractService-Class by inserting a mapping for the OrderCart-Method as Qname.
The message with zero elements was interpreted correctly and the
serviceMethodName is found by the methodNameMap-Lookup, but after that
the method will be searched by Reflection to invocate it.
Unfortnally the search-implementation in
org.apache.ws.resource.handler.ResourceHandler includes a check wether
a found method has excatly one parameter. If it has not, the found
method is treated as the wrong choise. The result is a
method-not-found-Fault.
To me it seems like operations with zero parameters are not possible
at the moment and that’s, what Ian said in his last mail.
/Michael
-----Ursprüngliche Nachricht-----
Von: Samuel Meder [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 15. Februar 2005 15:16
An: apollo-dev
Betreff: Re: Questions relating to Service-Generation andwsdl-interpretation
On Tue, 2005-02-15 at 10:31 +0100, Michael Marks wrote:
Hello Ian,
thank you very much for answering so detailed to my
WS-RF-newbie-questions.
It clarifies a lot
the use of document-literal message-style in the WS-RF and Web
Services in
general.
Regarding question #1: I believe, the use of inputs with zero parts
is
useful especially in
case of WS-RF. As the WS-Resource we talk to is identified by
wsa:ReferenceProperties(until
yet, we'll see what the RefProp-Removal-Discussion will bring), we
can send
messages to a
service using this identified WS-Resource without the need of any
other
parameter.
An example could be:
An E-Shop provides a ShoppingCart as WS-Resource. The ShoppingCart
can be
created,
modified(adding,deleting articles), destroyed and finally ordered.
Asuming
the
creation-operation of a ShoppingCart-Resource takes the
customer-identity as
a parameter and
the stateful resource is bound to the identified customer after
creation -
say by a
ResourceProperty "eshop:customerID". There would be no need for
providing
any other information
to the ShoppingCart.order() - operation. (I'm not sure, if this is a
real-world example, as
normally a ShoppingCart is created without identifying the customer.
The
binding to the
ordering customer is m,ost often done at ordertime (see amazon).)
But I
believe, it's a
question of modeling the underlying workflow.
At the moment, a developer has no chance to model the example
described
above with the WS-RF.
I'm not quite sure what makes you say that, can you elaborate?
/Sam
--
Sam Meder <[EMAIL PROTECTED]>
The Globus Alliance - University of Chicago
630-252-1752
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
