RE: [provision] Async execution (was "Re: [provision] Asynchronou s requests").

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

Gary, 

I think we are close and I agree to the way you put it, however, with the
risk I am repeating myself, I would like to stress that I do not really
object to the optimization involved in changing a async request to sync. I
am concerned with the way one would design an RA client app. If I have a
client that issue async operations to PSP and use separate thread to check
for the results, then the fact that the PSP does the optimization and return
the results to the requesting thread is of little help to me. In fact, it
may well introduce to me more burden of enhancing the client code to handle
that situation.

Now, I agree that for the sake of satisfying the optimization requirement,
we would need to enables the RA to specify to the PSP, "handle the request
async, but in case you can do it quickly, do a sync". If we choose to go
this way we need to provide a clear definition on how the implementation is
supposed to achieve this. For me it is sufficient that we state it in a
clear manner either by adding a new mode or by explicit description in the
normative text for the case no mode is specified.

Does this help?

Doron

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Monday, October 25, 2004 6:24 PM
To: Cohen, Doron
Cc: PSTC
Subject: Re: [provision] Async execution (was "Re: [provision] Asynchronou s
requests").

Doron,

I'm not sure that you're in the minority.  I agree with you that 
honoring a request for explicit execution mode (or failing the request) 
is more straightforward.  The notion that a client can simply omit the 
'execution' attribute (in order to indicate that the client will accept 
either mode) makes this argument even more compelling. 

However, it seems to me that Jeff Bohren's point is also very good: 
    If a service processes an asynchronous request synchronously,
    there is no reason to return an asynchronous response.
    The service knows the request was processed synchronously,
    and it should be reported as such.

Executing an operation synchronously (whenever a provider knows that it 
can do this) seems to be a reasonable optimization.  It does seems a 
little silly to make a provider 1) generate and return a requestID and 
2) hold onto results waiting to be asked for status. 

I suppose that I could live with a little bit of silliness (since the 
provider always has the option of failing the request if it is 
absolutely unwilling to execute asynchronously an operation that the 
provider could execute synchronously), but it would be nice to have a 
better answer to Jeff Bohren's point. 

If a request for asynchronous execution will always receive a 
synchronous response
(that contains the requestID), and
if a provider can execute the requested operation synchronously, then
why not let the provider return the results of the completed operation 
(rather than a requestID)?

gary

Cohen, Doron wrote:

>1) I may be in a minority here, but I still feel differently about this
>point. To me ,honoring the client request with regard to the mode of the
>operation is key. Allowing the PSP to behave differently than requested
>means more complexity on the RA side since the RA must be able to handle
>both scenarios instead of maintaining a simplicity of acting in one manner.
>Also, the RA has no way to predict the time that the request would execute
,
>and I must admit that in most cases, even the PSP would not really know
>that. 
>Overall, I find a design that honors the RA request more straight forward
>and recommend that if we choose to allow the PSP to convert the execution
>mode, let the RA say so by providing an additional indication that he is
>capable of handling PSP change of mode.
>  
>