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: Re: [sca-bindings] Issue 25: Does binding.ws imply SOAP


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 - Simon_Holdsworth@uk.ibm.com

David Booz <booz@us.ibm.com>

26/06/2008 13:21

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

            Anish Karmarkar                                              
            oracle.com>                                                To
            06/26/2008 02:56                                           cc
                                      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

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



[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

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

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]