[Oslc-Automation] recovery/error handling

[Michael F Fiedler]

The discussion in the meeting today was along similar lines.   A
recommendation was made to write up some guidance for synchronous
implementations, but not to make this a MUST requirement.  The workgroup
would like any feedback we can get from actual implementations or prototype
work.

Regards,
Mike

Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170

oslc-automation-bounces at open-services.net wrote on 05/17/2012 12:49:57 PM:

> John Arwe/Poughkeepsie/IBM at IBMUS
> Sent by: oslc-automation-bounces at open-services.net
>
> 05/17/2012 12:49 PM
>
> To
>
> oslc-automation at open-services.net,
>
> cc
>
> Subject
>
> [Oslc-Automation] recovery/error handling
>
> From today's draft agenda:
> Need to consider recovery/error handling. If bad things happen when
> creating requests, how does client know if the execution actually
occurred
> Suggestion: Service providers can only offer synchronous style for
> plans where multiple identical requests can be created and return
> the same results - idempotent.
>
> I don't know that the asynch style is any better in this regard.
> The Core discussion point was bad things like lost requests, lost
> responses, HTTP timeouts.
> With both synch and asynch, the only way to find the result is using
> information in the POST-Create for the Request.  If anything in that
> round-trip fails, like the cases above, the semantic result is
> identical: the client cannot know if the request was actually
> initiated or not.  If the Plan is idempotent then that is useful,
> insofar as the client can respond by simply repeating the request.
> If the Plan is not idempotent, the client cannot reliably tell how
> to respond, regardless of the interaction style in play.  (Remember
> that in the asynch case, the only "handle" the client has to search
> for its Result(s) is the Request URL - if the create-request round
> trip fails, it does not receive that URL so it has no input for the
> query over the Results set).
> For the particular implementations we have in mind, the requests are
> idempotent, so adding "requested Plan MUST be idempotent" would not
> pose a problem for them.  It seems awkward to impose that
> requirement for synch only however if the same logic applies to
> synch cases, absent some new information.
> Best Regards, John
>
> Voice US 845-435-9470  BluePages
> Tivoli OSLC Lead - Show me the Scenario
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120517/e8bc6ed9/attachment-0003.html>