You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Giorgio Zoppi <gi...@gmail.com> on 2007/08/16 21:46:07 UTC
Distributed Runtime and Distributed Calculator
Hi,
i'm highly interested in contributing to the distributed runtime.
Actually I'm trying to understand if this component model could be the
building block for creating autonomic components. An autonomic
component can consist of one or more managed components coupled with a
single manager that controls them. To pursue its goal, the manager may
trigger an adaptation of the managed components to react to a run-time
change (i.e. fault, load balancing, etc).
Some questions..i've updated the svn and it builds but not the
distributed-calculator.
Why? (It could be for me a starting point).
Cheers,
Jo.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distributed Runtime and Distributed Calculator
Posted by haleh mahbod <hm...@gmail.com>.
Simon,
This is a nice quick walk through of the code. Should this be added to the
development guide as a 'quick get started' section.
Haleh
On 8/17/07, Simon Laws <si...@googlemail.com> wrote:
>
> Hi some comments in line below. There are a number of things in the SCA
> kitbag (as defined by the SCA specification) that may help with what you
> want to do. For example, you can define asynchronous interfaces on you
> services and have then call callbacks. There is testing that needs to be
> done to see which of these features need extra work in the distributed
> mode
> of operation.
>
> On 8/17/07, Giorgio Zoppi <gi...@gmail.com> wrote:
> >
> >
> > > Hi Jo, I've just checked in the fixes and re-enbabled:
> > >
> > > binding-sca-axis2 module which provides a remote version of the
> > default
> > > binding between SCA components
> > > distributed-impl module which provides some abstractions of
> > distributed
> > > domains and nodes and some interfaces for service registration and
> > location
> > > calculator-distributed which, provides a simple sample of tuscany
> > running
> > > distributed
> > >
> > > I get a clean build on windows so give it a try and let me know how
> you
> > get
> > > on.
> >
> > Ok. I update
> > > The tests that run during the mvn build use an in memory registry so
> all
> > the
> > > nodes run in one VM. This in memory version is replaced in the
> > calculator
> > > distributed sample with a network version. You can make the sample go
> by
> > > starting four separate VMs using the ant build file provided:
> > I've seen that.
> >
> > > Run up the node that provides the registry
> > > ant runDomainNode
> > >
> > > Run up the node that runs the add service
> > > ant runNodeB
> > >
> > > Run up the node that runs the subtract service
> > > ant runNodeC
> > >
> > > Run up the node that runs the Calculator services and drives calls to
> > the
> > > various methods
> > > ant runNodeA
> >
> > Ok. Let's go. I've seen part of your code, and I'll debug it tomorrow. I
> > need to understand the Tuscany core: Where a component is activated?
>
>
> Bit of background needed to answer this so bear with me. Inside the node
> (EmbeddedNode) it uses a local domain implementation (EmbeddedSCADomain)
> that holds all of the parts of the runtime together.
>
> domain = new EmbeddedSCADomain(cl, domainName);
> domain.start();
>
> In fact it uses two at the moment. One to hold the application components
> that you want to run and one to run any management components there might
> be. At the moment the only management component is a proxy to the remote
> service registry but I left this management domain in so that I didn't
> have
> to hand craft service clients for management purposes.
>
> You can get various things from the EmbeddedSCADoamin, for example, you
> see
> the code getting a contribution service and adding a contribution to it.
>
> ContributionService contributionService =
> domain.getContributionService();
> Contribution contribution = contributionService.contribute("
> http://calculator",
> contributionURL,
> null,
> //resolver,
> false);
>
> Contributions are the collections of resources that describe your
> services,
> e.g. .composite files, xsd files, wsdl files etc. The act of contributing
> this information results in an in memory assembly model (see the assembly
> module).
>
> Composite composite = contribution.getDeployables().get(0);
>
> The root of which is a composite which contains a hierarchy of components
> that you want to run. Then various steps are taken to turn the logical
> assembly model into runnable artifacts so that the components can be
> started. The model composite gets added to a top level composite that the
> local domain controls.
>
> domain.getDomainComposite().getIncludes().add(composite);
>
> Then there is a build stage where the parts of the logical model are
> linked
> together, references to services etc.
>
> domain.getCompositeBuilder().build(composite);
>
> Then there is a step where information is provided to the runtime so that
> remote services can be resolved automatically across the network. I.e. we
> link to guts of the assembly model into the notion of a distributed
> domain.
>
> distributedDomain.addDistributedDomainToBindings(composite);
>
> Then finally the runtime artifacts are created based on the logical model,
> these include the service endpoints and clients.
>
> domain.getCompositeActivator().activate(composite);
>
> Once all this is done, each component in the domain can be started
> independently
>
> for (Composite composite :
> domain.getDomainComposite().getIncludes()
> ){
> domain.getCompositeActivator().start(composite);
> }
>
> We need to look at these various domain interfaces and decide if we need
> them all. An outstanding todo!
>
> Can
> > I at runtime, disactivate a component in order to distribute in an other
> > host?
>
> Haven't got to this kind of dynamic activation/reactivation scenario yet.
> No
> one has asked for it:-). but in theory you should be able to stop a
> component in one domain implementation and start it in another (assuming
> that it has been contributed there as well of course) and the newly
> started
> component will update the registry with its new details. Would need to
> ensure that the old details are removed from the registry when the
> component
> stops which doesn't happen at the moment.
>
>
> Can I have a multithreaded component (or how can simulate it)?
>
>
> Yes, tuscany components are multithreaded.
>
> Now I'm developing now a testing component: A distributed workpool
> > service. This is my initial step and I'd finish for next Monday.
> >
> > With the following interfaces:
> >
> > public interface WorkerService {
> > void submit(Job j);
> > }
> >
> > Where a Job is something that you can compute:
> >
> > public interface Job<T> {
> > void set(T k);
> > void compute();
> > T get();
> > }
> >
> > So if now with your changes, I can compute Jobs in parallel in my LAN:
> > placing nodeA,nodeB in a host and the others in my other host.
> > When I have something working I'll providing you a patch.
>
>
>
> Sounds cool. Be interested to understand a little bit more about what
> constitutes a job and how it is moved about physically so I look forward
> to
> seeing where you get to.
>
> Cheers,
> > Jo.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> Regards
>
> Simon
>
Re: Distributed Runtime and Distributed Calculator
Posted by Simon Laws <si...@googlemail.com>.
Hi some comments in line below. There are a number of things in the SCA
kitbag (as defined by the SCA specification) that may help with what you
want to do. For example, you can define asynchronous interfaces on you
services and have then call callbacks. There is testing that needs to be
done to see which of these features need extra work in the distributed mode
of operation.
On 8/17/07, Giorgio Zoppi <gi...@gmail.com> wrote:
>
>
> > Hi Jo, I've just checked in the fixes and re-enbabled:
> >
> > binding-sca-axis2 module which provides a remote version of the
> default
> > binding between SCA components
> > distributed-impl module which provides some abstractions of
> distributed
> > domains and nodes and some interfaces for service registration and
> location
> > calculator-distributed which, provides a simple sample of tuscany
> running
> > distributed
> >
> > I get a clean build on windows so give it a try and let me know how you
> get
> > on.
>
> Ok. I update
> > The tests that run during the mvn build use an in memory registry so all
> the
> > nodes run in one VM. This in memory version is replaced in the
> calculator
> > distributed sample with a network version. You can make the sample go by
> > starting four separate VMs using the ant build file provided:
> I've seen that.
>
> > Run up the node that provides the registry
> > ant runDomainNode
> >
> > Run up the node that runs the add service
> > ant runNodeB
> >
> > Run up the node that runs the subtract service
> > ant runNodeC
> >
> > Run up the node that runs the Calculator services and drives calls to
> the
> > various methods
> > ant runNodeA
>
> Ok. Let's go. I've seen part of your code, and I'll debug it tomorrow. I
> need to understand the Tuscany core: Where a component is activated?
Bit of background needed to answer this so bear with me. Inside the node
(EmbeddedNode) it uses a local domain implementation (EmbeddedSCADomain)
that holds all of the parts of the runtime together.
domain = new EmbeddedSCADomain(cl, domainName);
domain.start();
In fact it uses two at the moment. One to hold the application components
that you want to run and one to run any management components there might
be. At the moment the only management component is a proxy to the remote
service registry but I left this management domain in so that I didn't have
to hand craft service clients for management purposes.
You can get various things from the EmbeddedSCADoamin, for example, you see
the code getting a contribution service and adding a contribution to it.
ContributionService contributionService =
domain.getContributionService();
Contribution contribution = contributionService.contribute("
http://calculator",
contributionURL,
null, //resolver,
false);
Contributions are the collections of resources that describe your services,
e.g. .composite files, xsd files, wsdl files etc. The act of contributing
this information results in an in memory assembly model (see the assembly
module).
Composite composite = contribution.getDeployables().get(0);
The root of which is a composite which contains a hierarchy of components
that you want to run. Then various steps are taken to turn the logical
assembly model into runnable artifacts so that the components can be
started. The model composite gets added to a top level composite that the
local domain controls.
domain.getDomainComposite().getIncludes().add(composite);
Then there is a build stage where the parts of the logical model are linked
together, references to services etc.
domain.getCompositeBuilder().build(composite);
Then there is a step where information is provided to the runtime so that
remote services can be resolved automatically across the network. I.e. we
link to guts of the assembly model into the notion of a distributed domain.
distributedDomain.addDistributedDomainToBindings(composite);
Then finally the runtime artifacts are created based on the logical model,
these include the service endpoints and clients.
domain.getCompositeActivator().activate(composite);
Once all this is done, each component in the domain can be started
independently
for (Composite composite :
domain.getDomainComposite().getIncludes()
){
domain.getCompositeActivator().start(composite);
}
We need to look at these various domain interfaces and decide if we need
them all. An outstanding todo!
Can
> I at runtime, disactivate a component in order to distribute in an other
> host?
Haven't got to this kind of dynamic activation/reactivation scenario yet. No
one has asked for it:-). but in theory you should be able to stop a
component in one domain implementation and start it in another (assuming
that it has been contributed there as well of course) and the newly started
component will update the registry with its new details. Would need to
ensure that the old details are removed from the registry when the component
stops which doesn't happen at the moment.
Can I have a multithreaded component (or how can simulate it)?
Yes, tuscany components are multithreaded.
Now I'm developing now a testing component: A distributed workpool
> service. This is my initial step and I'd finish for next Monday.
>
> With the following interfaces:
>
> public interface WorkerService {
> void submit(Job j);
> }
>
> Where a Job is something that you can compute:
>
> public interface Job<T> {
> void set(T k);
> void compute();
> T get();
> }
>
> So if now with your changes, I can compute Jobs in parallel in my LAN:
> placing nodeA,nodeB in a host and the others in my other host.
> When I have something working I'll providing you a patch.
Sounds cool. Be interested to understand a little bit more about what
constitutes a job and how it is moved about physically so I look forward to
seeing where you get to.
Cheers,
> Jo.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Regards
Simon
Re: Distributed Runtime and Distributed Calculator
Posted by Giorgio Zoppi <gi...@gmail.com>.
> Hi Jo, I've just checked in the fixes and re-enbabled:
>
> binding-sca-axis2 module which provides a remote version of the default
> binding between SCA components
> distributed-impl module which provides some abstractions of distributed
> domains and nodes and some interfaces for service registration and location
> calculator-distributed which, provides a simple sample of tuscany running
> distributed
>
> I get a clean build on windows so give it a try and let me know how you get
> on.
Ok. I update
> The tests that run during the mvn build use an in memory registry so all the
> nodes run in one VM. This in memory version is replaced in the calculator
> distributed sample with a network version. You can make the sample go by
> starting four separate VMs using the ant build file provided:
I've seen that.
> Run up the node that provides the registry
> ant runDomainNode
>
> Run up the node that runs the add service
> ant runNodeB
>
> Run up the node that runs the subtract service
> ant runNodeC
>
> Run up the node that runs the Calculator services and drives calls to the
> various methods
> ant runNodeA
Ok. Let's go. I've seen part of your code, and I'll debug it tomorrow. I
need to understand the Tuscany core: Where a component is activated? Can
I at runtime, disactivate a component in order to distribute in an other
host? Can I have a multithreaded component (or how can simulate it)?
Now I'm developing now a testing component: A distributed workpool
service. This is my initial step and I'd finish for next Monday.
With the following interfaces:
public interface WorkerService {
void submit(Job j);
}
Where a Job is something that you can compute:
public interface Job<T> {
void set(T k);
void compute();
T get();
}
So if now with your changes, I can compute Jobs in parallel in my LAN: placing nodeA,nodeB in a host and the others in my other host.
When I have something working I'll providing you a patch.
Cheers,
Jo.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distributed Runtime and Distributed Calculator
Posted by Simon Laws <si...@googlemail.com>.
On 8/16/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 8/16/07, Giorgio Zoppi <gi...@gmail.com> wrote:
> >
> > Hi,
> > i'm highly interested in contributing to the distributed runtime.
> > Actually I'm trying to understand if this component model could be the
> > building block for creating autonomic components. An autonomic
> > component can consist of one or more managed components coupled with a
> > single manager that controls them. To pursue its goal, the manager may
> > trigger an adaptation of the managed components to react to a run-time
> > change (i.e. fault, load balancing, etc).
> > Some questions..i've updated the svn and it builds but not the
> > distributed-calculator.
> > Why? (It could be for me a starting point).
> > Cheers,
> > Jo.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> Hi Jo and welcome to Tuscany
>
> I'm just making some changes to the calculator sample to fix it up so it
> will work again. What we have is a a simple scenario where you start 3 nodes
> that run SCA components for different parts of the calculator application
> and the nodes talk to a registry to find out what components are on which
> node. Very simple at the moment but the framework is in place to add all
> sorts of interesting component management options. Sounds like you have some
> good ideas. Let me get the sample fixed up and I'll post back here. You can
> then look at something that runs.
>
> Regards
>
> Simon
>
Hi Jo, I've just checked in the fixes and re-enbabled:
binding-sca-axis2 module which provides a remote version of the default
binding between SCA components
distributed-impl module which provides some abstractions of distributed
domains and nodes and some interfaces for service registration and location
calculator-distributed which, provides a simple sample of tuscany running
distributed
I get a clean build on windows so give it a try and let me know how you get
on.
The tests that run during the mvn build use an in memory registry so all the
nodes run in one VM. This in memory version is replaced in the calculator
distributed sample with a network version. You can make the sample go by
starting four separate VMs using the ant build file provided:
Run up the node that provides the registry
ant runDomainNode
Run up the node that runs the add service
ant runNodeB
Run up the node that runs the subtract service
ant runNodeC
Run up the node that runs the Calculator services and drives calls to the
various methods
ant runNodeA
Regards
Simon
Re: Distributed Runtime and Distributed Calculator
Posted by Simon Laws <si...@googlemail.com>.
On 8/16/07, Giorgio Zoppi <gi...@gmail.com> wrote:
>
> Hi,
> i'm highly interested in contributing to the distributed runtime.
> Actually I'm trying to understand if this component model could be the
> building block for creating autonomic components. An autonomic
> component can consist of one or more managed components coupled with a
> single manager that controls them. To pursue its goal, the manager may
> trigger an adaptation of the managed components to react to a run-time
> change (i.e. fault, load balancing, etc).
> Some questions..i've updated the svn and it builds but not the
> distributed-calculator.
> Why? (It could be for me a starting point).
> Cheers,
> Jo.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Hi Jo and welcome to Tuscany
I'm just making some changes to the calculator sample to fix it up so it
will work again. What we have is a a simple scenario where you start 3 nodes
that run SCA components for different parts of the calculator application
and the nodes talk to a registry to find out what components are on which
node. Very simple at the moment but the framework is in place to add all
sorts of interesting component management options. Sounds like you have some
good ideas. Let me get the sample fixed up and I'll post back here. You can
then look at something that runs.
Regards
Simon