Re: Small point on DF RE: Intermediary support in the 1.1 version ofthe MSG and CPP/A specs

[christopher ferris <chris.ferris@Sun.COM>]

All,

It isn't clear to me that the cascading ack works in
all cases. An intermittently connected sender MSH
would be one, where it wants to get the message on
its way quickly and then disconnect/reconnecting later
to retrieve any responses. If the cascading Ack scheme
is applied, and the receiving (ToParty) node is *also*
intermittently connected, the sending node may not get an
Ack for quite some time. This is clearly not ideal.

In such a use case, getting an immediate ack from the
intermediary that is serving as a "mailbox" IM, forwarding
to the To Party when it is available, can be quite a useful
thing as it knows that the message has been safely persisted
and that the intermediary has assumed responsibility for 
reliably delivering the message or, failing that, sending
a DFN back to the sender (when it comes back on-line)
that the message could not be delivered to the receiving node 
despite all (retry) attempts. 

Note also that the receiving party might have a "pull"
interface to the messages in it's "mailbox". If it
doesn't come on-line to get its messages, for whatever
reason, then a retry from the sending node doesn't
do anything but clog up the receivers mailbox
with a bunch of duplicate messages.

It seems to me that what we could do is deal with
cascading acks as being distinct from 
immediate acks (store and forward reliably) by means
of some attribute in the message. If we had a separate
module for AckRequested, that would be a logical place
for it IMO. Either that, or else ackRequested attribute
should be something other than boolean so as to indicate
whether the sender wanted store and forward versus
just forwarding.

Another approach to consider, again, making the RM function
a module (SOAP bubble) would be to use the SOAP:actor attribute
on said module to indicate which node the sender wanted 
the ack from (e.g. 'next' versus the default actor or
a specified actor that means "the point at which the
message is considered safely received by the To Party"
which may not be the terminal/ultimate recipient MSH node
when we consider the firewall use case for intermediaries
that I have previously described.

Note also that a Via element is not always needed when forwarding
to the first IM especially in cases where the IM is effectively
transparent from the perspective of the sending party's MSH
because it is reflected only as the endpoint URL of the
To Party in the CPA.

As for the other options, I don't understand option 3. How can
you rescind an Ack? Do you mean that the IM purges any previous
reference to the messageId from its RM persistent store
before forwarding the DFN back through the message path?

This might be something we could consider, but again, I think
that we need to be careful about how we treat this. What does
it mean for a processing intermediary? Is it expected to 
roll-back any state change related to the message? This get's
into really gnarly areas IMO.

I also don't understand what is meant by option 4. Option
5 might be something to consider for 1.1, where we just admit that
dealing with intermediaries is hard (which it clearly is)
and we need to do more work to ensure that we get it right
so we don't consider them until v2.0.

Cheers,

Chris


Dale Moberg wrote:
> 
> David Fischer writes:
> "Forwarding to the first IM is easy.  If the From Party is not sending
> directly
> to the To Party, then the From Party simply adds a Via with another
> CPAId
> (different from the end-to-end CPA).   The MSH sees a Via and instead of
> sending
> to the To+PartyId the MSH looks up a url in the CPA specified by
> Via+CPAId.  So
> far, so good.  The IM gets the message -- now what.  If the IM can send
> to the
> To+PartyId (one IM) then everything works, what if it can't (multiple
> IMs)?  How
> does the IM know where to send the next hop?  This needs some serious
> consideration.
> 
> We also need to deal with Dale's issue of backing out Acks.  If the IM
> receives
> the message and sends an Ack, this does not mean the message reached the
> To
> Party.  If there is a failure (DFN) later in the path, then the Ack for
> each
> previous hop should be Backed Out.  I see the following options:
> 
> 1.  Don't send the Ack until the Ack from the next hop is received.
> 2.  Don't send IM Acks, end-to-end Acks only.
> 3.  Send DFN to each hop and rescind the Ack at each hop.
> 4.  Don't bother.
> 5.  Don't do Multi-hop.
> 
> Option 1 is the Cascading Ack we discussed earlier which has the
> potential for a
> Retry Flood downstream.
> Option 2 effectively eliminates IM RM.  It actually
> seems to me that option 1 and 2 are almost the same. .."
> 
> David,
> if Option 1 gets in the running, I suggest dealing with the cascading
> retry
> problem by stipulating that all retries stem from the original sender
> only. The
> IMs do not retry until prodded, in other words."