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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> Regards
>
> Simon
>
