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] on the need for a reopening an issue on soap fault withrm fault when no payload

 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

  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,

  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.

  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

  I don't think this is same as the one in v 0.992 as you quoted.

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


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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]