RE: T2 Retry with Delivery Receipt

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

David,

There have been 50 years of development of disaster backup and recovery
scenarios and software that have the answers to many of these questions.
Regarding MSH2 catching fire, the answer is easy. If MSH2 catches fire,
APP2 will be aware of it; an application should not commit the transaction
resulting from a message if it cannot send the delivery receipt or reply.
Thus APP2 should discard the message and roll back anything it did.  If the
reliable message had not yet been acknowledged when the plane crashed into
MSH2, and if it's the A-MSH's job to recognize delivery failure and notify
the A application, all is well. If the message had successfully been
acknowledged, the A application will never receive the response and someone
will have to make a phone call to resolve the in-doubt situation.

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
*************************************************************************************



"Burdett, David" <david.burdett@commerceone.com> on 09/13/2001 05:16:57 PM

To:   "'Dan Weinreb'" <dlw@exceloncorp.com>, Martin W
      Sachs/Watson/IBM@IBMUS
cc:   ebxml-msg@lists.oasis-open.org
Subject:  RE: T2 Retry with Delivery Receipt



Dan

You wanted a use case where where you have an IM "that's unreliable but
must
act at the ebXML MS level of abstrction, i.e. it understands and interprets
the data formats described in the MS spec".

In my last email at
(http://lists.oasis-open.org/archives/ebxml-msg/200109/msg00191.html) I
explained the benefits of an ebXML MSH and included the following diagram:


   A -------------- BM ------ B1 ------- B
  MSH              MSH       MSH        APP1
                    |
                    |-------- B2 ------- B
                    |        MSH        APP2
                    |
                     ----- Inteface ---- B
                             App        APP3

Suppose the B2 MSH and the B APP2 are running on the same server and the
server suffers a head crash. In this case the BM MSH should respond with a
Delivery Failure Notification to A when A sends it a reliable message.

You also cannot reasonably guarantee that the B2MSH when would NEVER lose
data when it crashed. Therefore it is quite possible that a Delivery
Receipt
could get lost.

This in fact suggests a really nasty use case. Suppose:
1. The B2 MSH forwards the message to APP2
2. The B2 MSH cathes fire and as a result loses both its database and
recovery log files and so CANNOT recover the fact that it previously
forwarded a message to APP2.

Thoughts?

David

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Thursday, September 13, 2001 11:06 AM
To: mwsachs@us.ibm.com
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: T2 Retry with Delivery Receipt


   Date: Thu, 13 Sep 2001 13:40:58 -0400
   From: Christopher Ferris <chris.ferris@sun.com>

   AN SMTP node is NOT an MSH node. It is not part of the equation.
   The MSH nodes that are communication via SMTP are the ones that
   adopt the RM protocol of retries in the absence of an Acknowledgment.
   The SMTP nodes are incidental.

I agree.  An SMTP store-and-forward mailer is *not* an MSH IM.  SMTP
is at the next layer down, which is an entirely different matter.
From the vantage point of ebXML MS, SMTP store-and-forward mailers are
just part of the vast, foggy, unreliable cloud labelled "Internet".
From our point of view, if an SMTP mailer drops a message, that's
exactly the same as a message being "lost in the Internet" while in
transmit between one MSH and another MSH.

What's needed is a use case that's unreliable but must act at the
ebXML MS level of abstrction, i.e. it understands and interprets the
data formats described in the MS spec.  An SMTP mailer just takes
the packaged message and passes it along, treating it as opaque.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>