Continuing down this trail... one positive note for document-literal bindings is that it appears header params can be ignored when routing based on just the message.
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. 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. Nicholas Gallardo WebSphere - WebServices Development [EMAIL PROTECTED] Phone: 512-838-1182 Building: 901 / 5G-016 Nicholas L Gallardo/Austin/[EMAIL PROTECTED] 01/11/2007 02:15 PM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: SOAPAction required? I agree with Wolfgang's statement and would like to one thing. In the WS-I Basic Profile 1.1, rule R1127 [1] states: "A RECEIVER MUST NOT rely on the value of the SOAPAction HTTP header to correctly process the message. " So, even in the case of a document/literal (wrapped or not) message, we must be able to route without the SOAP Action. I believe this works in Axis and should work in Axis2 as well. [1] - http://www.ws-i.org/Profiles/BasicProfile-1.1.html#SOAPAction_HTTP_Header Nicholas Gallardo WebSphere - WebServices Development [EMAIL PROTECTED] Phone: 512-838-1182 Building: 901 / 5G-016 WJ Krpelan <[EMAIL PROTECTED]> 01/10/2007 06:51 AM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: SOAPAction required? dear all, pls don't create a new bug. SOAPACTION is REQUIRED for HTTP-Transport (empty or otherwise) and it is PROHIBITED for every other transport other than HTTP. Noone is required to USE it, but there is some standard-usage within .NET. Cheers, Wolfgang Krpelan --- Amila Suriarachchi <[EMAIL PROTECTED]> wrote: > On 1/10/07, Justin Schoeman <[EMAIL PROTECTED]> > wrote: > > > > OK - Appending the operation name to the URL does > work, but I am not > > sure if .Net does this (I do not have .Net, just > some recorded > > messages). From what I can read on the web, > routing is supposed to > > occur via the first tag in the SOAP body (in this > case a > > confirmCustomerReq message). > > > Yes. This is the case if you have rpc/literal as > your soap binding style. > In rpc style it is supposed to wrap the input > message from an element of > which name equals to operation name. (see the WSDL > spec). hence it is > possible to determine the operation using the > message. > but in document/literal style (in this case) input > message is directly send > in the soapbody. And also it is possible to have the > same input message for > two different operations. Therefore it is not > possible to determine the > operation from the first element. > > > I realise this is a bit more complex, but it seems > to be how it is > > supposed to be done, although the documentation is > extremely vague on > > this point... > > > > > > > > > > -- > > > Amila Suriarachchi, > > > WSO2 Inc. > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > -- > Amila Suriarachchi, > WSO2 Inc. > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
