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 <import namespace> > > > > 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 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. I both reads and resolves contributions. It uses the list of contributions returned by the dependency analyser to determine the list of which contributions should be resolved in order to start a chosen composite. > > e.g. I can see some code like: List<Contribution> 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 contribution. The > contribution dependency analyzer is a utility class, which can be used to > get a contribution dependency graph, useful to have in hand if you're > building a contribution admin application for example and want to display > lists of dependencies. > Agreed. It's not absolutely required. I just added this in to work out which contributions really needed processing in order to start a chosen composite. If you have the situation where you are processing all the contributions that are being added then you don't need to work out how they are related before trying to resolve them. > > > > 3. I can also see getting composite started will have more codes than > > using domain. > > > > The composite activator has not changed and still works the same way as > before. So if you have composite objects already in memory, ready to be > used, they can be given to the composite activator exactly like before (like > you showed at the top of this email). > > If on the other hand you want to use SCANode2Factory, I think that the > test case code below and the FIXME statement in it are little confusing, and > can be simplified. More comments inline. I fixed that. My bad - I got confused about the intention of the interface. My use of the SCANode2 here is to show that the node can be used to run the composite based on the information that comes out of the composite processing we have already done. Of course the SCANode2 itself sets up a whole set of runtime things so you may want to avoid this to save on memory footprint if you are trying to run the composite within the same JVM that you are doing your contribution processing. > > 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 > > > > The second parameter of createSCANode is a variable list of arguments, you > can pass contribution0, contribution1, or... just pass an array, giving you > the ability to provide a 'dynamic' list of contributions. I'm assuming that > by 'dynamic' we meant 'not determined at compile time'. > > SCANode2 node = > > nodeFactory.createSCANode(chosenDeployableLocation, contribution0, > > contribution1); > > > > like that: > Contribution[] contributions = an array of contributions > nodeFactory.createSCANode(chosenDeployableLocation, contributions); I changed to this approach . > > > > > node.start(); > > > > Here's a simpler example: > SCANode2Factory factory = SCANode2Factory.newInstance(); > SCANode2 node = factory.createSCANode("Calculator.composite", > new Contribution("calc", "/tmp/calc.jar"), > new Contribution("math", "/tmp/math.jar")); > node.start(); > > This gives you the ability to use multiple contributions in an application > which DefaultSCADomain didn't support before. > I believe this is what the test is doing except that the contribution name and location are not hardcoded in the call. > > > SCAClient client = (SCAClient)node; > > CalculatorService calculatorService = > > client.getService(CalculatorService.class, > > "CalculatorServiceComponentA"); > > > > One more comment about SCANode2 and SCAClient. This is work in progress, > for example we named SCANode2 like that to not conflict with SCANode which > we also have in the code at the moment. SCANode2 will probably be renamed to > SCANode at some point or merged with it. > > 4. Another interest I have is about model validation for contribution > > or composite. I see another different thread discussing on > > validation ( > > http://www.mail-archive.com/[email protected]/msg29510.html), > > I wonder if the same answers can be applied to using workspace.... or > > it is different approach. > > > > Validation is currently performed as part of CompositeBuilder, it doesn't > change at all from before, since CompositeBuilder does not know at all (and > doesn't need to know) how the models given to it were obtained. > > Does that answer your question? I wasn't sure what the question was on > that one :) > > > > Thank you. Looking forward to some answers. > > > > Yang > > > > > Last comment, this is a pretty long email :) with 5/6 different subjects > piled in it. I've try to respond to all in line here, but I'd suggest to > spawn different threads for further discussion of each specific subject as > necessary if we want to keep this readable as others jump in the discussion > too. > > Hope this helps. > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
