Cleaning up the configuration and initialization of a module component

[Jean-Sebastien Delfino <js...@gmail.com>]

On my return trip from the Apache Conf I took a look at the code in the 
o.a.t.core packages and I think we need to clean up a little how we 
configure and initialize an SCA module component. Here is my 
understanding of the current design (intentionally excluding the 
creation of proxies here as I think we need to go step by step here and 
fix how we create proxies in a second step).

To initialize an SCA module component, we go through several steps:
1. Load the Assembly model, using Loaders
2. Initialize the assembly model, by calling initialize() on the model
3. Build runtime configurations, using RuntimeConfigurationBuilders
3. Create runtime contexts.

A Loader is responsible for loading SCDL files and/or any other source 
of metadata into our Assembly model. We should be able to register 
multiple specialized loaders with the runtime (to process multiple 
sources of metadata for example).

To initialize an assembly model object (for example a ModuleComponent 
object) we call it's initialize method. An assembly model object is 
responsible for driving the initialization of its children and related 
model objects.

A RuntimeConfigurationBuilder takes an Assembly model and builds 
RuntimeConfiguration objects. RuntimeConfiguration objects are stored in 
the corresponding Assembly model objects. Multiple builders can be 
registered with the runtime, for example the implementor of the Java 
component type will contribute a JavaComponentConfigurationBuilder, the 
implementor of an XSLT component type would contribute an 
XSLTComponentConfigurationBuilder etc.

A RuntimeConfiguration object is a factory for runtime Contexts 
(SimpleComponentContexts, ExternalServiceContext, EntryPointContext and 
AggregateComponentContexts). At some point I was not sure if a Context 
was supposed to manage one instance or all instances of a component, but 
I think that we now agree that we have one Context per component 
instance (please jump in if you think that this is not right).

Our code does not completely reflect this design right now. We're almost 
there but there are still a few differences. Some of the Configuration 
classes are in a oat.core.builder package instead of config, 
TuscanyModuleComponentContextBuilder builds a context directly instead 
of a RuntimeConfiguration, we're missing the Context interfaces for 
ExternalService and EntryPoint etc. I'm working on fixing that now and 
making good progress so we should be in a reasonably good shape by 
Friday to attack the next level of integration with the Subsystem layer.

-- 
Jean-Sebastien Delfino

Re: Cleaning up the configuration and initialization of a module component

[Jim Marino <jm...@myroma.net>]

Comments inline
On Dec 15, 2005, at 8:45 AM, Jean-Sebastien Delfino wrote:

> On my return trip from the Apache Conf I took a look at the code in  
> the o.a.t.core packages and I think we need to clean up a little  
> how we configure and initialize an SCA module component. Here is my  
> understanding of the current design (intentionally excluding the  
> creation of proxies here as I think we need to go step by step here  
> and fix how we create proxies in a second step).
>
> To initialize an SCA module component, we go through several steps:
> 1. Load the Assembly model, using Loaders
> 2. Initialize the assembly model, by calling initialize() on the model
> 3. Build runtime configurations, using RuntimeConfigurationBuilders
> 3. Create runtime contexts.
>
> A Loader is responsible for loading SCDL files and/or any other  
> source of metadata into our Assembly model. We should be able to  
> register multiple specialized loaders with the runtime (to process  
> multiple sources of metadata for example).
>
> To initialize an assembly model object (for example a  
> ModuleComponent object) we call it's initialize method. An assembly  
> model object is responsible for driving the initialization of its  
> children and related model objects.
>
> A RuntimeConfigurationBuilder takes an Assembly model and builds  
> RuntimeConfiguration objects. RuntimeConfiguration objects are  
> stored in the corresponding Assembly model objects. Multiple  
> builders can be registered with the runtime, for example the  
> implementor of the Java component type will contribute a  
> JavaComponentConfigurationBuilder, the implementor of an XSLT  
> component type would contribute an  
> XSLTComponentConfigurationBuilder etc.
>
> A RuntimeConfiguration object is a factory for runtime Contexts  
> (SimpleComponentContexts, ExternalServiceContext, EntryPointContext  
> and AggregateComponentContexts). At some point I was not sure if a  
> Context was supposed to manage one instance or all instances of a  
> component, but I think that we now agree that we have one Context  
> per component instance (please jump in if you think that this is  
> not right).
Yes, this is correct.  It is generally 1:1. I think the confusing  
part is an instance may possibly be 1 or more instances of an object  
although that is not the case for Java POJOs
>
> Our code does not completely reflect this design right now. We're  
> almost there but there are still a few differences. Some of the  
> Configuration classes are in a oat.core.builder package instead of  
> config, TuscanyModuleComponentContextBuilder builds a context  
> directly instead of a RuntimeConfiguration, we're missing the  
> Context interfaces for ExternalService and EntryPoint etc. I'm  
> working on fixing that now and making good progress so we should be  
> in a reasonably good shape by Friday to attack the next level of  
> integration with the Subsystem layer.
Great. One other thing I was thinking about in terms of the builders  
is that they should have the knowledge of particular wiring schemes.   
For example, they should be able to do things like resolve autowires  
(if we support that) against the model so that the model gets built  
up and the injection container does not need to know anything about  
what actually specifies the references.  This way, people can create  
their own configuration semantics/additions.
>
> -- 
> Jean-Sebastien Delfino
>