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.