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"/> </composite> Each included node composite looks something like <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0"; targetNamespace="http://sample/cloud"; xmlns:s="http://sample"; name="NodeA"> <component name="NodeA"> <t:implementation.node uri="nodeA" composite="s:CalculatorA"/> <service name="Node"> <binding.sca uri="http://localhost:8100"/> </service> </component> </composite> You will note that the node holds default binding URI information. With these files the workspace can produce the fully configured composites that will run on each node. Having done this I rewrote the code in the "node" package to create a set of launchers for the various parts of the sample. node.LaunchDomain [5] was the first and simply calls the DomainAdminLauncher from the workspace-admin package. This starts an SCA application, reads all these files, makes some web pages available and more importantly make the resolved composite information available at URLs starting http://host:9990/. .. node.LaunchCalculatorNodeA, B, C [6] allows each node to be started. You will note that in each of these a node gets started with a line something like node = nodeFactory.createSCANode("http://localhost:9990/node-image/NodeA";); This is a slightly different take on the node creation process we had before (this new node code is in the node2-* packages). It lets you create a node given a composite information. This is derived from the helper method Simon Nash put on the factory and in this case is the URI of an Atom feed that provides a link to a composite and the contributions required to run that composite. The node runs, pulls down this information. Based on this information it pulls down each of the contributions and the composite and starts up the composite. As all the composites are fully configured the nodes simply build, activate and start them. They don't need to go looking for service endpoints. The actual distributed calculator application is the same as it was before. I hope this makes some kind of sense. Please ask if you want more details. Regards Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28711.html [2] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/workspace.xml [3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/domain.composite [4] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/cloud.composite [5] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/src/main/java/node/LaunchDomain.java [6] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/src/main/java/node/LaunchCalculatorNodeA.java
