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] | [Elist Home]

Subject: RE: [provision] BatchRequest/Response envelope and batch ID


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