It's by definition of WSI basic profile 1.1 and some more specs. of document-literal webservices. On the wire there is only element ... no operation, no message .. only element (one defined in message). That's why it has to be unique, otherwise it's not possible to distinguish between them.
best regards jano "Manolescu, Radu \(IT\)" <[EMAIL PROTECTED]> 06/10/2008 19:17 Bitte antworten an [email protected] An <[email protected]> Kopie Thema WSDLToJava Error : Non unique body parts! In a port, operations must have unique operation signaure [Virus checked] We are receiving an error that we do not quite understand while trying to generate a Java client from a multi-operation WSDL file. The error message is: [java] WSDLToJava Error : Non unique body parts! In a port, operations must have unique operation signaure on the wire for successful dispatch. In port {http://www.example.org/wsdl14/}wsdl14SOAP, Operations "{http://www.example.org/wsdl14/}Operation35"; and "{http://www.example.org/wsdl14/}Operation36"; have the same request body block {http://www.example.org/wsdl14/}Operation35 The WSDL below is valid, and we can generate Java code from it using "Apache CXF (incubator) 2.1-incubator-SNAPSHOT". The WSDL contains two operations (Operation35,Operation36), which have input and output messages in the signature. As long as these input/output parameter messages are unique (by name), everything is fine. The "non unique body parts" error occurs if we try to say that both operations use the same messages as input and output. (See location marked "s/36/35/" below) The same thing happens if we try to say that the two request messages contain the same element (See location marked "s/73/71/" below). Note that all the elements defined in this schema (Element71..Element74) have identical structure, so we could use only one such element if it were not for the requirement to have unique names. Why does this error occur? In most programming languages, a method is uniquely defined by its signature (name+parameters), so the parameters can be the same as long as the method name is different. Is this requirement for uniqueness contained in the WSDL (or SOAP) specification, or was it introduced by the CXF implementation? How can we get around this, i.e. how can we have one port with two operations which take the same structures for input? Operation1(Type1 input, Type2 output) Operation2(Type1 input, Type2 output) <?xml version="1.0" encoding="UTF-8" standalone="no"?> <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:tns="http://www.example.org/wsdl13/"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; name="wsdl13" targetNamespace="http://www.example.org/wsdl13/";> <wsdl:types> <xsd:schema targetNamespace="http://www.example.org/wsdl13/";> <xsd:element name="Element71"> <xsd:complexType> <xsd:sequence> <xsd:element name="one" type="xsd:string"/> <xsd:element name="two" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Element72"> <xsd:complexType> <xsd:sequence> <xsd:element name="one" type="xsd:string"/> <xsd:element name="two" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Element73"> <xsd:complexType> <xsd:sequence> <xsd:element name="one" type="xsd:string"/> <xsd:element name="two" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Element74"> <xsd:complexType> <xsd:sequence> <xsd:element name="one" type="xsd:string"/> <xsd:element name="two" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl:types> <wsdl:message name="Operation35Request"> <wsdl:part name="parameters" element="tns:Element71"/> </wsdl:message> <wsdl:message name="Operation35Response"> <wsdl:part name="parameters" element="tns:Element72"/> </wsdl:message> <wsdl:message name="Operation36Request"> <wsdl:part name="parameters" element="tns:Element73"></wsdl:part> <!-- s/73/71/ --> </wsdl:message> <wsdl:message name="Operation36Response"> <wsdl:part name="parameters" element="tns:Element74"></wsdl:part> <!-- s/74/72/ --> </wsdl:message> <wsdl:portType name="wsdl13"> <wsdl:operation name="Operation35"> <wsdl:input message="tns:Operation35Request"/> <wsdl:output message="tns:Operation35Response"/> </wsdl:operation> <wsdl:operation name="Operation36"> <wsdl:input message="tns:Operation36Request"></wsdl:input> <!-- s/36/35/ --> <wsdl:output message="tns:Operation36Response"></wsdl:output> <!-- s/36/35/ --> </wsdl:operation> </wsdl:portType> <wsdl:binding name="wsdl13SOAP" type="tns:wsdl13"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="Operation35"> <soap:operation soapAction="http://www.example.org/wsdl13/Operation35"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="Operation36"> <soap:operation soapAction="http://www.example.org/wsdl13/Operation36"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="wsdl13"> <wsdl:port binding="tns:wsdl13SOAP" name="wsdl13SOAP"> <soap:address location="http://www.example.org/"/> </wsdl:port> </wsdl:service> </wsdl:definitions> [java] WSDLToJava Error : Non unique body parts! In a port, operations must have unique operation signaure on the wire for successful dispatch. In port {http://www.example.org/wsdl14/}wsdl14SOAP, Operations "{http://www.example.org/wsdl14/}Operation35"; and "{http://www.example.org/wsdl14/}Operation36"; have the same request body block {http://www.example.org/wsdl14/}Operation35 Radu Manolescu Morgan Stanley | Technology 2000 Westchester Ave, 1st Floor | Purchase, NY 10577 Phone: +1 914 225-5871 Mobile: +1 203 648-6964 [EMAIL PROTECTED] -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
