RE: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo

[David Fischer <david@drummondgroup.com>]

OK, I understand the concept but how exactly would this be implemented with the
current spec?  What headers would be used and how?  Please keep in mind that we
already have a published spec so we can't make massive changes.

Many months ago, I suggested what I think is a similar approach.  I didn't call
things high or low but I suggested that the end-to-end message be wrapped as the
payload of another ebXML message sent to the intermediary (who then unwrapped
and, if not the end, rewrapped to send to the end or to the next IM) so
everything worked including end-to-end acks.  We didn't even need two different
acks.  Everything then became a single hop (no Via).  However, I became stuck
when trying to suggest how we might do the TraceHeaderList (I don't know why we
need TraceHeaderList but I have been assured we do).  In my scheme the original
message would be the High Level and the wrap to go to the IM would be the Low
Level but there would be no need for High Level code and a different Low Level
code (resubmit to the same code after unwrap).  Is this similar to what you are
proposing?  How do you get around TraceHeaderList?

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Friday, August 17, 2001 10:29 PM
To: david@drummondgroup.com
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: T2, Proposed solution for ... Re: SyncReply and
ReliableMessagingMethod in QualityOfServiceInfo


   Date: Fri, 17 Aug 2001 09:54:08 -0500
   From: David Fischer <david@drummondgroup.com>

   This sounds interesting but I don't quite understand.  How can we allow
   intermediates to do duplicate elimination yet also allow the ends to retry?
   Wouldn't this mean the retry would get stopped midstream since some
Intermediate
   might think it is a duplicate?  The Intermediate needs to let the From Party
   retry to go through even if it is a duplicate because the problem might be
   downstream of that Intermediate.

   Please explain further.

The protocol is layered into the higher-layer-protocol (HLP) and
the lower-layer-protocol (LLP).  The HLP is implemented by a software
package called the HLPI (HLP Implementation); analogously for the LLPI.
We have a From Party, an IM, and a To Party.

The From Party application desires to send a payload to the To Party
Application.  The From Party application calls into the HLPI, saying
"please send this payload to the To Party".  The HLPI constructs an
HLP Message, with an HLP header plus the payload.  The HLP header
includes a globally-unique identifier called the HLPUID.

The HLPI calls into the LLPI, passing in the HLP message, saying
"please sent this octet string to IM".  The LLPI constructs an LLP
Message, with an LLP header plus the octet string (which is actually
an HLP message but the LLP has no idea of that).  The LLP header
includes a globally-unique identifier called the LLPUID.

Still running on the From Party machine, the LLPI now sends the LLP
message to IM, using SMTP or something.  It waits, retries, waits,
retries, until it gets an LLP-ack from IM.

The LLPI running on the IM receives the LLP message, and stores the
LLPUID persistently.  If it gets another LLP message with the same
LLPUID, it discards it as a duplicate.  The LLPI running on IM then
sends the LLP message to the To Party machine, again retrying until it
gets an LLP-ack.  At the To Party machine, the LLPUID is again used
for duplicate elimination.

On the To Party machine, the LLPI strips off the LLP header and sends
the LLP body up to the HLPI.  The HLPI knows how to interpret that
body, namely as an HLP message composed of an HLP header and a
payload.  The HLP header contains the HLPUID, which the HLP can now
use for duplicate elimination purpses.  The HLPI on the To Party
builds an HTP-ack message, and passes the HLP-ack to the LLPI, saying
to send it to the From Party.  The LLPI gets this octet string, having
no idea that it is an HLP-ack, and encapsulates it inside an LLP
header, with an all-new LLPUID, and sends it to IM, retrying until it
gets an LLP-ack from IM.

Meahwhile the HLPI back on the From Party machine is waiting for that
HLP-ack.  If the HLP-ack takes too long, the HTPI on the From Party
machine is free to take the HLP message is constructed way back in the
beginning, and pass it into the LLPI for retransmission.  As far as
the LLPI is concerned, it has just been handed an octet string to be
conveyed to the To Party machine.  The LLPI has no idea what this
octet string means; it has no idea that the HLP interprets this octet
string as an HLP retry.  The LLPI wraps the octet string in an LLP
header, generating an entirely new LLPUID, and sends it off to the IM
machine.

And so the answer to your question,

   Wouldn't this mean the retry would get stopped midstream since some
Intermediate
   might think it is a duplicate?

is no, the HLP retry would not be stopped midstream, because the IM would
not recognize it as a duplicate, because the HLP retry is encapsulated
by a different LLPUID than the original HLP message.

				   The Intermediate needs to let the From Party
   retry to go through even if it is a duplicate because the problem might be
   downstream of that Intermediate.

It is a duplicate and it is not a duplicate.  It is a duplicate at the
higher layer, but it is not a duplicate at the lower layer.  (It has
the same HLPUID but a different LLPUID.)  So we get the best of both
worlds.

-- Dan