[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Asynchronous requests.
I don't really like a value of "either" value for ExecutionType. I was trying only to elucidate Doron's point in order to draw out his opinions (and those of others) without putting forth my own. At least not yet. :-) Having said that, however, my analysis and opinions follow. I apologize in advance for the length of this note. 1) The following set illustrates choices (for asynchronous execution at requestor initiative). A requestor may request async execution for: A) NONE: for no operation. B) BATCH: only for the 'batch' operation. C) BATCHABLE: for any 'add', 'modify', 'delete' and 'batch' operation. D) ANY operation at all. E) Any operation EXCEPT 'cancel' or 'status'. I think (A) is probably unreasonable, since it would be nice to execute 'batch' operations asynchronously. Of course, this might make more sense if 'batch' operations always execute asynchronously or if 'batch' operations can be converted to asynchronous execution at the provider's initiative. For the purposes of this particular discussion, however, I'd call that (B). I think (B) is a good choice. The batch operation is the operation for which asynchronous execution is most clearly desirable (and perhaps even necessary). I think (C) is okay, but I would argue that this is easy enough to achieve with (B) since a requestor can put any batchable request into a 'batch' request. I think (D) is a good choice. This approach is very general, and we can make it clean and consistent. If every response is synchronous and if every response indicates whether the operation is pending or succeeded or failed (and, if pending, contains a requestId), then a client simply must be prepared to deal with this. I think (E) is okay, but I would argue that (D) would be better. If we cannot enumerate the set of operations for which someone would want asynchronous execution, then we should leave it up to the requestor. If this question were completely independent of the question of asynchronous *conversion* (at the provider's initiative), I would choose either B or D. Next, let's summarize the options with respect to asynchronous *conversion*. 2) A provider may convert to asynchronous execution: A) NONE: no operation at all. B) BATCH: only the 'batch' operation. C) BATCHABLE: the 'batch' operation plus 'add', 'modify' and 'delete'. D) ANY: any operation, regardless of what execution type was requested E) EXCEPT: any operation that is not explicitly requested as synchronous I think (A) is probably unreasonable. Jeff has explained that workflow can produce arbitrary delays. I think (B) is nice but may be unrealistic. Since workflow can produce arbitrary delays, this could affect any singleton 'add', 'modify' or 'delete'. If the 'batch' operation is the only operation that a provider can convert to asynchronous execution, then this means that (in a workflow scenario) any 'add', 'modify' or 'delete' operation would fail as a singleton but would succeed if it were part of a batch. This seems unfriendly. Therefore I think (B) pushes toward (C). I think (C) is a good choice. I haven't heard that any other operation (such as 'listTargets', 'lookup', 'cancel', 'status' or 'search') needs to be asynchronous. gpc I think (D) is a good choice. I don't know why 'listTargets', 'lookup', 'cancel', 'status' or 'search' needs to become asynchronous at provider's initiative, but perhaps I lack imagination. This has at least the advantages of generality and consistency. I think (E) is a lot like (D). To me, this simply means that the provider must fail the request if the requestor specifies synchronous execution and the provider cannot execute the operation synchronously. So, after looking at the interaction between questions (1) and (2), I think only a couple of approaches seem viable: C) BATCHABLE. Only specific operations (e.g., 'add', 'modify', 'delete' and 'batch') may be requested as asynchronous and only those same operations may be converted to asynchronous execution at a provider's initiative. An AsyncableRequestType will be available to custom requests as well. D) ANY operation may be requested as asynchronous and ANY operation may be converted to asynchronous execution at the provider's initiative. With either approach, if an operation is converted, the provider's response must indicate that the operation is pending and must return a requestID that the requestor may use to follow up. I lean toward (D), since it is the most general and is the easiest to explain. It does impose on any client the burden of following up on asynchronous operations. However, a client that cannot follow up on asynchronous operations can explicitly specify synchronous execution. This will force the provider to fail any operation that must convert to asynchronous execution. Approach (C) could work, but it's harder to explain and doesn't buy us much. A client still must be prepared to follow up on asynchronous operations converted at provider initiative (or must explicitly specify synchronous execution in order prevent conversion to asynchronous execution). Yes, this applies only to certain operations, but it applies to all the basic operations ('add', 'modify' and 'delete'). That's why I think it doesn't buy us much. What does everybody else think? gpc Jeff Larson wrote: > As far as the client being prepared to handle an async request, I > think this > will always be the case. The client has to have some awareness of > whether > the PSP does workflow or not, otherwise it isn't going to be able to > do anything > since the PSP will throw back errors on every sync request. > > But let me state again that I don't think workflow semantics should be > modeled using > ExecutionType. The spec would be more useful if it formally modeled > at least > a few of the basic workflow concepts. The sync mode then applies only > to the > message protocol, not the time at which provisioning eventually happens. > > In many cases (ours certainly) the client doesn't really care if the > request > is queued pending approval, they just want to make sure the process > is successfully started. In those cases, a synchronous request is > convenient > for the client. If we overload ExecutionType with workflow this > forces the > client to adopt an async-polling style of interface for EVERY request, > even the ones that might be able to run synchronously. The "either" > type addresses this, but it just feels strange to me.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]