OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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]