Re: Action item

A quick note to confirm that I have implemented the asynchronous
behaviour required by test case T7 as outlined in the original e-mail
below.

I have also deployed a first cut of a compound service endpoint at:

http://62.77.172.83:4080/compound/soap12
http://62.77.172.83:4080/compound/soap11
http://62.77.172.83:4080/compound/plain-http

Test cases T9, T10 and T11 appear to work using my own client.  Inner
asynchronous requests are ignored for the time being.

Regards
Tommy


On Thu, 7 Oct 2004 11:31:26 +0100, Tommy Lindberg
<tommy.lindberg@gmail.com> wrote:
> 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 Monday, 11 October 2004 22:14:37 UTC