OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [provision] Non-batchable operations.


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]