Hi Sebastien, I agree with your suggestions on two accounts...
- its really good to have the model defined around interfaces as it gives the flexibility to improve / modify the implementations we choose over a period of time without the impacting the core which I assume will use only these interfaces. If we use factories to instantiate model objects (i.e. specific implementations of these interfaces) that will keep the core futher away from impacts of changes to implementation of the SPI model. We could probably configure the factory class to be used as part of the scdl - for example as the property of a Loader(s). Hope I am making sense? - Specific to the case of references, I did imagine that we may have to clearly abstract out references at componentType level, component level and composite level as there is something specific in 'references' to each level - for example the 'promote' is something that is specific to the composite level. I have started to make some changes in the SPI model of the kernel. But then, it is not going to be difficult for me to migrate this to your proposed design in the 'assembly'. So I shall continue for now in the kernel unless you see some issues. Thanks. - Venkat On 3/13/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
[snip] Jean-Sebastien Delfino wrote: > comments inline > > Venkata Krishnan wrote: >> Hi, >> >> I am trying to bring the SPI model and the Loaders in sync with the >> current >> level of the specs as available on OSOA site. I am currently looking at >> 'references' - as and how they are defined in ComponentType, >> ComponentDefinition and Composite and have the following questions: - >> >> With respect to references defined in ComponentDefitions and the >> 'target' >> attribute therein >> - the specs says that whatever is mentioned in the target overrides that >> which is mentioned in the implementation. Now, my understanding is >> that a >> target is used to wire a reference to another Component's service. >> Given >> this, I thought defining a target makes sense only within a >> composite. So >> what does it mean by an implementation specifying a target for a >> reference? >> > > The idea is to allow a component implementation developed with a > particular composition in mind to specify a target right in the > implementation. This makes the SCA programming model more compact as > you may not even have to write SCDL then. SCA for PHP for example > leverages this capability, here's a sample from > http://us2.php.net/manual/en/ref.SCA.php: > <?php > /** > * The currency exchange rate service to use. > * > * @reference > * @binding.php ../ExchangeRate/ExchangeRate.php > */ > public $exchange_rate; > ?> > > The componentType/reference/target attribute allows you to express the > same thing in a .componentType SCDL file. > > Then later if you want to reuse your component implementation in other > compositions you can rewire the reference using a > component/reference/target attribute in the particular component > declaration, without changing your implementation. > > More generally, I've started to look more closely at the model spi as > well as I'm trying to see how to reuse it as an individual module, and > I'm not sure that the current ReferenceDefinition and ReferenceTarget > classes correctly represent references as defined in the SCA assembly > spec. > > The assembly spec defines the following: > - abstract reference definitions in constraining types > - reference definitions in component types > - component references > - composite references > > I'll try to come up with some ideas for an accurate representation of > references at these 4 levels. Venkat, I've checked in a few interfaces representing the 4 kinds of References above at http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/assembly/src/main/java/org/apache/tuscany/assembly/model/ (plus a few base interfaces to represent SCA interfaces, multiplicity, basically what I found in the SCA assembly spec for references). I think that we're going to need interfaces for the model SPI to achieve good modularization of the Kernel, so I thought I'd try to have these few interfaces actually in sync with the SCA 1.0 assembly spec. It's probably premature to try to use this assembly module as I just got it barely building today and it's not used by the rest of the runtime, but I hope that the few interfaces can help give some ideas or at least help initiate a discussion on how best to represent SCA assembly references. Let me know what you think. -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
