Re: What are the sides here? RE: T2 Retry with Delivery Receipt

[Martin W Sachs <mwsachs@us.ibm.com>]

(Note - I copied the list on this reply.)

Replies embedded below.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



"Dale Moberg" <dmoberg@cyclonecommerce.com> on 09/14/2001 02:31:53 PM

To:   "Christopher Ferris" <chris.ferris@sun.com>, Martin W
      Sachs/Watson/IBM@IBMUS
cc:
Subject:  What are the sides here? RE: T2 Retry with Delivery Receipt



I am not certain I have read every msg on
this topic of intermediaries and RM.

But whether ebXML RM or MQ RM is used,
isn't the intermediaries that
cause the problem of there even
being a distinction between hop to hop
and end to end?

Without intermediaries, the distinction
collapses because the next hop just is
the end!

I see two main ways to do handle the
end to end assurance (and I think
the flavor of onceandonlyonce
semantics is probably a slight tangent):

1. Make certain some message or
other from the real end actually
gets back to the real start.

(drawback: possibly a lot of unneeded traffic)

MWS:  If the intermediaries are passing acks back to the
To MSH, the end to end ACK may be more than just unneeded
traffic.  It would considerably complicate the protocol and
may produce its own indeterminate situations.

2. Lay down a constraint that
no intermediate ack be issued
before the next hop acks  back
(intermediates delay any ack
until final ack has been
issued.)

(drawback: possibly a slight implementation
burden on intermediaries--but
they deserve it!!)

MWS:  This actually a critical element, not just an option. The basic
requirement is that the To MSH must persist the message before sending the
acknowledgment.  The requirement cannot be met unless each intermediary
withholds an ACK until it receives an ACK from the next intermediary.  That
way, when an intermediary receives an ACK, it knows that the message was
persisted at the To MSH and then sends its own ACK forward. Each ACK must
be only on the hop connected to that IM.

MWS:  There is one problem with what I just said.  If one hop is an
exactlyOnce protocol that does not need ACKs because it unconditionally
guarantees that the message will get to the next destination, there is an
additional complication.  I believe that MQ is an example of this case.
Example:

        ebXML-RM        non-ebXML-RM        ebXML-RM    ebXML-RM
   A----------------B-------------------C-------------D-------------E

MWS: When the message gets to the E MSH, it returns an ACK which goes to D,
which then sends an ACK to C.  Since there are no ACKS in the B-C RM
protocol.  The application level of the C node must build an ebXML ACK that
can flow to B as an application message.  The B application level then has
to (somehow?) cause the B MSH to create an ACK that is a proper ebXML ACK
to the original message and sent it to A. Another way to say this is that
from an ebXML viewpoint, the combination of B and C is an ebXML node and
what goes on between B and C is irrelevant but the combination must be able
to send the correct ebXML ACK when the C MSH receives an ebXML ACK from D.


=============

Under item 1, either you add
on the Delivery Receipt as
the message (I think David F
favors this) or you
forward the last ack back
( is this Chris solution ) or something
like this.

Why has approach 2 been rejected?

MWS:  Approach 2 should be a key element.  See above.

MWS:  If we want to get V 1.1 out in a reasonable time, I urge that for V
1.1 all hops must be ebXML hops.  That's hard enough.  Non-ebXML hops
should be out of scope for V1.1 if not forever.  We can dispose of
non-ebXML hops once and for all by declaring among ourselves that two nodes
with a non-ebXML hop between them are a single ebXML node for purposes of
the specification.  We should not mention the non-ebXML hop at all but we
must have enough guiding text to make it clear what an ebXML node with a
non-ebXML hop inside it must do.