[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] BatchRequest/Response envelope and batch ID
Matthias, If you mean requesting the status for all the pending requests for a service, there is currently no mechanism for that. I could certainly see the value in something like that. We could make the request ID optional on the batch status request, and then specify that is the request ID is not declared the service should return the batch status responses for all pending requests. Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Matthias Leibmann [mailto:mattleib@microsoft.com] Sent: Monday, February 24, 2003 9:07 PM To: Jeff Bohren; provision@lists.oasis-open.org Subject: RE: [provision] BatchRequest/Response envelope and batch ID Thanks Jeff. I understand all that, but can I request a status of a single service, without maintaining batch-id's? What would I pass as a batch status request to find that out? Thx, Matthias -----Original Message----- From: Jeff Bohren [mailto:jbohren@opennetwork.com] Sent: Monday, February 24, 2003 5:58 PM To: provision@lists.oasis-open.org From a practical standpoint, batches are optional. The schema does require the batch request element, but the batch request could contain a single operation. If you don't want batching that is what you should do. Since batches are effectively optional, when should you use them? They should be used when one of the following is a requirement: 1) There is the need for transactions (i.e. all operations in a batch must succeed or they all roll back) 2) There is a set of operations that must all be approved or denied together 3) There is a set of operations that must be audited as a set Since you can do single operations with our current batch mechanisms, but you can't do the kinds of things descibed above, it makes sense to have batches as part of the standard. One piece of functionality we used to have for a batch status request was to return the status of all operations as they would be if the request was finished at that point. That would allow for the retrieval of the status of all the operations of a batch, not just status of the batch itself. Jeff Bohren OpenNetwork Technologies -----Original Message----- From: Matthias Leibmann [mailto:mattleib@microsoft.com] Sent: Mon 2/24/2003 3:57 PM To: provision@lists.oasis-open.org Cc: Subject: [provision] BatchRequest/Response envelope and batch ID I wanted to raise the question I was asking at the last face2face again. Leaving DSML aside for a moment, why does SMPL need to express all operations in batches? Correct me if I'm wrong , but for a RA, it looks to me that it will most likely submit single requests for a service. And later when it tries to check on status, I believe it will do this more frequently on a single object, using the PSO-ID, and not a batch ID. Some systems might want to-do "true batches" and address those by an ID. But even for that, SPML is missing currently the functionality to query on a status of a single service (that was part of a batch). This all most likely complicates the RA, I think. It needs to manage Batch-IDs and PSO-IDs. Batch-IDs are more temporary, but PSO-IDs stay until the service is de-provisioned. Wouldn't it be better to have some sort of functionality to use the PSO-ID in batch status/cancel? Or more general, shouldn't SPML allow to hide the batchRequest/batchResponse and allow anchoring everything on the PSO-ID (so the batch envelope could be completely ignored)? Best Regards, Matthias ---------------------------------- Matthias Leibmann Program Manager Microsoft Metadirectory Services Mailto:mattleib@microsoft.com <Mailto:mattleib@microsoft.com> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC