Subject: C432 JGSI Review
Resent-Date: Mon, 11 Oct 1999 08:24:10 -0400
Resent-From: Geoffrey Fox <gcf@npac.syr.edu>
Resent-To: p_gcf@npac.syr.edu
Date: Sun, 10 Oct 1999 14:12:26 -0400
From: Tomasz Haupt <haupt@npac.syr.edu>
To: Geoffrey Fox <gcf@npac.syr.edu>

a) publish
b) This is a nicley written paper, with a rich bibliography setting the
paper well in
the context of related research. The general idea of agent based
computations,
although not entirely new, and thanks to Java more feasible than ever, is
very
interesting and worth pursuing. The authors describe a pilot implementation
of such a
system, and present some benchmark results based on two simple applications.
The
results are very encouraging.

I have two general comments on the paper (which does not affect the high
quality of
the paper).

1. We need a better understanding of what does "global computing" actually
mean. We do
not want to make a false promise of free CPU form the Internet. What is the
mechanism
to participate in the computation, for example, providing resources? I know,
the technology is (almost) there: SSL, Kerberos. Globus faces the same
problem.
Potential users (site administrators) ask the question: "how I will be
credited for
CPU I provide (while making resouces available to the Grid)?". What are the
authenication/authorization policies? How to protect the CPU provider
against an
abuse? The technology is there, but what is the model of use? I realize that
the
authors concentrated on providing a proof of concept implementation. That's
fine. But
in the feature, these question will have to be answered. Note, that the pull
model is
much easier to understand (as far as security is
concerned). Also, the agent based computation may become very useful for
"private"
clusters or "intranets", where the security is not an issue. So I would tend
to see
"global computing", for practical purposes, as intranet computing.

2. What is the cost of retargetting of a legacy application to the traveller
environment? It is my understanding that it requires to rewrite the codes.
And even
though the net number of new lines to be inserted is really small, it is a
major
effort to examine the algorithm of the application in hand to make it right.
I
believe, that this model is better suited for a course grain, task parallel
distrubuted computation that shares data only through input and output.

There is one misspelling (p.8, UnicastRemoeObject - should be
UnicastRemoteObject, and
a minor flaw in fig 4 (msec).
Fig 2 and 3, I guess originally in color, can be slightly improved: the blob
representing the client is so dark, that it is virtually impossible to read
the label
of it.

c) none