Re: [sca-bindings] Issue 25: Does binding.ws imply SOAP

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Eric,

Thanks for the email.
You made a convincing argument that we need to focus on SOAP.

Comments inlined below.

-Anish
--

Eric Johnson wrote:
> Hi Anish,
> 
> Thanks for writing this up.
> 
> Anish Karmarkar wrote:
>> 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.
> One other variant is not necessarily to point at the WSDL, but to inline 
> the relevant parts in the SCA element.  Perhaps that detail is a 
> distraction, though.

One outcome that I would like to steer away from, and I'm not saying 
that you are suggesting anything like that, is reinventing WSDL or 
SOAP/HTTP binding syntax/semantics in SCA.

>>
>> 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.
> Having discussed this internally, and read through the email thread, I 
> think I end up with #2.
> 
> The key questions for me come back to what the use-cases are for having 
> a generic WSDL binding?  What are the use-cases for having a SOAP 
> specific binding?  If, as Anish suggests, a generic WSDL binding is not 
> really doing much to improve interoperability or improve portability, 
> why exactly do we want it, again?  And I happen to agree with Anish that 
> it doesn't improve interoperability or portability.
> 
> Given an SCA composite file, it seems like it is a "good thing" to be 
> relatively specific in modeling what a binding is about.  I've brought 
> this up in the context of the generic operation and data-binding problem 
> as part of the JMS and JCA bindings.  In this context, the same argument 
> comes back again - shouldn't we be explicit in saying this defines a use 
> of SOAP by saying "binding.soap."  The upsides are numerous:
> 
>     * Tighter conformance - must support SOAP 1.1
>     * WSDL generation description can be explicitly about a well known
>       binding
>     * References to WS-I profiles all make sense in all cases
>     * Developer gets a much clearer understanding of what they get.
> 

What about SOAP 1.2?
Is it just WSDL 1.1 or WSDL 1.1 and/or WSDL 2.0?

> It might even make sense to go slightly "tighter" in the definition, and 
> instead of being "binding.soap", call it "binding.soap_http".  Either 
> that, or binding.soap can be controlled by policy to indicate which 
> transport *must* be used.  I've had discussions at TIBCO with Sabin, 

If we are going to go down this path, I would prefer to keep it 
binding.soap with a default of soap1.1/http.
I think it would be valuable to allow for SOAP over JMS, SOAP over XMPP, 
SOAP over UDP, PAOS (all of these bindings exist today).

I should also mention that a variant of my proposal 1 is: status quo but 
to claim conformance to the binding you MUST support SOAP (pick a 
version(s)) over HTTP.

> that followed to the extreme, we could/should instead repackage the 
> "binding.jms" element as a standard WSDL binding.  There's no 
> theoretical limitation against that that I'm aware of.  If you're 
> resistant to it, that suggests to me that you already recognize that 
> discriminating at the SCA level, rather than relying on WSDL to call out 
> the differences, has some significant value.  The key question here:
> 
> What are the rules-of-thumb that might push one to define a new SCA 
> binding, rather than a new WSDL binding?  Some answers:
> 
>     * Using a WSDL binding implies predetermining binding choices.  As a
>       consequence, you may want to define a new SCA binding whenever you
>       think you might want to define a new policy that controls the
>       binding (see our current policies that affect SOAP).  We could,
>       for example, think of defining policies for JMS that preclude
>       certain types of messages (StreamMessage).
>     * Whenever you change the semantics of the metadata around a
>       binding.  For example, the JMS binding has radically different
>       data binding questions to answer due to the differences in payload
>       types (binary and streamed data, vs. XML) as compared to a SOAP
>       binding.
>     * When your message transport vehicle changes.  I immediately
>       thought of four obvious different message transports: JCA (none
>       defined), JMS (pure API), SOAP ("layered" on top of existing
>       protocols), and REST (implies HTTP, uses MIME types, usually uses
>       XML).
>     * When your "binding" is to an API, rather than to a protocol (JMS,
>       JCA, Axis2).
>     * When the quality of service changes dramatically as a result of
>       the choice.  For example, a "binding.smtp" solution has all sorts
>       of problems with request/reply operations, reliability, and
>       security, which, while independently all have solutions,
>       collectively the "solutions" to make this transport choice
>       equivalent to binding.jms might end up being extremely expensive
> 

Another important reason why someone will choose WSDL or not is whether 
you believe WSDL is the universal description language and whether you 
buy into the WS-* stack. There are a lot of folks (especially the REST 
guys) who do not like WSDL and will not use WSDL-based anything.

> I note, for example, that the entire discussion around WSDL generation 
> has been with respect to SOAP, and even more specifically with respect 
> to SOAP over HTTP. 

The reason for that is, all other cases require you to point to an 
existing WSDL. Because SOAP/HTTP is the default we have to say in WSDL 
terms what the default means. But your point is well taken.

> If we were genuinely considering this as a generic 
> WSDL binding, we'd be looking seriously at custom WSDL bindings that 
> we've each encountered, such as the existing SOAP/JMS bindings that you 
> can find.  We're not, so I'm skeptical that the binding.ws is anything 
> more than a SOAP/HTTP binding.  And that's from someone who has been 
> working on SOAP/JMS for years, so I have reason to be skeptical.
>>
>> 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).
> I'm not convinced by the argument about "we don't have to change the SCA 
> specs."  Anyone who introduces a new WSDL binding could equally well 
> define an new SCA binding element.  Vendors are highly likely, and 
> highly motivated to do this, for differentiation, if nothing else.  
> Burying the change in the WSDL doesn't make SCA any more or less 
> flexible, although I think it does make it harder for us vendors to 
> figure out what is going on in an SCA composite.

Folks who introduce a new WSDL binding may not define a new SCA binding 
because they may not care about SCA. For example, there is a SOAP over 
UDP spec, those folks don't care about SCA and are never going to define 
a binding.soap_udp in SCA. There is a WSDL HTTP (with no SOAP) binding 
that exists. We can choose to use that for REST in SCA (and that means 
very little work for us) or we can define binding.rest. But without the 
binding.ws we don't have a choice.

But I certainly buy the argument that it is unlikely that anyone would 
define a new WSDL binding for anything other than SOAP over 
pick-your-favourite-protocol.

>>
>> Comments?
> None whatsoever. ;-)
> 
> -Eric.
> 
> --------------------------------------------------------------------- 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