+1
At 06:59 PM 8/30/2006 -0700, Marvin Theimer wrote:
Hi;
A question to address is what the
interpretation is of having an operation request receive only a subset of
response elements in its reply. Consider TerminateActivities: what
are the failure semantics of having it succeed (i.e. be successfully
applied) to only a subset of activities? Presumably the client
wants back a vector of return information that describes exactly what
happened to each activity; i.e. they will want a vector that contains
either a success or a fault element for each activity that was listed in
the input vector rather than a vector containing just the success
elements or just the failure elements. For GetActivityStatus and
GetJSDLDocuments one might argue that its OK to get back information
about a subset of requested activities. But I would expect that
clients would still want to receive a failure element back explaining
what happened for each activity for which information could not be
returned.
Thus, it seems to me that in all
cases clients will want to receive back a vector response of the same
length as the input vector. In particular, I would advocate that
they should expect one of the following responses back:
·
A fault response if the operation as a whole could not be
handled e.g. if the client is not authorized to make the
request.
·
A response that consists of an info-set that contains a vector of
elements, where the number of elements equals the number of activities
specified in the input vector argument to the operation request.
Each element of the vector should be either a successelement or a fault
response element. Which input vector element the response element
refers to is unambiguously determined by the EPR returned in the response
element (as pointed out by Peter). An interesting question is
whether the EPR field is really needed since vector input arguments are
only available for operations on existing activities and one could
request that the vector order of the response message correspond to the
vector order of the request message. If we were to go down this
path then we could simplify the schema of the response
messages.
If BES were to take the approach
outlined above then the HPC Profile specification would contain a
restriction that simply says that HPC Profile-compliant services MUST
support input vectors of length 1 and MAY support vector lengths greater
than 1 or MAY return an overall fault response of not-implemented for
vector lengths greater than 1.
Thoughts?
Marvin.
-----Original Message-----
From: owner-ogsa-bes-wg@ggf.org
[mailto:owner-ogsa-bes-wg@ggf.org]
On Behalf Of Peter G. Lane
Sent: Wednesday, August 30, 2006 8:27 AM
To: Donal K. Fellows
Cc: ogsa-bes-wg@ggf.org; ogsa-hpcp-wg@ggf.org
Subject: [ogsa-bes-wg] Re: [ogsa-hpcp-wg] Minor BES issue
Donal K. Fellows wrote:
> An issue came up recently
during discussions in the HPC Profile WG, and
> that was that the BES spec
should require that the lengths of the input
> vectors and output vectors
in the operations GetActivitiesStatus,
> TerminateActivities and
GetJSDLDocuments should/must be the same length
> (assuming no faults,
naturally). Otherwise the responses might be a
> subset of the expected
ones. Maybe there are some other restrictions
> that ought to be imposed
(same order, referring to the same things thatt
> the input referred to,
etc.) but it was the length issue that came up
> (since that's the aspect
that's going to be profiled). We agreed that
> this sort of restriction
belongs in the base BES spec though; it's too
> fundamental to belong in
the Profile.
The schema types for the output
vector elements have EPR fields that associate each element with an
input vector element. So it
doesn't really matter if the response is a subset of the expected set or
is out of order. I'm assuming
that this is the point of including the EPR fields. Is there a more
fundamental reason for pushing
for such a restriction? I don't have a strong opinion either way. I'm
just curious about how this is
interpreted as "bad".
Peter
>
> Donal.
>
_______________________________________________________________
Ian Foster -- Weblog:
http://ianfoster.typepad.com
Computation Institute:
www.ci.uchicago.edu
& www.ci.anl.gov
Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org