[ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work

[Dave Berry]

Hi Marvin,
 
It seems strange to me to limit yourself to a list of identifiers as a
means of interacting with large numbers of jobs.  Wouldn't it be more
flexible to allow more complex expressions, such as "all jobs submitted
by Marvin that use more than 4 processors and are currently running" (or
whatever).  You could build an appropriate information model, map it to
a data model and provide a corresponding query language that clients
could use to request the information they need.

I agree that this is a service-oriented approach rather than a
resource-oriented approach.  However, having set up a particular query,
you might want to repeatedly interact with the current state of that
query.  So it might make sense to register the query with the service
and return an EPR that can be used to get the current set of results.
 
I don't see much point in passing back an abstract name (e.g. a UUID) on
its own.  Without a reference to a resolution mechanism, clients won't
be able to make much use of it.  This is why URL's and URI's have been
so successful; they include enough information for any client to know
which mechanism to use to resolve them.  This seems to be one advantage
of the WS-Name proposal; it includes an abstract name with a reference
to a resolution mechanism. 
 
Is it still the case that BES containers are allowed (or even
encouraged) to return WS-Names?
 
Would it be useful to have a means for composing WS-Name EPRs that use
the same resolution mechanism in order to make a single WS-Name that can
be used to query all of them?
 
Dave.
 
 
 
 
-----Original Message-----
From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On Behalf Of
Marvin Theimer
Sent: 29 April 2006 03:06
To: ogsa-wg at ggf.org
Subject: [ogsa-wg] Thoughts on extensions mechanisms for the HPC profile
work



	*        Support for array operations and other forms of
batching.

	*        When 1000's of jobs are involved the efficiency gains
of employing array operations for things like queries or abort requests
are too significant to ignore.  Hence a model in which every job must be
interacted with on a strictly individual basis via an EPR is arguably
unacceptable.

	*        One approach would be to simply add array operations
alongside the corresponding individual operations, so that one can
selectively interact with jobs (as well as things like data files) in
either an "object-oriented" fashion or in "bulk-array" fashion.

	One could observe that the array operations enable the
corresponding individual operations as a trivial special case, but this
would arguably violate the principle of defining a minimalist base case
and then employing only extensions (rather than replacements).

	*        Array operations are an example or a service-oriented
rather than a resource-oriented form of interaction: clients send a
single request to a job scheduler (service) that refers to an array of
many resources, such as jobs.  This raises the question of whether
things like jobs should be referred to via EPRs or via unique "abstract"
names that are independent of any given service's contact address.  At a
high level, the choice is unimportant since the client submitting an
array operation request is simply using either one as a unique (and
opaque) identifier for the relevant resource.  On a pragmatic level one
might argue that abstract names are easier and more efficient to deal
with than EPRs since the receiving scheduler will need to parse EPRs to
extract what is essentially the abstract name for each resource.  (Using
arrays of abstract names rather than arrays of EPRs is also more
efficient from a size point-of-view.)

	*        If abstract names are used in array operations then it
will necessary that individual operations return the abstract name and
not just an EPR for a given resource, such as a job.  If this approach
is chosen then this implies that the base case design and implementation
must return abstract names and not just EPRs for things like jobs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20060429/8f9b5cbb/attachment.htm