Hi Sebastien
I think it would be worth splitting contribution in two parts. - Contribution metadata: What's described in sca-contribution.xml and the relationships with the assembly and interface definition models (e.g. the list of deployables pointing to assembly composites, maybe also pointers to the interfaces containing in the contribution and the ones imported from others) plus the mechanisms for parsing that contribution file. - Contribution service: the SPI to add/remove/list etc. contributions in an SCA domain. Contribution metadata would be in the metadata layer. Contribution service in the system services layer.
I think what you are describing here is very similar with the design I have on the latest implementation of the contribution services available in java/sca/runtime/services/contribution. I have also updated the wiki page [1] with latest design being used on the Contribution services if people would like to get more information. [1] - http://cwiki.apache.org/confluence/display/TUSCANY/Deployment On 3/28/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Raymond Feng wrote: > Hi, > > By reading through a bunch of e-mails on this mailing list and adding > my imagination, I put together a conceptual diagram at the following > wiki page to illustrate the kernel modulization. > > http://cwiki.apache.org/confluence/display/TUSCANY/Kernel+Modulization+Design+Discussions > > > This diagram is merely for the discussion purpose and it only reflects > my understandings so far. By no means it is meant to be complete and > accurate. But I hope we can use it as the starting point for the > technical discussion. > > Going through this exercise, I start to see values of the efforts > which would lead to greater adoption of Tuscany/SCA by various > embedders including other Apache projects and simplication of the > kernel that the community can work together. You might take the > following items as my crazy brainstorming: > > 1) Allow different ways to populate the assembly model: from SCDL, > from other Domain Specific Languages (DSL) or even from another model > such as the Spring context. On the hand, make it possible to convert > the SCA assembly model to be executed by other frameworks such as Spring. > > 2) Improve the federation story so that we can plugin different > federation mechanisms, such as P2P discovery-based or repository-based > schemes. > > 3) Bootstrap the Tuscany kernel without the Java container in case > that either the hosting runtime is resource-constrained (for example, > cellular phones or network appliances) or it doesn't need to the > support for POJO (for example, scripting for Web 2.0). > > 4) Provide more flexibility to integrate with different hosting > environments with a subset of kernel modules. > ... > > I guess I throw out enough seeds for thoughts and now it's your turn :-). > > Thanks, > Raymond > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Raymond, This diagram looks pretty good to me. I have a few comments and thoughts: I think it would be worth splitting contribution in two parts. - Contribution metadata: What's described in sca-contribution.xml and the relationships with the assembly and interface definition models (e.g. the list of deployables pointing to assembly composites, maybe also pointers to the interfaces containing in the contribution and the ones imported from others) plus the mechanisms for parsing that contribution file. - Contribution service: the SPI to add/remove/list etc. contributions in an SCA domain. Contribution metadata would be in the metadata layer. Contribution service in the system services layer. I would also place the SCDL loader framework and any other Domain Specific Language people want to use to define an SCA assembly in the metadata layer as well. What to you think about turning kernel extensions (e.g support for Java components, Axis2 Bindings, WSDL/XSD interface definitions) into vertical boxes on the side of the diagram, to help show that they contribute to the different layers. For example, support for Java components contributes extensions to several layers: - the metadata layer (model representing the Java artifacts, support for the SCDL <interface.java> and <implementation.java> elements, and introspection of Java5 annotations) - the databinding support (with bindings to beans and the various databinding technologies supported in Java application code) - the invocation framework (with proxy/invocation handling and dispatching of calls to a Java component) It's just an idea, maybe colors will also help show this dimension better. I also have some questions: - I'm not sure where the runtime builders belong. What do people think? - What about the modules under Pluggable Federations? a lot of good work has been done in that space recently, does anybody have any comments on how it's decomposed in modules in the diagram, is it correct? Overall, I find this diagram very useful as it's starting to show how we could re-organize our kernel to make it more modular. At the moment many of the boxes shown here are concentrated in two Maven modules (kernel/spi and kernel/core), the diagram helps show how we could decompose these two central modules in smaller modules easier to work with. Thoughts? -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Luciano Resende http://people.apache.org/~lresende
