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