RE: Multi-hop reliable messaging

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

Nikola

See comments inline

David
PS I'll send out an updated presentation later today

-----Original Message-----
From: Nikola Stojanovic [mailto:nhomest1@twcny.rr.com]
Sent: Tuesday, October 31, 2000 6:00 AM
To: ebXML Transport (E-mail)
Subject: Re: Multi-hop reliable messaging


<David>
In the mean time comments are really welcome.
</David>

Here they are:

<Comment 1: page 12>
Picture is not right. Like in FC5: "eventually give up and send message 12".
If you give up you cannot send Ack, you should send "Delivery Failure".
Also, note on FC 6 about "Ack on Ack", why would that be needed?
</Comment 1: page 12>
##Correct, The ack should be a delivery failure message. This means that you
do not have an ack on ack. Instead you are acking the Delivery Failure.##

<Comment 2: page 14, 15>
Why would UC 9 need Ack back on Msg 5 to Hub 1 and UC 8 doesn't need Ack
back on Msg 2 to Party 2? 
##Because the link between Party One and the hub in UC 9 is asynchronous
over separate sessions. If there is no separate ack on message 5, then Party
One would need to resend Message 1 which would result in just the Message 2
(the ack) being re-sent. In UC 8, no separate ack is needed for Message 2
since if Message 2 did not arrive then message 1 would be resent which would
cause Party two to resend Message 2. The key rules are:
Rule 1) If you don't get back a message with a RefToMessageId of the message
you sent then resend the original message
Rule 2) If you receive a duplicate message then resend the most recent
response you sent with a RefToMessageId for that Message.
These are quite simple rules that you can (I think?) apply consistently and
get the result you want.##
Also, why wouldn't Hub send Msg 7 to Party 2,
which is also Final Ack? 
##Because the hub is following Rule 1. The hub knows that the message 3 was
received since it received Message 4. Party Two can assume that Message 4
was delivered since it has not received a duplicate request or an
out-of-band message to report the failure.##
Are you assuming not reliable on the way back
between Party 2 and the Hub, 
##No##
but reliable between the Hub and Party 1?
##... and no.##
</Comment 2: page 14, 15>

<Comment 3: page 16>
"Implicit and explicit acks must not be mixed on a single conversation over
one hop". How does this statement relate to the UC 10 and why this
restriction?
</Comment 3: page 16>
##I suppose that it is because of the need to control the state at, in this
use case, the hub. Referring to Use Case 10, when Message 2 is sent, the hub
is in the state "sent but not delilvered", once Message 3 is received, it is
in the state "message delivered", when Messsage 4 is received it is in the
state "delivered and processed". This means that between the Hub and Party
two you can use either the message flow in UC9 OR UC10, but not both at the
same time.##

<Comment 4: page 17>
This should be UC 11 not UC 10. 
##Fixed##
Also, if Ack is on Msg 9, do you need Msg
11 ##10??##, which is Ack back on Msg 8 to Party 2 (similar to "Comment 2")?
##Yes for same reasons as comment 2##
</Comment 4: page 17>

<Comment 5: page 18>
"Requires Message 4 to contain "Ref to" to Message 2". ##Yes## I would
establish
this as "ImplicitAcknowledgment" Pattern for all Implicit Acks and move it
earlier in the doc.
##No, it's not an implicit ack since there is an explicit ack in Message 3.
However there is an interesting UseCase where Message 3 fails permanently,
but Message 4 arrives. In which case, although an explicit ack was
intendeded, actually there was an implicit ack instead.##
</Comment 5: page 18>

<Comment 6: page 19>
Why wouldn't Msg 5 (Wait) work as an Ack (like Msg 2 on page 17)? Is it
because of rule on page 16?
</Comment 6: page 19>
##Message 5 does work as an explicit ack. However it does not mean that the
message has reached its final destination.##

<Comment 7: page 20>
"Need a concept of a lifetime". I agree.
</Comment 7: page 20>

<Comment 8>
It looks like a good start. I can imagine that if we would add shapes of
Headers for Msgs that flow (or at least for representative cases) it would
be very clear and useful doc for implementers and POC-like people.
</Comment 8>

Regards,
Nikola