Re: [wsrm] on the need for a reopening an issue on soap fault withrm fault when no payload

[Tom Rutt <tom@coastin.com>]

Sunil:

I quote from draft .992 again below (remember the only time soap fault 
is sent with rm-fault is when reuired response
paylod is not availabale"  There was editing of this text but the quoted 
paragraph is directly from .992 draft.


It is only in the case of missing return payload that this behaviour is 
called for.

This is why I am upset of the late (even June 10th is much after the 
.992 public comment draft comments closed)
concern.  Is it so important to change.  I have trouble seeing a problem 
in implementing a Sendingn RMP with
this behaviour. 

What would you prefer to be the behaviour


Sunil Kunisetty wrote:

>
>  Tom,
>  
>  Please read this mail completely.
>
>  I'm not sure why you think I'm raising this issue in the eleventh hour.
>  I raised this issue on June 9th itself [1] when I  first read this 
> paragraph.
>  And subsequently there were many discussions on this topic. Also, Doug's
>  summary mail clearly lists this as an issue (4(a)).
>
>  Note that the current thing is not the same as v0.992 [2] as you 
> suggested
>  in one of your mail.
>
>  v 0.992 [2] suggested that [lines 1019 - 1024]:
>
>            /The SOAP Fault model is used for reporting faults due to
>     the request payload, which fits the
>     SOAP fault model better. Thus a response may have a SOAP Fault
>     message, but the reason for
>     the SOAP fault would be due to problems associated with the WSDL
>     operation message
>     payload. (E.g., A problem with the soap:body of a request message
>     or the inability of the
>     receiving RMP to return the WSDL response in the soap:body of when
>     using the Response RMReply
>     pattern)./
>
>
>   As you notice above, there is no mention of the word RM Fault or 
> combination of RM Fault
>   and SOAP Fault.
>
>   I believe it got crept into either 1.01 version or few versions 
> before based on some comments
>   from Mark Peel and Doug Bunting,

The paragraph was editied and refactored, but the behaviour was there in 
.992.

>
>   As such there was no issue raised and it got crept inside as an 
> editorial update (may be with
>   few discussions).
>
>   It could be that I may not have raised it immediately after the 
> first draft containing this paragraph.
>   But then during the 1.01 version X days, there was draft every other 
> hour and no way I could
>   have caught up with it. Do note that this work is just part (10 - 
> 155) of my job and have many
>   other things to do. Inspite of that, I do read it as often as 
> possible and send comments. I did raise
>   this issue on June 9th itself [2] and infact I did start that mail 
> with a disclaimer that I'm catching up
>   with the email.

It was in .992, which you had 30 days to review.

>
>   The current text reads [3] (Lines 1083-1088):
>
>               When the Response RM-Reply Pattern is in use and the
>     message cannot be delivered
>     to the Consumer, the underlying protocol response of the SOAP MEP
>     instance MUST
>     contain a *SOAP Fault (in the SOAP Body) in addition to the
>     appropriate RM Fault (in
>     the SOAP Header). *The Sending RMP and Producer expect either a
>     complete
>     response or a SOAP Fault when using the Response RM-Reply Pattern
>     and this
>     requirement satisfies those expectations. More details are given
>     in the HTTP Binding
>     section.
>
>   I don't think this is same as the one in v 0.992 as you quoted.

from .992
lines 1043 thru 1047 of draft .992
"
When a receiving RMP cannot return the WSDL operation response for a 
request using the
Response Reply Pattern, it MUST return the RM Response in a SOAP Fault 
message. If the RM
Fault encountered was due to a problem with the request header element, 
a SOAP client fault
MUST be returned. If the RM Fault encountered was due to a problem with 
processing by the
receiving RMP (including the inability to return a response due to 
Duplicate Elimination), a
soap:server fault must be returned.

>
>   As I mentioned in the first mail [1] and subsequent mails, *the 
> biggest concern I had is
>   sending both RM Fault and SOAP Fault together (see the usage of the 
> word 'in
>   addition to').*
>
>  I did asked in that mail [1], is this comment specific for DE case or 
> generic case.
>
>  In the subsequent mail [4], I replied that
>  I don't see a need to send both RM Fault and SOAP Fault as both imply 
> the same,
>  In the same, I clarified sending both is not good.
>
>  Do note that I never insisted that it be only RM Fault, although I 
> preferred this than just
>  sending SOAP Fault.  My biggest concern has been sending both. I 
> explained in that mail [4],
>  why sending both is wrong.
>
>  Now, why I preferred sending RM Fault than SOAP Fault:
>   1) Consistent with other RM  faults.
>   2) Will be consistent when used with other patterns (Callback and Poll)
>        even for a WSDL 1.1 R-R operation.
>   3) Sending a RM Fault (in a SOAP Header) with an empty SOAP Body is okay
>       just as in other RM Fault cases as the response is not directly 
> handled by the Producer,
>       but rather '*intercepted*' by the Sending RMP. Sending RMP will 
> then throw an
>       exception or a Fault to the User which is what it would have 
> done with the SOAP
>        Fault anyway.
>    4) Sending a RM Fault in a SOAP Header is still BP/WSDL compliant 
> for Response
>         pattern (for a WSDL R-R operation) as it is still encapsulated 
> within a  SOAP
>        envelope. Note that WSDL 1.1 says that Response should have a 
> SOAP output,
>        doesn't insist that it have a SOAP Body, although it is good to 
> have one.

