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

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

Dave,

When there is no WSDL, and no intents then the binding generated is the 
SOAP 1.1/HTTP WSDL bidning. If there is a soap1.1 or 1.2 intent then the 
corresponding soap/http WSDL binding is generated. This is the issue 
that Eric has taken on and we have to decide what the rules are wrt wsdl 
generation.

To me that is separate from conformance -- is a runtime that claims 
conformance to binding.ws required to support soap1.1/http binding? 
Where as the defaulting issue is about syntactic convenience.

-Anish
--

David Booz wrote:
> 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
> e-mail:booz@us.ibm.com
> http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
> 
> 
>                                                                            
>              Anish Karmarkar                                               
>              <Anish.Karmarkar@                                             
>              oracle.com>                                                To 
>                                        sca-bindings@lists.oasis-open.org   
>              06/26/2008 02:56                                           cc 
>              AM                                                            
>                                                                    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.
> 
> 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.
> 
> 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).
> 
> Comments?
> 
> -Anish
> --
> 
> [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
> 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.  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 
>