[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Batch and Async Capabilities (was "Re: [provision] Batch Capability.")
I took a shot at the XSD for a Batch capability and an Async capability. I'm not sure that my XSD is spotless, but this really cleans things up quite nicely. Perhaps the best thing about defining a *capability* for asynchronous execution--beyond the fact that it dramatically simplifies the core schema and the core operations--is that it gives the provider a very nice way to declare whether it *supports* asynchronous execution. This in turn means that the requestor doesn't have to "program by exception" (as Mr. Bohren would say)--that is, request asynchronous execution, capture the failure, and infer/guess that the failure indicates that the provider doesn't support asynchronous execution. gpc Gary P Cole 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? >> >> Captured correctly? > > > Well, yes. This note was about #1, but the postscript does hint at #2. > #2 depends on how the list responds to my question about "Asynchronous > requests". If only the 'batch' really needs to be asynchronous, then > perhaps we make 'requestID' and 'execution' specific to the 'batch' > operation. > If we believe that other operations (possibly those from custom > capabilities) may need to be asynchronous, then perhaps we should > define a separate Asynchronous Capability. This capability would > define the 'status' and 'cancel' operations as well as a new > operation--call it 'async' or 'launch' or 'spawn'. The AsyncRequest > would wrap another request (much as BatchRequest does). > If we want it to be so, the AsyncResponse could be synchronous and > could contain a (server-generated) requestID that the requestor could > use to 'cancel' or obtain 'status' for the asynchronous operation > (i.e., for the wrapped request). That way the requestor gets an > immediate acknowledgment of the async request AND the requestor > doesn't have to generate a value that is globally unique for the server. > > Of course, I wasn't going to suggest any of this until I got some > feedback. > >> Anyone apposed? >> >> Darran >> >> Gary P Cole wrote: >> >>> Should 'batch' be a required operation? >>> Right now 'batch' is part of the core (which de facto makes it >>> required), but it doesn't really have to be part of the core. It's >>> not a *basic* operation (like 'add', 'modify', 'delete', or >>> 'lookup') and it's not a *bootstrap* operation (like >>> 'listTargets'). It's an operation that wraps multiple (batchable) >>> requests in a single request. >>> >>> I think we should move the 'batch' operation to a Batch Capability >>> (for the same reasons that we moved 'search' to the Search >>> Capability). The 'batch' operation imposes a fair amount of >>> complexity on the provider, and should be optional. 1) The 'batch' >>> operation requires that the provider order nested results within its >>> response (to correspond with the order of the requests within the >>> original request). >>> 2) The batch operation also also allows the requestor to specify >>> "processingType" as either "sequential" or "parallel". >>> >>> gpc >>> >>> ps. In addition to its specified features, the 'batch' operation is >>> the "poster child" for asynchronous execution. We could remove a >>> fair amount of complexity from the core protocol if the basic >>> operations were all synchronous--and we could do it without reducing >>> function. As long as the provider supports asynchronous execution >>> of batch requests, a requestor who wants to execute an operation >>> asynchronously can simply wrap the original request in a batch request. >>> >>> >>> >>> To unsubscribe from this mailing list (and be removed from the >>> roster of the OASIS TC), go to >>> http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php. >>> >>> > > > > To unsubscribe from this mailing list (and be removed from the roster > of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php. > >
draft_pstc_spmlv2_7_batch_async.zip
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]