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


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


Doron,  yes, this does help.  I think we agree, although I must confess 
that I am still unsatisfied.  I think that I would prefer to say that if 
a requestor specifies execution="asynchronous" that a provider must 
either execute the requested operation asynchronously (or must fail the 
request). 

Jeff Bohren and Jeff Larson,  why it is so important that a provider 
must be able to execute synchronously an operation that was requested to 
execute asynchronously?  (I understand that it may be a little bit 
unnecessarily expensive, but is there a deeper reason?)

gary

Cohen, Doron wrote:

>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.
>> 
>>
>>    
>>
>
>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_workgroup.php.
>
>  
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]