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

The application asks the RM to send the message an RM replies positively if
it can send the message. The application then goes and does something else.

The RM will send the message at a later point in time and will retry as many
times as necessary. The application never contacts the RM to determine what
the delivery status is.

From the perspective of the application, if the RM says that is will deliver
the message then the message will be delivered. The application does not
consider the possibility that the message will not be delivered.

The application does consider the possibility that the message will not be
processed. This may happen even if the message got delivered an you received
an ack. It is also something that only the application can deal with since
it involves logic that is specific to the application.

Such an approach greatly simplifies the development of the application and
the RM. It also means that if the message takes a few hours to arrive at its
destination, the application will not block for a few hours, but can go
about its normal duties.

arkin
  -----Original Message-----
  From: Ricky Ho [mailto:riho@cisco.com]
  Sent: Saturday, December 14, 2002 5:00 PM
  To: Assaf Arkin; Ugo Corda; www-ws-arch@w3.org
  Subject: RE: Is (sender-side) persistent storage needed for Reliable
Messaging ??


  Lets detail out ...

  App-A and RM-A is running inside node-A, so here is the flow.

  1) App-A --(M)--> RM-A   (App-A then wait for RM-A to report the delivery
status)
  2) RM-A --(M)--> RM-B  (using the retry mechanism we've been discussing so
far)
  3a) If (retry successful), then RM-A report delivery status "success" to
App-A.
  3b) If (retry timeout), then RM-A report delivery status "in-doubt" to
App-A.  Now it becomes App-A's responsibility to figure out the actual
status

  My question is:

  If nodeA crash between after point (1), why can't we simply treat that
same as the scenario of 3(b) ?

  In your proposal, do you expect ....
  a) App-A to extract the message from the persistent store of RM-A, and ask
the RM-A to resend that message ? or ...
  b) RM-A automatically resend that message, but after it get an ACK, how
does it report back to App-A (because App-A may not be running) ?

  Best regards,
  Ricky

  At 11:58 AM 12/14/2002 -0800, Assaf Arkin wrote:


      -----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
anyway.


      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?"

       arkin


      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.
        Ugo


        [1]
http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0rev_c.pdf