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.
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.
-Anish
--
48DC1D70.8030207@tibco.com" type="cite">-Eric.
Anish Karmarkar wrote:
48DBCF52.3060403@oracle.com" type="cite">I had
an
action to revise Eric's WSDL generation proposal [1].
The revised proposal is attached. The proposal is change-marked for
diffs from the one at [1] (except for deletion of inlined commentary in
attempt 3).
-Anish
--
[1]
http://lists.oasis-open.org/archives/sca-bindings/200807/msg00004.html
PS: in case you are interested, I did sent this email last night, but I
did that from my gmail account and the KAVI did not (correctly) allow
that email to make it to the ML. So resending it from my Oracle
account.
[sca-bindings] Attempt #3 at WSDL binding, and commentary
4 Transport Binding
The binding.ws element provides numerous ways to
specify exactly how messages ought to be transmitted from or to the
reference or service. Those ways include references to WSDL binding
elements from the @wsdlElement attribute, policy intents, and even
vendor extensions within the binding.ws element. However, all of
those ways to indicate how messages get carried happen to be
optional. This section describes the defaults that ought MUST
be used if the specific transport
details are not otherwise specified.
4.1 Intents
So as to narrow the range of choices for how
messages
are carried, the following policy intents affect the transport
binding.
-
soap
This indicates that messages MUST be transmitted using SOAP. One or
more SOAP versions can be used.
-
soap.1_1
Messages MUST be transmitted using only SOAP 1.1.
-
soap.1_2
Messages MUST be transmitted using only SOAP 1.2.
4.2 Default Binding
In the event that the transport details are not otherwise
determined, a conforming implementation SHOULD
MUST enable the following
configuration:
-
HTTP-based transfer protocol
-
Except when an intent or
policy
mandates the use of only SOAP 1.2, support SOAP 1.1
-
“literal” format as described in section 3.5 of [WSDL11]
-
For messages that have a single part, the message uses
“document” style, as per section 3.5 of [WSDL11].
-
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.}
-
For SOAP 1.1 messages, the SOAPAction HTTP
header described in section 6.1.1 represents the empty string, in
quotes (“”).
-
For SOAP 1.2 messages, the optional SOAP Action feature
described in section 6.5 of [SOAP12Adjuncts] does not appear.
-
All message parts are carried in the SOAP
body of the message
4.2.1 SOAP versions
Where no specific version of SOAP has been dictated, an SCA
runtime MUSTmight
generate bindings for both of SOAP
1.1 and SOAP 1.2.
4.3
WSDL portType or interface
An SCA service has a single interface description. For the Web
Services binding, this interface description MUST be converted into one or both of a WSDL
1.1 portType or a WSDL 2.0 interface.
B. Appendix - WSDL Generation
Due to the number of factors that determine how a WSDL might be
generated, including compatibility with existing WSDL uses, precise
details cannot be specified. For example, policy
implementation decisions can affect the way WSDL
might be generated. For reference, and consistency, this section
suggests non-normative choices for some of the various details
involved in generating WSDL.
-
wsdl:definitions/@name =
<componentName> + "." + <serviceName>
-
wsdl:definitions/@targetNamespace
= <HTTP Base URI> + ”/” + <componentName> + “/” +
<serviceName>
-
import each WSDL 1.1 portType or
WSDL 2.0 interface, rather than putting them inline
-
wsdl:binding/@name = <name of binding> + <SOAP
Version> + “Binding”
In the above, "<SOAP Version>" should be either
"SOAP11" or "SOAP12" as appropriate.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|