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 [email protected] 919-254-4170 [email protected] wrote on 05/17/2012 12:49:57 PM: > John Arwe/Poughkeepsie/IBM@IBMUS > Sent by: [email protected] > > 05/17/2012 12:49 PM > > To > > [email protected], > > 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 > [email protected] > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
