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 http://www.sosnoski.com - http://www.sosnoski.co.nz 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] http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ > (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: >> >> 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. >> >> >> >
