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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg