Here are my preferences:
> 1) Does every conformant implementation have to support the bare
> <binding.ws/> element?
No.
I don't think we should focus on syntax here wrt conformance. The
question is does every conformant implementation have to support WSDL
SOAP/HTT binding(s)? Assuming that the default is SOAP/HTTP.
> 2) Do we want to change the description of the bare <binding.ws/>
> element so that it does not always provide SOAP?
No.
I like the SOAP/HTTP default. That is the most common case.
> 3) Does every conformant implementation have to support referencing
> existing WSDL documents?
Yes. This is after all binding.ws. A conformant implementation better
understand WSDL and support using it.
> 4) Is a conformant implementation limited to exposing access to a
> service only in the manner described by that service's bindings?
As far as SCA is concerned yes. But what vendors, deployers,
implementers do outside of SCA, we should not say.
-Anish
--
Simon Holdsworth wrote:
>
> Dave,
>
> You've identified one of the sub-issues of BINDINGS-25, namely whether
> conformant implementations have to support the use of the bare
> <binding.ws/> element. Which begs a broader question - does a conformant
> implementation have to support all valid expressions of the binding
> schema. The opposite view might be an implementation that ONLY supports
> <binding.ws/> and does not allow you to point to a WSDL document - does
> that break conformance? That's down to us to define I guess as part of
> our conformance statements, either via a broad statement or through
> conformance statements that address each case individually.
>
> My preference is also to keep the status quo. The opposite approach
> that I have some sympathy with would be to say that in theory any SCA
> service can be described in WSDL, regardless of the type of binding on
> the SCA service, so why should we have a special binding.ws. Just use
> binding.soap, binding.jms, etc. and allow all of those to be configured
> by or to publish WSDL descriptions. Indeed, I would hope that over time
> the number of SCA bindings that can be described in WSDL will increase,
> as I believe that that should be the public representation of services
> that is exchanged with non-SCA runtimes. What you lose there is the
> flexibility of WSDL extensions to describe something that's outside of
> the current set of supported bindings - you have to create a new SCA
> binding for each new WSDL binding, something we did discuss early on
> with the concensus that that was not desirable.
>
> Another aspect of this discussion was raised by Mike E, I think, which
> is whether the binding definition implies a constraint on the access
> provided to the component to which the service is wired. So if I wire a
> component to an SCA service with binding.ws, and I have an intent that
> requires encryption, does a conformant implementation have to guarantee
> that that component can only be accessed via suitably encrypted web
> service invocation? Or is it simply saying that when accessed via the
> endpoint corresponding to the service/binding configuration, encryption
> must be used, with the runtime at liberty to provide alternative
> endpoints with different access methods and constraits?
>
> So I think the questions we have to answer to fully resolve this issue
> and the WSDL generation are:
>
> 1) Does every conformant implementation have to support the bare
> <binding.ws/> element?
> 2) Do we want to change the description of the bare <binding.ws/>
> element so that it does not always provide SOAP?
> 3) Does every conformant implementation have to support referencing
> existing WSDL documents?
> 4) Is a conformant implementation limited to exposing access to a
> service only in the manner described by that service's bindings?
>
> Regards, Simon
>
> Simon Holdsworth
> STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
> MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
> Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
> Internet -
>
>
> *David Booz <>*
>
> 26/06/2008 13:21
>
>
> To
>
> cc
>
> Subject
> Re: [sca-bindings] Issue 25: Does binding.ws imply SOAP
>
>
>
>
>
>
>
>
> Today, you don't need to point to a WSDL with binding.ws. The question we
> need to answer is what to do when there is no WSDL? What WSDL binding
> should be generated? Is a SOAP binding generated only when the SOAP intent
> is specified? What is the default when there are no intents?
>
> Dave Booz
> STSM, SCA and WebSphere Architecture
> Co-Chair OASIS SCA-Policy TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:
> http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
>
>
>
> Anish Karmarkar
> <Anish.Karmarkar@
> oracle.com> To
>
> 06/26/2008 02:56 cc
> AM
> Subject
> Re: [sca-bindings] Issue 25: Does
> binding.ws imply SOAP
>
>
>
>
>
>
>
>
>
>
> I took an AI some time ago to clarify issue 25 [1].
> I don't exactly remember the context wrt what I was supposed to clarify,
> but from the email discussion it seems clear that the issue is well
> understood (at least to some folks). So, I'll add my 2 cents (aka rant)
> regarding the issue and a proposal.
>
> The history of binding.ws is in supporting SOAP. Since SOAP bindings in
> general are described by WSDL, it did not make sense to reinvent WSDL in
> SCA. So we decided to just point to a WSDL document along with a few
> default values for the case where either there wasn't a WSDL to point to
> or it was thought that generating the WSDL for the simple case was
> putting too much burden on the developer/assembler.
>
> So now we have a binding.ws which is WSDL based and can describe/specify
> anything that WSDL can. Keep in mind that WSDL is meant to be extensible
> wrt bindings. So this means it can describe pretty much anything. This
> is unlike the other bindings, for example, binding.jms where the
> conformance is clear and very narrow. Conformance to binding.ws is not.
> Knowing that a particular runtime supports binding.ws does not give you
> any confidence that it will support a particular WSDL binding pointed to
> by binding.ws OR that it would support a SOAP binding described using
> WSDL (which was the original intent). IOW the conformance criteria for
> claiming that a runtime supports binding.ws is weak.
>
> In the email discussion that has occurred on this issue, two things are
> being mixed: interoperability and portability. This issue is not about
> interoperability. Yes, binding.ws is going to be SCA's answer to
> interoperability. But that is not because binding.ws is going to be
> consumed directly by entities outside of SCA that we want to
> interoperate with. Such entities will see the WSDL not binding.ws. It is
> the WSDL and the associated non-SCA "standard" WSDL bindings that are
> going to provide interoperability.
>
> To continue on interoperability, providing a WSDL or even a WSDL SOAP
> binding does not necessarily guarantee interoperability, it just
> increases the chances of it. For example, the WSDL may have the "wrong"
> version of SOAP, the WSDL itself may be the wrong version. It may have
> policies in it that are not recognized; it may have WSDL extensions in
> it that are not recognized. Typically, the WSDL consumer will look at
> the WSDL, process it and decide if the endpoint described by the WSDL is
> something that it can talk to.
>
> Wrt portability, as it is defined now, having binding.ws in a SCDL means
> that you have to find out not just whether the target runtime supports
> binding.ws but also the WSDL binding that binding.ws points to. If we
> want to provide a generic WSDL-based binding, there isn't a way around
> this.
>
> Proposal:
> I see three ways to address this issue:
>
> 1) status quo. Lot of flexibility and capability. When deploying such a
> binding, one will have to do more work to find out exactly what the
> target runtime supports.
>
> 2) constrain binding.ws to just SOAP. This would mean that the
> conformance requirement for the binding will have some teeth and is
> meaningful. Of course there are still no guarantees as the WSDL SOAP
> binding may have policies or extensions (eg: a policy that says WS-Trust
> is required) that are not supported by the runtime or the runtime may
> decide to support SOAP 1.1 and not 1.2. This would mean
> 'alwaysProvides=soap' must be true for this binding. If we go down this
> path I would prefer to rename it binding.soap to make it clear what the
> binding is about.
>
> 3) Create two different bindings binding.soap and binding.ws. binding.ws
> would be as it is right now and binding.soap would be as described in
> (2). binding.ws in this case then would not support the default (for
> SOAP) that we have now.
>
> My preference: Option (1). I like the idea of having a generic
> binding.ws that is WSDL based. This means a lot of things can be
> supported: WSDL soap 1.1 binding, WSDL soap 1.2 binding, WSDL http
> binding etc. This also means that if there is new WSDL binding defined,
> we don't need to rev the SCA specs. For example, a WSDL binding
> description for SOAP over JMS and SOAP over UDP is likely to happen in
> the future. So I prefer the status quo. Wrt portability of binding.ws
> that points to WSDL SOAP binding, all one has to check is whether the
> target runtime supports binding.ws with 'soap' intent. My second
> preference would be (3).
>
> Comments?
>
> -Anish
> --
>
> [1] http://www.osoa.org/jira/browse/BINDINGS-25
>
> ---------------------------------------------------------------------
> 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/
>
>
>
>
>
>
