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