RE: [provision] Asynchronous requests.

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

Gary,

1) The thing is that these (cancel, status) operations are not really
something you the PSP to really do. Its more of a mgmt thing that relate to
previous operations/requests issued. 

2) I do not feel strongly as others for the PSP converting a sync request to
async. For me, it tis the decision of the client as the client is the one
managing the session, meaning - the client KNOWS if it can wait for the
response (for ever , timeout based etc) or it is ready to work async (and
come back later for results). Therefore, for me a server that converts a
sync request to async is an unnatural scenario since the RA issued the
request for the operation to be sync may not be able to handle the async and
check later for the result.

Doron

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Sunday, October 17, 2004 7:49 PM
To: Cohen, Doron
Cc: PSTC
Subject: Re: [provision] Asynchronous requests.

I was afraid you were going to say that. :-) 

If 'cancel' and 'status' are the only operations that don't make sense 
to us, then somebody will want even *those* operations to be 
asynchronous. Thus, in  the most general case, 
1) any operation could be requested asynchronously. 

I suppose it follows that, in the most general case,
2) any operation could be converted to asynchronous execution at the 
provider's initiative.

Would you agree with those conclusions?

gpc

Cohen, Doron wrote:

>I think for basically all of them. The only that comes to mind as not
>applicable are 'Cancel' and 'Status' as you raised. In fact in many cases
>async will be the default for RA issuing requests to a PSP.
>
>Doron
>
>-----Original Message-----
>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
>Sent: Sunday, October 17, 2004 6:41 PM
>To: Cohen, Doron
>Cc: PSTC
>Subject: Re: [provision] Asynchronous requests.
>
>Thank you, Doron.  If it makes sense to request asynchronous execution 
>for only certain  operations, then the next question is...for which 
>operations? Jeff Larson suggested the following:
>- batch
>- add
>- modify
>- delete
>
>Would you add or take away any operation from this list?
>
>gpc
>
>Cohen, Doron wrote:
>
>  
>
>>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_workg
r
>>    
>>
>o
>  
>
>>up.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_workgro
up.php.
>
>  
>