[ogsa-bes-wg] Re: [ogsa-hpcp-wg] Minor BES issue
Ian Foster
foster at mcs.anl.gov
Wed Aug 30 21:02:41 CDT 2006
+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 at ggf.org [mailto:owner-ogsa-bes-wg at ggf.org] On
>Behalf Of Peter G. Lane
>Sent: Wednesday, August 30, 2006 8:27 AM
>To: Donal K. Fellows
>Cc: ogsa-bes-wg at ggf.org; ogsa-hpcp-wg at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-hpcp-wg/attachments/20060830/d40c0f5d/attachment.htm
More information about the ogsa-hpcp-wg
mailing list