Re: [PROPOSAL] Using new Workspace in samples/calculator-distributed Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
I got the code done last week but I'm only just now finishing up the build.xml file. So, as promised, here's what I did (a bit of a long post but I think I got it all) Firstly to get more familiar with the workspace I followed Sebastien's instructions from the Domain/Contribution repository thread [1] and ran up the workspace to have a play. You can use the latest tutorial modules to see the end to end integration, with the following steps: 1. Start tutorial/domain/.../LaunchTutorialAdmin. 2. Open http://localhost:9990/ui/composite in your Web browser. You should see all the tutorial contributions and deployables that I've added to that domain. 3. Click the feeds in the composite install image to see the resolved composites. 4. Start all the launch programs in tutorial/nodes, you can start them in any order you want. 5. Open tutorial/assets/tutorial.html in your Web browser, follow the links to the various store implementations. The workspace is allowing you to organize the relationships between contributions/composites, the domain composite that describes the whole application and the nodes that will run the composites. It processes all of the contributions that have been provided, the composites they contain, the association of composite with the domain and with nodes and produces fully resolved composites in terms of the contributions that are require to run them and the service and reference URIs that they will use. This resolved composite information is available from the workspace through composite specific feeds. From this feed you can get URLs to the required contributions and the composite. In fact what happens each time you do a GET on the composite URL is that all of the composites assigned to the domain are read and the domain composite is built in full using the composite builder. The individual composite that was requested is then extracted and returned. In this way policy matching, cross domain wiring, autowiring etc is manged at the domain level using the same code used by the nodes to build individual composites. This is very similar in layout with what is happening with our current domain/node implementation where you add contributions to the domain and nodes run the resulting composites. However there is a big difference here in that there is now an implication that the domain is fully configured before you start the nodes as the workspace is responsible for configuring service / reference URIs based on prior knowledge of node configurations. Previously you could start nodes and have them register with the domain without having to provide this knowledge manually to the domain. I guess automatic node registration could be rolled into this if we want. In making the calculator-distributed sample work I wanted to be able to test the sample in our maven build so having a set of HTTP forms (which the workspace does provide) to fill in is interesting but not that useful. So immediately I went looking for the files that the workspace writes to see if I could create those and install them pre-configured ready for the test to run. I used the tutorial files as templates and made the following to match the calculator-distributed scenario. Firstly there is a file (workspace.xml) [2] that describes all each contribution's location and URI workspace xmlns=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:ns1= http://tuscany.apache.org/xmlns/sca/1.0; contribution location=file:./target/classes/nodeA uri=nodeA/ contribution location=file:./target/classes/nodeB uri=nodeB/ contribution location=file:./target/classes/nodeC uri=nodeC/ contribution location=file:./target/classes/cloud uri= http://tuscany.apache.org/xmlns/sca/1.0/cloud/ /workspace Then there is a file (domain.composite) [3] that is a serialized version of the domain composite, i.e. what you would get from the specs getDomainLevelComposite() method. This shows which composites are deployed at the domain level. composite name=domain.composite targetNamespace=http://tuscany.apache.org/xmlns/sca/1.0; xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:ns1= http://www.osoa.org/xmlns/sca/1.0; include name=ns2:CalculatorA uri=nodeA xmlns:ns2=http://sample/ include name=ns2:CalculatorB uri=nodeB xmlns:ns2=http://sample/ include name=ns2:CalculatorC uri=nodeC xmlns:ns2=http://sample/ /composite Lastly there is a file (cloud.composite) [4] that is another SCA composite that describes the nodes that are going to run composites. composite name=cloud.composite targetNamespace=http://tuscany.apache.org/xmlns/sca/1.0; xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:ns1= http://www.osoa.org/xmlns/sca/1.0; include name=ns2:NodeA uri= http://tuscany.apache.org/xmlns/sca/1.0/cloud; xmlns:ns2= http://sample/cloud/ include name=ns2:NodeB uri= http://tuscany.apache.org/xmlns/sca/1.0/cloud; xmlns:ns2= http://sample/cloud/ include name=ns2:NodeC uri= http://tuscany.apache.org/xmlns/sca/1.0/cloud; xmlns:ns2= http://sample/cloud/
Re: [PROPOSAL] Using new Workspace in samples/calculator-distributed Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Simon Laws wrote: I got the code done last week but I'm only just now finishing up the build.xml file. So, as promised, here's what I did (a bit of a long post but I think I got it all) Firstly to get more familiar with the workspace I followed Sebastien's instructions from the Domain/Contribution repository thread [1] and ran up the workspace to have a play. You can use the latest tutorial modules to see the end to end integration, with the following steps: 1. Start tutorial/domain/.../LaunchTutorialAdmin. 2. Open http://localhost:9990/ui/composite in your Web browser. You should see all the tutorial contributions and deployables that I've added to that domain. 3. Click the feeds in the composite install image to see the resolved composites. 4. Start all the launch programs in tutorial/nodes, you can start them in any order you want. 5. Open tutorial/assets/tutorial.html in your Web browser, follow the links to the various store implementations. The workspace is allowing you to organize the relationships between contributions/composites, the domain composite that describes the whole application and the nodes that will run the composites. It processes all of the contributions that have been provided, the composites they contain, the association of composite with the domain and with nodes and produces fully resolved composites in terms of the contributions that are require to run them and the service and reference URIs that they will use. This resolved composite information is available from the workspace through composite specific feeds. From this feed you can get URLs to the required contributions and the composite. In fact what happens each time you do a GET on the composite URL is that all of the composites assigned to the domain are read and the domain composite is built in full using the composite builder. The individual composite that was requested is then extracted and returned. In this way policy matching, cross domain wiring, autowiring etc is manged at the domain level using the same code used by the nodes to build individual composites. This is very similar in layout with what is happening with our current domain/node implementation where you add contributions to the domain and nodes run the resulting composites. However there is a big difference here in that there is now an implication that the domain is fully configured before you start the nodes as the workspace is responsible for configuring service / reference URIs based on prior knowledge of node configurations. Previously you could start nodes and have them register with the domain without having to provide this knowledge manually to the domain. I guess automatic node registration could be rolled into this if we want. In making the calculator-distributed sample work I wanted to be able to test the sample in our maven build so having a set of HTTP forms (which the workspace does provide) to fill in is interesting but not that useful. So immediately I went looking for the files that the workspace writes to see if I could create those and install them pre-configured ready for the test to run. I used the tutorial files as templates and made the following to match the calculator-distributed scenario. Firstly there is a file (workspace.xml) [2] that describes all each contribution's location and URI workspace xmlns=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:ns1= http://tuscany.apache.org/xmlns/sca/1.0; contribution location=file:./target/classes/nodeA uri=nodeA/ contribution location=file:./target/classes/nodeB uri=nodeB/ contribution location=file:./target/classes/nodeC uri=nodeC/ contribution location=file:./target/classes/cloud uri= http://tuscany.apache.org/xmlns/sca/1.0/cloud/ /workspace Then there is a file (domain.composite) [3] that is a serialized version of the domain composite, i.e. what you would get from the specs getDomainLevelComposite() method. This shows which composites are deployed at the domain level. composite name=domain.composite targetNamespace=http://tuscany.apache.org/xmlns/sca/1.0; xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:ns1= http://www.osoa.org/xmlns/sca/1.0; include name=ns2:CalculatorA uri=nodeA xmlns:ns2=http://sample/ include name=ns2:CalculatorB uri=nodeB xmlns:ns2=http://sample/ include name=ns2:CalculatorC uri=nodeC xmlns:ns2=http://sample/ /composite Lastly there is a file (cloud.composite) [4] that is another SCA composite that describes the nodes that are going to run composites. composite name=cloud.composite targetNamespace=http://tuscany.apache.org/xmlns/sca/1.0; xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:ns1= http://www.osoa.org/xmlns/sca/1.0; include name=ns2:NodeA uri= http://tuscany.apache.org/xmlns/sca/1.0/cloud; xmlns:ns2= http://sample/cloud/ include name=ns2:NodeB uri= http://tuscany.apache.org/xmlns/sca/1.0/cloud; xmlns:ns2= http://sample/cloud/ include name=ns2:NodeC uri= http://tuscany.apache.org/xmlns/sca/1.0/cloud; xmlns:ns2=
Re: [PROPOSAL] Using new Workspace in samples/calculator-distributed Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
+1. Raymond -- From: Simon Laws [EMAIL PROTECTED] Sent: Wednesday, March 12, 2008 4:28 AM To: tuscany-dev@ws.apache.org Subject: [PROPOSAL] Using new Workspace in samples/calculator-distributed Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes I like the look of the workspace code Sebastien has been writing and I propose to try it out on samples/calculator-distributed. In particular I'd like to help Felix who is hitting the common filesystem restriction of the current domain implementation . Let me know if anyone has any concerns. I'll report back with what I learn. There are other modules that rely on distributed support itest/callable-references itest/domain itest/osgi-tuscany/tuscany-3rdparty itest/osgi-tuscay/tuscany-runtime samples/calculator-distributed tools/eclipse/plugins/runtime I'm happy to think about those if the sample/calculator-distributed goes ok. Regards Simon [1] http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg02610.html On Mon, Mar 10, 2008 at 6:07 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Simon Laws wrote: On Fri, Mar 7, 2008 at 4:18 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Mar 7, 2008 at 12:23 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Simon Laws wrote: I've been running the workspace code today with a view to integrating the new code in assembly which calculates service endpoints i.e. point4 above. I think we need to amend point 4 to make this work properly.. 4. Point my Web browser to the various ATOM collections to get: - lists of contributions, composites and nodes - list of contributions that are required by a given contribution - the source of a particular composite - the output of a composite after the domain composite has been built by CompositeBuilder Looking at the code in DeployableCompositeCollectionImpl I see that on doGet() it builds the request composite. What the last point needs to do is - read the whole domain - set up all of the service URIs for each of the included composites taking into account the node to which each composite is assigned - build the whole domain using CompositeBuilder - extract the required composite from the domain and serialize it out. Yes, exactly! Are you changing this code or can I put this in? Just go ahead, I'll update and merge if I have any other changes in the same classes. Simon, a quick update: I've done an initial bring-up of node2-impl. It's still a little rough but you can give it a try if you want. The steps to run the store app for example with node2 are as follows: 1) use workspace-admin to add the store and assets contributions to the domain; 2) add the store composite to the domain composite using the admin as well; 3) start the StoreLauncher2 class that I just added to the store module; 4) that will start an instance of node2 with all the node config served from the admin app. So the next step is to integrate your node allocation code with workspace-admin and that will complete the story. Then we'll be able to remove all the currently hardcoded endpoint URIs from the composites. I'll send a more detailed description and steps to run more scenarios later on Friday. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ok, sounds good. I've done the uri integration although there are some issues we need to discuss. First I'll update with your code, commit my changes and then post here about the issues. Regards Simon I've now checked in my changes (last commit was 634762) to integrate the URI calculation code with the workspace. I've run the new store launcher following Sebastien's instructions from a previous post to this thread. I don't seem to have broken it too much although I'm not seeing any prices for the catalog items. I was seeing that issue too before, it's a minor bug in the property writing code, which is not writing property values correctly. Issues with the URI generation code I have to turn model resolution back on by uncommenting a line in ContributionContentProcessor.resolve. Otherwise the JavaImplementation types are not read and compositeConfiguationBuilder.calculateBindingURIs(defaultBindings, composite, null); can't generate default services. I then had to tun it back off to make the store sample work. I need some help on this one. I'm investigating now. If you hand craft services it seems to be OK although I have noticed, looking at the generated SCDL, that it seems to be assuming that all generated service names will be based on the implementation classname regardless of whether the interface is marked as @Remotable
