Re: Workflow (was "Re: [provision] Re: Async and workflow")

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

>
> Would it make sense for the provider to issue some sort of callback to 
> the requestor (e.g., for contact information)?  I find it hard to 
> imagine an RA that is a program modifying the contents of a workitem.  
> It seems like this would be a *person* looking for workitems and 
> modifying their contents, or perhaps replying to an email from the 
> provider.  The provider's email could contains a link to a dialog that 
> requests specific information from the person and applies it to the 
> request/workitem.


I wouldn't recommend getting into a callbacks.  Everything can be done
with RA initiated communications, callbacks just add complexity.

Why can't an RA be a person?  I would imagine a lot of the time it
will be a person interacting with a system that happens to also
be an RA.  That was the case in the original PeopleSoft demo.

Granted, the RA application has to be built with the notion of
work item support in mind.  PeopleSoft isn't of course,
but something designed for SPML could be.  When the
person gets the email with the link to the dialog, what
are they interacting with?   The fact that SPML is being
used implies that the client wants to be in control of the user
interface, so there needs to be something on the RA side
of the fence that processes work items, and that is
going to need an API.  This can either be the same
RA application that started the request or a different one,
but they both use SPML to communicate with the PSP.


>
> Assuming that the requirement holds, I think we could formalize the 
> notion that an SpmlResponse may contain a (server-generated) 
> requestID. (I described one approach just a minute ago in my email 
> titled "Async Conversion".)
>
Works for me.

Jeff