You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/08/17 19:46:05 UTC
Developer guide update was: Distributed Runtime and Distributed Calculator
Good idea - we could do with something like this to help newcomers get a
grip with what the various bits are. The developers guide is currently all
about the process of development and not specifics of the code, and it's
quite long already. I'm wondering if it would be better in the achitecture
guide (or as a subpage thereof)
Simon
---------- Forwarded message ----------
From: haleh mahbod <hm...@gmail.com>
Date: Aug 17, 2007 6:38 PM
Subject: Re: Distributed Runtime and Distributed Calculator
To: tuscany-dev@ws.apache.org
Cc: giorgio.zoppi@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: Developer guide update was: Distributed Runtime and Distributed Calculator
Posted by Simon Laws <si...@googlemail.com>.
On 8/17/07, haleh mahbod <hm...@gmail.com> wrote:
>
> A section in the developer guide (as a link to a page like "get started
> with
> coding")..
> Also link from architecture guide to it.
>
> I'll take what you have and create the link and the page if this is the
> right content to start with
>
> Haleh
>
> On 8/17/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > Good idea - we could do with something like this to help newcomers get
> a
> > grip with what the various bits are. The developers guide is currently
> all
> > about the process of development and not specifics of the code, and it's
> > quite long already. I'm wondering if it would be better in the
> achitecture
> > guide (or as a subpage thereof)
> >
> > Simon
> >
> > ---------- Forwarded message ----------
> > From: haleh mahbod <hm...@gmail.com>
> > Date: Aug 17, 2007 6:38 PM
> > Subject: Re: Distributed Runtime and Distributed Calculator
> > To: tuscany-dev@ws.apache.org
> > Cc: giorgio.zoppi@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
> > >
> >
>
well i think we should take some bits out in the first instance but go ahead
and copy the text and we can edit it down from there.
Simon
Re: Developer guide update was: Distributed Runtime and Distributed Calculator
Posted by haleh mahbod <hm...@gmail.com>.
A section in the developer guide (as a link to a page like "get started with
coding")..
Also link from architecture guide to it.
I'll take what you have and create the link and the page if this is the
right content to start with
Haleh
On 8/17/07, Simon Laws <si...@googlemail.com> wrote:
>
> Good idea - we could do with something like this to help newcomers get a
> grip with what the various bits are. The developers guide is currently all
> about the process of development and not specifics of the code, and it's
> quite long already. I'm wondering if it would be better in the achitecture
> guide (or as a subpage thereof)
>
> Simon
>
> ---------- Forwarded message ----------
> From: haleh mahbod <hm...@gmail.com>
> Date: Aug 17, 2007 6:38 PM
> Subject: Re: Distributed Runtime and Distributed Calculator
> To: tuscany-dev@ws.apache.org
> Cc: giorgio.zoppi@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
> >
>