[Oslc-Automation] recovery/error handling

[John Arwe]

>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120517/2d227317/attachment-0003.html>