Re: Action item

Nice one Tommy!

How long do you think that'd take to get in place?

Stephen.

Tommy Lindberg wrote:
> I am responding to the action item that I took on from the last (28
> Sep) XKMS interop call.
> 
> The item relates to test case T7 and with all likelihood to other test
> cases that employ
> asynchronous processing.
> 
> Test case T7 specifies a sequence of requests along with the expected
> results in an asynchronous message exchange.  Specifically, the test
> case contains two StatusRequest's of which the first is expected to
> return a Pending status and the second is expected to return a Success
> status.
> 
> The issue is that "We cannot currently test 'long asynchronous'cases
> [with long delays between initial request and final result] since all
> of the servers answer almost immediately".
> 
> My comment during the call was that a client should not make
> assumptions about the delay in the processing that occurs between the
> initial request and completion of the request - this delay could be
> anything between minimal to considerable. As far as I can tell, the
> XKMS asynchronous protocol is not violated if this delay approaches
> zero.
> 
> I am currently taking the approach of operating my service endpoints
> with a minimal delay in
> this respect, something that both myself and others have found
> convenient as there is no
> out of band coordination required. Consequently a StatusRequest
> against my service will
> almost certainly never return the Pending status that the initial
> StatusRequest of T7
> expects.  I believe some other  implementors may have taken the same approach.
> 
> That said, I understand and accept that this is a protocol behaviour
> that requires interop
> testing.
> 
> Here are some of the options I considered for producing the final
> result of an asynchronous
> request in a way that would satisfy the wording of T7  (some of them
> more dubious than others):
> 
>   1) manually by the service operator
>   2) automatically after a fixed delay
>   3) a "lazy completion" approach that is triggered by the clients
> interest in the final result
>      i.e. the production of the final result is triggered by the first
> StatusRequest received.
>   4) a web based user interface through which the tester where he/she
> can invoke the final
>      result production by providing the required Id's
>   5) an XKMS message extension that allows for the specification of a delay
> 
> It turns out that by combining 3 and 2 I can with a relatively small
> effort produce the
> behaviour expected by T7 without sacrificing the convenience of
> unattended operation.
> Furthermore, this approach does not require any changes to the existing client 
> implementations.
> 
> The complete sequence:
> 
>   - the initial request processing will leave the status as Pending
>   - the first StatusRequest will trigger the final result processing
> and return the Pending
>     status
>   - subsequent StatusRequest's will find the final result produced and
> will therefore a return a
>     Success status
>   - a watch dog will ensure a configurable maximum delay (e.g. 15
> minutes) which when
>     reached, will also produce the final result
>   - a PendingRequest is used to pick up the final result
> 
> Regards
> Tommy
>

Received on Thursday, 7 October 2004 10:23:22 UTC