[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Async and workflow (was "Re: [provision] Batch Capability.")
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]