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
