Yes it does help! I need to go and read the Assembly spec again ;0)
But for now I think the change I put in is fine. Cheers, On 05/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Pete Robbins wrote: > On 05/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >> >> >> >> I thought that a ComponentType would need to know the composite it lives >> in, to reflect interfaces, or use complex data types for properties, >> which are currently packaged with a composite. > > > > But in the model Composite is a subclass of ComponentType and you say a > ComponentType "lives in" a Composite? If so I think the model is wrong. > > Do we need a review of the model. I have to say I haven't looked into > it in > detail ... as it worked ;-) > > Cheers, > Pete, OK I think I need to clarify what I meant by "lives in a Composite". Let's look at this from multiple angles: A) A composite describes a type. A composite can be used as an implementation of a component. A composite declares service types, reference types, property types. So I think it is correct for Composite to extend ComponentType in the model. B) Let's now look at a .componentType file. The .componentType file is currently packaged with the other artifacts contributing to a Composite. The ComponentType references WSDLs, XSDs, possibly other language artifacts declaring types, in its interface and property definitions. These artifacts are also currently packaged with the Composite. The WSDL and XSD metadata (and the corresponding DataFactory) are associated with (live in) the Composite. That's what I meant with "a ComponentType lives in a Composite". C) A variation on B: a ComponentType can be derived from a component implementation artifact (a Ruby script, a Python script, a C++ class if we add annotations to C++ at some point etc.). These implementation artifacts are currently packaged with a Composite so by derivation the ComponentType describing them belongs to the Composite as well. I think that we should discuss whether or not it's a good thing to use Composites as a packaging mechanism for implementation artifacts and type metadata. I have in mind some scenarios where multiple composites need to reuse a simple component implementation packaged and installed independently from these composites... Other even more obvious scenarios (like SupplyChain) need to share WSDL files, types and interfaces between composites... But I think all of this is a different, bigger and longer term subject, which will require some clarifications in the SCA spec and interesting work in perspective for our M3 release I guess :) Does that help? -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Pete
