On Fri, Aug 5, 2011 at 4:53 PM, Mike Edwards <mike.edwards.inglen...@gmail.com> wrote: > Greg, > > I'll try to address this with some inline replies, but I get the feeling > that maybe a conf call will be needed to interactively work on your > concerns. > > > Yours, Mike. > > On 05/08/2011 16:12, Greg Dritschler wrote: >> >> Simon, >> >> You seem to be saying there's an equivalence between binding.sca @uri and >> reference target in terms >> of promotion behavior. I cannot find anything in the spec that supports >> that. >> >> Here is the description of nonOverridable: >> >> 876 nonOverridable : boolean (0..1) - a boolean value, "false" by >> default, which indicates >> whether this >> 877 component reference can have its targets overridden by a composite >> reference which promotes the >> 878 component reference. >> 879 If @nonOverridable==false, if any target(s) are configured onto the >> composite references which >> 880 promote the component reference, then those targets replace all the >> targets explicitly >> declared on the >> 881 component reference for any value of @multiplicity on the component >> reference. If no targets are >> 882 defined on any of the composite references which promote the >> component reference, then any >> 883 targets explicitly declared on the component reference are used. >> This means in effect that >> any targets >> declared on the component reference act as default targets for that >> reference. >> >> This description explicitly talks about reference targets. There is >> nothing here that mentions >> bindings. This description also doesn't explain how nonOverridable >> applies to higher-level >> composites that reuse this composite. It only describes the interaction >> between the composite >> reference and the component reference within the composite itself. If >> targets are specified on both >> an 'outer' component reference and its promoted 'inner' component >> reference, what is supposed to >> happen? Is it dependent on the setting of nonOverridable? I can't find >> anything that addresses this. > > There are a lot of bones to pick out of here - let me see if I can > disentangle them. > > 1) This section talks about "targets" of a reference in the sense implied by > section 4.3.1 of the specification. There are 7 ways described in there for > specifying a target service for a reference, which includes binding specific > stuff like binding @uri values. So it is intended to cover bindings as well > as the other ways of specifying a target service. > > 2) How does nonOverridable apply to a higher level COMPONENT (not composite) > that reuse this composite? The answer is that it does not. ie the setting > has no effect on the configuration of the higher level component - if it > did, there would be a description in the spec - there isn't any. > > What effect nonOverridable has is on the reference that has nonOverridable > on it. It basically says whether a promotion obliterates any other targets > the reference may have or whether the promotion simply adds targets. The > DEFAULT is obliteration. ie if you promote a reference then the target > identified by the higher level component is what actually gets used. Only > if nothing is supplied at the higher level could a target on the lower level > get used (and that is the purpose of this bit complexity - it gives a > default (local) target in the case the higher level component does not > configure one. > > The relation between the higher level component reference and the lower > level component reference that is promoted is essentially captured in this > statement in section 4.3.1: > > "6. Through the promotion of a component reference by a composite > reference of the composite containing the component (the target service is > then identified by the configuration of the composite reference)" > > and "configuration" here means the configuration supplied by the component > using the composite as an implementation (there is other material that > covers the generalalities of how a component configuration configures ANY > implementation - and that applies equally to composite implementations as it > does to Java or any other type. > > If targets are specified on the outer level and the inner level, then what > is supposed to happen is described in the section that deals with > nonOverridable - and there are 2 cases: > > 1) "If @nonOverridable==false, if any target(s) are configured onto the > composite references which promote the component reference, then those > targets replace all the targets explicitly declared on the component > reference for any value of @multiplicity on the component reference. If no > targets are defined on any of the composite references which promote the > component reference, then any targets explicitly declared on the component > reference are used. This means in effect that any targets declared on the > component reference act as default targets for that reference." > > > 2) "If @nonOverridable==true, and the component reference @multiplicity is > 0..n or 1..n, any targets configured onto the composite references which > promote the component reference are added to any references declared on the > component reference - that is, the targets are additive." > > ...now here note that "targets" are meant in the sense implied in 4.3.1 - a > target service specified by any means - @target, binding @uri, <wire/> > element (note: autowire is excluded by definition since it can only come > into play where there is NO other way of establishing a target). > > So - this would mean for example that if the lower level reference had > <binding.ws uri="foobar"/>, > but was promoted and the higher level component configured the (higher > level) reference with @target="SomeComponent/SomeService", then there would > be one and only one target for the lower level reference - the > SomeComponent/SomeService service as configured by the higher level, > assuming nonOveridable=false (the default). >> >> Here is the description of how bindings are overridden. >> >> 900 binding : Binding (0..n) - A reference element has zero or more >> binding elements as >> children.If no >> 901 binding elements are specified for the reference, then the bindings >> specified for the equivalent >> 902 reference in the componentType of the implementation MUST be used. >> If binding elements are >> 903 specified for the reference, then those bindings MUST be used and >> they override any bindings >> 904 specified for the equivalent reference in the componentType of the >> implementation. [ASM50012] >> >> There is nothing in those lines talking about nonOverridable having any >> effect on binding override. > > But this only applies to the bindings on the COMPONENT reference and whether > any bindings are picked up (by defaulting) from the implementation of the > COMPONENT. > > Whether ANY of these bindings get used to identify target services depends > on the OTHER configuration of the reference - and in particular on whether > the reference is promoted. If its promoted, then in the default case, all > the "local" configuration of the reference like the bindings is obliterated. > (If nonOverridable is set true, then this is not the case, since everything > then is additive) > >> >> So where is this equivalence between binding uri and reference target >> stated? Does it apply just to >> binding.sca or to all bindings? >> > In my opinion, this equivalence is defined in section 4.3.1, which declares > 7 ways in which a target service can be configured for a reference. @target > is one way. A binding with some resolved target is another. @uri is ONE > way for a binding to have a resolved target (only way for binding.sca, but > other ways are available for other bindings, such as a pointer to some WSDL > service element for binding.ws). > > > PS I agree that this is complex. I tried to keep nonOverridable out of the > spec but I lost. >
Hmmm, now I'm not sure whether the example I posted is right or not. Specifically because of this debate about if/how the specification of nonOverrideable has an impact on the resulting targets for the runtime component. I didn't show the composite reference overriding the default provided by the promoted component reference and I suspect that's where the examples go wrong. I'll re-read what Mike said and try and be more precise but this seems to be more tricky than I thought it was. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
