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: Attempt #4 at WSDL binding

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).


[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.

Title: [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”

  • wsdl:service/@name = <name of the service>

  • wsdl:port/@name = <name of binding> + <SOAP Version> + “Port”

In the above, "<SOAP Version>" should be either "SOAP11" or "SOAP12" as appropriate.

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