But this is a completely different problem from the one you originally
described, where the worker could ask for classes it needed but didn't have.
The new version, fire-and-forget, is perfectly reasonable, but requires a
different architecture.

For a start, the job fired off to the worker must have /all/ the necessary
information for computation to complete (configuration, input data, classfiles,
...).  One natural medium for delivery of all that data would be a JAR file
containing all the needed.   Note that in a fire-and-forget environment it is
better to be pessimistic about providing data, in particular the effort of
identifying a truly minimal set of required classes would be a waste of time.

So I would just fire off a JAR file containing all the calculation classes with
every request.  There would be a lot of duplication, but so what ?  It would
make your life much easier.

If you do want to try to cut down the number of classes sent, then you'll have
to do it on the master machine, or in advance (perhaps by hand).  If you want
to generate such a list automatically (and I repeat that I don't think it would
be worthwhile), then a good way to do it would be to scan the bytecodes of the
relevant classes, forming a transitive closure of the class references starting
at the "entry-point".  The easy, but coarse, way to track inter-class
references is to look at each classfile's constant pool for references to other
classes.  If you are up for a bit of extra effort you could do the same kind of
thing, but at method granularity.  In either case, a classfile library like ASM
or BCEL would do the bulk of the work for you.   Note that you would have to
find some way of handling reflective references to class (Class.forName()) --
the simplest way of doing that would be to forbid them.  Alternatively look for
literal strings which are valid class names (in JNI syntax).

There are tools available which will do this kind of analysis in order to
reduce the size of JAR files.  You might be able to apply such a tool directly,
or "borrow" some of its code.

   -- chris

    A Jini-based compute server can accomplish this easily.  Consider
a Task class that exposes an execute() method.  The Master configures
Task instances and writes them into a JavaSpace.  Worker processes
take Tasks from the space.  If the Worker has the classes required by
the Task in its classpath, it simply calls execute().  If the Worker
does not know about the necessary classes, they are automatically
downloaded from the class server.

    Naturally, the use of a class server is more flexible because the
Workers don't need to be redeployed when the Task implementation
changes.

    The class server doesn't need to run on the same machine as the
Master process.  Unless performance requirements indicate otherwise,
the logical place to run it is the same machine running the JavaSpace.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | The experts in large scale distributed OO
                      | systems design and implementation.
         pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)