Build runtime wire/invocation chains for a composite hierarchy

[Raymond Feng <en...@gmail.com>]

Hi,

I'm trying to indentify all the paths of SCA component interactions which 
require to have runtime wires/invocation chains.

By the SCA spec, there are three cases for the wiring:

1) Component.Reference (A.ref1) --is wired to--> Component.Service (B.svc1)
--------------------------------------------------------------------------------------------------
1.1) If both the service and reference are defined by non-composite 
components, then the runtime wire is as simple as A.ref1-->B.svc1.

1.2) If the service is defined on a composite component, then it can be 
further resolved to the orginal atomic component service following the 
service promotion chain.

For example, A.ref1 --> B.svc1 (B is implemented by another composite and 
B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 --> C.svc1

1.3) If the reference is defined on a composite component, then it can be 
further resolved to the orginal atomic component reference following the 
reference promotion chain.

For example, A.ref1 --> B.svc1 (A is implemented by another composite and 
A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 --> B.svc1

2) Composite.Reference (Composite1.ref1) --promotes--> Component.Reference 
(B.ref1)
-----------------------------------------------------------------------------------------------------------------
If Composite1 is the top-level composite, and the B is a non-composite 
component, then the runtime wire will be: B.ref1 --> Composite1.ref1

If Composite1 is used to implement a component A in Composite2, then we need 
to futher check if A.ref1 is promoted or wired until we hit the end of the 
promotion chain. The final target will be either a composite reference or a 
component service that the out-most reference is wired to. For example, if 
A.ref1 is wired to D.svc1 in Composite2, then the runtime wire is B.ref1 --> 
D.svc1. If A.ref1 is promoted by Composite2.ref1, then the runtime wire is 
B.ref1 --> Composite2.ref1.

If B is a composite component, then we need to find out the final component 
reference that B.ref1 promotes. For example, it promotes D.ref1, then the 
runtime wire is D.ref1 --> C.ref1

3) Composite.Service (Composite1.svc1) --promotes--> Component.Service 
(A.svc1)
-----------------------------------------------------------------------------------------------------------
The source will be the outmost service on the promotion chain.  For example, 
if Composite2.svc1 promotes B.svc1 and B is implemented by Composite1, then 
it is Composite2.svc1.

The target will be the innermost service on the promotion chain. For 
example, if A is implemented by Composite3 and Composite3.svc1 promotes 
C.svc1, then it is C.svc1.

* Please note, due to the spec limitation, the composite service cannot 
promote a composite reference directly.

Based on the above scenarios, it seems that we can create runtime wires 
using the following algorithm (assuming multiplicity = 1..1). The key is to 
get a final list of targets and selected bindings.

1) Runtime wire for references: For each of the references (r1) on 
non-composite components, find the outmost reference (r0) on the reference 
promotion chain. Then get the targets and selected bindings from r0. If SCA 
binding is used for a target, it can be further optimized to use the 
orginally promoted component service. The runtime wire should be created 
between the r1 and a target (either a component service with SCA binding or 
a reference binding) from r0.

2) Runtime wire for service promotions: For each of the service1 (s1) on 
non-composite components, find the outmost service (s0, can be the same as 
s1) on the service promotion chain. Create a runtime wire between the 
selected binding of s0 and the component that defines s1. (Can we assume 
that s1 is always local to s0?)

The service/reference promotions make the picture complicated. I hope my 
thought makes sense.

Thanks,
Raymond


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Build runtime wire/invocation chains for a composite hierarchy

[Jean-Sebastien Delfino <js...@apache.org>]

