RE: [provision] Asynchronous requests.

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

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.

Doron

-----Original Message-----
From: Jeff Larson [mailto:Jeffrey.Larson@Sun.COM] 
Sent: Monday, October 18, 2004 5:23 PM
To: Cohen, Doron
Cc: Gary P Cole; PSTC
Subject: Re: [provision] Asynchronous requests.

Cohen, Doron wrote:

>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.
>  
>
The server must either be able to convert the request, or it must return 
an error if the
possibility exists that workflow will be used.  Supporting a scenario 
where the client
waits indefinitely for the workflow to complete imposes a burden on the 
server
to keep the socket open and enter into its own polling loop.  It may not
even be possible to keep an inactive socket open for days, routers are 
sometimes
configured to break these. 

The inability to convert a request (without also providing an SPML model 
to poll workflow status)
would effectively mean that synchronous requests are totally useless for 
our product,
we would only support async requests.   The same will be true for any 
other product
that incorporates workflow.

Jeff