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] Asynchronous requests.


Doron,

I agree that if the requestor explicitly specifies synchronous execution 
and the provider must execute the operation asynchronously (e.g., 
because the operation involves workflow and may involve approvals), the 
provider must fail the request.

Conversion to asynchronous at provider initiative is a new behavior.  As 
such, I'm not sure that we've modeled it correctly. 

As it stands, I believe that a client communicates its ability to handle 
the conversion of a request to asynchronous execution by omitting the 
'execution' attribute of its request.  If an execution type is not 
specified, the provider may assume that the requestor can support either 
type of execution.

If we feel that it would be better for a client to communicate 
*explicitly* which types of execution it can support, we might consider 
1) *requiring* the 'execution' attribute in a request, and 2) adding a 
value of "either" to ExecutionType (in addition to its current values 
of  "synchronous" and "asynchronous").

gpc

Cohen, Doron wrote:

>Gary,
>
>As long as we determine how the client communicates its ability to handle
>such a conversion by the PSP, I am ok. I feel uncomfortable with having the
>PSP change the execution type when it was explicitly specified by the RA as
>sync. The PSP can fail the request in such a case, but should not change the
>mode as it has no clue whether the RA can handle this.
>
>Doron
>
>
>
>-----Original Message-----
>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
>Sent: Monday, October 18, 2004 5:48 PM
>To: Cohen, Doron
>Cc: Jeff Larson; PSTC
>Subject: Re: [provision] Asynchronous requests.
>
>Doron,
>
>There is (currently) no way for an RA to *explicitly allow*  
>asynchronous execution in a request.  An RA must do one of the following:
>- explicitly request asynchronous execution
>- explicitly request synchronous execution
>- omit the execution attribute (which could be taken as
>   implicitly allowing either type of execution).
>
>Does this change your opinion (that it is okay for a provider to convert 
>a request to asynchronous execution)?
>
>gpc
>
>Cohen, Doron wrote:
>
>  
>
>>Jeff,
>>
>>I understand the scenario, but I believe in many cases the client would
>>anticipate the workflow scenario and use async the first place.
>>In any case, I do not object to allowing the PSP to convert the request as
>>long as the RA explicitly allows that in the request. If it doesn't the PSP
>>can either accept it and allow the client to wait indefinitely OR reject
>>    
>>
>the
>  
>
>>request with a fail status.
>> 
>>
>>    
>>




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