Re: Some questions for workspace module in Tuscany
Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: - Started to create sample tasks showing how to bootstrap a subset of Tuscany to work with the various models [1], see ListDeployables.java, ListDependencies.java, ListComponents.java, and WireComponents.java. ... The init() methods in the sample programs are there to help explore the various Tuscany bootstrap patterns required for these common tasks, candidate to become generic utility methods if people want that. Looking at these init methods, a lot of the setup code is about setting up XML and document artifact processors, which we shouldn't have to write if all the necessary processors were correctly registered under META-INF/services. I noticed that some of the base processors (CompositeProcessor, ComponentTypeProcessor, ConstrainingType etc) are missing from META-INF/services so I'm going to try to fix that and register them dynamically like all the other ones. That should help simplify that setup code. I've done a first pass through all the artifact processors and declared them under META-INF/services. I had to make minor changes or add the expected constructors to some of them to follow the pattern that was already in place to support lazy / automatic loading and initialization. The following methods: StAXArtifactProcessorExtensionPoint.getProcessor(modelClass) StAXArtifactProcessorExtensionPoint.getProcessor(qname) URLArtifactProcessorExtensionPoint.getProcess(modelClass) URLArtifactProcessorExtensionPoint.getProcess(artifactType) should now work for all artifact processors, hoping that I didn't miss any. With these changes I was able to simplify the bootstrapping code, as it doesn't need to create all these artifact processors manually anymore. It was a little tedious but I also went through most artifact processor unit test cases and was able to simplify their setup method as well. I'll try to go through the remaining test cases and samples in the next day or two. -- Jean-Sebastien
Re: Some questions for workspace module in Tuscany
Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: - Started to create sample tasks showing how to bootstrap a subset of Tuscany to work with the various models [1], see ListDeployables.java, ListDependencies.java, ListComponents.java, and WireComponents.java. ... The init() methods in the sample programs are there to help explore the various Tuscany bootstrap patterns required for these common tasks, candidate to become generic utility methods if people want that. Looking at these init methods, a lot of the setup code is about setting up XML and document artifact processors, which we shouldn't have to write if all the necessary processors were correctly registered under META-INF/services. I noticed that some of the base processors (CompositeProcessor, ComponentTypeProcessor, ConstrainingType etc) are missing from META-INF/services so I'm going to try to fix that and register them dynamically like all the other ones. That should help simplify that setup code. -- Jean-Sebastien
Re: Some questions for workspace module in Tuscany
Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: - Started to create sample tasks showing how to bootstrap a subset of Tuscany to work with the various models [1], see ListDeployables.java, ListDependencies.java, ListComponents.java, and WireComponents.java. ... The init() methods in the sample programs are there to help explore the various Tuscany bootstrap patterns required for these common tasks, candidate to become generic utility methods if people want that. This is work in progress, subject to changes and improvements in the next few days. I'm also in the process of adding more sample tasks to show XML schema based validation, composite include processing, assignment of composites to SCA nodes etc. Feedback is welcome. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/domain-management/ I've added more code to these samples, got WireComponents working and added a DistributeComponents sample that shows how to describe the allocation of deployable composites to SCA nodes and then use it to configure the services that run on each node. I'm planning to make the following improvements tomorrow or Friday: - Fix the samples that use CompositeBuilder to correctly handle SCA . - Clean up the samples to remove code dependencies on the builder implementation classes (they all implement the CompositeBuilder interface now so it'll be easy). - Add a sample that feeds the SCA models to an SCA runtime node. On a related subject, I'm also thinking about the renaming the workspace-admin module to domain-admin or domain-manager as it has expanded to manage more than just a workspace of contributions. That'll be in line with the sample module currently named domain-management. Hope this helps. One more thing. I just saw that Raymond seems to have fixed the databinding dependency issues so I'll try to add the databinding modules. Hopefully they won't add runtime dependencies to the mix. -- Jean-Sebastien
Re: Some questions for workspace module in Tuscany
Jean-Sebastien Delfino wrote: - Started to create sample tasks showing how to bootstrap a subset of Tuscany to work with the various models [1], see ListDeployables.java, ListDependencies.java, ListComponents.java, and WireComponents.java. ... The init() methods in the sample programs are there to help explore the various Tuscany bootstrap patterns required for these common tasks, candidate to become generic utility methods if people want that. This is work in progress, subject to changes and improvements in the next few days. I'm also in the process of adding more sample tasks to show XML schema based validation, composite include processing, assignment of composites to SCA nodes etc. Feedback is welcome. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/domain-management/ I've added more code to these samples, got WireComponents working and added a DistributeComponents sample that shows how to describe the allocation of deployable composites to SCA nodes and then use it to configure the services that run on each node. I'm planning to make the following improvements tomorrow or Friday: - Fix the samples that use CompositeBuilder to correctly handle SCA . - Clean up the samples to remove code dependencies on the builder implementation classes (they all implement the CompositeBuilder interface now so it'll be easy). - Add a sample that feeds the SCA models to an SCA runtime node. On a related subject, I'm also thinking about the renaming the workspace-admin module to domain-admin or domain-manager as it has expanded to manage more than just a workspace of contributions. That'll be in line with the sample module currently named domain-management. Hope this helps. -- Jean-Sebastien
Re: Some questions for workspace module in Tuscany
Jean-Sebastien Delfino wrote: ... I can do the following: - Provide a few pre-canned init methods that bootstrap the subset of a Tuscany runtime required for your scenarios. I'll start with these: a) list deployables in a contribution b) resolve deployables given the set of available contributions - Come up with samples (easier to understand than test cases) showing how to use the init methods and the current SPIs to implement these scenarios. I'll probably keep the init method in each sample to start with, and then as we work through more usage scenarios I'm hoping that we can find common init patterns that we can then push into proper SPIs for all to reuse. ... To allow programs to work with the Tuscany model extensions without dragging a dependency on the runtime modules (which is one of the ideas discussed here), I need to push the following interfaces/classes: o.a.t.sca.core.ExtensionPointRegistry o.a.t.sca.core.DefaultExtensionPointRegistry o.a.t.sca.core.ModuleActivator down from module core to module extensibility This is transparent to all modules that use these classes, as there is no name change and module core already has a compile dependency on module extensibility. If there's no objection I'll do that at the end of the day tomorrow. I've made some progress with what was discussed here: - Moved ExtensionPointRegistry to module extensibility - Started to create sample tasks showing how to bootstrap a subset of Tuscany to work with the various models [1], see ListDeployables.java, ListDependencies.java, ListComponents.java, and WireComponents.java. I've also added to extensibility a ModuleActivatorExtensionPoint (since people seemed interested in working with module activators directly [2] and I needed that too in the sample tasks) and a UtilityExtensionPoint useful to hold common utilities like the monitor factory or the interface contract mapper used in some of the sample tasks too. The init() methods in the sample programs are there to help explore the various Tuscany bootstrap patterns required for these common tasks, candidate to become generic utility methods if people want that. This is work in progress, subject to changes and improvements in the next few days. I'm also in the process of adding more sample tasks to show XML schema based validation, composite include processing, assignment of composites to SCA nodes etc. Feedback is welcome. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/domain-management/ [2] http://marc.info/?t=12076902691&r=1&w=2 -- Jean-Sebastien
Re: Some questions for workspace module in Tuscany
+1 on the proposed refactoring. Thanks, Raymond -- From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> Sent: Monday, April 21, 2008 3:34 PM To: Subject: Re: Some questions for workspace module in Tuscany Simon Laws wrote: Hi A few clarifications in line. Simon On Fri, Apr 4, 2008 at 8:24 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Yang Lei wrote: Hello, I have the following usage scenarios that I currently use EmbeddedSCADomain's ContributionService to accomplish. When I look at the new set of workspace modules, I wonder how it can be accomplished by using this new set of workspace related apis. And what the pros/cons if I switch to use workspace: Scenario 1: I need to load a SCA contribution to iterate the deployables , each deployable composite needs to resolve the componentType: from java annotation, from componentType file, from QName of another composite file which may be imported from another contribution by using The way I support it today is like what itest/contribution-import-export does: ContributionService contributionService = domain.getContributionService(); ... Contribution consumerContribution = contributionService.contribute(...); Composite consumerComposite = consumerContribution.getDeployables().get(0); domain.getDomainComposite().getIncludes().add(consumerComposite); domain.buildComposite(consumerComposite); Scenario 2: I need to start a contribution 's deployable composite with a domain. Again I use the same approach as in itest/contribution-import-export, besides the above code I add the following // Start Components from my composite domain.getCompositeActivator().activate(consumerComposite); domain.getCompositeActivator().start(consumerComposite); Now I am looking into how to accomplish the above by using workspace related APIs. I started looking at a workspace test case: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/domain/src/test/java/org/apache/tuscany/sca/itest/domain/ContributionSPIsTestCase.java I have the following observations: 1. The bootstraping of Tuscany extension points are outside the workspace. I can see a lot code in init() to do bootstraping. I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent, even though it may happen that scenario1 bootstrapping is only a subset of scenario 2's . If we are worried that one fit for all bootstrapping is an overhead for scenario 1, maybe we can have some 2 stage bootstrapping: composite model resolved, composite start. Or we can even break into 3 : composite model load from scdl no resolving componentType, composite model resolved, composite start... I'm interested in what you say about bootstrapping being associated with a domain. The code you have been looking at in the domain itest I believe contains all the detailed steps you need to go through in order to read contributions, understand the dependencies between them, read and resolve them and finally run some composite that is contained in the contributions. Is your main concern here that these steps are just too complicated and that you would like them wrapped up (which is, as Sebastien suggests, relatively straightforward to do as long as we can agree that the steps are fundamentally doing the right kinds of things). Or is there some more fundamental issue with the concepts that concerns you. In particular you say "I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent," But if I take the init code from the test you have been looking at and run it twice both copies of the runtime would have the same sets of extensions and bindings as the code loads these from the runtime classpath. As Sebastien describes below the workspace is independent of the rest of the code in the init method in that that is just holds onto contributions and doesn't care how those contributions were generated. Makes sense. I am not sure that the bootstrap code should be 'tied to a domain', but I can do the following: - Provide a few pre-canned init methods that bootstrap the subset of a Tuscany runtime required for your scenarios. I'll start with these: a) lis
Re: Some questions for workspace module in Tuscany
Simon Laws wrote: Hi A few clarifications in line. Simon On Fri, Apr 4, 2008 at 8:24 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Yang Lei wrote: Hello, I have the following usage scenarios that I currently use EmbeddedSCADomain's ContributionService to accomplish. When I look at the new set of workspace modules, I wonder how it can be accomplished by using this new set of workspace related apis. And what the pros/cons if I switch to use workspace: Scenario 1: I need to load a SCA contribution to iterate the deployables , each deployable composite needs to resolve the componentType: from java annotation, from componentType file, from QName of another composite file which may be imported from another contribution by using The way I support it today is like what itest/contribution-import-export does: ContributionService contributionService = domain.getContributionService(); ... Contribution consumerContribution = contributionService.contribute(...); Composite consumerComposite = consumerContribution.getDeployables().get(0); domain.getDomainComposite().getIncludes().add(consumerComposite); domain.buildComposite(consumerComposite); Scenario 2: I need to start a contribution 's deployable composite with a domain. Again I use the same approach as in itest/contribution-import-export, besides the above code I add the following // Start Components from my composite domain.getCompositeActivator().activate(consumerComposite); domain.getCompositeActivator().start(consumerComposite); Now I am looking into how to accomplish the above by using workspace related APIs. I started looking at a workspace test case: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/domain/src/test/java/org/apache/tuscany/sca/itest/domain/ContributionSPIsTestCase.java I have the following observations: 1. The bootstraping of Tuscany extension points are outside the workspace. I can see a lot code in init() to do bootstraping. I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent, even though it may happen that scenario1 bootstrapping is only a subset of scenario 2's . If we are worried that one fit for all bootstrapping is an overhead for scenario 1, maybe we can have some 2 stage bootstrapping: composite model resolved, composite start. Or we can even break into 3 : composite model load from scdl no resolving componentType, composite model resolved, composite start... I'm interested in what you say about bootstrapping being associated with a domain. The code you have been looking at in the domain itest I believe contains all the detailed steps you need to go through in order to read contributions, understand the dependencies between them, read and resolve them and finally run some composite that is contained in the contributions. Is your main concern here that these steps are just too complicated and that you would like them wrapped up (which is, as Sebastien suggests, relatively straightforward to do as long as we can agree that the steps are fundamentally doing the right kinds of things). Or is there some more fundamental issue with the concepts that concerns you. In particular you say "I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent," But if I take the init code from the test you have been looking at and run it twice both copies of the runtime would have the same sets of extensions and bindings as the code loads these from the runtime classpath. As Sebastien describes below the workspace is independent of the rest of the code in the init method in that that is just holds onto contributions and doesn't care how those contributions were generated. Makes sense. I am not sure that the bootstrap code should be 'tied to a domain', but I can do the following: - Provide a few pre-canned init methods that bootstrap the subset of a Tuscany runtime required for your scenarios. I'll start with these: a) list deployables in a contribution b) resolve deployables given the set of available contributions - Come up with samples (easier to understand than test cases) showing how to use the init methods and the current SPIs to implement these scenarios. I'll probably keep the init method in each sample to start with, and then as we work through mor
Re: Some questions for workspace module in Tuscany
Hi A few clarifications in line. Simon On Fri, Apr 4, 2008 at 8:24 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Yang Lei wrote: > > > Hello, > > > > I have the following usage scenarios that I currently use > > EmbeddedSCADomain's ContributionService to accomplish. When I look at > > the new set of workspace modules, I wonder how it can be accomplished > > by using this new set of workspace related apis. And what the > > pros/cons if I switch to use workspace: > > > > Scenario 1: I need to load a SCA contribution to iterate the > > deployables , each deployable composite needs to resolve the > > componentType: from java annotation, from componentType file, from > > QName of another composite file which may be imported from another > > contribution by using > > > > The way I support it today is like what itest/contribution-import-export > > does: > > > >ContributionService contributionService = > > domain.getContributionService(); > >... > >Contribution consumerContribution = > >contributionService.contribute(...); > >Composite consumerComposite = > > consumerContribution.getDeployables().get(0); > >domain.getDomainComposite().getIncludes().add(consumerComposite); > >domain.buildComposite(consumerComposite); > > > > > > Scenario 2: I need to start a contribution 's deployable composite > > with a domain. > > > > Again I use the same approach as in itest/contribution-import-export, > > besides the above code I add the following > > > >// Start Components from my composite > >domain.getCompositeActivator().activate(consumerComposite); > >domain.getCompositeActivator().start(consumerComposite); > > > > > > > > Now I am looking into how to accomplish the above by using workspace > > related APIs. I started looking at a workspace test case: > > > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/domain/src/test/java/org/apache/tuscany/sca/itest/domain/ContributionSPIsTestCase.java > > > > I have the following observations: > > > > 1. The bootstraping of Tuscany extension points are outside the > > workspace. > > > > I can see a lot code in init() to do bootstraping. I think I would > > prefer the bootstrapping are tied with a given domain, as all the > > workspace usage for a given domain should have the same bootstrapping > > on the object model and what kind of bindingTypes or > > implementationTypes are supported. If it can be done it that way, then > > I do not need to bootstrap everytime I use workspace, and I can keep > > both bootstrapping of scenario 1 and 2 consistent, even though it may > > happen that scenario1 bootstrapping is only a subset of scenario 2's . > > > > If we are worried that one fit for all bootstrapping is an overhead > > for scenario 1, maybe we can have some 2 stage bootstrapping: > > composite model resolved, composite start. Or we can even break into 3 > > : composite model load from scdl no resolving componentType, > > composite model resolved, composite start... > > > I'm interested in what you say about bootstrapping being associated with a domain. The code you have been looking at in the domain itest I believe contains all the detailed steps you need to go through in order to read contributions, understand the dependencies between them, read and resolve them and finally run some composite that is contained in the contributions. Is your main concern here that these steps are just too complicated and that you would like them wrapped up (which is, as Sebastien suggests, relatively straightforward to do as long as we can agree that the steps are fundamentally doing the right kinds of things). Or is there some more fundamental issue with the concepts that concerns you. In particular you say "I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent," But if I take the init code from the test you have been looking at and run it twice both copies of the runtime would have the same sets of extensions and bindings as the code loads these from the runtime classpath. As Sebastien describes below the workspace is independent of the rest of the code in the init method in that that is just holds onto contributions and doesn't care how those contributions were generated. > > Makes sense. I am not sure that the bootstrap code should be 'tied to a > domain', but I can do the following: > > - Provide a few pre-canned init methods that bootstrap the subset of a > Tuscany runtime required for your scenarios. I'll start with these: > a) list deployables in a contribution > b) resolve deployables given the set of available contributions > > - Co
Re: Some questions for workspace module in Tuscany
Yang Lei wrote: Hello, I have the following usage scenarios that I currently use EmbeddedSCADomain's ContributionService to accomplish. When I look at the new set of workspace modules, I wonder how it can be accomplished by using this new set of workspace related apis. And what the pros/cons if I switch to use workspace: Scenario 1: I need to load a SCA contribution to iterate the deployables , each deployable composite needs to resolve the componentType: from java annotation, from componentType file, from QName of another composite file which may be imported from another contribution by using The way I support it today is like what itest/contribution-import-export does: ContributionService contributionService = domain.getContributionService(); ... Contribution consumerContribution = contributionService.contribute(...); Composite consumerComposite = consumerContribution.getDeployables().get(0); domain.getDomainComposite().getIncludes().add(consumerComposite); domain.buildComposite(consumerComposite); Scenario 2: I need to start a contribution 's deployable composite with a domain. Again I use the same approach as in itest/contribution-import-export, besides the above code I add the following // Start Components from my composite domain.getCompositeActivator().activate(consumerComposite); domain.getCompositeActivator().start(consumerComposite); Now I am looking into how to accomplish the above by using workspace related APIs. I started looking at a workspace test case: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/domain/src/test/java/org/apache/tuscany/sca/itest/domain/ContributionSPIsTestCase.java I have the following observations: 1. The bootstraping of Tuscany extension points are outside the workspace. I can see a lot code in init() to do bootstraping. I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent, even though it may happen that scenario1 bootstrapping is only a subset of scenario 2's . If we are worried that one fit for all bootstrapping is an overhead for scenario 1, maybe we can have some 2 stage bootstrapping: composite model resolved, composite start. Or we can even break into 3 : composite model load from scdl no resolving componentType, composite model resolved, composite start... Makes sense. I am not sure that the bootstrap code should be 'tied to a domain', but I can do the following: - Provide a few pre-canned init methods that bootstrap the subset of a Tuscany runtime required for your scenarios. I'll start with these: a) list deployables in a contribution b) resolve deployables given the set of available contributions - Come up with samples (easier to understand than test cases) showing how to use the init methods and the current SPIs to implement these scenarios. I'll probably keep the init method in each sample to start with, and then as we work through more usage scenarios I'm hoping that we can find common init patterns that we can then push into proper SPIs for all to reuse. 2. Some detailed questions related to what I see in the ContributionSPIsTestCase: I can see contribution can be added to workspace by workspace.getContributions().add(contribution); I am not sure if at this stage I will be able to get the composite model object that I need for scenario 1 I'm assuming that you're talking about the code in testReadDependentContributions()? Workspace is a model object, which you can use to represent the collection of Contributions that you're working with. Workspace.getContributions() simply returns a java.util.List for you to record and list contributions. So workspace.getContributions().add(contribution) does not affect in any way the contents or state of the contribution model object and the ability to get composites from it. You should be able to just get a composite from a contribution, but going through the list of artifacts returned by getArtifacts() or using a model resolver. or I need to go extra steps to get the Composite model resolved. The test case does not seem to try to resolve anything, as it just reads contributions and never calls resolve on the contribution processor. I'll try to add code to one of to-be-written samples to show how to resolve a contribution. e.g. I can see some code like: List dependencies = analyzer.buildContributionDependencies(workspace, workspace.getContributions().get(0)); is it needed for me to get the resolved model or it is just something to play with to get a dependency graph. No it's not needed to resolve artifacts in a co
Some questions for workspace module in Tuscany
Hello, I have the following usage scenarios that I currently use EmbeddedSCADomain's ContributionService to accomplish. When I look at the new set of workspace modules, I wonder how it can be accomplished by using this new set of workspace related apis. And what the pros/cons if I switch to use workspace: Scenario 1: I need to load a SCA contribution to iterate the deployables , each deployable composite needs to resolve the componentType: from java annotation, from componentType file, from QName of another composite file which may be imported from another contribution by using The way I support it today is like what itest/contribution-import-export does: ContributionService contributionService = domain.getContributionService(); ... Contribution consumerContribution = contributionService.contribute(...); Composite consumerComposite = consumerContribution.getDeployables().get(0); domain.getDomainComposite().getIncludes().add(consumerComposite); domain.buildComposite(consumerComposite); Scenario 2: I need to start a contribution 's deployable composite with a domain. Again I use the same approach as in itest/contribution-import-export, besides the above code I add the following // Start Components from my composite domain.getCompositeActivator().activate(consumerComposite); domain.getCompositeActivator().start(consumerComposite); Now I am looking into how to accomplish the above by using workspace related APIs. I started looking at a workspace test case: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/domain/src/test/java/org/apache/tuscany/sca/itest/domain/ContributionSPIsTestCase.java I have the following observations: 1. The bootstraping of Tuscany extension points are outside the workspace. I can see a lot code in init() to do bootstraping. I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent, even though it may happen that scenario1 bootstrapping is only a subset of scenario 2's . If we are worried that one fit for all bootstrapping is an overhead for scenario 1, maybe we can have some 2 stage bootstrapping: composite model resolved, composite start. Or we can even break into 3 : composite model load from scdl no resolving componentType, composite model resolved, composite start... 2. Some detailed questions related to what I see in the ContributionSPIsTestCase: I can see contribution can be added to workspace by workspace.getContributions().add(contribution); I am not sure if at this stage I will be able to get the composite model object that I need for scenario 1, or I need to go extra steps to get the Composite model resolved. e.g. I can see some code like: List dependencies = analyzer.buildContributionDependencies(workspace, workspace.getContributions().get(0)); is it needed for me to get the resolved model or it is just something to play with to get a dependency graph. 3. I can also see getting composite started will have more codes than using domain. One thing I realized that there is no association of a Node to a Domain. (sorry if I missed it ). I would assume the Node will be associated with a SCADomain as then we can call SCADomain.getService to locate the services hosted on the Domain. And also it will make it possible that we can have multiple domain in one single JVM , each may have different contributions , so its hosted services are different and behaviors are different as there can be different definitions.xml in a contribution for intent or policy or others.. // // run the chosen composite SCANode2Factory nodeFactory = SCANode2Factory.newInstance(); SCAContribution contribution0 = new SCAContribution(contributionsToDeploy.get(0).getURI(), contributionsToDeploy.get(0).getLocation()); SCAContribution contribution1 = new SCAContribution(contributionsToDeploy.get(1).getURI(), contributionsToDeploy.get(1).getLocation()); // FIXME - need a more flexible constructor on the node so we can pass in a // dynamic list of contributions SCANode2 node = nodeFactory.createSCANode(chosenDeployableLocation, contribution0, contribution1); node.start(); SCAClient client = (SCAClient)node; CalculatorService calculatorService = client.getService(CalculatorService.class, "CalculatorServiceComponentA"); 4. Another interest I have is about model validation for contribution or composite. I see another different thread discussin
