Re: [provision] Batch Capability.

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

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