sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Updated WSDL generation - a.k.a. web service bindingdefaults
- From: Simon Nash <NASH@uk.ibm.com>
- To: OASIS Bindings <sca-bindings@lists.oasis-open.org>
- Date: Thu, 26 Jun 2008 11:04:27 +0100
Here are my comments/questions on the
proposal. They mostly concern changes from the rules defined in the
current specification.
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?
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?
3. What is the HTTP base URI?
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?
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.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
Anish Karmarkar <Anish.Karmarkar@oracle.com>
26/06/2008 08:26
|
To
| Eric Johnson <eric@tibco.com>
|
cc
| OASIS Bindings <sca-bindings@lists.oasis-open.org>
|
Subject
| Re: [sca-bindings] Updated WSDL generation
- a.k.a. web service binding defaults |
|
My comments inlined below.
-Anish
--
Eric Johnson wrote:
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)
As I mentioned in last week's
call. I prefer that we do not constraint the deployer (or the runtime/vendor)
on this.
<binding.ws/> means that a <wsdl:port>, which is bound to the
WSDL SOAP 1.1, must be made available. Nothing more.
If there are additional <wsdl:port> elements in the same <wsdl:service>
or in different <wsdl:service> is none of our business. I.e. out
of scope for SCA specifications. Whether additional <wsdl:port> that
are made available have the same value of <soap:address> or different
values that get HTTP redirected to the same thing, or aliases to the same
thing or something completely different and unconnected -- we shouldn't
say. That is for the deployer/policy czars runtimes to figure out.
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.
s/ought to be used/are used/
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:
Given that this is about empty <binding.ws/>, I'm
not sure what 'elsewhere' is.
Why is it 'SHOULD'? I expected a 'MUST'.
s/HTTP-based
transport/HTTP transfer protocol/
-
Use Except when policy mandates the
use of SOAP 1.2, support SOAP 1.1
Shouldn't
we say that if there is no soap 1.2 policy/intent then it must be 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.
Didn't we agree that empty <binding.ws>
when using WSDL 1.1 would be BP complaint. If so, and if we say that then
the above 2 bullets can be removed.
Also, most of the bullet here talk about WSDL 1.1. Are we saying that empty
<binding.ws> means that WSDL 1.1 must be used? If so, which I would
perfectly happy with given that WSDL 2.0 is not widely implemented, we
should say that.
-
- 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.
I think we need to say SOAP 1.1 must be supported. Whether
SOAP 1.2 is supported or not we don't have to say.
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.
Should we mandate WSDL 1.1? By mandate I mean that WSDL
1.1 description must be generated. Whether you also make the equivalent
WSDL 2.0 description available we shouldn't say.
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
What if the interface
is specified as Java interface? Must the generated portType not be
inlined?
-
- 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”
--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. You may a link to this group and 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. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]