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

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

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.

...

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

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.

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

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

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

...

thanx,
	doug