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
