Re: Entries, ServiceTemplates, and JavaSpaces

> > We wanted to have agents working jobs distributed from a master 
> > process after which they would be returned to the master. 
> Seemed like 
> > the usual use-case for JavaSpaces.
> >
> 
> Kind of except, obviously, you have this suitability thing going on.

True, that.

> Okay, so the question is, does the job processing take 
> sufficiently long that a remote call is not really the way to 
> go?  Or perhaps you want to do some kind of queue'ing or 
> maybe you want to simplify the logic/number of threads in the 
> master or something else????

Our work can take on the order of multiple minutes, maybe longer.
We're extending CruiseControl http://cruisecontrol.sf.net to do
distributed builds. Basically we're doing Ant, Maven, or NAnt-based
builds on distributed machines and organizing the results (and
triggering the builds) from a build master.
 
> Basically, we need to figure out if this is genuinely 
> something you need a JavaSpace for or whether a straight 
> remote call is good enough.

Currently we only have one type of work we're distributing--a
BuildRequestEntry is taken, worked, and replaced with a
BuildResultEntry. Down the line we'd rather have a more sophisticated
process that lets us expose any of the steps in our build procedure,
and not just the build request. That means we would have many
different kinds of agents looking for work suitable to them. We ended
up seeing it as a general work-flow problem that needs to expose its
units of work. We'd love to implement a basic, generic, work-flow
system on top of JavaSpaces.

> If a JavaSpace is needed for some reason, I'd be tempted to 
> do something like this (not completely thought through just 
> trying to put up a straw man to refine):
> 
> (1)     Have your agents advertise a proxy as usual with all the
Entry
> attributes.
> 
> (2)     Have a couple of methods on the proxy - one to return 
> a unique id
> for that agent and the other to return a reference to a JavaSpace.
> 
> (3)     Submit a job to the agent's preferred JavaSpace with 
> the appropriate
> unique id on it plus some kind of Job ID.
> 
> (4)     Agent, at startup, finds a JavaSpace (could be just a 
> random lookup
> or something more predictable/fixed), then register's it's proxy.
> 
> (5)     Master can wait on the JavaSpace with an appropriate 
> template (based
> on the Job ID from (3)) to catch the result.

Yeah, that's an interesting idea. I think for the moment we'll have
the agents read an Entry and check its applicability and then do a
take. More notifications will go out than are truly necessary, but I
think it's easier to implement. We'll keep the other idea in mind,
though.

> This would seem to fit the bill as you can still select an 
> appropriate agent and then dispatch a job to it but use a 
> JavaSpace to ease co-ordination woes.

Yup.

> As I say, I'd only do this were there a convincing case for 
> using a JavaSpace.

Feel free to weigh in. We recognize that our current implementation
isn't maximizing its use of JavaSpaces, but we see potential for
growth.
 
> So there you go, a starting point, time for some refinement.

Thanks again!

> Best,
> 
> Dan.

Jeff

| Jeff Ramsdale |
|   SolutionsIQ |
|  Bellevue, WA |
 

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html

JDC members can download the JavaSpaces(tm) Technology from:
http://developer.java.sun.com/developer/products/jini/