W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2002

RE: Is (sender-side) persistent storage needed for Reliable Messaging ??

From: Assaf Arkin <arkin@intalio.com>
Date: Sat, 14 Dec 2002 11:58:26 -0800
To: "Ricky Ho" <riho@cisco.com>, "Ugo Corda" <UCorda@SeeBeyond.com>, <www-ws-arch@w3.org>

  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Ricky Ho
  Sent: Saturday, December 14, 2002 7:48 AM
  To: Ugo Corda; www-ws-arch@w3.org
  Subject: Is (sender-side) persistent storage needed for Reliable Messaging

  Can someone elaborate why this is a need of persistent storage at the
sender side (as said in ebXML spec) ?  I don't see such need because if the
client system crash before getting the ACK, the message delivery status is
"in-doubt" and the client side application has to find it out by himself

  Node A wants Node B to do something. Node A creates a message and sends it
to Node B. Node A crashes. Node B sends an ack and starts processing the
message. The ack is not received by Node A since its down. Later Node A
comes back to life. Node A does not have any recollection of sending a
message to Node B, it missed the ack coming from B, so it has no clue that
Node B is processing the message or that it should even ask Node B "how's it
going with that message over there?"


  Rgds, Ricky

  At 02:30 PM 12/12/2002 -0800, Ugo Corda wrote:

    I just reread ebXML's work on Reliable Messaging (see [1], Part II, Sec.
6, Reliable Messaging Module), and it looks like required reading for any
discussion on this subject within our group (so that we don't spend a lot of
time redoing what has already been done).

    Besides the specific syntax used, which belongs to ebXML and does not
need to be duplicated, I am curious to know if people find deficiencies, or
have any other type of observations, regarding the reliability model used.


Received on Saturday, 14 December 2002 14:59:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:01 UTC