Re: [provision] Batch Capability.

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

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