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

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

Stefano

I think analogies help and yours is a good one. So how about this as another
one ...

When you send an email to someone, you send it your local email server which
then sends it to the destination email server which then sends it to the
utlimate recipient. You don't ask for the intervening servers to give you
confirmation that the email you sent was received by them. You just, if you
ask for it, get a receipt from the final recipient.

The situation I described in my use is similar in where a message is sent
from Party A via Party B to Party C. Just like the email servers Party B is
agnostic to the message that is being sent and does do any processing of the
payload. It is just a forwarding service, that provides acts more like a PO
box for messages and not much more.

What I think we need to do is have a clear separation between the business
process definition in terms of the sequence of messages that are sent
between parties, and the technical infrastructure that is used to send those
messasges. It really should not matter how many hops a message traverses in
order to get from its origin to its destination.

David 

-----Original Message-----
From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
Sent: Friday, January 26, 2001 1: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$
>