OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

> I don't understand why we should specify
> the crash tolerance level in a message.
> My understanding is that WS-RM relys on message parsistance to achieve
> the three functionalities (i.e., guaranteed delivery, duplicate elimination, and
> ordering).  If it is true, the specification "mustpersist=false" does not make
> since, without message persistance, WS-RM does not provide any reliability.

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

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.

> (Of cource, the level of persistance reliability may differ from main memory to
> hard disks.)
> If "mustpersist" is meant to specify the level of persistance reliability,
> the boolean is too simple -- the level of persistance reliability is not
> all-or-nothing.
> Moreover, even if we can specify crash torelance in a message,
> we still need some agreement before establishing reliable messaging
> (such as retry interval, maximum time-to-live, ...).

> My opinion is that we should use a (yet-to-come) standard for (service level /
> (description / agreement / negotioation), which is orthogonal to WS-RM.
> Since we can't expect such a standard within our timeframe, all we can do
> is to list up what sender/receiver should agree on (how to agree should
> be out-of-scope), such as message persistance reliability, retry interval,...

I agree with this point, we do need such a protocol. While we are waiting for
it, we should point out what are the parameters/capabilities to be negotiated.
Anyway, while we are waiting for a standardized solution to our problem, we may
still allow some simple configuration options (e.g. <mustpersist>) to be decided
at run-time, on sender's demand. Also when the negotiation will be performed in
a standard way, we will still need a mechanism to report errors when one of the
end-points does not respect some agreed parameters.

> ---
> Junichi Tatemura
> ----- Original Message -----
> From: "Paolo Romano" <Paolo.Romano@dis.uniroma1.it>
> To: <wsrm@lists.oasis-open.org>
> Sent: Monday, June 09, 2003 5:15 PM
> Subject: [wsrm] What about this tradeoff solution for the persistence issue?
> >
> > Persistent storage usage is the default mode.
> > An apposite <mustpersist="false"/> tag is used when applications do not require
> > a crash tolerance reliability level, but only tolerance to transport layer
> > failures.
> > In case a device which is not able to persist a message receives a message
> > without the <mustpersist="false"> element, a fault message MUST be sent in
> > response, indicating the inability of the receiver to assure required
> > reliability guarantees.
> > In that case it is up to the application layer to decide whether to send again
> > the same message requiring a lower quality of service.
> >
> > It seems to me to be very simple, needs only to define two reliability levels:
> >              (non-destructive) crash tolerance
> >              transport layer (communication channel) failure tollerance
> >
> > By default <mustpersist="true"> even if not specified since it is the most
> > common use case.
> > No need for negotiation, reliability level is estabilished by the sender, and
> > possibly refused by the receiver.
> > ..
> > And cell phones users (and surely mobile developers too!) will be happy not
> > being bothered anymore by disconnections when driving into tunnels!
> >
> > Comments?
> >
> >
> > --
> > Paolo Romano
> >
> >
> >
> > You may leave a Technical Committee at any time by visiting
> >
> >

Paolo Romano

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]