OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sca-bindings] Attempt #4 at WSDL binding

Eric Johnson wrote:
48DC6B54.4040604@tibco.com" type="cite"> Hi Anish,

Thanks for the clarifications.

Anish Karmarkar wrote:
48DC3513.80602@oracle.com" type="cite"> Eric Johnson wrote:
48DC1D70.8030207@tibco.com" type="cite"> So far as I can tell, this looks great.  I realize as I read it through again, that I'm struggling with this one, to figure out the context:

"For messages that have multiple parts, the message uses “rpc” style, as per section 3.5 of [WSDL11]. In this case, the child elements of the SOAP Body element must be namespace qualified with a non-empty namespace name. {I find this to be problematic. Unless one knows the namespace, one cannot generate the correct messages on the wire. This has to be nailed down. The options I see are: specify a generic NS “http://docs.oasis-open.org/sca/binding/ws/YYYYMM” or disallow messages with multiple parts when defaulting. I'm leaning towards the latter.}"

Anish, could you remind us of what is going on here?  I think this relates to WS-I Basic Profile version 1.2, R1014 - http://www.ws-i.org/Profiles/BasicProfile-1_2(WGAD).html#SOAP_Body_Namespace_Qualification.  However, I cannot figure out exactly the dynamics of how one ends up *without* namespace qualified elements under the body, and thus, how this constraint comes into play.  I have stared at WSDL and BP 1.2 for quite some time, and am careening towards completely numbing my brain.

If you want to struggle with more wsdl/soap/addressing related complexity, here is some more:
What is the relationship between:
1) SOAPAction HTTP header
2) action parameter on the SOAP 1.2 media type
3) wsa:Action WS-Addressing SOAP header block
4) wsaw:Action WS-Addressing WSDL extension attribute
5) soapAction WSDL SOAP 1.1 binding extension attribute
6) soapAction WSDL SOAP 1.2 binding extension attribute
7) soapActionRequired WSDL SOAP 1.2 binding extension attribute

Back to your question:
As you know there are four possible styles: rpc/literal, rpc/encoded, doc/literal and doc/encoded. Lets stick to the two that are allowed by WS-I BP: rpc/literal and doc/literal.
In doc/literal, the messages must have a single part (or no part) and the part must point to a XML Schema element. The content of the SOAP body is an instance of that XML Schema GED.
In rpc/literal, the message may contain > 1 part. The parts are wrapped in another element, and it is this wrapper that is the child of the SOAP body. The wrapper is a QName, whose local name is the same as the operation name (for requests) and operation name + "Response" (for responses). The namespace for the QName is the same as the value of the namespace attribute of the <soapbind:body> element in WSDL. WS-I BP 2717 (http://www.ws-i.org/Profiles/BasicProfile-1_2(WGAD).html#R2717) say:

"An rpc-literal binding in a DESCRIPTION MUST have the namespace attribute specified, the value of which MUST be an absolute URI, on contained soapbind:body elements."

This is really a corallary to R1014 that you point to. If the child element of the SOAP body has to be namespace qualified then for rpc/literal the namespace attribute on the <soapbind:body> element must have a value. The root cause of all this is the fact that in a rpc/literal binding the message parts refer to a XML Schema type (not a GED) and the fact that the message can contain multiple parts (WSDL 2.0 resolves this by allowing you to point only to a GED and getting rid of parts inside a message). So when the type appears on the wire, you have to say what the element name and the what the wrapper name is.

In any case, if we want the binding.ws to specify exactly what happens on the wire (which I would argue we do), then we have to say what the value of the namespace attribute of <soapbind:body> element is, for rpc/literal. If you don't specify the namespace, then the only reasonable assumption would be that the wrapper is not namespace qualified.

I hope this make it clear. If not, I can send some examples that make it clearer.
Yes, this does make it clear - your suggestion for a namespace sounds good to me.
48DC3513.80602@oracle.com" type="cite">
48DC1D70.8030207@tibco.com" type="cite">Unrelated, while I was trying to re-learn the meaning of what I wrote before, I tripped across this item in WS-I Basic Profile 1.2:
    R2705 -  A wsdl:binding in a DESCRIPTION MUST either be a rpc-literal binding or a document-literal binding.

That is to say, BP 1.2 wants consistency for an entire binding, whereas our bullet points below make a distinction based on the number of parts in a given operation.  We could change our criteria to say if *any* operation has multiple parts, then then entire binding should be style "rpc".  That seems draconian to me, but does anyone else have thoughts on the matter?

If we want to be BP compliant, and for the default binding I think it makes sense  to be BP compliant, then we would have to adopt this rule. But it is slightly more complicated then that:
For rpc/lit: all parts must point to XML schema type
For dpc/lit: all parts must point to GEDs *and* must have either zero or one part.
anything else would be an error.
Actually, I don't think we get to fail.  If the customer has specified a portType that violates the expected rules of WS-I BP 1.2, they may have good reasons for doing so.  So the reason that I put the rule the way I did was precisely for this corner case - if a customer does use elements instead of types, and ends up doing an rpc/lit binding, there must still be a valid binding, even if it is not WS-I BP 1.2 compliant.  This is another one of those reasons where we don't want to be in the WSDL generation business, because we'd have to identify another set of corner cases where the generated WSDL follows our spec, but doesn't result in something WS-I BP compliant.

I'm not advocating for restrictions on what can be included in the WSDL binding that binding.ws points to. The restrictions would only be for the case where binding.ws does not use the wsdlElement attribute.  So the case where types are used to define message parts and rpc/lit binding is specified would not fall under the 'default' criterion (to specific rpc/lit you have to specify the wsdlElement). If there is a wsdl binding specified and it says rpc/lit, then the binding specifies exactly what is to be done.
I tend to think that for the simple case, where for whatever reason the user doesn't want to generate the WSDL binding and wants to just use defaults, we should encourage (in this case, require) Basic Profile.
But I don't feel strongly about this. If you think mixing of doc/lit operations and rpc/lit operations within the same portType/binding should be supported, I would be ok with it. If we proceed that way, the rule would be:
For each operation,
a) if all the messages for that operation have zero or one part and are described using XML Schema GED, then the style attribute has a value of "document"
b) if all the message parts for that operation are described using XML Schema types, then the style attribute has a value of "rpc"
Anything else would be an error.

Here are the cases that are then disallowed:
1) a message containing multiple parts using both GEDs and types.
2) > 1 parts in a message all of them described by GEDs

I'm not sure how one would go about constructing a WSDL binding for (1). It can't be a 'document' style, since you need to specify the part accessors for the parts defined using types. If it is rpc, would the part described using GED also have a part accessor? For (2), the simplest way would be to make it 'document' style and have multiple children in the SOAP body. I don't really see a problem with allowing (2) -- so we could relax the rule for that.

The bigger question, is do we want our default binding to be interoperable, if yes, then we should stick to BP conformance with some minimal exceptions. Anything else, define your own WSDL binding.

48DC6B54.4040604@tibco.com" type="cite">If you think this really is an error, is seems that the assembly specification must state something normative about how interface.wsdl portTypes cannot be any odd WSDL 1.1 portType, but they must be WS-I BP 1.2 compliant portTypes.  But I don't think it should.
I don't think we need to go that far. If someone wants to do BP non-compliant portType they can, but they have to define their own bindings. Don't rely on defaults.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]