Re: [wsrm] Duplicate message responses [was Re: [wsrm] about Request-ResponseMEP]

Doug Bunting wrote:

All,
  

  

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".

  -Sunil