note moved all node related content from the old user doc to here. This page can explain node in the context of distributed calculator.
Tuscany SCA Node
In order to run an SCA application Tuscany SCA Java provides a runtime that is wrapped up in a Node. The runtime itself is made up of many of the modules that are present in the modules directory of the Tuscany SCA Java distribution. As you might expect there are functions that read XML, create an in memory mode model of the SCA assembly, create the components and wire them together ready to process incoming messages. All of these functions are wrapped up in a Node. A node is configured using SCA contributions and will run a single composite. When running standalone the node also defines the scope of component services that references can target by name. SCA defines the term Domain to describe this scope.
A node runs within a single JVM. A JVM can run many Nodes.
host embedded
For a long time in Tuscany we have had a modules called host.embedded that contains the code required to get the runtime up and running in standalone configuration. This was developed before the distributed domain support was added but the main interface here is called an SCADomain. It's just a very small domain with only one node inside it. You can't see the node and you configure and access it via the SCADomain interface. The majority of samples and tests use this today. However the new SCA Node implementation can work in both standalone and distributed configuration so may be more appropriate in situations other than the simple Tuscany samples and tests. We will convert more samples ant tests to this approach over time to show the benefit of using the node implementation.
Tuscany SCA Node Implementation
Available from release 1.2 there is a new domain/node implementation. The node part of this can be run either stand alone or as part of a distributed domain. Most of the sample and test code has not started using this implementation yet and there may be more changes to the API.
Creating and Configuring Node
Creating a node in code is straightforward. For example,
SCANode2 node = SCANode2Factory.newInstance().createSCANodeFromClassLoader("calculator.composite", null);
The node uses current classes classloader to located the named composite file. The location of the composite file is assumed to be the location if the SCA contribution. The assumption here is that only one contribution is required.
If more contributions must be loaded by the node the following interface can be used.
SCANode2 node = SCANode2Factory.newInstance().createSCANode("file:/C:/CalculatorContribution1/Calculator.composite", new SCAContribution("CalculatorContribution1", "file:/C:/CalculatorContribution1"), new SCAContribution("CalculatorContribution2", "file:/C:/CalculatorContribution2"));
Where
"file:/C:/CalculatorContribution1/Calculator.composite"
Is the explicit location of the composite file to be run and
new SCAContribution("CalculatorContribution1", "file:/C:/CalculatorContribution1")
Shows how to provide contribution details. Multiple contributions can be specified. You might have multiple contributions if, for example, you have chosen to separate common artifacts from those specific to this composite. The contribution containing common artifacts can then be used in other SCA applications without change.
Starting a Node
Once the node is created it is configured and ready for use. It can be started as follows.
node.start();
Locating Services
A local service reference can be retrieved in the following way.
calculatorService = ((SCAClient)node).getService(CalculatorService.class, "CalculatorServiceComponent");
Stopping a Node
If you are done with the node or need to stop is processing messages use the following.
node.stop();
You can run SCA applications in many different ways but the same underlying runtime is used but packaged in slightly different ways as follows
Command Line
Most of the samples that are shipped with the Tuscany SCA Java distribution run from the command line by driving the Node API or old SCADomain API programmatically.
There is a pre-packaed launcher that has a mainline for starting nodes. When run from the command line it expects to be running in the context of the binary distribution where "modules" and "lib" directories are present.
It loads all of the jars from
1) the directory where the launcher class is found.
2) the ../modules directory
3) the ../libs directory
It then repeats the process looking for ../modules and ../lib dirs based on the contents of a TUSCANY_HOME environment variable
With the final list it creates a URLClassLoader with the current classloader as the parent and enforces a parent first classloading strategy.
TODO - how does it find the composite file to run?