I agree that even the phone call is either inconclusive or impractical in
some cases. Customer service at my wife's health insuror has no idea
whether a claim has arrived until processing is completed. They don't
enter it into the computer until then.
One could conclude that reliable messaging is impossible or at best it only
pushes retries down from the application to the middleware. A better
approach is to design for the .999 of the cases where it does what it is
supposed to do and then add some caveat about pathological cases. Delivery
Failure Notification, when it is a message from the From MSG to the From
software will mean what it says except in odd cases out on the wings of the
distribution. Having Reliable Messaging work MOST of the time is better
than not having it.
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
*************************************************************************************
"David Fischer" <> on 09/13/2001 11:59:00 AM
To:
"Dan Weinreb" <>, Martin W Sachs/Watson/IBM@IBMUS
cc:
<>
Subject: RE: T2 Retry with Delivery Receipt
Even a phone call does not guarantee lack of delivery -- it may come later
or
the administrator could miss it. Failure can never be proven. OTOH, if
the
administrator (or MessageStatus or end-to-end Ack) perceives a success,
this
should be definitive. Even for success, an end-to-end Retry may be
necessary to
get a required NRR (DR).
Confirmation of non-delivery is not really possible (Logic 101 -- you can
never
prove a negative). TTL may come into play here and help resolve this but
TTL is
likely to be too long for time-sensitive issues.
Regards,
David Fischer
Drummond Group.