What would you propose we put in the soap body in this case of an rm 
fault and no response
payload (even if the response payload is defined in the WSDL for the two 
way operation).  Do you
propos an empty soap body, even though the wsdl stated the soap body 
should be populated with
the response payload?  This disobeys the wsdl contract for the operation.

>    5)  As we discussed and decided earlier, our RM-Reply way of 
> sending RM-Fault is
>         alternate to the SOAP Fault model.

The special case has two faults for two different sending roles, the rm 
fault is targeted to the
sending rmp while the soap fault (to signal missing response payload) is 
targeted to the producer.

>     6) And finally do note that a WSDL 1.1 R-R operation may or may 
> not have the
>         <fault> message defined  in it as the <fault> definition has a 
> minOccurs=0. In that
>          case sending a SOAP Fault is equally bad as sending an empty 
> SOAP Body.
>          Also, if the Receiving RMP has to send SOAP Fault only when 
> there is a <fault>
>          definition,  then it will un-necessary create a dependency to 
> understand wsdl which
>          we don't want to do.

A wsdl client for a request/response operation
must always be prepared to receive a soap fault.  My concern is that it 
may not be prepared to
receive an empty soap body

>  
>    But again I'm okay just sending the SOAP Fault as was during the 
> pre v 0.992 days
>    It's just that I don't want to send both. Between sending only RM 
> Fault or SOAP Fault,
>     I prefer the former as I think it is a lesser evil.
>
>    While discussing this with Jacques, we also found out that our 
> spec. is not clear what
>    will be the response for a WSDL 1.1 R- Operation with a Callback or 
> Poll Reply pattern
>    when a Duplicate elimination occurs. As per the current proposal, 
> RM-Fault is sent
>    to the Callback listener or as the Poll response, but what should 
> be the response for
>    the initial request???  
>
>    Seems like we haven't covered this issue.
>
>   Hope this clarified and explain my position.

You still have not suggested the solution you want.  Do you want an 
empty soap body in this special case
of no available response payload?

Tom Rutt
(not as chair but as member)

>
>  -Sunil
>
>  [1] - http://www.oasis-open.org/archives/wsrm/200406/msg00085.html
>  [2] - 
> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5999/WS-Reliability-CD-0992.zip
>  [3] - 
> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7454/COntribution-JD-WS-Reliability-2004-06-21.pdf
> [4] - http://www.oasis-open.org/archives/wsrm/200406/msg00115.html
> Tom Rutt wrote:
>
>> Sunil has, in his emails on the subject
>> The mails I've sent on this thread:
>>    http://www.oasis-open.org/archives/wsrm/200406/msg00085.html
>>    http://www.oasis-open.org/archives/wsrm/200406/msg00108.html
>>    http://www.oasis-open.org/archives/wsrm/200406/msg00110.html
>>    http://www.oasis-open.org/archives/wsrm/200406/msg00115.html
>>    http://www.oasis-open.org/archives/wsrm/200406/msg00117.html
>>
>> made the point that the sending rmp can intercept the rm fault and 
>> deliver the fault to the producer, without a soap fault.
>>
>> I think this is a valid implementation, but if the soap fault is 
>> signalled to the sending rmp it still extracts the wsrm:response from
>> the header and can do the same thing it would do if the soap body is 
>> empty.
>>
>> I am sorry, I have read these mails three times, and I still do not 
>> understand the problem with the behaviour
>> we have in the spec regarding sending the rmfault in a soap
>> header with a soap fault when there is no payload to put in the soap 
>> body.
>>
>> Tom Rutt
>>
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133