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

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

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


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

Comments inlined below.


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

>> 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:

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]