Queries on Chianti spi.model

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

Hi Jim / Jeremy & others familiar with Chianti,

I have just started with Chianti.  Am looking at the SPI first and in that
the model.   I have some questions on the classes there.  Please help me
understand with your answers.   As answers you may even point me to other
portions of the codebase looking at which I can get answers.

1) What is the purpose of the class Implementation?  It only wraps a
ComponentType?  And why a CompositeImplementation?  Since an implementation
is centred round a ComponentType, won't this suffice?

2) What is the need for a type 'Include'?  From what I saw, the
CompositeComponentType should be enough after all that is what the Include
is all about - a CompositeComponentType?  It would also be good to have the
attribute 'scdlLocation' as part of the CompositeComponentType after all it
is relevant to it.  With that I see no other specific role for 'Include'?

3) Would it make sense to have some sort of object identifier attribute for
ComponentType - like a name or a version number?  In future would we have
some (say management) scenarios where we may need to track components by the
name or version of ComponentTypes that they configure?

Hope to get to some speed with Chianti with some initial handholding from
you folks.

Thanks.

- Venkat

Re: Queries on Chianti spi.model

[Jeremy Boynes <jb...@apache.org>]

Comments inline...

On Jul 20, 2006, at 1:03 AM, Venkata Krishnan wrote:

> Hi Jim / Jeremy & others familiar with Chianti,
>
> I have just started with Chianti.  Am looking at the SPI first and  
> in that
> the model.   I have some questions on the classes there.  Please  
> help me
> understand with your answers.   As answers you may even point me to  
> other
> portions of the codebase looking at which I can get answers.
>
> 1) What is the purpose of the class Implementation?  It only wraps a
> ComponentType?  And why a CompositeImplementation?  Since an  
> implementation
> is centred round a ComponentType, won't this suffice?

Implementation is an abstract concept that forms the base of a tree  
that represents the different physical artifacts that can be  
component implementations. For example, for a component implemented  
in Java, the JavaImplementation specifies the Class to use, for a  
Groovy component the script, for a Composite the associated SCDL.

Some parts of an implementation are fixed - for example, you cannot  
change the bytecode of a Class without redefining it. Other parts  
though are configurable - for example, the SCA aspects such as what  
are Services, References and Properties. These configuration points  
are supported by all implementations although their representation in  
the physical artifact may be different.

What, IMO, is poorly defined in the spec is a top-down model for  
component definition and configuration. By this I mean one where you  
just start with a model of your architecture  and build it up out of  
service components without worrying at that stage what the  
implementation of those components would be. In that model all you  
need are Components and ComponentTypes - Implementations come later  
as you map the model to physical artifacts. However, at this time the  
spec relates a Component to its ComponentType though an Implementation.

> 2) What is the need for a type 'Include'?  From what I saw, the
> CompositeComponentType should be enough after all that is what the  
> Include
> is all about - a CompositeComponentType?  It would also be good to  
> have the
> attribute 'scdlLocation' as part of the CompositeComponentType  
> after all it
> is relevant to it.  With that I see no other specific role for  
> 'Include'?

Include represents the actual inclusion rather than what is included.  
scdlLocation is part of that inclusion (where to get it from) rather  
than part of the ComponentType itself. There may be other ways of  
specifying where the artifact may be found (including none i.e. leave  
it to the runtime to resolve) and the same ComponentType may be  
located in multiple places.

> 3) Would it make sense to have some sort of object identifier  
> attribute for
> ComponentType - like a name or a version number?  In future would  
> we have
> some (say management) scenarios where we may need to track  
> components by the
> name or version of ComponentTypes that they configure?

In the spec ComponentTypes are unidentified but when you think about  
a top-down view then some form of identity is essential.

Similarly, the spec is also silent on versioning not just for  
ComponentType but also for interfaces, implementations etc. We should  
add this in as we go (as it is hard to add in later).

--
Jeremy


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