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

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.

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]