Re: Action item

Hi Stephen -

I am working on a few things and expect to redeploy an updated version
early next week, probably Monday but not commiting. This feature will
be present in that version.

The other main thing is support for compound messages.

Regards
Tommy


On Thu, 07 Oct 2004 11:25:29 +0100, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
> 
> 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:31:31 UTC