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.
