Re: [provision] Non-batchable operations.

[Darran Rolls <Darran.Rolls@Sun.COM>]

The "Custom Capability Registry" sounds like an excellent 
interoperability tool.  Does anyone have thoughts on how this would be 
best implemented?
Darran

Gary P Cole wrote:

> Participants in today's PSTC conference call agreed on a list of 
> non-batchable operations *almost* as the chair had captured it.  The 
> sole change from the agenda item is that batches are not batchable.
>
> Participants agreed that the ability to nest batches is valuable when 
> a batch implies an atomic transaction but that, since the batch 
> capability does not imply transactional semantics, the ability to nest 
> batches does not have enough value to justify the complexity that it 
> implies.
>
> Gary Cole argued that a *transactional* batch should be a separate 
> capability (even if it were syntactically similar to today's batch 
> capability) because of the additional complexity required 1) to manage 
> transactional semantics and 2) to undo specific operations.  Rami 
> Elron said that such a capability would need additional consideration 
> and design.  Darran Rolls therefore suggested that any such capability 
> should be developed as a custom capability.  This in turn spurred 
> further discussion of an earlier suggestion that the PSTC should 
> maintain a "registry" of capabilities in order to promote sharing and 
> re-use.
>
> Gary P Cole wrote:
>
>> I think what Jeff says is reasonable.  Batch-being-batchable gives me 
>> a little bit of heartburn, but I'm not sure how much I care.  (In 
>> addition to the possibility that a batch might imply atomicity, I 
>> *suppose* that you could achieve some interesting failure semantics 
>> by nesting batches with different settings for 'onError' and 
>> 'processingMode'.)  However, I will note that in SPML1.0 the batch 
>> request was not itself batchable.  Are we *sure* we want to support 
>> nested batches?
>>
>> I'm okay with bulk operations being batchable.  There is no scale 
>> issue, and I see no logical issue.
>>
>> Jeff Bohren wrote:
>>
>>>
>>> 1, 3, 4, 5, 6 all seem reasonable.
>>> I would not want to restrict batch to not being batchable. This is 
>>> for the case where batch is being used to provide atomic semantics 
>>> (assuming the service provides such support). A batch of batches 
>>> would be an atomic transaction composed of atomic transactions. I 
>>> doubt that this would really ever be used, but I also don't see a 
>>> reason to disallow it either.
>>>
>>> The bulk operations should absolutely be batchable. For instance if 
>>> there is a need to perform the same bulk operation to two different 
>>> targets, it would make sense to batch them.
>>>
>>> Jeff B.
>>>
>>>     -----Original Message-----     From: Gary P Cole 
>>> [mailto:Gary.P.Cole@Sun.COM]     Sent: Thu 2/17/2005 9:44 AM     To: 
>>> PSTC     Cc:     Subject: Re: [provision] Non-batchable operations.
>>>        
>>>     I agree that this is the real question, so I'll repeat the original
>>>     content (since it may have been lost or buried in subsequent 
>>> replies in
>>>     this thread).
>>>         It seems clear to me that:
>>>     1) 'listTargets' is not batchable
>>>        (for the same "bootstrapping" reasons that it is synchronous).
>>>     2) 'batch' is not batchable
>>>        (it would be a mess to nest these).
>>>     3) 'search' is not batchable
>>>        (the batch response could become far too large).
>>>     4) 'iterate' is not batchable
>>>        (for the same reasons that it must be synchronous)
>>>         I don't see why Async Capability operations would be batchable
>>>     (since they must be synchronous and batch is usually async):
>>>     5) 'cancel' should not be batchable
>>>        (seems weird to batch a cancel request with other requests;
>>>         the batch would have to be synchronous)
>>>     6) 'status' should not be batchable
>>>        (seems weird to batch a status request with other requests;
>>>         the batch would have to be synchronous)
>>>         Finally, I'm not sure that Bulk Capability operations should 
>>> be batchable
>>>     (but I cannot really say that this would cause a problem):
>>>     7) 'bulkModify' ?
>>>     8) 'bulkDelete' ?
>>>         Everything else (add, lookup, modify, delete, setPassword,
>>>     expirePassword, resetPassword, validatePassword) seems okay to be
>>>     batchable.
>>>         I lean toward normatively specifying at least those that are 
>>> NOT
>>>     batchable. For example, to batch a listTargets request is a logical
>>>     error.  To batch a batch request seems a very bad idea--this way 
>>> lies
>>>     madness.
>>>         Jeff Bohren wrote:
>>>         >So now the real question is what should normatively 
>>> specified as batchable. I really don't see any value in normatively 
>>> calling out certain verbs and declaring them batchable. I would lean 
>>> towards leaving this unspecified.
>>>     >
>>>     >
>>>                 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. 
>>
>>
>
>
>
> 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. 
>
>