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

[Rik Drummond <rvd2@worldnet.att.net>]

just a note... we are running out of time to finish the mhs document...
anything we can put off until after version 1.0 should be tabled...... first
versions never have everything in them....... so i suggest we focus on
getting the document complete using the black box approach for routing, i.e.
point to point only.... best regards, rik

-----Original Message-----
From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
Sent: Friday, January 26, 2001 3:07 AM
To: Chris.Ferris@east.sun.com; ebXML Transport (E-mail)
Subject: RE: We need Multi-hop reliable messaging without Intermediate
Acks


I agree with Chris's comments.

I would like to discuss a little bit on how the scenario is actually
modelled.
As Chris was mentioning, the intermediate does not play a passive role in
the chain but plays an active role, i.e. he is effectively another Trading
Partner. At this point, as Chris mentioned, there are two interleaving CPAs
that take place.
The semantic that is described in the original message from David implies,
from a Business perspective, that the Sender receives a notification from
the target; from a Business perspective, I do not think that one could say
that "no notification from the intermediate should be received". I would
rather think the contrary.
	Let's take the example of a mailing service. You can send a letter
	or a parcel asking for a return-receipt. Now, the post office gives
	you back an acknowledge immediately when you post the letter and,
	somehow, independently on the fact that someone on the other side
	would be there or would actually accept the incoming letter.

So, I think that the original example mixes two separate flavours. One is
the "business process" description and the other is a "technical
infrastructure constraints". The latter is the one which actually "prevents"
the sender from receiving both an ack and a receipt. But this has nothing to
do with the business process description.

My very humble opinion would be that, in this case, one should choose
between the adherence to the process definition and the technical means he
uses to implement that.

Best regards

/Stefano

> -----Original Message-----
> From: Chris.Ferris@east.sun.com [mailto:Chris.Ferris@east.sun.com]
> Sent: 25 January 2001 22:38
> 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.
>
> 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$
>