[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Attempt #3 at WSDL binding, and commentary
My apologies to those who aren't getting at least an hour to review
this before the call. I've been meaning to get to this for several
days now. The following rolls up a bunch of edits, and I've inserted
editorial comments to answer questions.4 Transport BindingThe 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 IntentsSo as to narrow the range of choices for how messages are carried, the following policy intents affect the transport binding.
4.2 Default BindingIn the event that the transport details are not
otherwise determined, a conforming implementation SHOULD enable the
following configuration: [Eric note: Anish asks why is the above "SHOULD",
not "MUST"? In short, because there is a slight change of meaning I've
performed here. I've not specified that this is restricted to just
"<binding.ws/>". To "defeat" a "MUST" criteria on this
representation, all the vendor has to do is introduce an attribute of
any kind. In this sense, I've broadened the applicability of this
section. That is, even if a vendor does introduce additional
attributes, they SHOULD still make this configuration available, unless
those attributes are specifically about changing this configuration.
To clarify this, I changed it to read "not otherwise determined."]
4.2.1 SOAP versionsWhere no specific version of SOAP has been dictated, an SCA runtime might generate bindings for both of SOAP 1.1 and SOAP 1.2. [Eric note: Anish thinks we should say that the SCA
runtime MUST support SOAP 1.1. I agree, but I don't think that this is
the place to state that. I changed the wording to reflect that this
section is about the bindings that might be generated.] 4.3 WSDL portType or interfaceAn 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. [Eric note: Anish asks whether we should mandate
WSDL 1.1. That's a broader question. I don't think we should, and
haven't indicated that above.] B. Appendix - WSDL GenerationDue 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.
Commentary: 1. The current spec says that a separate WSDL document is generated for each SCA service. The new text is silent on this. Do we want to say anything about whether the WSDL document should correspond to the SCA service (possibly with multiple SCA bindings), or whether there should be a WSDL document for each binding on that service? Eric: My take is to say nothing here. Guessing at or suggesting the useful granularity of generated WSDL files seems like a tricky business. 2. The current spec says that WSDL binding elements may be imported from existing WSDL documents specified on <binding.ws>. The new text only mentions importing portTypes or interfaces. Should the new text also mention importing WSDL bindings? Eric: I don't particularly care. If others think that this is a useful recommendation to add to appendix B, then we can add it. Seems tricky, though, because the actual binding of the resulting service could be affected by vendor provided custom WSDL annotations, or any number of other good reasons a vendor might have for inlining the binding information. 3. What is the HTTP base URI? Eric: Hmmm - that's a good question. I thought when I was first looking at this that it would be URI defined in section 9.2.1 (of course there is no reference here), but looking at it now, that doesn't seem appropriate. I believe I took this from the original version, so the intent there is now lost on me. Can someone else chime in? 4. The current spec says that the name of the <wsdl:definitions> element should be "componentName.serviceName". The new spec says nothing about naming the <wsdl:definitions> element. Should it? Eric: Added. 5. (Raised previously on a call). What is the syntax of <SOAP Version>? I'm guessing it's "SOAP11" or "SOAP12". This should be stated explicitly. Eric: I added a line above. Do you agree with it? -Eric. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]