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] Duplicate message responses [was Re: [wsrm] about Request-ResponseMEP]

Doug Bunting wrote:

Splitting this[1] part out to keep the topics somewhat separate.  The issue
here is generally about responding  to duplicate messages and should not be
specific  to the  Request-Response MEP  or Response  RM-Reply  pattern.  It
does, however,  touch on payload content  and whether it  is available when
creating a response to a duplicate  message.  Except to say that my various
payload   inclusion  options  (especially   alternative  A)   may  restrict
situations to which this discussion applies, I will attempt to focus on the
duplicate messages only.

Note  that  existing  implementation  choices  allow  payload(s)  from  the
consumer to be available when a duplicate message is received.  The Respond
operation  does  not  have to  be  invoked  more  than  once when  the  RMP
"remembers" an earlier invocation --  caching, if you will.  There are more
choices than always returning either a SOAP fault or an empty SOAP Body.

Nothing  in section  3.2.2 describes  this important  area of  the protocol
requirements.  (If  other sections of the document  describe the processing
steps or  other semantics involved  in duplicate elimination,  please point
them out!)

We have a number of options for responding to a duplicate message:

a. Require a SOAP fault along with the acknowledgement indication.  This is
incorrect at many levels since duplicate message elimination is part of the
normal  RMP processing.   Such a  fault could  result in  a  SOAP processor
within  the sending  RMP (were  it implemented  using a  generic processor)
passing the  exception up to  the "application" and preventing  this normal
processing.   I  would prefer  *not*  to  disallow  implementation using  a
generic SOAP processor.

This choice is specific to  the Response and synchronous RM-Reply patterns.
The  explicit or  implicit operation  invoked as  part of  the  Callback or
asynchronous pattern (from  the original receiving RMP back  to the sending
RMP)  would likely  not include  a SOAP  fault in  the  outbound underlying
transport request.

This  requirement would  also disallow  "normal" processing  of  producer /
consumer interactions described as one-way.

b. Require a SOAP fault only when payload content is not available.  Again,
this choice is  specific to the Response and  synchronous RM-Reply patterns
and may prevent use of a generic SOAP processor.  Payloads may be available
due to  any caching  the receiving RMP  implementation happens  to provide,
allowing the enhancements Tom mentions.

c. Require  an empty SOAP  Body along with the  acknowledgement indication.
This seems  initially reasonable but may  lead to unexpected  faults, as we
discussed with  regard to RM faults  in general yesterday.   Unlike (a) and
(b), this requirement could apply to all publication methods.

This requirement would  match the sending RMP's expectations  when the WSDL
description of the  operation (as known to the producer,  just to be clear)
is one-way.

d. Require an  empty SOAP Body only when payload  content is not available.
This comes  closest to  meeting the sending  RMP expectations and  will, in
most cases,  result in  an identical response  (however publicized)  to the
original request.


I lean toward  (d) and would prefer such  "caching" be strongly recommended
in  our  specification.   It  may   appear  to  increase  the  RMP  storage
requirements but  supports full round-trip reliability.  This  option was a
MUST in the ebXML Messaging 2.0 document for good reason.

To  summarize, we  have apparently  made it  explicit in  the specification
(section 5.2  as it stands, for  example) that responses may  be lost[2], I
would  suggest we  also mostly  punt  on the  question of  responding to  a
duplicate.  That would avoid an incorrect SOAP fault (which would, in turn,
lead to  extraordinary handling in the  sender RMP for  a normal condition)
and make  the optimal  solution possible.  That  "optimal solution"  is the
same as the choice we have made for the sending RMP (when resending): Store
payload(s) for responses until the  original message has expired and return
them in the appropriate duplicate message responses.

  This is the most appropriate solution, although I'd hesitant to call it "optimal".
  Infact, I suggested the SAME way back in Feb when we had the initial
  discussions in R-R and DE.

  But this solution will result in practical nightmare. Caching 'payload response'
  until the original message expires is very impractical.

  Either sending a SOAP Fault or a RM "Warning' (a special Fault code to
  imply that this is a duplicate message) is the 'optimal' solution.

  Sending an empty SOAP Body is very un-interoperable or impractical as
  it will anyway return in some kind of serialization errors by the underlying
  SOAP Processor. Such a fault will be meaningless to the Sender and may
  not help him in recovering from the "problem".


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