Raymond Feng wrote:
> Hi,
>
> I'm trying to indentify all the paths of SCA component interactions 
> which require to have runtime wires/invocation chains.
>
> By the SCA spec, there are three cases for the wiring:
>
> 1) Component.Reference (A.ref1) --is wired to--> Component.Service 
> (B.svc1)
> -------------------------------------------------------------------------------------------------- 
>
> 1.1) If both the service and reference are defined by non-composite 
> components, then the runtime wire is as simple as A.ref1-->B.svc1.
>
> 1.2) If the service is defined on a composite component, then it can 
> be further resolved to the orginal atomic component service following 
> the service promotion chain.
>
> For example, A.ref1 --> B.svc1 (B is implemented by another composite 
> and B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 --> 
> C.svc1
>
> 1.3) If the reference is defined on a composite component, then it can 
> be further resolved to the orginal atomic component reference 
> following the reference promotion chain.
>
> For example, A.ref1 --> B.svc1 (A is implemented by another composite 
> and A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 --> 
> B.svc1
>
> 2) Composite.Reference (Composite1.ref1) --promotes--> 
> Component.Reference (B.ref1)
> ----------------------------------------------------------------------------------------------------------------- 
>
> If Composite1 is the top-level composite, and the B is a non-composite 
> component, then the runtime wire will be: B.ref1 --> Composite1.ref1
>
> If Composite1 is used to implement a component A in Composite2, then 
> we need to futher check if A.ref1 is promoted or wired until we hit 
> the end of the promotion chain. The final target will be either a 
> composite reference or a component service that the out-most reference 
> is wired to. For example, if A.ref1 is wired to D.svc1 in Composite2, 
> then the runtime wire is B.ref1 --> D.svc1. If A.ref1 is promoted by 
> Composite2.ref1, then the runtime wire is B.ref1 --> Composite2.ref1.
>
> If B is a composite component, then we need to find out the final 
> component reference that B.ref1 promotes. For example, it promotes 
> D.ref1, then the runtime wire is D.ref1 --> C.ref1
>
> 3) Composite.Service (Composite1.svc1) --promotes--> Component.Service 
> (A.svc1)
> ----------------------------------------------------------------------------------------------------------- 
>
> The source will be the outmost service on the promotion chain.  For 
> example, if Composite2.svc1 promotes B.svc1 and B is implemented by 
> Composite1, then it is Composite2.svc1.
>
> The target will be the innermost service on the promotion chain. For 
> example, if A is implemented by Composite3 and Composite3.svc1 
> promotes C.svc1, then it is C.svc1.
>
> * Please note, due to the spec limitation, the composite service 
> cannot promote a composite reference directly.
>
> Based on the above scenarios, it seems that we can create runtime 
> wires using the following algorithm (assuming multiplicity = 1..1). 
> The key is to get a final list of targets and selected bindings.
>
> 1) Runtime wire for references: For each of the references (r1) on 
> non-composite components, find the outmost reference (r0) on the 
> reference promotion chain. Then get the targets and selected bindings 
> from r0. If SCA binding is used for a target, it can be further 
> optimized to use the orginally promoted component service. The runtime 
> wire should be created between the r1 and a target (either a component 
> service with SCA binding or a reference binding) from r0.
>
> 2) Runtime wire for service promotions: For each of the service1 (s1) 
> on non-composite components, find the outmost service (s0, can be the 
> same as s1) on the service promotion chain. Create a runtime wire 
> between the selected binding of s0 and the component that defines s1. 
> (Can we assume that s1 is always local to s0?)
>
> The service/reference promotions make the picture complicated. I hope 
> my thought makes sense.
>
> Thanks,
> Raymond
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

The paths you have identified and the algorithm that you describe make 
sense to me, but I'm not sure that we actually need to create "runtime 
wires". My understanding is that references have bindings and target 
services are provided through bindings as well. To make a reference talk 
to a target service we just need to select the appropriate binding 
(assuming that the SCA binding can do a direct in-memory call when the 
target service is running in the same SCA contribution and runtime) and 
configure the reference with the endpoint of the target service (or 
/bindings/endpoints/targets when multiplicity > 1).

Target and binding configuration can be overriden at multiple levels of 
composition, so a simple way to handle that is to recursively walk the 
nested compositions and propagate the relevant configuration to the 
innermost component services and references. That's what I have started 
to do in the CompositeProcessor.wire() method to be able to present a 
fully configured model to the runtime so that it doesn't have to dig for 
that configuration at the various levels.

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org