Re: [wsrm] clarification on Respond primitive

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

Tom Rutt wrote:

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.

 the current text already says that both SOAP Fault and RM Fault need
to be
 sent. See:

        In case of a Response RM-Reply Pattern was required, and when the message cannot
be delivered to the Consumer due to a failure in processing the RM headers, then a
SOAP Fault MUST be generated in addition to the RM-Reply that contains the RM Fault.
Because either a well-formed response or a SOAP Fault is expected on the sending
side, then the response leg of the transaction MUST contain a SOAP Fault in the SOAP
Body when no business response is available. More details are given in the HTTP
Binding section.

 
 As I said before, first of all, I don't see a use case that such a scenario happens.
 Even if so, we should avoid sending both as I listed the problems in of my previous
 mails in this thread.

 I believe I convinced Jacques that this is not a good idea to send both on Friday.

 

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