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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
