Unresolved issues in BES from implementation experiences
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?
On Sun, Feb 24, 2008 at 12:28 AM, Steven Newhouse <Steven.Newhouse@microsoft.com> wrote:
* Handling SOAP Faults
Currently, SOAP faults can be used in response vectors but the specification can be interpreted in the way that in some cases the faults could be returned directly (without the message body). I think it would be easier for the developer (of a client, for example) to have only one kind of faults. So I'd vote for having the faults returned only in the response element, even if the request concerned only one activity or the fault concerns all of the activities given in the vector (these are the cases I think the fault could be returned directly, according to the current spec). -- Piotr Domagalski
On Sun, Feb 24, 2008 at 11:19 PM, Piotr Domagalski <piotr.domagalski@fedstage.com> wrote:
Currently, SOAP faults can be used in response vectors but the specification can be interpreted in the way that in some cases the faults could be returned directly (without the message body).
I think it would be easier for the developer (of a client, for example) to have only one kind of faults. So I'd vote for having the faults returned only in the response element, even if the request concerned only one activity or the fault concerns all of the activities given in the vector (these are the cases I think the fault could be returned directly, according to the current spec).
Sorry, it just got to me that this is not optimal at all - for example having to return the same 1000 faults in the response element... It is a bit cumbersome for the developer but it is better to return the direct SOAP fault in case there's an error concerning all of the activities (including the case of 1 activity) in the vector. So I think the WSDL needs to be corrected so to add some faults (i.e. NotAuthorizedFaults) to some operations (i.e. TerminateActivities, GetActivityDocuments) as it lacks some of them currently. -- Piotr Domagalski
On 23/2/08 15:28, "Steven Newhouse" <Steven.Newhouse@microsoft.com> wrote:
* Handling Authorization for the BES Port types
...
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.
I'm not sure that I agree with this approach. Depending on the back end that you are dealing with, the evaluation of who is authorized might not happen until the back end is contacted (i.e. after the operation invocation itself has been authenticated and authorized). It would also be useful to be able to indicate to the caller that the back end is not authorizing the access by using a NotAuthorizedFault. -- Chris
On Sun, Feb 24, 2008 at 12:28 AM, Steven Newhouse <Steven.Newhouse@microsoft.com> wrote:
There are some issues arising from recent implementation experiences that need some discussion...
* Handling SOAP Faults
As I've seen no response, I'll try my best to to sum up the things that I consider unresolved: 1. I assume that faults can be thrown both directly (when the requests concerns a vector of 1 elements or the fault concerns all the elements in the vector) and indirectly (in the response body). 2. Therefore, I think that WSDL is lacking the following (direct) faults: NotAuthorizedFault for operation GetActivityStatuses NotAuthorizedFault for operation TerminateActivities NotAuthorizedFault for operation GetActivityDocuments 3. Are the faults CantApplyOperationToCurrentStateFault, OperationWillBeAppliedEventuallyFault meant to be used for any of the specified calls or are they supposed to be used with BES-Activity? -- Piotr Domagalski
Hi Piotr,
As I've seen no response, I'll try my best to to sum up the things that I consider unresolved:
Thank you again for your comments... most of us were occupied at OGF and the post-meeting catch up.
1. I assume that faults can be thrown both directly (when the requests concerns a vector of 1 elements or the fault concerns all the elements in the vector) and indirectly (in the response body).
That does not seem unreasonable... Any concerns from the XML/WSDL experts? Are there any interoperability issues between SOAP 1.1 and 1.2 - another concern Piotr raised.
2. Therefore, I think that WSDL is lacking the following (direct) faults:
NotAuthorizedFault for operation GetActivityStatuses NotAuthorizedFault for operation TerminateActivities NotAuthorizedFault for operation GetActivityDocuments
The updated BES draft on GridForge has these added in. Adding the NotAuthorizedFault into the BES-Management operations also seems to make sense.
3. Are the faults CantApplyOperationToCurrentStateFault, OperationWillBeAppliedEventuallyFault meant to be used for any of the specified calls or are they supposed to be used with BES-Activity?
These are defined on Page 34 of the specification but are not used in any of the operations, but are mentioned in section 4.3 on 'Specialization Fault Response'. At certain times in the spec there was an operation that could attempt to move an activity from one state to another. Hence these faults. That operation has gone and the state changes are driven by the internal activity of the BES and exposed through the state model - and any extensions to it. I don't believe these faults make sense any more... Comments from anyone? Steven
participants (3)
-
Christopher Smith -
Piotr Domagalski -
Steven Newhouse