Async execution (was "Re: [provision] Asynchronous requests").

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Having heard no objection, I assume that everyone accepts the following 
positions:
1. ANY operation may be requested as asynchronous.
2. ANY operation may be converted to asynchronous execution at the 
provider's initiative.
3. If a requestor explicitly specifies synchronous execution,
    the provider must execute the operation synchronously (or must fail 
the operation).
4. If a requestor explicitly specifies asynchronous execution,
    the provider must execute the operation asynchronously (or must fail 
the operation).
5. If a provider executes an operation asynchronously
    (whether at the requestor's or the provider's initiative),
    - the provider's response must indicate that the operation is 
pending and
    - the provider's response must return a requestID
       that the requestor may use to follow up.
6. Unless a requestor explicitly specifies synchronous execution,
     the requestor must be prepared to accept a response from the provider
     that indicates the operation was converted to asynchronous execution.

gpc

Gary P Cole wrote:

> 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.
>
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php. 
>
>