Action item

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 Wednesday, 6 October 2004 22:28:18 UTC