On 09/08/2011 23:33, Greg Dritschler wrote:
New question:  What is the scope for resolving a COMPOSITE reference target?  
It seems like it is
resolved in the context of the using composite.

I recall seeing something about this somewhere but all I can find is this:
http://www.osoa.org/jira/browse/ASSEMBLY-5

Greg
Greg,

If a composite reference has a target defined, either via @target or via some binding declared on the reference, these are to be taken as DEFAULTS which apply when the composite is used as an implementation by some component (ie a component in a "higher level" composite). These targets have no meaning within the composite in which they are declared.

The configuration of the implementation is supplied by that using component - and the component can either supply all its own configuration (this is expected to be the 99% default situation) or it can decide to use the defaults supplied by the implementation (ie by the composite reference in this case).

When viewed this way, the target(s) of the higher level component reference are in the context of the higher level component - either its composite or the Domain, depending on the level of that component.

In my opinion, it is not a wise procedure to define targets in a composite reference either using @target or using an SCA binding with a @uri declared. The reason for this is that the writer of the composite cannot normally know the context in which it is going to be used - so for example if they had @target="fooComponent/barService", how could they be sure that the using component was in any kind of context that had a component with the name fooComponent.

The idea of setting a default binding & target using a "concrete" binding such as binding.ws makes more sense - ie the composite writer can say - "here is a reference for this composite implementation & I know that there is one Web service over there that will satisfy the reference".

HOWEVER, either way, what counts is the confuguration on the component reference - whether this was explicity set by the component or was a default value derived from the composite reference - and it is the higher level component reference configuration that is then pushed down onto the ("proxy") component reference at the lower level (ie the component reference identified in the composite reference @promotes attribute).

Note that this process of an implementation potentially having a default configuration for a reference applies in principle to ANY type of implementation, not only to a composite - ie a Java implementation class could in principle have a reference with a binding & target defined.


I hope that this helps.


Yours,  Mike.

Reply via email to