[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Duplicate of Delivered Fault revisited
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. > -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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]