+1.
We have discussed this issue pretty extensively during the F2F
and the consensus was that levels of persistence/crash tolerance
was out-of-scope. "persistence" is must for RM. If vendors want to
do vendor-sepcific extensions, they are more than welcome to do
so.
For this version, we should just assume "message persistence".
-Sunil
Jun Tatemura wrote:
> 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 message
> ordering). If it is true, the specification "mustpersist=false" does not make sense
> since, without message persistance, WS-RM does not provide any reliability.
> (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 / policy)
> (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,...
>
> ---
> Junichi Tatemura
>
> ----- Original Message -----
> From: "Paolo Romano" <>
> To: <>
> 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 http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php
> >
> >
