[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] clarification on Respond primitive
Sunil Kunisetty wrote: > > Before answering this question, I'll ask the same qn. I'm asking in > the last 2 mails. > In what scenarios we have to send both RM faults and SOAP Faults. In > fact, > in what scenarios both these faults occur? Sunil: the current text uses an RM fault to signal to the Sending RMP that the message was not delivered due to a faulure in Reliable message processing. This is our fault code, and can be returned with all three reply patterns. We are arguing whether we also need a soap fault, directed to the procucer of the request/response exchange. This is the one which several developers last week told us they want to have, rather than an empty soap body. Tom Rutt > > If there are such scenarios, we could then discuss how to do it? If > not, it becomes mutes > to even discuss it. > > -Sunil > > Tom Rutt wrote: > >> Sunil; >> >> are you proposing that when we send an rm fault in response reply >> pattern, we always send an empty soap >> body, rather than a soap fault? >> >> Sunil Kunisetty wrote: >> >>> Tom Rutt wrote: >>> >>>> comments inline >>>> >>>> Sunil Kunisetty wrote: >>>> >>>>> Tom Rutt wrote: >>>>> >>>>>> The reason to send both is that one is targeted to the sending >>>>>> RMP the other is targeted to the consumer. >>>>>> >>>>>> It does not hurt to send both in this case. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I think it hurts. I'm a big proponent of not sending information >>>>> when not needed,. I believe in >>>>> not sending unnecessary and duplicate information as it will >>>>> cause confusion, mutual conflict, >>>>> unnecessary bandwidth etc. >>>>> >>>>> Specifically the problems I see in this case are: >>>>> i) The duplicate message may either be triggered by the RMP >>>>> itself or accidentally by the >>>>> application itself. Most likely by the former because of >>>>> Guaranteed Delivery. In that case, >>>>> RMP itself is the consumer, so sending separate faults >>>>> doesn't make much sense. >>>> >>>> >>>> >>>> >>>> duplicate invocation is not an rm fault, it gets acked for an rm >>>> reply. >>> >>> >>> >>> I was referring to the SOAP Fault based on the *current* proposal. >>> But that's not the main >>> point here. My main point is: A*re they any cases where we need >>> to send both RM and >>> SOAP Faults?* >>> >>> >>> >>>> >>>>> ii) Just saying "send a SOAP Fault" is very bad for a spec. as it >>>>> is not interoperable. >>>>> We need to be very specific about the Fault information to be >>>>> sent. Is it Client/Sender or >>>>> Server/Receiver or what sub-code etc.? >>>> >>>> >>>> >>>> >>>> we used to say that it is a client soap fault if it is message >>>> formatn category, >>>> a server soap fault if it is message processing >>>> >>>> Perhaps that text went away in Jacques. edits? It should be there >>>> >>>>> iii) In most cases, the Sending RMP will formulate a >>>>> Fault/Exception to the Consumer if >>>>> required based on the RM fault itself. A combination of RM >>>>> Fault and SOAP Fault >>>>> could be problematic in such cases as they could conflict. >>>>> >>>> Well we do not have a body to send back since we did not delivery >>>> the message, so the >>>> sending rmp does not know what to put in the soap body. Are you >>>> proposing that for response reply >>>> pattern we send empty soap body with rm reply header? >>>> >>>>>> >>>>>> Tom Rutt >>>>>> >>>>>> Sunil Kunisetty wrote: >>>>>> >>>>>>> Tom Rutt wrote: >>>>>>> >>>>>>>> whenever the request causes any rm-fault, it cannot be >>>>>>>> delivered to the consumer. All RM faults >>>>>>>> have this property that for response reply pattern no response >>>>>>>> payload is avialable, unless >>>>>>>> the sending RMP caches prior responses. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> In this case, we will be semding a SOAP Envelope with one >>>>>>> Header (that has the RM Fault) and >>>>>>> with no SOAP Body. >>>>>>> >>>>>>> The specific qn. I've is in what cases, we need to send BOTH >>>>>>> SOAP Fault and a RM Fault? >>>>>>> >>>>>>> I can't think of any. >>>>>>> >>>>>>>> Tom Rutt >>>>>>>> >>>>>>>> >>>>>>>> Sunil Kunisetty wrote: >>>>>>>> >>>>>>>>> Tom Rutt wrote: >>>>>>>>> >>>>>>>>>> This section is about rm faults. >>>>>>>>>> >>>>>>>>> Ok. if it is not about DE and generic Faults, what is the >>>>>>>>> chance that BOTH RM Fault and SOAP Fault >>>>>>>>> need to be sent. I can't think of any cases myself. >>>>>>>>> >>>>>>>>> Even if there are few chances, since it is not for all >>>>>>>>> cases, we have to say "*the underlying protocol >>>>>>>>> response MUST contain a SOAP Fault (in the SOAP Body)_ if >>>>>>>>> exists one _ in addition to the >>>>>>>>> appropriate RM Fault (in the SOAP Header).". >>>>>>>>> >>>>>>>>> >>>>>>>>> * >>>>>>>>> >>>>>>>>>> The clarification about duplicate elilmination needs to go in >>>>>>>>>> section 4, where duplicate elimination >>>>>>>>>> element is defined. >>>>>>>>>> >>>>>>>>>> There we have three options, which are up for debate: >>>>>>>>>> 1) allow the receiving rmp to cache the earlier response and >>>>>>>>>> send it with the ack for the duplicate incoke >>>>>>>>>> 2) allow the receiving rmo to send nothing in the soap body. >>>>>>>>>> Since the sending RMP was responsible for the second invoke, >>>>>>>>>> it can filter out the second ack with the empty body. It >>>>>>>>>> will not deliver it to the sender. There is a small case >>>>>>>>>> where the original response is lost, in which case the sender >>>>>>>>>> does not get the response. This would be >>>>>>>>>> the case with sending a soap fault as well. >>>>>>>>>> 3) send a soap fault with tha duplicat ack. This bothers >>>>>>>>>> some, since it is not a fault condition, and the >>>>>>>>>> sending rmp can filter out the second ack and not deliver it. >>>>>>>>>> >>>>>>>>>> Tom Rutt >>>>>>>>>> >>>>>>>>>> Sunil Kunisetty wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> 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. >> >> >> >> >> >> >> > > > 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@us.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]