[ogsa-hpcp-wg] [OGSA-BES-WG] error responses from BES

[Vesselin Novov]

Hi all,

Could I add one more question:
As the StagingSchedule element, defined in the DataStaging extension 
draft, is only relevant
to files being staged-in - shouldn't this element be added as a 
subelement of the JSDL's <Source> as opposed the the JSDL's <DataStaging>.
If it stays as it is now, then, any code processing <DataStaging> 
elements would have to check
if there is a <Source> or <Target> present just so it would ignore the 
<StagingSchedule> if <Target> is found.
This unnecessary processing would be avoided if the <StagingSchedule> is 
a subelement of <Source> only.

--Vesso

Glenn Wasson wrote:

>Hey all,
>
>	I'm trying to interpret the BES document's text on throwing errors
>in cases where the input vector is of length 1 (all that is required by
>HPCBP). Section 6.2 of the BES v1.0 spec says:
>
>The GetActivityStatuses, TerminateActivities, and GetActivityDocuments
>operations take a vector
>of activity EPRs as input and operate on all the referenced activities.
>Since an input vector may
>contain EPRs that are either unknown to a BES or for which the BES cannot
>execute the
>requested operation, the following failure semantics MUST be provided by a
>compliant BES:
>. If a request fails for some reason that applies to all the specified
>activities-e.g., due to
>  an authorization fault-then the BES MUST respond with an appropriate fault
>response
>  message.
>. If a request can succeed for one or more of the specified activities then
>the BES MUST
>  respond with a vector of response elements, where each element corresponds
>to the
>  equivalent activity designated in the input EPR vector. Each response
>element MUST be
>  either an element describing the results of the request, as applied to the
>designated
>  activity, or a SOAP-1.1 fault element describing why the request could not
>be applied to
>  the designated activity (e.g., because the EPR could not be resolved to
>any known
>  activity within the BES).
>
>
>My interpretation of this is that if one of these operations takes a vector
>of length 1, the first bullet says that a failure (which by definition
>applies to all specified activities) allows me to simply return a soap
>fault. However, reading the text of the actual sections for those methods
>(6.2.2, 6.2.3, 6.2.4) it seems that even for vectors of length 1, I should
>return any fault information inside a, for example,
>GetActivityStatusesResponse message. 
>
>Further, the WSDL shown in the BES spec for (we'll again use this as an
>example) GetActivityStatuses is:
>
><wsdl:operation name="GetActivityStatuses">
>  <soap:operation
>soapAction="http://schemas.ggf.org/bes/2006/08/besfactory/BESFactoryPortType
>/GetActivityStatuses" />
>  <wsdl:input name="GetActivityStatuses">
>    <soap:body use="literal" />
>  </wsdl:input>
>  <wsdl:output name="GetActivityStatusesResponse">
>    <soap:body use="literal" />
>  </wsdl:output>
>  <wsdl:fault name="UnknownActivityIdentifierFault">
>    <soap:fault name="UnknownActivityIdentifierFault" use="literal" />
>  </wsdl:fault>
></wsdl:operation>
>
>To me, the <wsdl:fault> element indicates that it is legitimate to throw an
>UnknownActivityIdentifierFault "directly", i.e. not inside the Fault element
>of a GetActivityStatusesResponse message.
>
>
>So, my questions are:
>1. should it be the case that the only permissible response from a BES for
>the GetActivityStatuses (or similar) method is a GetActivityStatusesResponse
>message (which would then contain appropriate faults)?
>	- in this case, it seems that the WSDL should be changed and the
>text in 6.2 clarified
>2. or should we allow cases where faults can be returned directly?
>	- in which case the text of 6.2.2 (and 6.2.3 and 6.2.4) should be
>clarified
>3. or is the UnknownActivityIdentifierFault special and so that one can be
>thrown directly, while faults of other types need to be inside a
>GetActivityStatusResponse message?
>	- this seems like a strange option to me.
>
>Not sure what our ability is to change the BES text based on its point in
>the OGF document pipeline, but at this point I'm trying to figure out what
>to do for interop.
>
>Glenn
>
>--
>  ogsa-bes-wg mailing list
>  ogsa-bes-wg at ogf.org
>  http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
>  
>