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

[Doug Bunting <Doug.Bunting@Sun.COM>]

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.

thanx,
	doug

[1] I am  responding to both of the following comments  made earlier on the
"about Request-Response  MEP" thread.  I am  not sure exactly  where Tom is
going (beyond our existing abstract Notify operation) in (2) but agree with
the general "do not disallow" stance he outlines in (1).

On 09-Jun-04 15:50, Tom Rutt wrote:

On a tangential matter, with  the duplicate elimination with response reply
pattern, I though of another set of behaviours which should be allowed:

1) The receiving RMP could provide its own QOS enhancements, where it would
buffer the previous response, and just  resend that response in the case of
a duplicate invocation.   Surely this is desired behaviour,  and should not
be disallowed by the spec.

2) in  the absence  of having  a response  to send  back for  the duplicate
invocation, we could just have the protocol allow the Receiving RMP to just
not send any return message in this  case. The Sending RMP is the one doing
the  resend, so  if it  got an  ack to  the preceding  invoke it  would be
happy. In the rare case where the  original response was lost (say due to a
transport connection going down due  to a backHoe incident) the sending RMP
state machine  would eventually time out  and it could to  invoke a special
(api  specific)  notification  operation  to the  Submitter.   This  simple
solution should also be allowable behaviour.

On 09-Jun-04 00:11, Jacques Durand wrote:

NOTE:  For [non-expired]  duplicates with  response reply  pattern, because
there is no "Deliver" and "Respond" invocations, the issue remains the same
as previously: the RMP generates an  RM Reply with either an empty body, or
a SOAP Fault. To be decided.

[2] I  remain unclear what "does  not support reliability  of WSDL response
messages" means but "responses may  be lost without notice" seems close and
troubling.   My earlier alternative  B provides  some level  of reliability
through its direct link of RM-Replies with any provided consumer payload(s)
and alternative  C is entirely  unreliable with respect to  the payload(s).
In any  case, the quality  of service offered  sits on a sliding  scale and
"does  not  support"  seems extreme.   I  also  believe  too many  MEPs  at
different levels  of abstraction and in different  wire-level exchanges are
involved to talk  about the reliability of responses  in general.  However,
that point is somewhat tangential to the issue at hand.