[ogsa-bes-wg] Re: [ogsa-hpcp-wg] Minor BES issue

[Ian Foster]

+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-bes-wg/attachments/20060830/d40c0f5d/attachment.html