I suspect that the key to your question lies in your binding. If we are talking about a SOAP binding, you have two main options: RPC and Document style. If you are attempting to do document style SOAP Web services, the operation that is being invoked is tied to the contents of the SOAP body. In your case, you had two operations that take as input the same payload element regardless of if you created two messages as they both end up with the same element in the body. Document style SOAP services can have one and only one part in each message if you want to be WS-I compliant, that is just the way it works. Furthermore, other specs and implementations may also enforce this restriction. You should not have two operations that take the same input element in a document style SOAP Web service as it will be ambiguous as to which operation to bind the message to on the server. You may be tempted to use RPC style, but this is ill advised as document style is more or less the de facto standard these days. If you need to simulate multiple operations that take the same argument, I would suggest adopting the wrapped document-literal pattern [1].
As far as it working when you add a second parameter, the tooling likely isn't enforcing the single part per operation rule as it is your choice if you want to be WS-I compliant or not; however, the fact that it doesn't complain when both messages contain the same two parts could indicate a bug. This last scenario is speculation on my part as I have not reviewed the code. The above advice should be sufficient to get around the problems you are encountering for now and the tooling should probably be looked at to determine why the rule enforcement changes when you add the second part. [1] http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ -----Original Message----- From: dmichel [mailto:[email protected]] Sent: Wednesday, April 28, 2010 8:57 AM To: [email protected] Subject: "Non unique body parts" error when trying to use same input message for 2 different operations Hi All, I just encountered this problem while trying to use the same message as input for 2 different operations: WSDLToJava Error: Non unique body parts, operation [ GetImageFileName ] and operation [ GetImageFormat ] in binding {http://theSoftwareArchive.com}SoftwareArchiveBinding have the same body block: {http://theSoftwareArchive.com}imageID the relevant part of the wsdl is below: <wsdl:types> <xs:schema xmlns:tns="http://theSoftwareArchive.com"; targetNamespace="http://theSoftwareArchive.com";> <xs:element name="imageID" type="xs:integer"/> <xs:element name="imageFileName" type="xs:string"/> <xs:element name="imageFormat" type="xs:string"/> </xs:schema> </wsdl:types> <wsdl:message name="imageIDMessage"> <wsdl:part name="parameters" element="tns:imageID"/> </wsdl:message> <wsdl:message name="imageFileNameMessage"> <wsdl:part name="parameters" element="tns:imageFileName"/> </wsdl:message> <wsdl:message name="imageFormatMessage"> <wsdl:part name="parameters" element="tns:imageFormat"/> </wsdl:message> <wsdl:portType name="SoftwareArchivePortType"> <wsdl:operation name="GetImageFileName"> <wsdl:input message="tns:imageIDMessage"/> <wsdl:output message="tns:imageFileNameMessage"/> </wsdl:operation> <wsdl:operation name="GetImageFormat"> <wsdl:input message="tns:imageIDMessage"/> <wsdl:output message="tns:imageFormatMessage"/> </wsdl:operation> </wsdl:portType> Now, I thought this may be because I use the same message imageIDmessage for both operations GetImageFileName and GetImageFormat, so I created a 2nd message which uses the same element like so: <wsdl:message name="imageIDMessage"> <wsdl:part name="parameters" element="tns:imageID"/> </wsdl:message> <wsdl:message name="imageIDMessage_2"> <wsdl:part name="parameters" element="tns:imageID"/> </wsdl:message> and use them like that: <wsdl:portType name="SoftwareArchivePortType"> <wsdl:operation name="GetImageFileName"> <wsdl:input message="tns:imageIDMessage"/> <wsdl:output message="tns:imageFileNameMessage"/> </wsdl:operation> <wsdl:operation name="GetImageFormat"> <wsdl:input message="tns:imageIDMessage_2"/> <wsdl:output message="tns:imageFormatMessage"/> </wsdl:operation> </wsdl:portType but this leads to the same error message. Actually, from the error message the problem seems to come from the fact they both use the same imageID element. Googling a bit on that, I found this (on this forum actually): http://old.nabble.com/WSDLToJava-Error-%3A-Non-unique-body-parts!-In-a-port% 2C-operations-must-have-unique-operation-signaure-ts17760468.html#a17760644 where someone has a similar issue. The 2 replies seem to suggest that this is not possible for some reason (which I didn't really understand actually) and one reply suggested making a complexType out of the simple element and create 2 simple elements based on that complex type. This way, there are actually 2 different elements. I tried that and it works, but it sounds like a hack to me... why is not possible to use the same message or element as input for 2 different operations ?? Even more confusing, when I add a second element (called bla as an example) to the message, e.g.: <wsdl:types> <xs:schema xmlns:tns="http://theSoftwareArchive.com"; targetNamespace="http://theSoftwareArchive.com";> <xs:element name="imageID" type="xs:integer"/> <xs:element name="bla" type="xs:integer"/> <xs:element name="imageFileName" type="xs:string"/> <xs:element name="imageFormat" type="xs:string"/> </xs:schema> </wsdl:types> <wsdl:message name="imageIDMessage"> <wsdl:part name="parameters1" element="tns:imageID"/> <wsdl:part name="parameters2" element="tns:bla"/> </wsdl:message> Then it works (?????) even if the 2 operations GetImageFileName and GetImageFormat uses the same message imageIDMessage which is made of the same input parameters (only difference, there is now 2 parameters instead of one) Is this a bug, or am I missing something here ? Cheers David -- View this message in context: http://old.nabble.com/%22Non-unique-body-parts%22-error-when-trying-to-use-s ame-input-message-for-2-different-operations-tp28387764p28387764.html Sent from the cxf-user mailing list archive at Nabble.com.
