[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

process view in our 1st deliverable




This is a comment to the draft charter.

What is the template into which we pack our results after surveying the
as-is family of Grid Computing Environments?

What I want to introduce here is the idea that we should present what we
have learned from at least two views.

** One possible pair of views:

* Product view:
 - What components does the user perceive in their Grid Environment?  
  Details
  + as essential?
  + as value-added?
 - Are there any dependencies exposed?  These are services that have to be
there deeper in the Grid so the user's complement of services will work?

* Process view:
 - The life cycle of a Grid Computation.

** notes:

One example of what I mean by "what are the components as the user views
them?" has to do with the discussions to date of a "super-scheduler."  This
may turn out not to be a functional unit in the user's view.  Scheduling is
a separate function on the server side, but not a separate function on the
user side.  What the user wants is a _job-builder_, with some decision
support built in.  Schedule information is but one of the variables that
the user and the user's support tools are manipulating in the job-building
activity.  

The user, if they have computations that are hard to find competent
resources for, will be interactively trading off the technical definition
of the computation to be performed vs. when, where, and how cheaply it can
run.  The job definition is not frozen at the point where the user is
dickering with the schedulers at different resource organizations as to
price and availability of service.

This is discussed in a section of the whitepaper I prepared.  When we get
it up on the web, please refer to ...UD4Grid.htm#_Toc495220392 for this
discussion.  A key point there is that what the user can tell us about the
compute resources they need is the kind of job that the resources have to
be able to run.  The user doesn't want to volunteer where these resources
are, or know where to find them in a hierarchical namespace.  The user
wants to have a range of choice and then select the best deal they can get,
including adjusting the particulars of the job to be run.  The process
model should separate discovery of relevant resources from definitization
of the computational plan.

Al