[email protected] wrote on 06/30/2012 06:47:24 AM: > From: David N Brauneis/Raleigh/IBM@IBMUS > > Then you are making the assumption that the parameters passed on the > request are cloned into the result (I do not believe that semantic > is true for all automation providers).
The specification, as currently written states that the inputParameters to the Automation Request are cloned to the Automation Result. > From: Daniel Berg/Raleigh/IBM@IBMUS > > It is fine if the AutomationRequest has a relationship to the > AutomationResult versus the other way around if we want to avoid > dangling references. However, we need to have the request parameter > values captured and stored with the AutomationResult for audit purposes. I thought one of the reasons that we needed to have the reference the other way around (from Result to Request) was so that an async style request could do a query to determine which Automation Result was associated with the Automation Request it generated (in the case where Automation Requests have a shorter lifespan than Automation Results). If the link is from request to result there is a timing window where the consumer creates the request (but there is no associated result yet) and the request gets deleted. At that point, the consumer has no way to determine which result goes with their request. At least with the link going from result to request, even if the reference is dangling, the reference itself is still accurate, and allows the needed query. Charles Rankin
