[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Duplicate of Delivered Fault revisited
Tom Rutt wrote: > Sunil Kunisetty wrote: > > > Tom, > > > > Could you explain what idempotent means in R-R operation case which is > > essentially a combination of 2 one-way messages? > > > > It is clear what it means for a (one-way) message, but I always have difficulty > > in understanding it in terms on R-R case. > > > > > Simple you have a debit transaction, which gives the new ballance in the > response. > > I want to make sure it gets there, but I do not want it to take money > out of my account twice. > I was not really looking for an use case, rather the definition and semantic meaning of this. To me, R-R and idempotency doesn't really jell well at the container level and any such requirement should be in application logic. > > > -Sunil > > > >Tom Rutt wrote: > > > > > > > >>Sunil Kunisetty wrote: > >> > >> > >> > >>>Tom, > >>> > >>>Good observation. For similar reasons, I didn't want to have batching of Acks > >>>on R-R. Infact, for all these reasons, I never wanted (or rather was never > >>>enthusiastic about) RM support for WSDL 1.1 R-R operations. > >>> > >>>So we have couple of choices here: > >>>0) Remove RM support completely for WSDL 1.1 R-R operations > >>> > >>> > >>> > >>> > >>Unacceptable > >> > >> > >> > >>>1) Or , say DE doesn't make sense for R-R operations > >>> > >>> > >>> > >>> > >>unacceptable, this is a main reason to use it, to protect non > >>idempotent ops > >> > >> > >> > >>>2) Or, create a new thing called 'warning' (like ack and fault) and > >>> for R-R DE case, deliver the msg. to the destination and send the > >>> response along with the 'warning'. > >>> > >>> > >>> > >>> > >>will not protect agains non idempotent operations. Not acceptable > >> > >> > >> > >>>3) Or, just send a Http response back (i.e., response doesn't have any SOAP > >>> envelope or just SOAP envelope with no body/header/attachment entries. > >>> > >>> > >>> > >>> > >>This will confuse the soap/wsdl processor, which is expecting a soap body. > >> > >> > >> > >>>4) Or, create a new fault for DE for R-R case and send the fault... > >>> > >>> > >>> > >>> > >>I believe this is the best soluction. It is a fault condition, since > >>the rmp has nothing to put in the soap body to obey the wsdl contract. > >> > >> > >> > >>>The problem with 4 is that, if the Ack & Response was lost on the first invocation, > >>>he cannot ever get the response unless he changes the Message Id. > >>> > >>> > >>> > >>> > >>That is ok, since we are not offering relibility on the response. > >> > >> > >> > >>>I prefer (0), but I know it will be too drastic and critical at this stage. If not (0), I > >>>prefer (4). > >>> > >>>-Sunil > >>> > >>>Tom Rutt wrote: > >>> > >>> > >>> > >>> > >>> > >>>>I have come up with a scenario, that makes me want to reconsider sending > >>>>an ack for a dupcate of delived message. > >>>> > >>>>Suppose we have a wsdl , non idempotent, request response operation type > >>>>which the user wants to protect with ws-reliability. > >>>> > >>>>Lest look at the response reply patern . > >>>> > >>>>So if the first time the operation is invoked, the receiver will deliver > >>>>it, and the operation response will carry the rm ack. > >>>> > >>>>Now if the sender gets nervous and resends just before it receives an > >>>>ack, it will be detected as duplicate, by the receiving rmp. Now > >>>>the receiving rmp must not deliver this second operation invocation to > >>>>the receiving app, so what does it put in the soap body for > >>>>this response. We are calling it a rm ack, so we will not trigger a > >>>>fault condition. > >>>> > >>>>What would happen if the body was empty, with no indication of faulut in > >>>>the ws response header. > >>>> > >>>>Perhaps we should return a "duplicateOf Delivered" fault code to convey > >>>>the situation in an unambiguous manner. > >>>> > >>>>-- > >>>>---------------------------------------------------- > >>>>Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com > >>>>Tel: +1 732 801 5744 Fax: +1 732 774 5133 > >>>> > >>>>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php. > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>-- > >>---------------------------------------------------- > >>Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com > >>Tel: +1 732 801 5744 Fax: +1 732 774 5133 > >> > >>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php. > >> > >> > > > > > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to 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]