Hello Michael,

I apologize for not getting back to you earlier.

Regarding question #1, the reason we don't allow more than one part within a message is because, in the tradition of the Globus WSRF/WSN impl, we are requiring conformance to the WS-I Basic Profile 1.1 [1], which says the following:

R2204 A document-literal binding in a DESCRIPTION MUST refer, in each of its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the element attribute.

Since a WSRF Web service consists of one "most-derived" portType and a corresponding binding, and all of the parts for the WSRF spec-defined operations are defined using the 'element' attribute, the most-derived binding is necessarily a document-literal binding, which WS-I defines as
"a wsdl:binding element whose child wsdl:operation elements are all document-literal operations."


WS-I also says:

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:parts.

Because our most-derived binding is necessarily a doc-lit binding, the messages it references must contain zero or one parts. So, Apollo's Wsdl2Java should be permitting either zero or one parts (right now, it is only accepting one). I'm not sure what the value of having an input or an output with zero parts would be, but I guess there must be some use case for it.

Regarding question #2, WS-I section 4.7.6 says:

"
The profile defines the "operation signature" to be the fully qualified name of the child element of SOAP body of the SOAP input message described by an operation in a WSDL binding.


In the case of rpc-literal binding, the operation name is used as a wrapper for the part accessors. In the document-literal case, since a wrapper with the operation name is not present, the message signatures must be correctly designed so that they meet this requirement.

An endpoint that supports multiple operations must unambiguously identify the operation being invoked based on the input message that it receives. This is only possible if all the operations specified in the wsdl:binding associated with an endpoint have a unique operation signature.

R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in operation signatures that are different from one another.
"


So Apollo Wsdl2Java should not be allowing two operations that reference the same element for their inputs. However, it should be aborting with an error message instead of silently ignoring the second operation. I will work on fixing this next week.

Hopefully, this makes some sense. Let me know what you think.

Regards,
Ian

[1] http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html

Michael Marks wrote:
Hi,

today I've got two problems concerning wsdl-interpretation during generation
of the Java(-Service-)Classes with the wsdl2JavaTask of apollo.

First Question:

If my wsdl-file contains message-elements with zero or more then one
part-elements, a runtime-exception is thrown by the class OperationInfo,
saying "Wsdl input element should have exactly one part.".
WSDL1.1 specifies the number of part-elements in a message-elements with "*"
meaning zero till unbounded.

If I encapsulate the part-elements in a new element and use this in the
message-declaration, everything works fine.
It seems the implementation differs in that point to the wsdl
1.1-specification. Is that so? Why is that so?

example:
<types>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
targetNamespace="http://bookstore.com/ShoppingCart";
xmlns="http://www.w3.org/2001/XMLSchema";
xmlns:tns="http://bookstore.com/ShoppingCart";
xmlns:wsrl="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceLifetime-1.2-draft-01.xsd";
xmlns:wsbf="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-BaseFaults-1.2-draft-01.xsd";
elementFormDefault="qualified">


<xs:element name="CustomerId" type="xs:string"/> <xs:element name="CustomerIdCreateCart" type="xs:string"/> <xs:element name="CustomerIdOrderCart" type="xs:string"/> <xs:element name="ProductId" type="xs:string"/> <xs:element name="Price" type="xs:int"/> <xs:element name="Quantity" type="xs:int"/> <xs:element name="ArticleOrder">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:ProductId"/> <xs:element ref="tns:Quantity"/> </xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</types>
...


works fine
========= <message name="AddArticleRequest">
<part name="ArticleOrder" element="tns:ArticleOrder"/>
</message>
doesn't work
=============
<message name="AddArticleRequest">
<part name="CustomerID" element="tns:CustomerId"/>
<part name="Quantity" element="tns:Quantity"/>
</message>







Second Question:

If a defined type-element is used in more then one messages for different
operations, only the last operation that uses the element in it's
message-type is generated into the CustomerOperationsPortType.
That means, i can't use defined type-elements more then one time and have to
define equivalent elements with an other, unique name. Why is that so? WSDL 1.1 don't specify such an restriction.


example:

(assuming the same type definitions as in the example for the first
question)

doesn't work
=============
message-definitions:

   <message name="CreateCartRequest">
        <part name="CustomerId" element="tns:CustomerId"/>
   </message>

   <message name="CreateCartResponse">
        <part name="Created" element="xs:boolean"/>
   </message>

...

   <message name="OrderCartRequest">
        <part name="CustomerId" element="tns:CustomerId"/>
   </message>

   <message name="OrderCartResponse">
        <part name="TotalPrice" element="tns:Price"/>
   </message>

operations-definitions:

     <operation name="CreateCart">
         <input message="tns:CreateCartRequest"/>
         <output message="tns:CreateCartResponse"/>
      </operation>

        ...

      <operation name="OrderCart">
         <input message="tns:OrderCartRequest"/>
         <output message="tns:OrderCartResponse"/>
      </operation>

result:

only the createCart-Operation is provided in the generated
MyServiceCustomOperationsPortType.java, the orderCart-Operation is lost.


works fine ============= message-definitions:

   <message name="CreateCartRequest">
        <part name="CustomerId" element="tns:CustomerIdCreateCart"/>
   </message>

   <message name="CreateCartResponse">
        <part name="Created" element="xs:boolean"/>
   </message>

...

   <message name="OrderCartRequest">
        <part name="CustomerId" element="tns:CustomerIdOrderCart"/>
   </message>

   <message name="OrderCartResponse">
        <part name="TotalPrice" element="tns:Price"/>
   </message>

operations-definitions:

     <operation name="CreateCart">
         <input message="tns:CreateCartRequest"/>
         <output message="tns:CreateCartResponse"/>
      </operation>

        ...

      <operation name="OrderCart">
         <input message="tns:OrderCartRequest"/>
         <output message="tns:OrderCartResponse"/>
      </operation>

result:

both operations are provided in the generated
MyServiceCustomOperationsPortType.java


Any ideas?

Thank You
Michael

--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to