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

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

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$