RE: Next Steps in Reliable Messaging (was RE: Different Levels of Rel iable Messaging)

I apologize for any lengthy discussion on my part.

In my opinion it would be extremley helpful if XMLP could address ack and
resend for asynchronous operations and standardize these. I believe that
anything beyond that is extremley important, but should probably not be
solved by XMLP, but by future specifications layered on top of that. I think
David's listings of the 5 levels (assuming XMLP does level 0) summarizes the
scope of such a specification.

There is a well developed body of theory regarding asynchronous messaging in
distributed environments. I often refer people to Distributed Algorithms
(Nancy A. Lynch) which covers all of these aspects and more, though I'm not
sure reading the book would help you identify a practical solution.

You can also use MOMs as a reference point. MOMs are designed to deal
exactly with this problem or asyncronous communication, acks an resens. Even
though implementations and APIs vary the underlying principles are always
the same.

arkin
  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Champion, Mike
  Sent: Saturday, December 14, 2002 5:13 PM
  To: www-ws-arch@w3.org
  Subject: Next Steps in Reliable Messaging (was RE: Different Levels of Rel
iable Messaging)


  [wearing a co-chair hat]

  I'm very pleased that this discussion has been so productive and
illuminating.  It's getting a little too deep into possible specs and even
implementations for the WSA WG's purposes, however.

  I would appreciate it if there was discussion of what we would need to do
to actually do something with the reliable messaging idea in the context of
the W3C's Web services activity, however:

  1 - How does it fit into the WSA architecture document as drafted?  Is
there a well-developed body of theory or practice that the document to
reference? (TCP comes to mind ... the point of this might be to replicate
TCP's semantics at a higher architectural level, e.g. where there are
non-TCP/IP networks in the mix, discrete message delivery mechanisms use
higher-level protocols such as HTTP, etc.)
  2 - What would be the scope of a WG that would actually draft a reliable
messaging spec?
  3 - Is the scope/timing limited enough so that we could -- assuming they
were interested -- propose that the XMLP WG take this job on, or will it
require specialized expertise and/or a lot of time that XMLP doesn't have?

  Thanks!
    -----Original Message-----
    From: Ricky Ho [mailto:riho@cisco.com]
    Sent: Saturday, December 14, 2002 7:36 PM
    To: Burdett, David; www-ws-arch@w3.org
    Subject: RE: Different Levels of Reliable Messaging


    <Ricky>
    This is what our disagreement is.  I think the sender should report to
the application that delivery is "in-doubt".  (not "failed")
    </Ricky>


      3. The destination restarts, finds the message, sends the ack and
starts processing it.
      4. The sender receives the ack and has to tell the application that
the message for which it had just reported a delivery failure had actually
been received and was processed - not a desirable outcome

      Alternatively by specifying a time out and basing the retries on that
you know, with a high degree of certainty, that even if the message is
picked up, it won't be processed and therefore you are much less likely to
have to report the a delivery failure and then have to reverse it.

    <Ricky>
    Lets say the message has been picked up before time expired, and the
receiver site is down before the ACK message is sent.
    Now even though the sender keep resending message until time expired, he
still cannot conclude the delivery failure
    </Ricky>