RE: [provision] Asynchronous requests.

["Cohen, Doron" <Doron_Cohen@bmc.com>]

Gary,

I believe you may want to go async for many operation, even if not batch as
the requestor as no way to predict how long the operation would take and
opting for async. I would tend to agree that there is no point in status or
cancel operations. 

Doron 

Doron

Doron Cohen
Chief Architect, Identity Management BU
BMC Software
Email: doron_cohen@bmc.com

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Thursday, October 14, 2004 11:39 PM
To: Jeff Bohren
Cc: PSTC
Subject: [provision] Asynchronous requests.

Does it make sense to be able to issue a 'cancel' or a 'status' request 
asynchronously?  I don't think so, since you'd have to keep track of the 
requestID of the cancel request in order to find out whether your cancel 
worked.  Imagine keeping track of the requestID of a status request in 
order to find out the status of the status request. 

You see where I'm headed, right?  It doesn't make much more sense to get 
the status of a status request than it would make to batch up batch 
requests.  (We prevent the latter by specifying that BatchRequestType is 
not itself a BatchableRequestType.)

Which operations would one want to execute asynchronously?
- 'listTargets'?
- 'cancel'?
- 'status'?
- 'lookup'?
- 'search'?
- an individual 'add'?
- an individual 'modify'?
- an individual 'delete'?

Or does asynchronous execution make sense primarily for the 'batch' 
operation?


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_workgro
up.php.