cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject Re: Using the same SOAP message for two operations with different WS-Addressing Actions not allowed ?
Date Tue, 27 Jul 2010 02:58:02 GMT
I'm with Glen on this. The whole point of the WS-I BP requirements is
that the actual XML message needs to be different for different
operations (really required only for when WS-Addressing is not in use,
but BP was written without reference to WS-Addressing). That's not the
case using the WSDL provided.

But just because it's forbidden by WS-I BP doesn't mean it should not be
supported by CXF. If industry groups have designed their WSDLs to be
non-compliant with WS-I BP that's their choice, and I don't think it's
CXF's place to be telling them they don't know what they're doing. A
warning that they're violating WS-I BP would be the best way of handling
this type of WSDL.

  - Dennis

Dennis M. Sosnoski
XML and Web Services in Java
Training and Consulting -
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117

On 07/27/2010 04:42 AM, Glen Mazza wrote:
> Are you sure?  I'm reading R2710 below completely oppositely from the way
> that you are, namely, that the SOAP request messages for the operations
> defined in a WSDL must be distinct from each other.
> Doc/Lit wrapped[1] relies on the request type (say, UpdateObjectsRequest or
> RegisterObjectsRequest) to determine the operation to call.  While some web
> service providers will rely on soapAction and ignore the soap body request
> name, my experience is that the JAX-WS RI ignores soapAction instead.  I'm
> not sure where CXF is on this, but the point of WS-I is to have maximum
> interoperability with many SOAP clients (not just Java-based ones),
> including ones that might not send a soapAction.  So you should probably
> keep the operation names distinct.  However, the complex types that
> UpdateObjectsRequest and RegisterObjectsRequest can refer to can be the
> same, perhaps giving you the reuse you're looking for.
> HTH,
> Glen
> [1]
> (scroll to bottom)
> 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:
>>, section 4.7.6 -
>> also included inline below.
>> 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.

View raw message