Jeremy, thanks :-) and I am going to take more help like this to graduate into Tuscany-Java.
- Comments Inline - Venkat On 7/20/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
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.
I guess this is good to be a part of the JavaDoc for the class Implementation. If you agree then I can add it up and submit a patch or would it be less work for you if you actually did it. Let me know. 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.
This gives better clarity to what was running in my mind. I was wondering if a ComponentType and an Implementation should actually be 'tied' in a ComponentDefinition. Whether this 'tie' is best done as part of the Component Defining or Component Configuring is also another point worth considering. So is this something that you are going to take to the specs for consideration.
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.
By scdl files here don't we mean the files that will contain a Composite's definition. And then my understanding is that by the CompositeComponentType abstraction is what encapsulates this Composite's definition?
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]
