[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
Here are my preferences: > 1) Does every conformant implementation have to support the bare > <binding.ws/> element? No. I don't think we should focus on syntax here wrt conformance. The question is does every conformant implementation have to support WSDL SOAP/HTT binding(s)? Assuming that the default is SOAP/HTTP. > 2) Do we want to change the description of the bare <binding.ws/> > element so that it does not always provide SOAP? No. I like the SOAP/HTTP default. That is the most common case. > 3) Does every conformant implementation have to support referencing > existing WSDL documents? Yes. This is after all binding.ws. A conformant implementation better understand WSDL and support using it. > 4) Is a conformant implementation limited to exposing access to a > service only in the manner described by that service's bindings? As far as SCA is concerned yes. But what vendors, deployers, implementers do outside of SCA, we should not say. -Anish -- Simon Holdsworth wrote: > > Dave, > > You've identified one of the sub-issues of BINDINGS-25, namely whether > conformant implementations have to support the use of the bare > <binding.ws/> element. Which begs a broader question - does a conformant > implementation have to support all valid expressions of the binding > schema. The opposite view might be an implementation that ONLY supports > <binding.ws/> and does not allow you to point to a WSDL document - does > that break conformance? That's down to us to define I guess as part of > our conformance statements, either via a broad statement or through > conformance statements that address each case individually. > > My preference is also to keep the status quo. The opposite approach > that I have some sympathy with would be to say that in theory any SCA > service can be described in WSDL, regardless of the type of binding on > the SCA service, so why should we have a special binding.ws. Just use > binding.soap, binding.jms, etc. and allow all of those to be configured > by or to publish WSDL descriptions. Indeed, I would hope that over time > the number of SCA bindings that can be described in WSDL will increase, > as I believe that that should be the public representation of services > that is exchanged with non-SCA runtimes. What you lose there is the > flexibility of WSDL extensions to describe something that's outside of > the current set of supported bindings - you have to create a new SCA > binding for each new WSDL binding, something we did discuss early on > with the concensus that that was not desirable. > > Another aspect of this discussion was raised by Mike E, I think, which > is whether the binding definition implies a constraint on the access > provided to the component to which the service is wired. So if I wire a > component to an SCA service with binding.ws, and I have an intent that > requires encryption, does a conformant implementation have to guarantee > that that component can only be accessed via suitably encrypted web > service invocation? Or is it simply saying that when accessed via the > endpoint corresponding to the service/binding configuration, encryption > must be used, with the runtime at liberty to provide alternative > endpoints with different access methods and constraits? > > So I think the questions we have to answer to fully resolve this issue > and the WSDL generation are: > > 1) Does every conformant implementation have to support the bare > <binding.ws/> element? > 2) Do we want to change the description of the bare <binding.ws/> > element so that it does not always provide SOAP? > 3) Does every conformant implementation have to support referencing > existing WSDL documents? > 4) Is a conformant implementation limited to exposing access to a > service only in the manner described by that service's bindings? > > 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 > > > *David Booz <booz@us.ibm.com>* > > 26/06/2008 13:21 > > > To > sca-bindings@lists.oasis-open.org > cc > > Subject > Re: [sca-bindings] Issue 25: Does binding.ws imply SOAP > > > > > > > > > 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 > > > > > > ------------------------------------------------------------------------ > > / > / > > /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]