[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 Retry with Delivery Receipt
Reliable Messaging is not reliable without retries. Retries have to be made
to work with multi-hop.
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" <david@drummondgroup.com> on 09/18/2001 09:27:17 AM
To: "David Fischer" <david@drummondgroup.com>, Martin W
Sachs/Watson/IBM@IBMUS, "Christopher Ferris" <chris.ferris@sun.com>
cc: "Dan Weinreb" <dlw@exceloncorp.com>, <ebxml-msg@lists.oasis-open.org>
Subject: RE: T2 Retry with Delivery Receipt
I haven't seen any discussion on the list from this question. Does this
mean
everyone agrees there are valid use cases supporting end-to-end retries?
The way the spec is written now, single-hop, end-to-end retries work.
Multi-hop
end-to-end retries do not work when RM is turned on (idempotence). Can we
now
discuss what that will entail?
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Friday, September 14, 2001 8:46 AM
To: Martin W Sachs; Christopher Ferris
Cc: Dan Weinreb; ebxml-msg@lists.oasis-open.org
Subject: RE: T2 Retry with Delivery Receipt
This all comes down to "Are end-to-end Retries REQUIRED"? All the other
things
like automated retries, end-to-end RM, retry on DR, are secondary issues.
Under any delivery failure scenario, the ability to retry the original send
is
REQUIRED. This might be automated or it might be manual. It might come
from
the MSH or from the Application. It might be now or after a fix. No
matter
where or how, we MUST allow end-to-end Retries.
Can anyone disagree with this?
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, September 14, 2001 8:25 AM
To: Christopher Ferris
Cc: Dan Weinreb; david@drummondgroup.com; ebxml-msg@lists.oasis-open.org
Subject: Re: T2 Retry with Delivery Receipt
Sure but it is an example of how ebxml end to end RM can work through
unreliable IMs.
********************************************************************************
*****
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
********************************************************************************
*****
Christopher Ferris <chris.ferris@sun.com> on 09/13/2001 01:40:58 PM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: Dan Weinreb <dlw@exceloncorp.com>, david@drummondgroup.com,
ebxml-msg@lists.oasis-open.org
Subject: Re: T2 Retry with Delivery Receipt
Marty,
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.
Cheers,
Chris
Martin W Sachs wrote:
>
> Re: "I think David's position is that we can't do that, because there
are
> hosts/entities out there that (a) must participate as ebXML MS IM's,
> and (b) that are unreliable. The question is whether there's a use
> case demonstrating this."
>
> There is one major use case, which is SMTP. SMTP intermediate nodes are
> notoriously unreliable and only acknowledge to the previous node so a
> sender has no idea whether the message got to its destination. ebXML on
> top of SMTP is one of the major reasons for having ebXML reliable
messaging
> and only end to end reliable messaging helps with SMTP. I don't know if
> there is a use case for ebXML unreliable intermediaries but if there is,
> end to end RM is the answer.
>
> 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
>
********************************************************************************
*****
>
> Dan Weinreb <dlw@exceloncorp.com> on 09/13/2001 12:55:02 PM
>
> Please respond to Dan Weinreb <dlw@exceloncorp.com>
>
> To: chris.ferris@sun.com
> cc: david@drummondgroup.com, ebxml-msg@lists.oasis-open.org
> Subject: Re: T2 Retry with Delivery Receipt
>
> Date: Thu, 13 Sep 2001 11:48:33 -0400
> From: Christopher Ferris <chris.ferris@sun.com>
>
> > The only problem is that the addition of multi-hop interferes with
> end-to-end
> > retries (duplicates) which, as we have seen, is a fundamental
> functional
> > requirement under all circumstances when a Delivery Receipt is
> requested but not
> > received.
>
> You're asking for retries on top of retries. What happens when the
> end-to-end
> retries are exhausted and there is still no delivery receipt? Do we
add
> retries
> of retries of retries? What happens when they fail? Do we add yet
> another layer?
>
> What David is asking for is perfectly sensible *if* you your failure
> model states that IM's are unreliable, e.g. that an IM might accept a
> message, and then silently forget it. In that case, the end-to-end
> retries exist for a specific purpose: to harden the system against the
> possibility of flaky IM's. There would be no need to add another
> layer unless there is some additional, distinct failure mode to be
> taken care of.
>
> Why not focus on what you perceive as an omission in the spec, that an
> intermediary
> has certain obligations w/r/t reliable delivery. Let's address that by
> adding
> text that fully sets out what the responsibilities of an intermediary
> are
> not only w/r/t RM but w/r/t routing and any other oddities of an
> intermediaries
> role that is clearly distinct from that of an endpoint.
>
> I think David's position is that we can't do that, because there are
> hosts/entities out there that (a) must participate as ebXML MS IM's,
> and (b) that are unreliable. The question is whether there's a use
> case demonstrating this.
>
> I'd like to focus on the specific use case that you cited in the call,
> where
> an MSH uses an EDI/INT gateway. Is there an ebXML MSH at the To Party
or
> do they
> simply have an EDI/INT server?
>
> MSHA -> IMSHGW -> EDI/INTGW -> EDI/INTB
>
> In this case, how does the ebXML delivery receipt get generated? IMO,
> the
> EDI/INT Gateway has a responsibility to ensure that the message is
> safely
> delivered. How it does this is not the perview of our specification.
> However,
> that doesn't obviate the responsibility that the gateway intermediary
> node
> assumes.
>
> I'd call this a protocol-translating gateway, not an ebXML MS IM at
> all. I agree that the gateway has to make sure that the message is
> truly delivered, and then the gateway generates the DR. It's the
> job of the protcol-translating gateway to create the illusion that
> the far end is really running ebXML MS.
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC