Re: [wsrm] What about this tradeoff solution for the persistence issue?

["Jun Tatemura" <tatemura@ccrl.sj.nec.com>]

Paolo,

I realized that we don't have a consensus on the meaning of  "persistence."

In my message, "message persistence" refers to 
"ability to preserve message content and/or status information
as long as it is required to achieve reliable messaging."

Note that it does not mean memory volatility.
Through the f2f discussion we realized that volatility is
an implementation feature.

So the phrase "stored in a non persistent way" in your message
can be restated with the above definition as "stored in a non volatile way"

I hope now you understand what I meant by "WS-RM relys on message persistence"

Junichi Tatemura

----- Original Message ----- 
From: "Paolo Romano" <Paolo.Romano@dis.uniroma1.it>
To: <wsrm@lists.oasis-open.org>
Sent: Monday, June 09, 2003 11:34 PM
Subject: Re: [wsrm] What about this tradeoff solution for the persistence issue?


> As Sunil pointed out we exstensively discussed about this point in F2F, but I do
> not think we reached an agreement. In fact, also when the protocol state (i.e.
> the information concerning the exchanged messages) is stored in a non persistent
> way, some additional reliability guarantees are still provided by ws-rm, when
> compared to classic TCP based protocols: that is, applications relying on ws-rm
> are guaranteed that their messages will be delivered in face of communication
> channel failures. This use case is common in wireless environments, and was
> originally presented by Nokia members.
> 
> Even when you choose to persist, in fact, ws-rm still can fail to provide
> reliable messaging, simply because, whatever redundancy you can imagine, you
> still cannot exclude a priori the event of persistent storage failures.
> In other words, since ws-rm is not a stateless protocol, it can not be crash
> tolerant in case of persistance storage failures.
> 
> If I look at WS-RM from this point of view (i.e. if I consider WS-RM as a
> protocol which, also when persisting, can provide a "limited" level of fault
> tolerance) and since some members agree that WS-RM could be used in environments
> with high probability of communication failures, but very simple hardware (i.e.
> no persistance), I do not see any harm in formalizing within the specification
> an optional behavior for rm-processors which allows them, on demand, not to
> persist messages, as long as the ws-rm users are aware of it, and of its
> implications.
> 
> Reliability IS NOT crash tolerance. Reliability is the ability of a process to
> carry on succesfully its task, despite the event of failures. It is up to us
> deciding what the process task is, and what failures will be tolerated.
> I believe we can not find an agreement because we do not even agree on this.
>