[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Re: BINDINGS-73
See comments inline. Simon David Booz wrote: > I've been waiting for the appropriate time to jump into this discussion.... > > First, Thank you Simon for spelling out the scenarios. I agree with > almost everything in your initial scenario outline. > > S1a) I don't see why you needed to use the SOAP intent at all given that > the binding config (via the @wsdlElement) was already constraining the port. > It wouldn't be necessary to use the SOAP intent on the binding in this case. It might be useful to put it on the service, as this would constrain what bindings are allowed to be used on the service. > S1b) The nuance here is whether or not the binding is chosen by the > assembler or by the deployment infrastructure. If the binding is chosen > by the assembler, then I agree with your outcome. If the binding is > chosen by the deployment infrastructure, then you will likely end up > with a SOAP.1_1 endpoint as the default qualifier will come into play. > > R3) I agree with the comments on this. The only way to accomplish this > scenario (with multiplicity 1..1) is to change the WSDL to contain only > the ports for the versions of SOAP you want and then the scenario > becomes identical to R1. > > Finally, see below for two in-line comments on BINDINGS-23. > > Dave Booz > STSM, BPM and SCA Architecture > Co-Chair OASIS SCA-Policy TC and SCA-J TC > "Distributed objects first, then world hunger" > Poughkeepsie, NY (845)-435-6093 or 8-295-6093 > e-mail:booz@us.ibm.com > > Simon Nash <oasis@cjnash.com> wrote on 05/20/2009 07:02:06 AM: > > > [image removed] > > > > Re: [sca-bindings] Re: BINDINGS-73 > > > > Simon Nash > > > > to: > > > > Simon Holdsworth > > > > 05/20/2009 07:04 AM > > > > Cc: > > > > sca-bindings > > > > Simon Holdsworth wrote: > > > > > > Simon, > > > > > > Adding my comments at the top.... > > > > > > I'm concerned about the scenario where there are multiple bindings > with > > > a reference with 1..1 multiplicity. My assumption had been that in > this > > > case the bindings were considered equal alternatives and one would be > > > chosen by the runtime - this is obviously not true. > > > > > > My understanding of what you're saying is that having one reference > > > binding.ws which points at a WSDL service with multiple available > ports > > > (all can be valid, one gets picked) is NOT the same has having > multiple > > > binding.ws which point at each individual port in the same service > (only > > > one is allowed to be valid). > > > > > If the reference multiplicity is 1..1, this is correct. > > > > > For references to non-SCA services, there's no wiring to subset the > > > bindings, so it seems that in this case you can't have multiple > binding > > > elements that can satisfy the policies on a 1..1 reference, which > > > invalidates scenario R3. In that case with the current rules for > > > defaults and exclusivity, R3 is not permitted. I don't personally see > > > that as sufficiently important to want to change the rules for the > intent. > > > > > This doesn't completely invalidate scenario R3. It just requires > > the client to use a 1..n reference instead of a 1..1 reference, and > > define multiple <binding.ws> elements for the different SOAP versions > > it is willing to use. If the service provides endpoints for more than > > one of these SOAP versions, the client will have more than one proxy > > injected and it can choose between the proxies in any way that it likes. > > In Java, it might choose the first proxy in the array or collection. > > > > However, this scenario has made me think we have a problem with the > > the current proposal for BINDINGS-23. This says that the SCA runtime > > MUST raise an error if it does not support the reference binding's > > WSDL port or WSDL binding. This does not seem correct if the reference > > has multiplicity 1..n. For example, the reference might have > > multiplicity 1..n with two bindings: B1 with a SOAP.1_1 intent and > > B2 with a SOAP.1_2 intent. If the SCA runtime only supports SOAP 1.1, > > I think this should not cause an error but result in a single proxy > > for B1 being injected into the reference. > > I disagree. An error is appropriate in this case. Bindings only appear > on a reference if they are being targetted outside the SCA Domain. The > presence of two bindings on the same reference is a clear indication > of multiple target services, and the presence of multiplicity 1..n > further enforces the point. If any of the bindings are not supportable > then an error is appropriate. > My comment was based on trying to meet the requirements of scenario R3, where the composite has been set up with the intention of allowing the reference-side code to call a non-SCA service using either SOAP 1.1 or SOAP 1.2. The presumption is that the reference-side code would be happy with either of these and does not need both. Howeve, I'm inclined to agree that making this an error case is preferable, given that the SCA runtime can't know whether or not the second binding was required by the business logic. This would mean that the R1 approach is the only way to handle this scenario. Simon > > > > There's another similar scenario where the right answer is less clear. > > The current proposal for BINDINGS-23 says that the binding MUST satisfy > > all the policy constraints of the SCA reference. I think this is correct > > as far as it goes, but it does not cover the case of the binding element > > having policy constraints that go beyond the policy constraints of the > > reference. For example, the reference might specify a SOAP intent and > > have multiplicity 1..n with two bindings: B1 with a SOAP.1_1 intent and > > B2 with a SOAP.1_2 intent. If B2's WSDL port or WSDL binding can't > > satisfy the SOAP.1_2 intent, and B1 is fine, we need to decide whether > > a) this should raise an error, or > > b) B2 should be ignored, with a single proxy for B1 injected into > > the reference > > I think you're right and we should change the words to refer to bindings > instead of references. The reason being that policy attached to a > reference always flows to the bindings, so policy on a binding implies > policy that might be attached to any parent element. > > It's an error per my previous comment. > > > > > Simon > > > > > Simon Nash <oasis@cjnash.com> wrote on 15/05/2009 16:52:10: > > > > > > > Simon, > > > > See responses inline below. > > > > > > > > Simon > > > > > > > > Simon Holdsworth wrote: > > > > > > > > > > Simon, > > > > > > > > > > Please see comments on R3 inlined below > > > > > > > > > > Simon Nash <oasis@cjnash.com> wrote on 15/05/2009 12:26:57: > > > > > > > > > > > > Simon, > > > > > > This scenario-based approach is very helpful. I have some > comments > > > > > > on R3 inline below. > > > > > > > > > > > > Simon > > > > > > > > > > > > Simon Holdsworth wrote: > > > > > > > > > > > > > > So here's the set of scenarios I can think of, assuming > qualified > > > > > > > intents are exclusive and require support limited to a > single SOAP > > > > > > > version, and no default. I think all scenarios are catered > > > for, so I > > > > > > > don't see any reason to change this behaviour, unless the > way > > > that the > > > > > > > scenarios are realized is unacceptable. > > > > > > > > > > > > > > Overall question, given that the set of SOAP versions is > > > > > open-ended, is > > > > > > > there a guaranteed way to be able to look at a namespace > and know > > > > > "this > > > > > > > is SOAP of some version" ? Or do you have to have a set of > > > known SOAP > > > > > > > namespaces to compare against? > > > > > > > > > > > > > > Scenarios for a service: > > > > > > > > > > > > > > S1) I want to expose a SOAP endpoint but I'm not immediately > > > fussed > > > > > > > about the SOAP version, although that may then be > specified by the > > > > > > > wsdlElement if present. > > > > > > > > > > > > > > Use SOAP intent on the service binding > > > > > > > > > > > > > > a) if I point at a SOAP binding/port of any version using the > > > > > > > wsdlElement attribute then that version of SOAP is supported > > > by the > > > > > > > endpoint. I think this should be exclusive and no other > versions > > > > > > > supported by the endpoint. > > > > > > > b) if I don't point at a SOAP binding/port using the > wsdlElement > > > > > > > attribute, then any number of any versions of SOAP may be > > > supported by > > > > > > > the endpoint. In this case a single binding.ws could > result in > > > > > multiple > > > > > > > WSDL binding elements to describe it. In all the other > cases I > > > > > believe > > > > > > > there is a 1-1 correspondance between WSDL and SCA bindings > > > for the > > > > > service > > > > > > > > > > > > > > S2) I want to expose a SOAP endpoint and it has to support a > > > single > > > > > > > specific SOAP version. > > > > > > > > > > > > > > Use a qualified SOAP intent (SOAP.1_1 or SOAP.1_2) on the > service > > > > > binding > > > > > > > > > > > > > > a) if I point at a SOAP binding/port using the wsdlElement > > > then it > > > > > must > > > > > > > match the specific SOAP version, if not its an error. > > > > > > > b) if I don't point at a SOAP binding/port using the > wsdlElement > > > > > > > attribute, then only the specified version of SOAP is > > > supported by the > > > > > > > endpoint. > > > > > > > > > > > > > > S3) I want to expose a SOAP endpoint that must support more > > > than one > > > > > > > specific SOAP version. > > > > > > > > > > > > > > This cannot be done with a single binding.ws element. > > > > > > > Have one binding.ws for each required SOAP version > following S2) > > > > > above. > > > > > > > Runtimes may to allow each binding.ws to be exposed at > the same > > > > > endpoint > > > > > > > address, but I don't think that's necessary for all SCA > runtimes. > > > > > > > > > > > > > > S4) I want to expose a SOAP endpoint that must at least > support a > > > > > > > specific SOAP version, but is allowed to support other SOAP > > > versions. > > > > > > > > > > > > > > This cannot be done with a single binding.ws element. > > > > > > > Use two binding.ws, following S1b) and S2) above. > > > > > > > > > > > > > > S5) I want to expose a web service endpoint, and have the > binding > > > > > > > details taken from what the wsdlElement points at, whatever > > > that is. > > > > > > > > > > > > > > Use no SOAP intent on the service binding. > > > > > > > > > > > > > > For a reference: > > > > > > > > > > > > > > R1) I want to invoke a service using SOAP, with the > specific SOAP > > > > > > > version resolved by choice of port from the wsdlElement. > > > > > > > > > > > > > > Use SOAP intent on the reference binding. > > > > > > > > > > > > > > When determining the set of available WSDL ports, only > those that > > > > > > > support SOAP (of any version) and satisfy the other > binding policy > > > > > > > requirements are included. > > > > > > > > > > > > > > R2) I want to invoke a service using a specific SOAP version. > > > > > > > > > > > > > > Use a qualified SOAP intent (SOAP.1_1 or SOAP.1_2) on the > > > reference > > > > > binding > > > > > > > > > > > > > > When determining the set of available WSDL ports, only > those that > > > > > > > support SOAP of the specified version and satisfy the other > > > binding > > > > > > > policy requirements are included. > > > > > > > > > > > > > > R3) I want to invoke a service using any of a given set > of SOAP > > > > > versions. > > > > > > > > > > > > > > This cannot be done with a single binding.ws element. > > > > > > > Have one binding.ws for each required SOAP version following > > > R2) above. > > > > > > > > > > > > > The words "any of a given set" and "required SOAP version" > don't > > > > > > seem consistent. > > > > > > > > > > The intention of this wording was to say that the requirement > is to be > > > > > able to invoke the service using one of a set of specific SOAP > > > versions, > > > > > e.g. pick one of SOAP 1.1 and SOAP 1.2. > > > > > > > > > > Having said that I don't think this is valid but not particularly > > > > > compelling scenario. > > > > > > > > > > > I think the scenario is that the client wants > > > > > > to use (for example) either 1_1 or 1_2 and requires the service > > > > > > to provide at least one of these. Using the approach you are > > > > > > suggesting, the service would need to make endpoints > available for > > > > > > both 1_1 and 1_2 so that both of the <binding.ws> elements > on the > > > > > > reference are valid. If the service only had (for example) a > > > > > > 1_1 endpoint, the client's 1_2 reference binding couldn't be > > > > > > satisfied and the client deployment would fail. > > > > > > > > > > I imagined that this would be a subset of the set of versions > of SOAP > > > > > provided by the service - otherwise of course this won't work as > > > you say. > > > > > > > > > OK, I understand this now. > > > > > > > > > > A further inconvenience is that the client implementation would > > > > > > need to provide a reference with multiplicity 1..n and the > > > > > > application code would receive an array of reference proxies, > > > > > > one for each available SOAP version. The choice between these > > > > > > would need to be made by business logic instead of being left > > > > > > to the SCA runtime. > > > > > > > > > > I'm not sure I follow that. Does a reference have to have > > > multiplicity > > > > > 1..n to have multiple valid bindings? What would go wrong if the > > > > > multiplicity is 1..1 and there are multiple bindings that > satisfy the > > > > > constraints? > > > > > > > > > This is defined by the Assembly spec in sections 4.3.1 and 4.3.1.1. > > > > > > > > Section 4.3.1 gives various ways of defining target services for > > > > a reference. Points 2 and 3 in the numbered list relate to > > > > specifying targets using binding elements in the reference. > > > > My reading of this is that there will be one target service for > > > > each binding element that satisfies either point 2 or point 3. > > > > > > > > Section 4.3.1.1 gives the rules for matching target services > > > > (as defined in section 4.3.1) to reference multiplicity. If there > > > > are two bindings that produce target services and the reference > > > > has multiplicity 1..1, this is an error. > > > > > > > > Simon > > > > > > > > > > Simon > > > > > > > > > > > > > R4) I want to invoke a service using any port that my > runtime can > > > > > support. > > > > > > > > > > > > > > Use no SOAP intent on the reference binding. > > > > > > > > > > > > > > When determining the set of available WSDL ports, all that > > > satisfy the > > > > > > > binding policy requirements are included. > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > *Simon Nash <oasis@cjnash.com>* > > > > > > > > > > > > > > 14/05/2009 20:22 > > > > > > > > > > > > > > > > > > > > > To > > > > > > > Eric Johnson <eric@tibco.com> > > > > > > > cc > > > > > > > David Booz <booz@us.ibm.com>, > sca-bindings@lists.oasis-open.org > > > > > > > Subject > > > > > > > [sca-bindings] Re: BINDINGS-73 (was: Suggested wording for > > > > > POLICY-83) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I updated the subject line, as this is now a BINDINGS-73 > > > discussion. > > > > > > > > > > > > > > Eric has presented some important use cases for > preserving the > > > current > > > > > > > rules in the WS Binding spec. In addition, I think the > following > > > > > > > should be allowed: > > > > > > > > > > > > > > 1. A service with the unqualified SOAP intent, exposed > using a > > > > > > > SOAP 1.2 WSDL binding or WSDL port (specified via > > > @wsdlElement). > > > > > > > > > > > > > > 2. A reference with the unqualified SOAP intent that uses a > > > > > > > SOAP 1.2 WSDL binding or WSDL port (specified via > > > @wsdlElement). > > > > > > > > > > > > > > Simon > > > > > > > > > > > > > > Eric Johnson wrote: > > > > > > > > Ugh. > > > > > > > > > > > > > > > > I find myself confused by the entire thread. To > clarify, here > > > > > are the > > > > > > > > scenarios I care about: > > > > > > > > > > > > > > > > Here's my simple notion: I put binding.ws on a > *service*, > > > with > > > > > a SOAP > > > > > > > > intent - not further qualified. > > > > > > > > > > > > > > > > I want it to be possible for the conforming SCA runtime to > > > > > expose BOTH a > > > > > > > > SOAP 1.1 and SOAP 1.2 endpoint at the same URI. That > is, I > > > want to > > > > > > > > follow in the useful pattern of "being lenient in what I > > > accept, and > > > > > > > > strict in what I produce." > > > > > > > > > > > > > > > > For the reference case, when putting a binding.ws on a > > > > > *reference*, with > > > > > > > > a SOAP intent - again, not further qualified - and then > > > pointing > > > > > at a > > > > > > > > WSDL service element, and it contains ports with different > > > > > versions of > > > > > > > > SOAP supported, can the conforming SCA runtime choose any > > > of those > > > > > > > > ports? There may be orthogonal concerns (security), > which will > > > > > > > > discriminate amongst the available ports, and being > forced to > > > > > use SOAP > > > > > > > > 1.1 as the default arbitrarily over-constrains the > solution, > > > > > possibly to > > > > > > > > the point of error. > > > > > > > > > > > > > > > > Based on Dave's last response, neither of the above > > > scenarios is the > > > > > > > > same as "resolving the intent to a binding" based on the > > > the default > > > > > > > > qualifier, at least not if an SCA runtime MUST use the > default > > > > > qualifier. > > > > > > > > > > > > > > > > -Eric. > > > > > > > > > > > > > > > > Simon Nash wrote: > > > > > > > >> Dave, > > > > > > > >> Thanks, this helps. I understand your interpretation of > > > what the > > > > > > > >> unqualified SOAP intent means now. Let's continue this > > > discussion > > > > > > > >> in the Bindings TC under BINDINGS-73. > > > > > > > >> > > > > > > > >> Simon > > > > > > > >> > > > > > > > >> David Booz wrote: > > > > > > > >>> ...sigh... > > > > > > > >>> > > > > > > > >>> "If the intent is attached in an unqualified form > then any > > > > > version of > > > > > > > >>> SOAP is acceptable." > > > > > > > >>> > > > > > > > >>> That statement is simply repeating the meaning of an > > > > > unqualified but > > > > > > > >>> qualifiable intent, i.e. it can always be further > > > qualified by > > > > > > > >>> another part of the composite. What does the SOAP > intent > > > mean > > > > > to an > > > > > > > >>> assembler that finds it on a service or reference > > > element? It > > > > > means > > > > > > > >>> that he must find a binding that can provide SOAP. Any > > > version of > > > > > > > >>> SOAP is fine because the developer did not constrain > it. The > > > > > > > >>> assembler may have to add the 1_2 qualifier if that's > > > what he > > > > > wants > > > > > > > >>> to provide. If he says nothing, the FW will handle > > > resolving the > > > > > > > >>> intent to a binding (or policySet) based on the default > > > qualifier. > > > > > > > >>> > > > > > > > >>> Dave Booz > > > > > > > >>> STSM, BPM and SCA Architecture > > > > > > > >>> Co-Chair OASIS SCA-Policy TC and SCA-J TC > > > > > > > >>> "Distributed objects first, then world hunger" > > > > > > > >>> Poughkeepsie, NY (845)-435-6093 or 8-295-6093 > > > > > > > >>> e-mail:booz@us.ibm.com > > > > > > > >>> > > > > > > > >>> Inactive hide details for Simon Nash ---05/14/2009 > 10:31:14 > > > > > > > >>> AM---Dave, Here is an extract from the Policy spec CD02 > > > rev1:Simon > > > > > > > >>> Nash ---05/14/2009 10:31:14 AM---Dave, Here is an > extract > > > from the > > > > > > > >>> Policy spec CD02 rev1: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > 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/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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/ > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]