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

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

Gary P Cole wrote:

> 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.

Yes, in SPML 1.0 it is just a client preference.  I brought it up during 
the SPML 2.0 discussions, which
led it to becoming something controlled by the PSP.  I haven't been 
following the 2.0 spec that closely,
so if this got dropped it needs to be brought up again.  The PSP must be 
allowed to convert any
synchronous request into an asynchronous request, and the RA needs to be 
prepared to deal with it.
If that isn't allowed, then one of two things happens:

   1) The RA blocks on a synchronous request for days until the approver 
gets around
        to approving it.

    2) The PSP returns a synchronous response, with some kind of proprietary
         indication that the request has been queued pending approval.

The problem with the first approach is obvious.  The problem with the 
second approach
is that the RA has no standard way of knowing whether the request 
actually completed.


>
>
> 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?


Yes, I'm not sure SPML should get into the business of defining a 
workflow interface
protocol, though really that does make some sense since I would venture that
the majority of PSPs are going to have workflow of some form.   At the very
least we would need:

  1) A standard way for an SpmlResponse to indicate that the request has
      been "queued".    This could be because of workflow, or just because
      the PSP can't deal with the request immediately for some reason.
      Part of this is an identifier that the client can use to query the
      status of the request.

   2) A standard way for a client to request the status of a queued request
        using the identifier returned by 1.

This is similar to the async request operations but I really don't think it
is the same thing.  One difference is that the RA will probably not
be able to cancel a workflow once it is in progress.  It can only poll
status.

The next step then would be dealing with what we call "manual actions"
and "work items".  Manual actions are commonly used for approvals,
but they are more general than that.  I can easily imagine situations where
a request sent to a PSP kicks off a workflow that then decides it needs
more input from the RA. The RA then would need some kind of interface
to search for it's work items and modify their contents, which would then
resume the workflow and complete the original request.

This is not all that hard and can be done with SPML 1.0 by defining
proprietary object classes and operational attributes in the SpmlResponse.
But if this will be that common, we should consider something more formal.

I'm ok with having task status and work item editing handled
with standard schemas rather than introducing new  elements to the protocol.
I'm not very fond though of having to pass back the identifier of the
workflow task in a proprietary operational attribute, something more formal
in the SpmlResponse would be nice.

Jeff