[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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]