RE: [ebxml-msg] reliability of Responses: a draft of definitions

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

Title: RE: [ebxml-msg] reliability of Responses: a draft of definitions

>Generally, I hope we do not need this many words to explain how ebXML
>Messaging uses WS-Reliability at this level of abstraction.

I'll try to be more terse... my excuse in being verbose is that precisely,
this is a notion of reliability that does not rely much on WS-Reliability 1.1. (out of scope).

>I also suspect the bulk of your email is focused on the synchronous case
>but am not sure that was your intent.

Indeed, only synchronous case. Intent is that it does not sound right to reuse the same definition of reliability for a response as for a request, given the synchronous aspect.

So this is a slightly different definition of reliability for responses, that takes into account the fact that there was an associated (reliable) request.

more inline.

Jacques

-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Monday, September 20, 2004 6:03 PM
To: Jacques Durand
Cc: 'ebxml-msg@lists.oasis-open.org'
Subject: Re: [ebxml-msg] reliability of Responses: a draft of
definitions

Just re-read this one...

Generally, I hope we do not need this many words to explain how ebXML
Messaging uses WS-Reliability at this level of abstraction.

I also suspect the bulk of your email is focused on the synchronous case
but am not sure that was your intent.

On 15-Sep-04 19:24, Jacques Durand wrote:

...

> 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)

Sounds like you are saying "synchronous" essentially means "underlying
protocol MAY be relied upon for implicit correlation between some message
pairs if the space between the messages are short enough"?  In any case,
SOAP request-response seems to have a well-understood definition; I am not
sure why the assumptions you list above are necessary.

<JD> I admit these assumptions (which go beyond the SOAP Request-response definition) have mostly implementation relevance. (1) was assumed to avoid introducing an ebMS-defined correlation indicator at this time (by narrowing the case as binding to a request-response protocol). But it is in fact enough to assume here that a Sender will always be able to correlate response and request no matter how, which can be inferred by the definition of this MEP.(2) can have a big impact in implementing the proposed solution.

...

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

I am not sure this reflects the situation correctly.  As a submitter of
purchase orders, I care just as much about the negative acknowledgements
from my supplier's systems as I do about the (PO) delivery failures from my
platform.  As a receiver of purchase orders, I care just as much about the
goods receipt documents as I do about the (shipment advice) delivery
failures from my platform.  If we are speaking about an asynchronous
interaction, we can both initiate all resends.  What is the rationale for
your statement above?  Is it specific to the synchronous case?

<JD> it is. I concede that "who will be notified of delivery failure" is (has always been) somehow arbitrary - dictated by communication contingencies rather than by business sense. In WS-Reliability 1.1 we do not even attempt to notify a receiver that we failed to deliver to it... (there is some common sense to this). Only the sender is notified. In theh prsent case, when a synchronous response fails to be delivered, it would make sense to notify the party that produced this response. In the proposed definition which involves reliable requests - and where no Acks are sent for a response - the Receiver of a request will know that its response has not been well received when it receives retries of the request

up to exhaustion (cause could be the Ack of the request is lost, but then the sender could still stop resending if the Response is well received). Although this does not give 100% certainty that the response has failed (the last attempt may have succeeded), it is as fair an indicator as using an Ack (the Ack may be lost, and we know that delivery failure actually means "there are significant chances that your message did not reach the other party") . </JD>

I thought we were talking about correlating independent reliable messages
into request-response pairs in the asynchronous case.  That means every
message would have an acknowledgement.

<JD> In case of asynchronous messages, yes. Again, that means we would not use the same criteria to ensure reliability of a synchronous response and of an async. response, but personally I can live with that.

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

Again, I do not understand which case you are covering here.  If you are
covering only the synchronous case, the RM-Replies and the business payload
are tied together into the same SOAP response message.  When the RMP or MSH
receives the acknowledgement, they MUST have also received the payload.

<JD> If we do not narrow the use of WS-Reliability, it is possible to use Callback reply pattern with a SOAP Request-response,as odd as it may sound (not so odd if we have a configuration that bundles callback replies, say for every N reliable messages,

regardless which MEP they were sent on.)</JD>

 If
you are covering the asynchronous case, resends have the semantic meaning
of "send me the acknowledgement, I did not get it".  Going down this route,
we probably need some mechanism to specifically request a missing business
response.

<JD> in async case, I hope we can just reuse the same reliability mechanism as for any
SOAP One-way (including requests)

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

This sounds like a requirement for a Receiving RMP to always implement
duplicate elimination, regardless of the requested semantics.  If and when
this is actually necessary, why not require the Sending RMP to include the
appropriate indication in its request?

<JD> the above behavior is justified regardless of dup elimination: even when the latter is used, we need this caching when doing guaranteed delivery of the response. This means that any repeat of a request should at least trigger the resending of the response, before the request is discarded as a duplicate.

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

What about the asynchronous case?  How does an RMP distinguish between an
asynchronous response and a new (reliable) message?  May a single
asynchronous request result in multiple, distinct responses?  Why not?

<JD>
Q1: async case would be handled by WS-Reliability as is.
Q2: the RMP would not need to know the difference... the RM requirements for any asynchronous message would be known from CPA access (and passedto the RMP the same

way as for any other message submitted via "Submit").
Q3/Q4: we might want to recognize such a pattern if we can add value to it, and again at RMP level, no need to know, because it is asynchronous.

Hope that clarifies a bit (that helped me uncover a few things actually :)

Jacques

...

thanx,
        doug