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
|