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

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

From: Ricky Ho <riho@cisco.com>
Date: Sat, 14 Dec 2002 17:18:49 -0800
Message-Id: <4.3.2.7.2.20021214171344.0266ec38@franklin.cisco.com>
To: "Assaf Arkin" <arkin@intalio.com>, "Ugo Corda" <UCorda@SeeBeyond.com>, <www-ws-arch@w3.org>
Question embedded..

Ricky

At 05:10 PM 12/14/2002 -0800, Assaf Arkin wrote:
>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.

<Ricky>
Does it mean the value of "persistent storage" is so that RM can promise 
the App-A earlier after it persist the message, and release App-A to do 
something else ?

In other words, does it mean if App-A is willing to wait until the message 
is actually delivered (RM-A get an ACK from RM-B), then there is no need 
for persistent storage.
</Ricky>

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

<Ricky>
But it is possible RM-A fail to deliver the message after retry and decide 
to give up.  Does the application still not care ??
</Ricky>

>
>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>http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0rev_c.pdf 
>>>
Received on Saturday, 14 December 2002 20:19:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:11 GMT