Mail

In Tuscany at the moment the thing that runs a composite is an Node.(we are trying to deprecate SCADomain as it's a little confusing). So in the calculator-distributed sample you see the nodes being launched programmatically with something like;

NodeLauncher nodeLauncher = NodeLauncher.newInstance();
node = nodeLauncher.createNodeFromURL("http://localhost:9990/node-config/NodeA");

Then, as you have found, there is a separate domain manager which is just a web app that configures the composites in the domain and makes them available to the nodes that are going to run them. If you look at the command above, the URL "http://localhost:9990/node-config/NodeA" is a place the node looks for it's configuration.

A composite with references configured using targets will work in this case, for example,

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://sample"
xmlns:sample="http://sample"
name="CalculatorA">

<component name="CalculatorServiceComponentA">
<implementation.java class="calculator.CalculatorServiceImpl"/>
<reference name="addService" target="AddServiceComponentB" />
<reference name="subtractService" target="SubtractServiceComponentC" />
<reference name="multiplyService" target="MultiplyServiceComponentA"/>
<reference name="divideService" target="DivideServiceComponentA" />
</component>

<component name="MultiplyServiceComponentA">
<implementation.java class="calculator.MultiplyServiceImpl" />
</component>

<component name="DivideServiceComponentA">
<implementation.java class="calculator.DivideServiceImpl" />
</component>

</composite>

This has references on the CalculatorServiceConponentA that target services that you can see inside the same composite and others that are remote and have to be found by the domain manager.

You can run nodes happily without this central domain manager. For example a node can be started up with a command like;

node = SCANodeFactory.newInstance().createSCANode("nodeA/calculator.composite",
new SCAContribution("common", "target/classes"),

(Note - I notice that we use a launcher in some samples and looking for this I notice we use factories in others. Needs some rationalization!)

However this means that each node runs independently and you have to manually configure the composites so that the target services are know. So our compoiste would have to be something like;

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://sample"
xmlns:sample="http://sample"
name="CalculatorA">

<component name="CalculatorServiceComponentA">
<implementation.java class="calculator.CalculatorServiceImpl"/>
<reference name="addService">
<binding.ws uri="http://localost:8080/NodeB/AddServiceComponentB"/>
</reference>
<reference name="subtractService" >
<binding.ws uri="http://localost:8080/NodeC/SubtractServiceComponentC"/>
</reference>
<reference name="multiplyService" target="MultiplyServiceComponentA"/>
<reference name="divideService" target="DivideServiceComponentA" />
</component>

<component name="MultiplyServiceComponentA">
<implementation.java class="calculator.MultiplyServiceImpl" />
</component>

<component name="DivideServiceComponentA">
<implementation.java class="calculator.DivideServiceImpl" />
</component>

</composite>

So I have to know where the remote services are going to be. If you want to just be able to start nodes and have them discovered in some way then we don't support that at the moment. However I'm keen to understand your requirement as this sounds like something we've been asked for a few time so we really should have a go at providing support.

Re. your specific questions

1. the domain composite is just the composite that Tuscany provides to run the domain manager application. The other three composites are application composites.

2. With the calculator distributed coded the way it is the nodes don't really know very much. They are told to read their configuration from a specific URL and are given a fully configured composite file with all of the concrete URLs filled in. The notion that a set of nodes are given URLs pointing to the same domain manager mean that they are part of the same domain.

3. Not sure about this yet. I need to understand your application a little better. It sounds like the services you are scheduling requests to all have the same interface so you could have a reference which has multiplicity >1 (represented as an array or a list for example. Then in you scheduler component you could just pick a component off the list. Or you could implement an operation on the worker compoenent that allows the scheduler to ask a worker questions such as finding out its name.

The harder question is how to wire the scheduler to the workers. If there are a set number then you can do this manually. If you don't have a fixed number then that's harder as it implies some kind of discovery which is a feature we would have to look at adding.

Mail