Represent the recursive composition in runtime

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

Hi,

In the current code base, we use builder framework to create peer objects 
for runtime corresponding to the model and use the runtime metadata to drive 
the component interactions. This approach adds more complexity and 
redundance. I think now it should be possible to take advantage of the 
fully-resolved/configured model directly.

To acheive this, we need to normalize the model to represent the recursive 
composition in runtime. There are some cases:

1) For <include>, we need to merge all 
components/services/references/properties from the included composite to the 
enclosing composite.

2) Two components use the same non-composite implementation, for example, 
two components are implemented by the same java class. In this case, we 
should have two component model instances and one implementation model to 
avoid duplicate introspection.


3) Two components are implemented by the same composite

This is a more interesting case. Please see the diagram @ 
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy.

Path a: Composite1.ComponentB is implemented by Composite3
Path b: Composite2.ComponentD is implemented by Composite3

The service/reference can be promoted to different things:

a: the final target for the ComponentF.Reference1 is Composite1.ComponentA
b: the final target for the ComponentF.Reference1 is Composite1.Reference1 
(pointing to an external service)

The property can be set to different value following different composition 
path:

a: Composite3.ComponentE.Property1 is overrided by 
Composite1.ComponentB.Property1 (say value="ABC")
b: Composite3.ComponentE.Property1 is overrided by 
Composite2.ComponentD.Property1 (say value="XYZ")

To represent the fully-configured components, we need to clone the model for 
Composite3 for Path a and b so that it can be used to hold different 
resolved values. With the flatten structure, we should be able to fully 
configure the components at model level.

Am I on the right track? Feedbacks are welcome.

Once we agree on this, I'll continue to bring up the discussions on 
additional runtime behaviors beyond the model that needs to be provided by 
the component implementation or binding extensions to work with the core 
invocation framework.

Thanks,
Raymond 


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

Re: Represent the recursive composition in runtime

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

Comments inline.

Raymond Feng wrote:
> Hi,
>
> In the current code base, we use builder framework to create peer 
> objects for runtime corresponding to the model and use the runtime 
> metadata to drive the component interactions. This approach adds more 
> complexity and redundance. I think now it should be possible to take 
> advantage of the fully-resolved/configured model directly.
>
> To acheive this, we need to normalize the model to represent the 
> recursive composition in runtime. There are some cases:
>
> 1) For <include>, we need to merge all 
> components/services/references/properties from the included composite 
> to the enclosing composite.

We already do that (in CompositeUtil) but I'll review this code again to 
make sure that we're not missing anything.

>
> 2) Two components use the same non-composite implementation, for 
> example, two components are implemented by the same java class. In 
> this case, we should have two component model instances and one 
> implementation model to avoid duplicate introspection.
>

Yes, isn't it how it already works? or are we still introspecting the 
Java class twice? If it's not already working like you describe then 
we'll need to use the ArtifactResolver to resolve the implementation and 
make sure that the two components point to it.

>
> 3) Two components are implemented by the same composite
>
> This is a more interesting case. Please see the diagram @ 
> http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy. 
>
>
> Path a: Composite1.ComponentB is implemented by Composite3
> Path b: Composite2.ComponentD is implemented by Composite3
>
> The service/reference can be promoted to different things:
>
> a: the final target for the ComponentF.Reference1 is 
> Composite1.ComponentA
> b: the final target for the ComponentF.Reference1 is 
> Composite1.Reference1 (pointing to an external service)
>
> The property can be set to different value following different 
> composition path:
>
> a: Composite3.ComponentE.Property1 is overrided by 
> Composite1.ComponentB.Property1 (say value="ABC")
> b: Composite3.ComponentE.Property1 is overrided by 
> Composite2.ComponentD.Property1 (say value="XYZ")
>
> To represent the fully-configured components, we need to clone the 
> model for Composite3 for Path a and b so that it can be used to hold 
> different resolved values. With the flatten structure, we should be 
> able to fully configure the components at model level.

That looks like the best approach to me. I had started to add code to 
the model to clone model instances, and this already works for includes. 
I can help and go over the various model classes and make sure that we 
have the correct support for this kind of cloning. Then we'll need to 
implement the logic to propagate service/reference/property 
configuration from the top to the bottom of the composition hierarchy.

>
> Am I on the right track? Feedbacks are welcome.
>
> Once we agree on this, I'll continue to bring up the discussions on 
> additional runtime behaviors beyond the model that needs to be 
> provided by the component implementation or binding extensions to work 
> with the core invocation framework.
>
> Thanks,
> Raymond
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
Jean-Sebastien


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

Re: Represent the recursive composition in runtime

[Venkata Krishnan <fo...@gmail.com>]

Hi Raymond,

Thanks for bringing this up.  I did get a feel of this during a recent
addition that I did for supporting configuration of properties for
components implemented by a composite.  I was probably at loss to lay out an
illustration as well as you have done :).

1) I guess the 'includes' thing is presently there in CompositeUtil of the
assemly module and gets invoked as part of the 'wire' phase.

2) As far as cloning goes, its seems to be a good solution but I really
wonder if this would give a consistent view of the model.  I persceive a
'componentType' to be singular in a SCA Domain once loaded by the
Contribution and Composite being a 'componentType' makes be feel it should
also be left singular.  If the configuration of the implementation instances
with properties and reference settings happen only during build time for
other implementations that we have done up to now.. like the java-impl,
maybe this is the pattern we must follow for composite implementations too.
I feel this common treatment will help us in framing our SPIs.
consistently.  This is just about what occurs to me immd. and maybe there
are some perspectives I am missing out - please let me know of them.

Thanks

- Venkat


On 4/21/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> In the current code base, we use builder framework to create peer objects
> for runtime corresponding to the model and use the runtime metadata to
> drive
> the component interactions. This approach adds more complexity and
> redundance. I think now it should be possible to take advantage of the
> fully-resolved/configured model directly.
>
> To acheive this, we need to normalize the model to represent the recursive
> composition in runtime. There are some cases:
>
> 1) For <include>, we need to merge all
> components/services/references/properties from the included composite to
> the
> enclosing composite.
>
> 2) Two components use the same non-composite implementation, for example,
> two components are implemented by the same java class. In this case, we
> should have two component model instances and one implementation model to
> avoid duplicate introspection.
>
>
> 3) Two components are implemented by the same composite
>
> This is a more interesting case. Please see the diagram @
>
> http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy
> .
>
> Path a: Composite1.ComponentB is implemented by Composite3
> Path b: Composite2.ComponentD is implemented by Composite3
>
> The service/reference can be promoted to different things:
>
> a: the final target for the ComponentF.Reference1 is Composite1.ComponentA
> b: the final target for the ComponentF.Reference1 is Composite1.Reference1
> (pointing to an external service)
>
> The property can be set to different value following different composition
> path:
>
> a: Composite3.ComponentE.Property1 is overrided by
> Composite1.ComponentB.Property1 (say value="ABC")
> b: Composite3.ComponentE.Property1 is overrided by
> Composite2.ComponentD.Property1 (say value="XYZ")
>
> To represent the fully-configured components, we need to clone the model
> for
> Composite3 for Path a and b so that it can be used to hold different
> resolved values. With the flatten structure, we should be able to fully
> configure the components at model level.
>
> Am I on the right track? Feedbacks are welcome.
>
> Once we agree on this, I'll continue to bring up the discussions on
> additional runtime behaviors beyond the model that needs to be provided by
> the component implementation or binding extensions to work with the core
> invocation framework.
>
> Thanks,
> Raymond
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>