reliability of Responses: a draft of definitions

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: reliability of Responses: a draft of definitions

Here is my recollection of what can be said about reliability of Responses.
(a complement to previous email, focusing on the reliability definitions)

Reliability of Response messages, in synchronous ebMS request-response MEPS:
============================================================================

NOTE 1: A "synchronous" ebMS request-response MEP maps to a SOAP Request-response MEP.
We make the following assumption on the  way a SOAP Rrequest-response is processed:
(1) the SOAP processors (Sender, and Receiver) can correlate the request and response without
a need for special correlation indicators in message SOAP header. This is the case when binding to an
underlying protocol like HTTP.
(2) the round-trip time to complete a request-response, is relatively short (not long-lasting transactions)

NOTE 2: Reliability of the Response leg of a SOAP Request-response MEP (called hereafter the "Response")
is not supported by WS-Reliability today, but we show here that it can easily be supported by the layer above - e.g. an ebMS MSH. This is because the definition of reliability does not need be quite the same for a Response as for a Request,

in SOAP Request-response MEPs.

NOTE 3: Terminology: we call "Producer" the submitter of a Request message (to the Sender message handler).
We call "Consumer" the party to which the Request message is delivered (by the Receiver message handler).
For the Response leg of a DOAP Request-response, the Consumer submits the Response to the Receiver message handler.
The Sender message handler delivers the Response to the Producer party.
This terminology was used in WS-Reliability. We extend it to ebMS
(e.g. the Producer is submitting the Request to the Sender MSH, etc.)

Guaranteed delivery of a Response:
----------------------------------

The guaranteed delivery contract for a Response, is as follows:
(1) guaranteed delivery for the Request is enabled, and
(2) when a Request has been sent, a Response should be obtained by the Sender before a timeout,
or else an error is notified to the request Producer (sender side) by the Sender message handler.
-The round-trip timeout countdown will start after the Request is acknowledged.
-Protocol-wise, when no response is received in time after a Request has been acknowledged,
an additional message resending technique SHOULD be used for the Request (allowing for resending the Response).

NOTE 4: no Ack is used for the Response leg, and no independent automatic resending of the response alone , are needed.
Rationale: Acks mostly make sense for the party that initiated the transaction (and the one that can initiate a resending).

In this case, the transaction initiator and re-sender is the sender of the Request, not the sender of the Response.
The Receiver MSH (sender of the Response)is generally not able to initiate a Response re-sending alone, due to Request-response protocol constraints.

NOTE 5: Regarding ebMS using WS-Reliability/RMP: The "lazy" option (as soon as the Response times out, the Receiver MSH
notifies delivery failure and does not try to resend the Request) is quite easy to enforce by the MSH.
It is however preferable that some additional resending be done in case no Response is received in time,
meaning that an RMP implementation will be asked to do more (while remaining compliant to WS-R):
the same message ID should be used for this Request resending (i.e. after it has been Acknowledged) in order for
duplicate elimination to work. So this resending cannot be initiated by MSH level, but instead by the RMP.
This means that an RMP should be able to do resending not just based on the lack of Acks, but also on lack of (synchronous) Response (when asked to do so by MSH).

If a Response was successfully produced on Receiver side, it should be cached/queued for a reasonable time in case
the Response fails to be delivered back. A retry mechanism would then have the Sender retry the request,
and the cached Response would be sent back. So even if more than one copy of the Request message is delivered to the Consumer

(due to absence of duplicate elimination) then the first response would be the one sent back (we cannot assume the Request

messages are idempotent on Receiver).
Note that this is exactly the same MSH persistence mechanism that would support a "Pull" message mode.

Duplicate Elimination of a Response:
------------------------------------

The duplicate elimination contract for a Response, is defined as follows:
(1) duplicate elimination of the Request is enabled,
(2) when a Response is received by the Sender and delivered to the Request Producer, then no other Response correlating

with the same Request will ever be delivered to the Request producer.

NOTE 6: this assumes the Sender message handler can correlate its Requests and Responses, which is expected in
a SOAP Request-response MEP. Response duplicate eimination is quite easy to enforce at MSH level:
as soon as the Sender of a request got its response and delivered it, this request can be "forgotten",
even if it has been resent several times and some of these retries still wait for a response.
When a response arrives on Sender that does not correlate to any pending (i.e. remembered) Request,
it means it can be discarded (likely a duplicate).
No sophisticated persistence is required: pending requests will not need be remembered for long (due to
synchronous character of response and short timeout). If there was a long time allowed between request and response,
then an async communication would be more appropriate, where each request and response is treated as separate one-ways
and suject to RMP duplicate elimination.

Message Ordering for Responses:
-------------------------------

The ordering contract for an ebMS synchronous Response, is defined as follows:

(1) Ordering is based on the order of Request submission (by the Producer), NOT of Response submission (by the Consumer):

Response payloads must be delivered to Producer (sender side) in the same order as the Requests
have been submitted by this same Producer (to the MSH).

NOTE 7: A simple way to enforce this, is to not send an ebMS Request message before the previous Response was received.

A second option, more efficient, would have the MSH enforce pipe-lining on Sender side: Response messages would be
delivered by Sender MSH to its Producer in same order as the requests have been submitted to this MSH.
Requiring ordered delivery for the Request will also help achieve this, (is RECOMMENDED).
The other alternative - enforcing ordered delivery of the Response based on submission of the Response on Receiver side

instead of the submission of the Request on Sender side, does not seem to correspond to any business requirement.

Conclusion:
-----------

These definitions of Reliability for Responses can be enforced by the Sender MSH with modest effort
(at least for the "easy" option of each one of them).
They can be implemented in MSH without duplicating RMP functionality.
The resending mechanism for Response guaranteed delivery, if delegated to the RMP, represents an upgrade of the RMP
(yet implementation level: compatible with spec.)
The above definitions mostly leverage the reliability of the Request which is supported by the current version of WS-Reliability, and the fact that a Response always correlates with a Request.

NOTE 8: These definitions of reliability also apply to the "pull" ebMS MEP, where an ebMS signal is sent to get a (synchronous) business response.