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 it’s 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 “success”
element 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.
>