Re: [provision] Asynchronous requests.

[Jeff Larson <Jeffrey.Larson@Sun.COM>]

Gary P Cole wrote:

>
> If we feel that it would be better for a client to communicate 
> *explicitly* which types of execution it can support, we might 
> consider 1) *requiring* the 'execution' attribute in a request, and 2) 
> adding a value of "either" to ExecutionType (in addition to its 
> current values of  "synchronous" and "asynchronous").

I'm ok with an "either" ExecutionType, which in practice would be the 
only value we would ever use.
Any request for synchronous execution would be an unconditional error 
because at the SPML
layer we simply can't predict what's going to happen in the workflow.  
Approvals are dependent
on arbitrarily complex logic which we won't know until we actually 
execute the workflow.


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.

Jeff