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

[Gary P Cole <Gary.P.Cole@Sun.COM>]

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