Create A Distributed Application

An SCA assembly can be run in a single or multi-node environment. Here we introduce SCA node and walk you through an example that demonstrates how the calculator example can be distributed.

Nodes

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.

The composite was run using the following API;

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

Thisloads the named composite, and any associates 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,

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();

SCA Domain

When running standalone a node also 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.

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 and reference components running on a separate node. To make this work the nodes must be running as part of the same distributed SCA domain.

SCA introduces the concept of a domain. 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.

Composites with the Domain

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. 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"
           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 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 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 run by separate nodes within the context of a single domain and the calculator addService reference

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

will still be able to find the add component running on a separate node. So a domain can consist of more than one 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.

Domain Configuration

Tuscany SCA supports running an SCA Domain in a single Node or spread across multiple Nodes potentially distributed across different machines. In the distibuted a separate domain manager process is run to parse SCA contributions and to provide suitable configuration to the nodes running as part of the domain.

We have seen a domain with a single node before.

A domain with multiple nodes allows wires to run between components running in the separate nodes which may be running on different JVMs on different machines.

When reference and service are in different composites 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 = SCANode2Factory.newInstance().createSCANodeFromURL("http://localhost:9990/node-config/NodeA");

The URL http://localhost:9990/node-config/NodeA 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 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. 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.

<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>

Old Notes

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.

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();

">

Unknown macro: {bgcolor}

Hosting Tuscany SCA Nodes

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.

">

Unknown macro: {bgcolor}

Tuscany SCA Domain

SCA has the concept of a domain. 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.

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. For example, this section of the calculator composite file shows how the CalcuatorServiceComponent targets the AddServiceComponent.

<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>

The target="AddServiceComponent" of the CalculatorServiceComponent's addService reference refers to the AddServiceComponent defined later on in this composite. A domain can consist of more than one composite and wires can run between components defined in the composites. The SCA Domain describes the boundary within which target component services can be located.

To connect to services outside of the SCA Domain (whether they be services provided by SCA or by other means) you configure an explicit binding, for example, lets assume that the AddServiceComponent 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" >
           <interface.java interface="calculator.AddService" />
            <binding.ws uri="http://localhost:8080/sample-calculator-ws-webapp/AddServiceComponent"/>
        </reference>
        <reference name="subtractService" target="SubtractServiceComponent"></reference>
        <reference name="multiplyService" target="MultiplyServiceComponent"></reference>
        <reference name="divideService" target="DivideServiceComponent"></reference>
    </component>

Tuscany SCA supports running an SCA Domain in a single Node or spread across multiple Nodes potentially on different machines. We have seen a domain with a single node before.

A domain with multiple nodes allows wires to run between components running in the separate nodes which may be running on different JVMs on different machines.

When reference and service are in different composites 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 workspace 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 = SCANode2Factory.newInstance().createSCANodeFromURL("http://localhost:9990/node-config/NodeA");

The URL http://localhost:9990/node-config/NodeA 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 workspace. You can fire up the workspace and play with the gui or look at the 3 xml files in the top directory of that sample which the workspace 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);
    }

TODO - how is this run without having to create your own mainline.

Configuring A Domain Through The Web Interface

One the domain manager is running you can get to the web interface of the default domain point you browser at http://localhost:9990/ui. 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.

Tuscany Web-based Domain Manager Tool

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.

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>

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>

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.

Child pages

Distributed Calculator

Create A Distributed Application

Nodes

Configuring Nodes

Starting a Node

Locating Services

Stopping a Node

SCA Domain

Composites with the Domain

Domain Configuration

Starting A Domain

Configuring A Domain Through The Web Interface

Configuring a Domain Through The File System

Connection to non-SCA services

Old Notes

Tuscany SCA Node

Tuscany SCA Node Implementation

Creating and Configuring Node

Starting a Node

Locating Services

Stopping a Node

">

Command Line

">

Starting A Domain

Configuring A Domain Through The Web Interface

Configuring a Domain Through The File System

Tuscany Web-based Domain Manager Tool

Mail

Mail