Async and workflow (was "Re: [provision] Batch Capability.")

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

1) From my reading of the SPML1.0 specification, asynchronous requests 
*are* just a client preference.  I suppose that I could have missed 
something, but I see no discussion of sync/async being determined by the 
server, nor any discussion to suggest that a client must be prepared to 
deal with an unexpected async requestID.  In fact, quite the opposite.  
The SPML 1.0 specification explicitly states that the *client* must 
generate a globally unique value and must specify it as the value of the 
"requestID" attribute in the SpmlRequest.

2) Like you, I dislike overloading the synchronicity of requests with 
workflow semantics.   If it's really true that a client must be prepared 
for a synchronous request to become asynchronous at the server's 
discretion, then (at a minimum) that's quite a complication and we must 
be prepared to document it thoroughly.

3) I would strongly prefer to deal with workflow explicitly and 
separately if possible.  What sort of a "minimal interface for workflow 
interaction" did you have in mind?

Jeff Larson wrote:

> Darran Rolls wrote:
>
>> So in summary, the proposal is to
>>
>> 1) Move Batch to an optional capability
>> 2) Make core operations synchronous and async functionality a 
>> separate capability that can be applied to it?
>
>
> I was liking this, but then I remembered some issues that were 
> "resolved" at the last
> F2F I attended involving workflow.
>
> I had originally thought that async requests were just a client 
> preference.  I raised
> the issue of possibly having a minimal interface for workflow 
> interaction since many PSPs
> will involve workflows.  The resolution at that time was that this is 
> what async requests
> were for.  If a PSP processed a request by launching a worklfow which 
> suspended
> waiting for approval, then the PSP would have to return an async id 
> that the client
> could then use to poll for status.  This means that sync/async is no 
> longer determined
> by the client, it is determined by the server.  The client may ask for 
> sync, but it may
> still get back an async request id and must be prepared to deal with it.
>
> I don't especially like overloading the synchronousness (synchronicity?)
> of requests with workflow semantics.    But if we do, then we can't move
> request ids to just batch requests since it is possible for any request
> (except the obvious ones like status, schema, and cancel) to become
> async requests at the PSPs discretion.
>
> If we break apart async & workflow, then we'll have to go back
> and consider how we're going to model workflow.  IDM currently
> does this with a set of SPML object classes that map onto
> our workflow task instances.  This works ok but doesn't do anything
> for interoperability since it is a non-standard schema.  Given that a 
> significant
> percentage of provisioning systems are going to involve workflows, it may
> make sense to have something more formal in the standard.
>
>
> Jeff
>
>
>