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: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
