Programmatically dynamic distributed app without a domain manager

["Maloney, Robert A" <bm...@bottomline.com>]

Greetings,

 

I am fairly new to Tuscany, and am having a difficult time with
programmatic configuration and launch of multiple nodes in a single
domain.  I started with helloworld-ws-service and
helloworld-ws-reference, but each is in a separate domain.  Then to
calculator-distributed, but it uses a Domain Manager.  I would like to
avoid having to run a separate Domain Manager: from
http://tuscany.apache.org/sca-java-user-guide.html:

 

>> 

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.

<< 

 

However, I would also like to avoid having to manually create/manage the
composite files, if possible.  

 

I am trying to convert our multiple-process app to SCA, and be
distributable across JVMs and machines.  We essentially have a
scheduling component, and 1 or more identical worker components.  The
worker components will have unique names.  Based on the samples, the
domain and individual nodes can be programmatically started.  I am
missing the overall picture of what needs to be run, and what
configuration should be provided for each runtime.  

 

I am relating my configuration with calculator-distributed, where the
scheduling component would be the "Calculator Service Component" (in
nodeA), and the worker components would be in nodeB and nodeC, but
without the Domain Manager.  For example, I am expecting to have to:

 

1)       Launch the scheduling component

a.       Create a new SCADomain instance

b.      Create nodeA

2)       Launch 2 uniquely named worker components, one in nodeB and the
other in nodeC

3)       Then from the scheduling component, call into the individual
worker components

 

Questions:

 

1)       If 4 composites are required (domain, nodeA, nodeB, and nodeC),
what are the contents of the domain composite versus the nodeA
composite?

2)       How does nodeB and nodeC know that they are part of the domain
created by nodeA?  Or is it not relevant, as long as A can talk to B and
C?

3)       In the scheduling component (nodeA), how to differentiate the
service calls to nodeB and nodeC?

 

Also, having to restart the application to add/remove worker nodes is
acceptable, but not preferable.

 

Many thanks,

 

Bob

Re: Programmatically dynamic distributed app without a domain manager

[Simon Laws <si...@googlemail.com>]

On Tue, Nov 11, 2008 at 7:02 PM, Maloney, Robert A
<bm...@bottomline.com>wrote:

>  Greetings,
>
>
>
> I am fairly new to Tuscany, and am having a difficult time with
> programmatic configuration and launch of multiple nodes in a single domain.
>  I started with helloworld-ws-service and helloworld-ws-reference, but each
> is in a separate domain.  Then to calculator-distributed, but it uses a
> Domain Manager.  I would like to avoid having to run a separate Domain
> Manager: from http://tuscany.apache.org/sca-java-user-guide.html:
>
>
>
> >>
>
> 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.
>
> <<
>
>
>
> However, I would also like to avoid having to manually create/manage the
> composite files, if possible.
>
>
>
> I am trying to convert our multiple-process app to SCA, and be
> distributable across JVMs and machines.  We essentially have a scheduling
> component, and 1 or more identical worker components.  The worker components
> will have unique names.  Based on the samples, the domain and individual
> nodes can be programmatically started.  I am missing the overall picture of
> what needs to be run, and what configuration should be provided for each
> runtime.
>
>
>
> I am relating my configuration with calculator-distributed, where the
> scheduling component would be the "Calculator Service Component" (in nodeA),
> and the worker components would be in nodeB and nodeC, but without the
> Domain Manager.  For example, I am expecting to have to:
>
>
>
> 1)       Launch the scheduling component
>
> a.       Create a new SCADomain instance
>
> b.      Create nodeA
>
> 2)       Launch 2 uniquely named worker components, one in nodeB and the
> other in nodeC
>
> 3)       Then from the scheduling component, call into the individual
> worker components
>
>
>
> Questions:
>
>
>
> 1)       If 4 composites are required (domain, nodeA, nodeB, and nodeC),
> what are the contents of the domain composite versus the nodeA composite?
>
> 2)       How does nodeB and nodeC know that they are part of the domain
> created by nodeA?  Or is it not relevant, as long as A can talk to B and C?
>
> 3)       In the scheduling component (nodeA), how to differentiate the
> service calls to nodeB and nodeC?
>
>
>
> Also, having to restart the application to add/remove worker nodes is
> acceptable, but not preferable.
>
>
>
> Many thanks,
>
>
>
> Bob
>

Hi Bob

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 xmlns="http://www.osoa.org/xmlns/sca/1.0"
           targetNamespace="http://sample"
           xmlns:sample="http://sample"
           name="CalculatorA">

    <component name="CalculatorServiceComponentA">
        <implementation.java class="calculator.CalculatorServiceImpl"/>
        <reference name="addService" target="AddServiceComponentB" />
        <reference name="subtractService" target="SubtractServiceComponentC"
/>
        <reference name="multiplyService"
target="MultiplyServiceComponentA"/>
        <reference name="divideService" target="DivideServiceComponentA" />
    </component>

    <component name="MultiplyServiceComponentA">
        <implementation.java class="calculator.MultiplyServiceImpl" />
    </component>

    <component name="DivideServiceComponentA">
        <implementation.java class="calculator.DivideServiceImpl" />
    </component>

</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 xmlns="http://www.osoa.org/xmlns/sca/1.0"
           targetNamespace="http://sample"
           xmlns:sample="http://sample"
           name="CalculatorA">

    <component name="CalculatorServiceComponentA">
        <implementation.java class="calculator.CalculatorServiceImpl"/>
        <reference name="addService">
            <binding.ws uri="http://localost:8080/NodeB/AddServiceComponentB
"/>
        </reference>
        <reference name="subtractService" >
            <binding.ws uri="
http://localost:8080/NodeC/SubtractServiceComponentC"/>
        </reference>
        <reference name="multiplyService"
target="MultiplyServiceComponentA"/>
        <reference name="divideService" target="DivideServiceComponentA" />
    </component>

    <component name="MultiplyServiceComponentA">
        <implementation.java class="calculator.MultiplyServiceImpl" />
    </component>

    <component name="DivideServiceComponentA">
        <implementation.java class="calculator.DivideServiceImpl" />
    </component>

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

Regards

Simon