RE: Multi-hop reliable messaging

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

Nikola

I think you may be right about combining implicit and explicit acks. 

Perhaps what the hub needs to do after it receives message 1 is the
following:
1. Forward the message (message 2) as usual
2. Wait for a "normal" message (message 4) that has a RefToMessageId that
points to Message1
3. When it arrives look for a) messages waiting for an implicit ack, that
have a message Id that is the same (i.e. Messager 1)and then 
4. Forward the message to Party One and change the state to message
received.

I **think** the rules I identified in version 2 of the document still work,
but we it really does call for a state diagram and some careful working
through of the logic required.

We should walk through this use case next week in Tokyo.

David

-----Original Message-----
From: Nikola Stojanovic [mailto:nhomest1@twcny.rr.com]
Sent: Thursday, November 02, 2000 7:23 PM
To: Burdett, David; ebXML Transport (E-mail)
Subject: Re: Multi-hop reliable messaging


<Nikola 1>
<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.
</Comment 5: page 18>
</Nikola 1>

<David 1>
##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.##
</David 1>

From the doc: "Intermediate MSHs needs to know that Message 4 from Party Two
is implicit ack to Message 1 from Party One. Requires Message 4 to contain
"Ref to" to Message 2". How would the Hub know that it is implicit to
Message 1 and explicit to Message 2 when it has the same "RefToMessageId"?
And your definition of an Acknowledgement: 'An acknowledgement to a message
that was previously sent is identified by the receipt of a message that
includes a "RefToMessageId" that contains the MessageId of the message that
was previously sent.' And, as you confirm, if Message 3 fails, and Message 4
arrives, Message 4 serves the purpose of an implicit Ack? I need to digest
rule: "Implicit and explicit acks must not be mixed on a single conversation
over one hop" a little bit more, but it seems like this morphing between
implicit and explicit may break it?

Regards,
Nikola