All,
I think we are nearly there... below is a link to a change tracked version of GFD 108 that addresses (I hope) all of the issues that have come up during our recent implementation experiences. The WSDL and schemas have been updated and clarifications and corrections made to the text.
*** Please review and make comments by the Friday 21st March 2008 ***
https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-bes…
Thanks,
Steven
There are some issues arising from recent implementation experiences that need some discussion...
* Handling SOAP Faults
Many BES operations take in a vector of activities and return a vectorised response based on these activities. How should faults be handled? The current document is ambiguous. Should:
1. Any fault generated by one of the activities in the vector can only be returned as part of the response vector from the operation. The WSDL is then incorrect as currently only a single specified fault can currently be generated from the operations.
2. Faults can be returned directly. Say if the vector length is 1. In which case text in 6.2.2, 6.2.3 & 6.2.4 needs to be clarified and the WSDL changed to allow faults of other types to be returned.
See Glenn's original tracker for more details - https://forge.gridforum.org/sf/go/artf6066?nav=1
* Handling Authorization for the BES Port types
The BESFactory port type contains operations that are to be applied to a vector of activities. An authenticated client may be authorized to access the operation - but may not be allowed to access one (or more) of the specified activities, for instance if the activity is owned by a different user. I've added NotAuthorizedFaults to the GetActivityStatuses, TerminateActivities & GetActivityDocument operations.
The BESManagement port type does not throw any (authorization) faults. Authentication and authorization is provided by the container. A deployment therefore specifies who has access to the operations within BESManagement and any client that enters the operation is already authorized to start/stop the container from accepting activities and no fault is needed.
Are these changes sufficient?
