Re: [provision] Asynchronous requests.

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

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.