Updated WSDL generation - a.k.a. web service binding defaults

[Eric Johnson <eric@tibco.com>]

Based on the minutes of the meeting of 2008-05-29, I've made a few edits.  Since I was MIA for the meeting, my understanding of the discussion might be somewhat misguided.  Additions shown with underscore, deletions shown with strike-through.

I see one key question worth floating to the top:
Suppose someone puts <binding.ws/> on a service with no further qualifications.  Per default binding rules in the new proposal, this will enable an endpoint that supports SOAP 1.1 over HTTP.  Must this be the only WSDL 1,1 port for the binding, or could an implementation choose to simultaneously implement a SOAP 1.2 binding, and if it implements an additional binding, must it be at the same endpoint, or can it be at a different endpoint?  Put differently, if an SCA end-user wants to support both SOAP 1.1 & SOAP 1.2 at the same HTTP URL:

• Can a vendor automatically expose those two different WSDL ports on the same URL endpoint, supporting both SOAP 1.1 & SOAP 1.2, and the end-user only declares a single <binding.ws/> element?
  
• Or does the end-user have to define two different binding.ws elements (and then has to use policy intents to indicate which binding element is which).
  

Responding to the notes from the meeting:

Scribe: Simon H. look through the proposal, appendix B
Scribe: Set of 5 rules, around def of the name space
Scribe: Comments on the proposal
Scribe: Anish: is the description an example?
    Me: Assuming this is still referring to Appendix B, yes - certainly not normative.

Scribe: Simon H: the wording suggests its a recommended approach
    Me: I added text indicating that appendix B is non-normative.

Scribe: Simon N: Should parts be included
    Me: ???
Scribe: Anish: Importing PortType, the imported doc will have reference to message and schema, its importing recursively, if its inlined, correct import has to be present
Scribe: No other comments, document had not yet been reviewed by all
Scribe: Simon N: not consistent normative language in the proposal
    Me: Specifics here would help me out.

Scribe: Bryan: Not clear whether its WSDL 1.1 or 2.0, should be explicit
    Me: Which section?
Scribe: Bryan, comment for section 4.2 (Default Binding)
Scribe: Simon N: should we have different versions of the section ?
    Me: Two versions to cover what?  SOAP 1.1 vs SOAP 1.2 or WSDL 1.1 vs. WSDL 2.0?  Or something else.  I don't see the need, so I think I need clarification.

Scribe: Mentions SOAP 1.2
Scribe: Section or each item is compared against policy ?
Scribe: Ambiguous as to it should be applied whole as opposed to each item separately
    Me: My take is that policy is explicit orthogonal to the default binding.  That's why I put in the sentence "In the event that transport details are not determined elsewhere...".  Elsewhere could include binding details, policy choices, or vendor extensions.

Scribe: In 4.2.1, if there is no policy, RT may support 1.1 or 1.2, but then second bullet says 1.1
Scribe: Mike E: proposal is not consistent
Scribe: We need author to explain the intentions to help with wording
Scribe: Go back to Eric for clarification
    Me: I think I understand the concern here, but I'm not sure.  The text "the following configuration SHOULD be used" is wonderfully vague.
    My intent here was to allow for the possibility that the WSDL generator could publish multiple WSDL 1.1 "ports" as a consequence of WSDL generation related to a single binding.ws element.  A consequence of this would be a service that supports both SOAP 1.1 & SOAP 1.2 form invocations at the same endpoint.  This results in the apparently contradictory statements that SOAP 1.1 should be used (bullet 2), but then that in the case of SOAP 1.2, how to carry the "action" parameter (bullet 7).  This relates to the question I put at the top of this email.

Scribe: Last bullet of 4.2
Scribe: should not be dependent on any policy affecting how you generate WSDL
Scribe: Anish: 4.2, except last bullet should be mandatory
Scribe: Should --> Must
    Me: I don't see the value of putting a "MUST" inside of a section for which the entire contents is a "should."

Scribe: If you don't specify anything, the WS binding is described in 4.2
Scribe: Simon H: if you don't specify anything, you are guaranteed interoperability, once you start specifying things, you don't have interop
Scribe: Anish: Autogeneration of WSDL should be supported, rules to generate WSDL
    Me: ???  I don't think I understand Anish's comment.  Once we've fully specified what the SOAP messages look like, why do we need to spell out how the WSDL gets generated?  What's the use case where the SCA bindings TC needs to spell this out?

Scribe: Simon N: SOAP version spelling
Scribe: Square bracket with two versions
    Me: details?

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 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 determined elsewhere, a conforming implementation SHOULD enable the following configuration SHOULD be used:

• HTTP-based transport

• Use Except when policy mandates the use of 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.
  

• For SOAP 1.1 messages, the SOAPAction 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 body of the message

4.2.1 SOAP versions

Where no specific version of SOAP has been dictated, an SCA runtime might support both version 1.1 and version 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 possible consistency, this section picks optionssuggests non-normative choices for some of the various details involved in generating WSDL.

• 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”