Distributed SCA Domain (TUSCANY) edited by Simon Laws
Page:
http://cwiki.apache.org/confluence/display/TUSCANY/Distributed+SCA+Domain
Changes:
http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=66885&originalVersion=2&revisedVersion=3
Content:
---------------------------------------------------------------------
{section:border=true}
{column:width=15%}
{include: SCA Java Subproject Menu}
{include: Java SCA Menu New}
{column}
{column:width=85%}
h1. 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.
h2. 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|http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/samples/calculator/]
that included Calculator, Add, Subtract, Multiply and Divide components
included in a single composite.
!calculator2.png|align=centre!
The composite was run using the following API;
{code}
node =
SCANodeFactory.newInstance().createSCANodeFromClassLoader("Calculator.composite",
getClass().getClassLoader());
node.start();
{code}
This loads the named composite, and any associated resources, and then starts
the node to start up all of the components within the composite.
h3. Configuring Nodes
Creating a node in code is straightforward. For example,
{code}
SCANode2 node =
SCANodeFactory.newInstance().createSCANodeFromClassLoader("calculator.composite",
null);
{code}
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}
SCANode2 node =
SCANodeFactory.newInstance().createSCANode("file:/C:/CalculatorContribution1/Calculator.composite",
new
SCAContribution("CalculatorContribution1",
"file:/C:/CalculatorContribution1"),
new
SCAContribution("CalculatorContribution2",
"file:/C:/CalculatorContribution2"));
{code}
Where
{code}
"file:/C:/CalculatorContribution1/Calculator.composite"
{code}
Is the explicit location of the composite file to be run and
{code}
new SCAContribution("CalculatorContribution1",
"file:/C:/CalculatorContribution1")
{code}
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.
h3. Starting a Node
Once the node is created it is configured and ready to be started. It can be
started as follows.
{code}
node.start();
{code}
h3. 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}
calculatorService = ((SCAClient)node).getService(CalculatorService.class,
"CalculatorServiceComponent");
{code}
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.
h3. Stopping a Node
If you are done with the node or need to stop it processing messages use the
following.
{code}
node.stop();
{code}
h2. 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.
h3. Creating composites to run across multiple nodes.
>From the [calculator
>sample|http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/samples/calculator/]
> 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.
!calculator2.png|align=centre!
For example, this section of the calculator composite file shows how the
CalcuatorServiceComponent targets the AddServiceComponent.
{code}
<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>
{code}
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|http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/samples/calculator-distributed/]
sample the composite defines the calculator component but not the add
component;
{code}
<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>
{code}
Another composite defines the add component.
{code}
<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>
{code}
These two composites are run by separate nodes within the context of a single
domain and the calculator addService reference
{code}
<reference name="addService" target="AddServiceComponent" />
{code}
is still be able to find the add component running on a separate node.
!calculator3.png|align=centre!
So a distributed SCA domain can consist of more than one node/composite and
wires can run between components defined in the separate composites.
h3. Starting A Domain
There is a launcher that has a mainline for starting the domain. For example,
{code}
public static void main(String[] args) throws Exception {
DomainManagerLauncher.main(args);
}
{code}
In the
[calculator-distributed|http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/samples/calculator-distributed/]
sample this code is contained in the class node.LaunchDomain.java. Runing this
will run the domain mananger.
This
[article|http://www.ibm.com/developerworks/webservices/library/ws-sca-tuscany/index.html?S_TACT=105AGX04&S_CMP=EDU]
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.
h3. 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.
h3. 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.
h3. 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}
<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>
{code}
h3. 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}
SCANode2 node =
SCANodeFactory.newInstance().createSCANodeFromURL("http://localhost:9990/node-config/NodeA";);
{code}
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|http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/samples/calculator-distributed/]
sample java classes are provided which are set up ready to start the required
nodes. Look at the files.
{code}
node.LaunchCalculatorNodeA
node.LaunchCalculatorNodeB
node.LaunchCalculatorNodeC
{code}
The README provided with the samples gives more detailed instruction on how to
run the sample.
{column}
{section}
---------------------------------------------------------------------
CONFLUENCE INFORMATION
This message is automatically generated by Confluence
Unsubscribe or edit your notifications preferences
http://cwiki.apache.org/confluence/users/viewnotifications.action
If you think it was sent incorrectly contact one of the administrators
http://cwiki.apache.org/confluence/administrators.action
If you want more information on Confluence, or have a bug to report see
http://www.atlassian.com/software/confluence
