+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