I guess I would go ahead and log this as a bug.     That said, I still 
recommend avoiding doing this if you want your service to be interopable.  

Dan


On Monday 26 July 2010 12:21:04 pm Grenier Nicolas wrote:
> Hello,
> 
> I'm developping an healthcare application using IHE profiles.
> An XDS.b profile for submiting healthcare documents and its metadata is
> provided that supportq both submission and update of metadata using the
> same SOAP message (an ebXML SubmitObjectRequest). XDS.b uses the
> WS-Addressing feature (the Action attribute) to distinguish between the
> two operations.
> 
> Extract from my wsdl:
> 
>         <message name="RegisterDocumentSet-b_Message">
>                 <documentation>Register Document Set - b</documentation>
>                 <part name="body" element="lcm:SubmitObjectsRequest"/>
>         </message>
> 
>         <message name="UpdateDocumentSet_Message">
>                 <documentation>Update Document Set </documentation>
>                 <part name="body" element="lcm:SubmitObjectsRequest"/>
>         </message>
> 
>                 <operation name="DocumentRegistry_RegisterDocumentSet-b">
>                         <input message="ihe:RegisterDocumentSet-b_Message"
>                                
> wsaw:Action="urn:ihe:iti:2007:RegisterDocumentSet-b"/> <output
> message="ihe:RegisterDocumentSet-bResponse_Message"
> wsaw:Action="urn:ihe:iti:2007:RegisterDocumentSet-bResponse"/>
> </operation>
> 
>                 <operation name="DocumentRegistry_UpdateDocumentSet">
>                         <input message="ihe:UpdateDocumentSet_Message"
>                                
> wsaw:Action="urn:ihe:iti:2010:UpdateDocumentSet"/> <output
> message="ihe:UpdateDocumentSet-Response_Message"
> wsaw:Action="urn:ihe:iti:2010:UpdateDocumentSet-Response"/> </operation>
> 
> This is normally allowed by the WS Basic Profile 1.2 (extract below).
> 
> But when I try to use wsdl2java to generate my code using my wsdl, I get
> the following error:
> 
>         WSDLToJava Error: Non-unique body parts! In a port, operations must
> have unique operation signatures on the wire for suc cessful dispatching.
> In port {urn:ihe:iti:xds-b:2007}DocumentRegistry_Port_Soap12, operations
> "{urn:ihe:iti:xds-b:2007}D ocumentRegistry_UpdateDocumentSet" and
> "{urn:ihe:iti:xds-b:2007}DocumentRegistry_RegisterDocumentSet-b" have the
> same re quest body block
> {urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0}SubmitObjectsRequest
> 
> 
> Does CXF support Basic Profile 1.2 ? Is this a bug or do I miss anything ?
> 
> Thanks a lot.
> 
> Nicolas.
> 
> 
> WS-I BP 1.2:
> 
> http://ws-i.org/profiles/BasicProfile-1.2-WGD.html, section 4.7.6 -
> also included inline below.
> http://ws-i.org/profiles/BasicProfile-1.2-WGD.html#bp11compatibility:
> R2710 is explicitly mentioned
> 
> 
> 4.7.6 Operation Signatures
> 
> Definition: operation signature
> 
> 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 and the URI value
> of the wsa:Action SOAP header block, if present.
> 
> 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. CORE
> TESTABLE BP2120a BP2120b
> 
> 
> 
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage
> exclusif de ses destinataires. Il peut également être protégé par le
> secret professionnel. Si vous recevez ce message par erreur, merci d'en
> avertir immédiatement l'expéditeur et de le détruire. L'intégrité du
> message ne pouvant être assurée sur Internet, la responsabilité du groupe
> Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien
> que les meilleurs efforts soient faits pour maintenir cette transmission
> exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard
> et sa responsabilité ne saurait être recherchée pour tout dommage
> résultant d'un virus transmis.
> 
> This e-mail and the documents attached are confidential and intended solely
> for the addressee; it may also be privileged. If you receive this e-mail
> in error, please notify the sender immediately and destroy it. As its
> integrity cannot be secured on the Internet, the Atos Origin group
> liability cannot be triggered for the message content. Although the sender
> endeavours to maintain a computer virus-free network, the sender does not
> warrant that this transmission is virus-free and will not be liable for
> any damages resulting from any virus transmitted.

-- 
Daniel Kulp
[email protected]
http://dankulp.com/blog

Reply via email to