RE: We need Multi-hop reliable messaging without Intermediate Ack s

["Burdett, David" <david.burdett@commerceone.com>]

Chris

See comments in line.

David

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Thursday, January 25, 2001 1:38 PM
To: ebXML Transport (E-mail)
Subject: Re: We need Multi-hop reliable messaging without Intermediate
Acks


David/All,

I think that this gets into an area that, quite possibly,
we *haven't* addressed adequately. Namely "reliable" synchronous
response.
<DB>I had the goal of supporting synchronous reliable messaging in the 0.92
version of spec.</DB>

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). 
<DB>Agreed</DB>

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!)
<DB>The use case you describe is completely valid. However there is an
equally valid use case where the intermediary is not the To Party.
Specifically this would be where Party C is Party A's bank, and Party A
wants to send the payment request to his bank (i.e. Party C). In this case
Party C is the To Party and Party B is just the intermediary.</DB>

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)
<DB>Resending of messages by the user is OK for payments that are initiated
using a GUI in a web browser. However you could use a HTTP client without a
web browser. For example suppose Intuit adapted Quick Books so that they
could do a payment direct from Quick Books. In this use case you would
benefit from Reliable Messaging as it would not require the user to resend
the message manually.</DB>

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
<DB>I agree. However in this case I would expect this to be an application
level generated response that occurs after the payment has been registered
in the payment system. You could also argue that if you have an XML document
as the payment receipt, then a separate email is no longer necessary.</DB>
	2) use idempotency such that the same request
is not processed twice, but the original response
is returned
<DB>But isn't this processing **exactly** like the ebXML RM processing for a
receiving MSH. I don't see the benefit in forcing the application to do this
type of processing when the MSH already contains all the logic and
processing to do it anyway. In fact it is worse, since you would need to
define in a spec the idempotency/return of the original response rules
somewhere and you would be reinventing RM again.</DB>

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). 
<DB>I don't see any difference between BestEffort + idempotency and
OnceAndOnlyOnce. In OnceAndOnlyOnce, theres is no way of for the receiving
MSH to distinguish between a message resent because of user interaction and
one sent automatically. So the fact that in your example the resend is being
resent because a button has been pressed on the web browser is
irrelevant.</DB>

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?

<DB>Chris what you say could work. But what I would like to know is why the
current spec with Reliable Messaging without Intermediat Acks **doesn't**
work. 

The current spec only has two values for delivery semantics
"OnceAndOnlyOnce" and "BestEfforts". I think these are sufficient. Adding
another method called "synchronousWithIdempotency", as you suggest, only
adds to the complexity. The only thing you need to be able to add in order
to support synchronous reliable messaging is to have an
"IntermediateAckRequested" indicator in the Trace (was RoutingHeader)
element or in the CPA which tells the intermediate MSH whether or not to
generate an intermediate ack. Does this make sense?</DB>


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$