[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?
+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" <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 http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]