Versions Compared

Old Version 2

changes.mady.by.user Simon Laws

Saved on

compared with

New Version Current

changes.mady.by.user Simon Laws

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Section
bordertrue
Column
width15%
Include Page
TUSCANY: SCA Java Subproject MenuTUSCANY:
SCA Java Subproject Menu
Include Page
TUSCANY: Java SCA Menu NewTUSCANY:
Java SCA Menu New

Distributed SCA Domain

Using a distributed SCA domain that works across multiple JVMs is not much harder than using the Standalone SCA Domain.

Image Removed

Here each running node has a representation of the domain so we create an instance of

Column
width85%

Create A Distributed Application

An SCA assembly can be run in a single or multi-node environment. Here we introduce the Tuscany node and SCA domain and explain how the calculator example can be distributed across multiple nodes.

Nodes

Node is a Tuscany specific term (you won't find it in the OASIS SCA specifications). 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;

Code Block

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

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

Configuring Nodes

Creating a node in code is straightforward. For example,

Code Block

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.

Code Block

SCANode2  node = SCANodeFactory.newInstance().createSCANode("file:/C:/CalculatorContribution1/Calculator.composite",
        		                               new SCAContribution("CalculatorContribution1",
        		                                                               "file:/C:/CalculatorContribution1"),
                                                       new SCAContribution("CalculatorContribution2",
        		                                                               "file:/C:/CalculatorContribution2"));

Where

Code Block

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

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

Code Block

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

Code Block

node.start();

Locating Services

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

Code Block

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

Code Block

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

Code Block

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

In the distributed calculator sample the composite defines the calculator component but not the add component;

Code Block

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

Another composite defines the add component.

Code Block

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

Code Block

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

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

Image Added

So a distributed SCA domain can consist of more than one node/composite and wires can run between components defined in the separate composites.

Starting A Domain

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 by pointing your 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

When you start the domain manager for the distributed calculator 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 SCANode instance will be started for each composite included in the virtual domain. Each SCANode 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 SCANode 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. In the distributed calculator sample you can find these files in the root directory.

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.

Code Block

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

Code Block

SCANode2 node = SCANodeFactory.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.

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

Code Block

node.LaunchCalculatorNodeA
node.LaunchCalculatorNodeB
node.LaunchCalculatorNodeC

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

Note
title:Notificationtitle:Notification
Center
Code Block

org.apache.tuscany.sca.domain.SCADomain.

Note that the package name is different compared to the standalone SCA domain. This time we are dealing with a distributed domain rather than a standalone domain.

Again there are a number of newInstance() operations to choose from. The first two are the same as in the standalone case

Code Block

public static SCADomain newInstance()

Starts a standalone domain with a default domain URI and will treat the classpath as the contribution to this domain. All .composite files on the classpath will will read any deployable components created accordingly.

Deployable components are defined by either

1/ placing the .composite file in the META-INF/sca-deployables/directory
2/ By specifying the composite as deployable in the META-INF/sca-contribution.xml file

Code Block

    public static SCADomain newInstance(String composite)

Starts a standalone domain with a default domain URI and will try and find the named composite file in the classpath and use it's location as the contribution location. It will deploy the named composite.

The third variation has changed to take account of the distributed domain.

Code Block

public static SCADomain newInstance(String domainURI, String nodeURI, String contributionLocation, String... composites)

This starts a local node with the identifier "nodeURI". This must be a unique uri that identifies this node. If this uri is a valid url of the form http://hostname:portnumber/Image Removed it is used by the node implementation as the root address for the management services that the node starts up.

In the future, when distributed domain support has been enabled in webapps, this will also indicate to SCA what the host name and port number of the web app container is.

The domainURI is the URL of the domain manager. This is a separate java application that the nodes contact in order to register service information and in order to find information about other services in the domain.

The contributionLocation and composite parameters are as before.

When the node starts is will load the contribution, deploy any deployable composites and then register information about any external services with the domain manager.

We can see how this works by taking a look at the calculator-distributed sample.

Image Removed

We have a sample domain manager implementation in the calculator-distributed sample. If you go to the sample you can run this using the following command

Code Block

ant runDomainNode

This starts some domain management services at the endpoint http://myhost:8877Image Removed. So the domain name in this case is http://myhost:8877Image Removed.

If you take a look at node.CalculatorNode.java you can see how each node in the domain is started.

Code Block

SCADomain scaDomain = SCADomain.newInstance(domainName, nodeName, null, nodeName + "/Calculator.composite");

Where domainName will be "http://myhost:8877" and the node name will be "nodeA" or "nodeB" or "nodeC". In the calculator-distributed sample you can start the node implementation using the ant build file again, for example

Code Block

ant RunNode http://localhost:8877 nodeB

Once started we can used the SCADomain interface as before. For example, a service proxy can be created and an operation called.

Code Block

CalculatorService calculatorService = scaDomain.getService(CalculatorService.class, "CalculatorServiceComponent");
double result = calculatorService.add(3, 2));

Putting this all together the following picture gives an idea of what is going on under the covers.

Image Removed