Return-Path: Delivered-To: apmail-cxf-users-archive@www.apache.org Received: (qmail 27472 invoked from network); 27 Jul 2010 02:59:18 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 27 Jul 2010 02:59:18 -0000 Received: (qmail 96074 invoked by uid 500); 27 Jul 2010 02:59:18 -0000 Delivered-To: apmail-cxf-users-archive@cxf.apache.org Received: (qmail 95596 invoked by uid 500); 27 Jul 2010 02:59:16 -0000 Mailing-List: contact users-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cxf.apache.org Delivered-To: mailing list users@cxf.apache.org Received: (qmail 95588 invoked by uid 99); 27 Jul 2010 02:59:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Jul 2010 02:59:15 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [206.123.75.163] (HELO sosnoski.com) (206.123.75.163) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Jul 2010 02:59:08 +0000 Received: from linux.site (dhcp184-48-115-103.spgs.phx.wayport.net [184.48.115.103]) (authenticated bits=0) by sosnoski.com (8.12.10/8.12.10) with ESMTP id o6R2w98n009509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Jul 2010 22:58:44 -0400 Message-ID: <4C4E4B3A.70802@sosnoski.com> Date: Tue, 27 Jul 2010 14:58:02 +1200 From: Dennis Sosnoski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5 MIME-Version: 1.0 To: users@cxf.apache.org Subject: Re: Using the same SOAP message for two operations with different WS-Addressing Actions not allowed ? References: <04DEF5D2955AEB468DCC881BDA2B50CE57F163AAC8@FRSPX100.fr01.awl.atosorigin.net> <1280162539116-2228262.post@n5.nabble.com> In-Reply-To: <1280162539116-2228262.post@n5.nabble.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org 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: >> >> >> Register Document Set - b >> >> >> >> >> Update Document Set >> >> >> >> >> > >> wsaw:Action="urn:ihe:iti:2007:RegisterDocumentSet-b"/> >> > message="ihe:RegisterDocumentSet-bResponse_Message" >> >> wsaw:Action="urn:ihe:iti:2007:RegisterDocumentSet-bResponse"/> >> >> >> >> > >> wsaw:Action="urn:ihe:iti:2010:UpdateDocumentSet"/> >> > message="ihe:UpdateDocumentSet-Response_Message" >> >> wsaw:Action="urn:ihe:iti:2010:UpdateDocumentSet-Response"/> >> >> >> 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. >> >> >> >