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

[Simon Nash <NASH@uk.ibm.com>]

Simon,
Does the last part of your note imply
that you think <binding.ws> should prohibit non-SOAP/HTTP/WS-I/BP
WSDL bindings?  Or could they be specified in addition to a SOAP/HTTP/WS-I/BP
binding?

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999

Simon Holdsworth/UK/IBM@IBMGB

10/07/2008 12:41

To	sca-bindings@lists.oasis-open.org
cc
Subject	Re: [sca-bindings] Issue 25: Does binding.ws imply SOAP

My overall comments on this discussion: 

Our original discussion on binding.soap vs. binding.ws included debate
about support for non-SOAP WSDL bindings.  With binding.ws, an SCA
runtime based on a web service runtime that supports additional WSDL bindings
can (at least in theory) automatically support them in SCA via binding.ws.
 If we don't have binding.ws, then a new SCA binding has to be created
to cover these additional WSDL bindings.  In general that's not likely
to be a simple thing for an end-user to do if their SCA runtime doesn't
happen to support the SCA binding corresponding to the WSDL binding. 

For the 1.1 version of the specs, we may consider that non-SOAP WSDL bindings
that are not catered for by other binding specs, are a sufficient minority
that we don't want to have them dictate the direction we take.  If
that's the case, we need to explicitly state and agree that.  Given
that binding.ws is included in the TC charter, that decision would have
significant impact. 

We also wanted to avoid duplicating WSDL binding extensibility in SCA bindings.
 If we have binding.soap, do we duplicate the WSDL SOAP binding, including
its extensibility?  Or do we pin it down further to being binding.soaphttpWS-I1.1BP....
 or allow reference to a WSDL document?   Note that "Defining
SCA binding metadata for non-WS-I compliant Web services" and "Defining
SCA binding metadata for non-SOAP based Web services" are ruled out
of scope by the TC Charter. 

On the other hand, any SCA service can in theory be described in WSDL with
an appropriate WSDL binding.  That's why we didn't end up with binding.wsdl.
 the "ws" implies a model of description, use and capability
that goes beyond WSDL, and embraces more than SOAP/HTTP.

Back to the subject line of this email, my preference is that the simplest
case is also the most common.  That to me means that <binding.ws/>
implies SOAP/HTTP using WS-I BP, and that it should always imply that,
and always be available if the runtime claims to support binding.ws.

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

Anish Karmarkar <Anish.Karmarkar@oracle.com>

10/07/2008 08:13

To	Eric Johnson <eric@tibco.com>
cc	sca-bindings@lists.oasis-open.org, Scott Vorthmann <scottv@tibco.com>, Sabin Ielceanu <sabin@tibco.com>
Subject	Re: [sca-bindings] Issue 25: Does binding.ws imply SOAP

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to 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

---

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