Page History

...

Node is a Tuscany specific term (you won't find it in the OASIS SCA specifications). A node runs an SCA assembly described by one or more composite files. A node runs in a single JVM. You can start more than one node in a single JVM if you need to. In the first section of the user guide we built a calculator sample that included Calculator, Add, Subtract, Multiply and Divide components included in a single composite.

Image Removed

The composite was run using the following API;

The node wraps the Tuscany SCA runtime. The runtime comprises 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 model of the SCA assembly, create the components and wire them together ready to process incoming messages.

A node runs an SCA assembly described by one or more composite files. A node runs in a single JVM. You can start more than one node in a single JVM if you need to but we only tend to do this for testing purposes. In the first section of the user guide we built a calculator sample that included Calculator, Add, Subtract, Multiply and Divide components included in a single composite.

Image Added

The composite was run using the following API;

        node = SCANodeFactory.newInstance().createSCANodeFromClassLoader("Calculator.composite", getClass().getClassLoader(

        node = SCANodeFactory.newInstance().createSCANodeFromClassLoader("Calculator.composite", getClass().getClassLoader());
        node.start();

This loads the named composite, and any associates associated resources, and then starts the node to start up all of the components within the composite.

The Node wraps the Tuscany SCA runtime. The runtime comprises 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 model of the SCA assembly, create the components and wire them together ready to process incoming messages.

Configuring Nodes

Creating a node in code is straightforward. For example,

Configuring Nodes

Creating a node in code is straightforward. For example,

SCANode2 node = SCANodeFactory.newInstance().createSCANodeFromClassLoader("calculator.composite", null);

Here the "null" parameter means that the node factory uses the current class' classloader to locate the named composite file. The location of the composite file is assumed to be the location of 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 

SCANode2 node = SCANodeFactory.newInstance().createSCANodeFromClassLoadercreateSCANode("calculatorfile:/C:/CalculatorContribution1/Calculator.composite", null);

Here the node factory uses current classes classloader to locate 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 = SCANodeFactory.newInstance().createSCANode("
        		                               new SCAContribution("CalculatorContribution1",
        		                                                               "file:/C:/CalculatorContribution1/Calculator.composite"),
                        		                               new SCAContribution("CalculatorContribution1CalculatorContribution2",
        		                                                               "file:/C:/CalculatorContribution1")CalculatorContribution2"));

Where

"file:/C:/CalculatorContribution1/Calculator.composite"

Is the explicit location of the composite file to be run and

new SCAContribution("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

"file:/C:/CalculatorContribution1")

Shows how to provide contribution details. The first parameter "CalculatorContribution1" gives a name for the contribution. The second parameter tells the node where to find the contribution. As this second parameter is a URL the contribution can be read from disk or directly from the network.

Using multiple contributions can be useful 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 to be started. It can be started as follows.

node.start();

Locating Services

If the mode has been created from from within a piece of Java code using the node fatory interface a local service reference can be retrieved in the following way.

calculatorService = ((SCAClient)node).getService(CalculatorService.class, "CalculatorServiceComponent");

One a node has been started all of its remote bindings will be active so you can also access the component services that the node contains via any remote bindings that they define.

Stopping a Node

If you are done with the node or need to stop it processing messages use the followingOnce the node is created it is configured and ready to be started. It can be started as follows.

node.startstop();

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 it processing messages use the following.

node.stop();

SCA Domain

When running standalone a node defines the scope of component services that references can target by name. SCA defines the term SCA Domain to describe this scope. With a standalone node references can only target services that are running within the same node. Section 10 of the SCA Assembly specification describes an SCA Domain as defining "the boundary of visibility for all SCA mechanisms". SCA wires can be used to connect components within a single SCA Domain.

Nodes running in separate JVMs can be configured to run an SCA assembly in a distributed fashion. In this way components running on one node can reference components running on a separate node. To make this work the nodes must be running as part of the same distributed SCA domain.

Creating composites to run across multiple nodes.

From the calculator sample you can see that the wires between the component references and services, formed by adding a target component name to a reference, are resolved inside an SCA domain comprising a single node.

Image Removed

For example, this section of the calculator composite file shows how the CalcuatorServiceComponent targets the AddServiceComponent.

SCA Domain

When running standalone a node defines the scope of component services that references can target by name. SCA defines the term SCA Domain to describe this scope. Section 10 of the SCA Assembly specification actually describes an SCA Domain as defining "the boundary of visibility for all SCA mechanisms".

In a standalone node a reference can only target services that are running within the same node. However nodes running in separate JVMs can be configured to run an SCA assembly in a distributed fashion. In this way components running on one node can reference components running on a separate node. To make this configuration work the nodes must be running as part of the same distributed SCA domain. In Tuscany a distributed SCA domain is represented using a separate domain manager process.

Creating composites to run across multiple nodes.

From the calculator sample you can see that the wires between the component references and services, formed by adding a target component name to a reference, are resolved inside an SCA domain comprising a single node.

Image Added

For example, this section of the calculator composite file shows how the CalcuatorServiceComponent targets the AddServiceComponent.

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
        

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
           targetNamespace="http://sample"
           xmlns:sample="http://sample"
           name="Calculator">
    <component name="CalculatorServiceComponent">
        <implementation.java class="calculator.CalculatorServiceImpl"/>
        <reference name="addService" target="AddServiceComponent" />
        <reference name="subtractService" target="SubtractServiceComponent" />
        <reference name="multiplyService" target="MultiplyServiceComponent" />
        <reference name="divideService" target="DivideServiceComponent" />
    </component>

    <component name="AddServiceComponent">
        <implementation.java class="calculator.AddServiceImpl"/>
    </component>
 
    ...
</composite>

The target="AddServiceComponent" of the CalculatorServiceComponent's addService reference refers to the AddServiceComponent defined later on in this composite. A single composite must run on a single node so to distribute this application we need to separate it into more than one composite, for example, the first .

In the distributed calculator samples the a composite defines the calculator component but not the add component;

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
           targetNamespace="http://sample"
           xmlns:sample="http://sample"
           name="Calculator">
    <component name="CalculatorServiceComponent">
        <implementation.java class="calculator.CalculatorServiceImpl"/>
        <reference name="addService" target="AddServiceComponent" />
        <reference name="subtractService" target="SubtractServiceComponent" />
        <reference name="multiplyService" target="MultiplyServiceComponent" />
        <reference name="divideService" target="DivideServiceComponent" />
    </component>
 
    ...
</composite>

The second Another composite defines the add component.

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

    <component name="AddServiceComponent">
        <implementation.java class="calculator.AddServiceImpl"/>
    </component>
 
    ...
</composite>

These two composites can be are run by separate nodes within the context of a single domain and the calculator addService reference

<reference name="addService" target="AddServiceComponent" />

will is still be able to find the add component running on a separate node.

...

So a distributed SCA domain can consist of more than one node and hence composite and wires can run between components defined in the separate composites. The SCA Domain describes the boundary within which target component services can be located.

Starting A Domain

...

When a reference and the service to which is refers are in different composites a domain manager is used to pre-process each composited prior to the composites being deployed to nodes for running. Contributions (containing the composites) are added to the domain manager. Configuration must be provided which tells the domain manager where the nodes are that are going to run the composites and which composites they will run. Based on this information the domain manager makes an atom feed available for each composite that is deployed to a node. The node to which the composite is assigned must read the correct atom feed in order to configure itself by downloading the composite to run and the contributions required provide the artifacts required by the composite. There is a Node API that takes as input the URL of an atom feed exposed by the domain manager as follows.

...

There is a launcher that has a mainline for starting the domain. For example,

Code Block
public static void main(String[] args) throws Exception { DomainManagerLauncher.main(args); }

In the calculator-distributed sample this code is contained in the class node.LaunchDomain.java. Runing this will run the domain mananger.

This article that is hosted outside of Tuscany provides a step by step instruction for how to use the Tuscany web-based domain manager UI to administer an SCA domain and how to use the domain administrative UI to deploy an SOA solution comprised of SCA components.

Configuring A Domain Through The Domain Manager Web Interface

...

Once the domain manager is running you can get to the web interface of the default domain point you browser at

http://localhost:9990/

...

The URL http://localhost:9990/node-config/NodeA^{Image Removed} is the URL of the atom feed that the domain manager provides.

The domain manager processes all the relationships between all composite components and provides a fully configured composite to each node, i.e. all of the binding URIs are filled out correctly so it's basically a pre-processing step. You can simulate the effect by manually adding the full uri to the reference binding.ws if you don't want to run with the domain manager

The calculator-distributed sample is a simple example of the use of the domain manager. You can fire up the domain manager and play with the gui or look at the three xml files in the top directory of that sample which the domain manager relies on for configuration.

Starting A Domain

There is a launcher that has a mainline for starting the domain. For example,

    public static void main(String[] args) throws Exception {
        DomainManagerLauncher.main(args);
    }

This article that is hosted outside of Tuscany provides a step by step instruction for how to use the Tuscany web-based domain manager UI to administer an SCA domain and how to use the domain administrative UI to deploy an SOA solution comprised of SCA components.

Configuring A Domain Through The Domain Manager Web Interface

Once the domain manager is running you can get to the web interface of the default domain point you browser at http://localhost:9990/ui^{Image Removed}. This provides a number of different pages allowing you to

• Add contributions to the domain
• Add node configurations to the domain
• Configure composites to run on specific nodes
• Start local node instances to test the configuration

Configuring a Domain Through The File System

Behind the domain manager web application there are three files where the configuration information is stored.

workspace.xml - stores the ID and location of each contribution that has been added to the domain.

domain.composite - the virtual domain composite. This is an SCA composite that represents the virtual domain which includes all of the composites that will run in the domain. A URI is provided which indicates which contribution each composite comes from. Ultimately an SCANode2 instance will be started for each composite included in the virtual domain. Each SCANode2 instance can be running on separate/distributed processors. So the virtual domain is a consolidated description of you distributed SCA application

cloud.composite - describes the compute cloud (the set of distributed SCANode2 instances) being used to run the SCA application. Each node is assigned a composite and also has details of the configuration of bindings when they run on that node, for example, the root URI is set. It's possibly slightly confusing that this file is in SCA composite format also but this is a convenience because firstly we didn't have to create a new file format and secondly there may be some benefit in the future of representing this network of nodes as a network of SCA services for management purposes although we don't do that yet.

These files are updated when you make changes to the domain through the domain manager interface but they have a fairly simple XML format and can be edited manually or new utilities could be constructed to edit them automatically.

Connection to non-SCA services

To connect to services outside of the SCA Domain (whether they be services provided by SCA or by other means) you can still configure an explicit binding, for example, lets now assume that the DivideServiceComponent is a non-sca web service out there on the network somewhere. As this is outside the SCA domain we can use an explicit remote binding to talk to it.

...

ui^{Image Added}. This provides a number of different pages allowing you to

• Add contributions to the domain
• Add node configurations to the domain
• Configure composites to run on specific nodes
• Start local node instances to test the configuration

When you start the domain manager for the distributed calcultor sample you will see the pages already populated with the information needed to execture the sample.

Configuring a Domain Through The File System

Behind the domain manager web application there are three files where the configuration information is stored.

workspace.xml - stores the ID and location of each contribution that has been added to the domain.

domain.composite - the virtual domain composite. This is an SCA composite that represents the virtual domain which includes all of the composites that will run in the domain. A URI is provided which indicates which contribution each composite comes from. Ultimately an SCANode2 instance will be started for each composite included in the virtual domain. Each SCANode2 instance can be running on separate/distributed processors. So the virtual domain is a consolidated description of you distributed SCA application

cloud.composite - describes the compute cloud (the set of distributed SCANode2 instances) being used to run the SCA application. Each node is assigned a composite and also has details of the configuration of bindings when they run on that node, for example, the root URI is set. It's possibly slightly confusing that this file is in SCA composite format also but this is a convenience because firstly we didn't have to create a new file format and secondly there may be some benefit in the future of representing this network of nodes as a network of SCA services for management purposes although we don't do that yet.

These files are updated when you make changes to the domain through the domain manager interface but they have a fairly simple XML format and can be edited manually or new utilities could be constructed to edit them automatically.

Connection to non-SCA services

To connect to services outside of the SCA Domain (whether they be services provided by SCA or by other means) you can still configure an explicit binding, for example, lets now assume that the DivideServiceComponent is a non-sca web service out there on the network somewhere. As this is outside the SCA domain we can use an explicit remote binding to talk to it.

<component name="CalculatorServiceComponent">
		<implementation.java class="calculator.CalculatorServiceImpl"/>
        <reference name="addService" ></reference>
        <reference name="subtractService" target="SubtractServiceComponent"></reference>
        <reference name="multiplyService" target="MultiplyServiceComponent"></reference>
        <reference name="divideService" target="DivideServiceComponent">
            <binding.ws uri="http://localhost:8080/sample-calculator-ws-webapp/AddServiceComponent"/>
        </reference>
    </component>

Starting Nodes In A Distributed Domain

The domain manager is used to pre-process each composited prior to the composites being deployed to nodes for running. Contributions (containing the composites) are added to the domain manager. Configuration must be provided which tells the domain manager where the nodes are that are going to run the composites and which composites they will run. Based on this information the domain manager makes an atom feed available for each composite that is deployed to a node. The node to which the composite is assigned must read the correct atom feed in order to configure itself by downloading the composite to run and the contributions required provide the artifacts required by the composite. There is a Node API that takes as input the URL of an atom feed exposed by the domain manager as follows.

SCANode2 node = SCANodeFactory.newInstance().createSCANodeFromURL("http://localhost:9990/node-config/NodeA");

The URL http://localhost:9990/node-config/NodeA^{Image Added} is the URL of the atom feed that the domain manager provides.

The domain manager processes all the relationships between all composite components and provides a fully configured composite to each node, i.e. all of the binding URIs are filled out correctly so it's basically a pre-processing step.

In the calculator-distributed sample java classes are provided which are set up ready to start the required nodes. Look a the files.

node.LaunchCalculatorNodeA
node.LaunchCalculatorNodeB
node.LaunchCalculatorNodeC

The README provided with the samples gives more detailed instruction on how to run the sample.