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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > Date: Aug 17, 2007 6:38 PM > Subject: Re: Distributed Runtime and Distributed Calculator > To: [email protected] > Cc: [EMAIL PROTECTED] > > 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 > > >
