[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] clarification on Respond primitive
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. -- ---------------------------------------------------- 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]