Re: We need Multi-hop reliable messaging without Intermediate Acks

[christopher ferris <chris.ferris@east.sun.com>]

David/All,

I think that this gets into an area that, quite possibly,
we *haven't* addressed adequately. Namely "reliable" synchronous
response.

The use case that David cites is a synchronous request/response
where the sender of a message is blocking on the channel that
the message is delivered for the response message (which is
an application response, not an RM acknowledgment). 

In this use case, the "intermediary" is in fact NOT an
intermediary, but a To Party. The fact that B is sending
a message to C to obtain payment is governed by a
separate CPA between B and C (the same way that your
local retailer has an agreement with Visa, Master Card
Discover or Amex that is separate from the agreement
that you as a consumer has with your credit card issuer
such as Fleet, CitiBank, etc. which is separate from
the agreement that your credit card issuer has with
Visa, Master Card, Discover or Amex (which, by the way,
is not included in David's use case, but rightly should be!)

However, my point is that in this particular case, with
synchronous messaging, the response is the "acknowledgment".

What is NOT clear to me is why an RM "ack" is needed in this
case (of a synchronous request/response) at all. What
is needed is idempotency. If I have a browser or 
web client that I, as a user, use for a scenario such as
this, then I don't need reliable messaging in the sense
that I need automated retry, persistence, etc. I only
need the assurance that the request is idempotent
(meaning that my account will only be credited ONCE
and that I'll only receive ONE George Foreman Grill
from the Home Shopping Network). Afterall, I can always
hit the submit button again if I so choose (or not
as the case may be if I am thoroughly disgusted with 
the service and couldn't be bothered anymore)

If I don't get a response confirmation (a business
message that says thanks for the business and here's
your confirmation/shipment tracking number) then
it would seem to me that the best way to address this
would be to:
	1) have an alternate path for the confirmation
such as an email, which many if not most e-tailers
use IN ADDITION TO the response web page
	2) use idempotency such that the same request
is not processed twice, but the original response
is returned

Now, the key missing ingredient in all of this
is a separate idempotency feature that is distinct from
OnceAndOnlyOnce *delivery*. The CPA has a separate
idempotent attribute that can be set. This is an
artifact of tpaML, but quite possibly, what is needed
for just this sort of case.

BestEffort + idempotency *could* be specified to
mean that the sender MAY resend the message but that
a duplicate request message received MUST be responded with 
the original response (which could be cached by the 
MSH or reproduced by the application that enforces
the idempotent characteristic of the exchange). 

Maybe what is needed is a separate deliverySemantics
of "synchronousWithIdempotency". Or, as with HTTP,
we could specify that a synchronous request/response
have idempotent characteristics. HTTP RECOMMENDS
that certain methods have this characteristic
(e.g. GET, HEAD, PUT, DELETE) but fall short of 
REQUIRING that all requests using these methods be 
idempotent. From RFC2068:

   9.1.2 Idempotent Methods

   Methods may also have the property of "idempotence" in that (aside
   from error or expiration issues) the side-effects of  N > 0 identical
   requests is the same as for a single request. The methods GET, HEAD,
   PUT and DELETE share this property.

Comments?

Chris

"Burdett, David" wrote:
> 
> Rich
> 
> See comments inline
> 
> David
> 
> -----Original Message-----
> From: Rich Salz [mailto:rsalz@caveosystems.com]
> Sent: Thursday, January 25, 2001 11:49 AM
> To: Burdett, David
> Cc: ebXML Transport (E-mail)
> Subject: Re: We need Multi-hop reliable messaging without Intermediate
> Acks
> 
> > but I've just thought of a use case
> > involving synchronous messaging using HTTP where I think you absolutely
> MUST
> > have it. This is described in the attached PDF file.
> 
> Seems to me that the 'payment received' message is really an app-level
> message, and that your example doesn't quite hold.
> <DB>The payload of the message, i.e. the payment receipt comes from an
> application. However it needs to be wrapped in an ebXML envelope to be sent
> so it is still an ebXML message IMO.
> In order to do reliable messaging, you also need to resend the original
> payment message if no response is received, which then needs to be filtered
> for duplicates by the receiving MSH and the lost response resent. If the MSH
> doesn't do this standard reliable messaging behavior then the application
> has to which means it is duplicating functionality that is in the MSH which
> doesn't make sense.
> 
> So I think the example does hold. Can you explain why it does not?</DB>
> 
> I do believe there might be a need for intermediate acks and final acks,
> which is why I suggested the sender be able to 'keep the connection
> open' until acks have gone as far down as desired.  (The message where I
> talked about "three cases.")  I also think it's very complicated and
> would profile it as an optional feature for 1.0
> <DB>If you allow reliable messaging without intermediate acks, then you
> don't need to hold the connection open and it is actually a simple solution,
> IMO.</DB>
> 
> Your example also brings up an interesting point, about return paths,
> particularly where the POC wanted replies to go back via the same path.
> If that *stays* as a POC requirement, we should probably explicitly say
> that it can't be met. :)
> <DB>I think the POC requirement to send replies back by the same path can be
> met and the current spec describes how to do this. Can you explain why it
> can't be done?</DB>
>         /r$
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard