RE: [provision] Keeping results of asychronous operations.

["Jeff Bohren" <jbohren@opennetwork.com>]

I am afraid I don't see the value of this issue being addressed in the
specification. That the status is retained for some time period should
be self-evident, otherwise there would be no reason to have a status
request. However the specific time period is up to the service
implementer. 

I am not comfortable with not keeping the status after a status request
is done. The problem with that approach is that the client may have
issued a status request but there may have been a failure to process the
status results.

The only way I would address this in the spec would be something like:

"The service SHOULD maintain the status of asynchronous requests for the
purposed of responding to status requests for a specific duration, where
that duration is published out-of-band to potential clients."

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 
Try the industry's only 100% .NET-enabled identity management software.
Download your free copy of Universal IdP Standard Edition today. Go to
www.opennetwork.com/eval.
 
 

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Friday, October 29, 2004 10:04 AM
To: Darran Rolls; Jeff Bohren
Cc: PSTC
Subject: Re: [provision] Keeping results of asychronous operations.

I like that idea, too.  I think Jeff Bohren would be most likely to have

a contrasting opinion.

Jeff, how could/should/would a provider specify a time limit on async 
results as part of the Async Capability?  Is this a terrible idea?

Darran Rolls wrote:

> I like 1 & 1b with the assumption that the service can "advertise" its

> retention timings as part of the service definition.
>
> Darran
>
> Gary P Cole wrote:
>
>> A provider will eventually want to forget about a completed 
>> asynchronous operation. I can think of two approaches.  Neither 
>> approach excludes the other.
>> 1) A provider can save the results of asynchronous operations for a 
>> certain amount of time.
>> 2) A provider can send a final, unsolicited response to the
requestor.
>>
>> I prefer the first approach.  I like the simplicity and consistency 
>> of a response always being a synchronous reply to a request.  
>> (However, if someone wants to make a case for the second approach, 
>> I'll listen.  Neither approach excludes the other.)
>>
>> Assuming the first approach, we still have options to consider. 1a) A

>> provider should keep results for each completed asynchronous 
>> operation for a certain amount of time.
>> 1b) A provider should keep results for each completed asynchronous 
>> operation for a certain amount of time OR until a requestor uses the 
>> status operation to obtain the final results of the operation, 
>> whichever comes first.
>>
>> gpc
>>
>>
>>
>> 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_wor
kgroup.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_wor
kgroup.php. 
>
>