RE: T2 Retry with Delivery Receipt

[David Fischer <david@drummondgroup.com>]

I believe you, but that's not what is in the spec now.  Right now the spec just
says that OnceAndOnlyOnce means the message must be sent using a
reliableMessagingMethod that will result in the application or other process at
the To Party receiving the message once and only once (10.2.1).  This does not
sound like it must be done using ebXML RM.  This says ANY RM method will do.

What would it take to make the spec fit your drawing (which would also eliminate
the issue about unreliable nodes)?  At the very least we would have to eliminate
the reliableMessagingMethod attribute.  We would also have to specify somewhere
that if ebXML RM is not supported then send back an error (DFN).

Is this what we want to do?

David Fischer
Drummond Group.

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Friday, September 14, 2001 4:15 PM
To: David Fischer
Cc: Martin W Sachs; Dan Weinreb; ebxml-msg@lists.oasis-open.org
Subject: Re: T2 Retry with Delivery Receipt


David,

The diagram I drew IS the agreed upon behaviour of an IM
w/r/t routing (e.g. IM routing is NOT an MSH function). It
is almosgt straight from the white board in Tokyo (I think
that was the meeting where we agreed on this).

The diagram isn't in the spec, but it probably should be
to help clarify what we meant.

Note that I'm not hopping over any unreliable nodes
in what I suggest at all. There are only reliable MSH nodes
involved.

Cheers,

Chris
David Fischer wrote:
>
> Chris, good explanation about how things might work.  However, none of this is
> in the spec.  If this is all correct, then why bother to have
> reliableMessagingMethod in Via -- or why bother having it at all?  I don't
> dispute that your way would work, and maybe we should do it this way, but what
> you are describing does not align with the current spec although it could be a
> subset of the current functionality.
>
> The way RM was designed was to allow for other RM methods.  Your explanation
> does not cover those and I can't find your "routing application" anywhere in
the
> spec.  If this is some sort of source routing protocol (workflow routing), we
> have specifically avoided that in the current spec.  I have tried to stay out
of
> the IM functionality discussion but I have to think that an IM which does more
> than store-and-forward is out of our scope for this version.
>
> I do like the way you hop over unreliable nodes.  Let's just hop over
everything
> and do end-to-end RM only!
>
> Regards,
>
> David Fischer
> Drummond Group.
>
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Friday, September 14, 2001 2:00 PM
> To: David Fischer
> Cc: Martin W Sachs; Dan Weinreb; ebxml-msg@lists.oasis-open.org
> Subject: Re: T2 Retry with Delivery Receipt
>
> David,
>
> In this case, where the MSH doesn't support ebXML RM protocol,
> you cannot send a message with OnceAndOnlyOnce semantics. It
> MUST send back an error "Not Supported".
>
> My point is that the RM protocol is hop-to-hop and the end-to-end
> semantics are achieved by having each hop be reliable (whether
> using ebXML RM or something else).
>
> Think of it this way:
>
>                   (routing app)
>                      |  |
>         A[eb] <-> [eb]B  B[MQ] <-> [MQ]C
>
> In this case, the B intermediary is reliable and supports
> both ebXML RM *and* MQ series. Whether these are separate
> instances or the same instance with multiple capabilities
> is irrelevant. It may be distributed for that matter. The
> routing app needs to be reliable as well (just as any other
> app) because it should ONLY mark the message as having been
> processed if it has successfully processed it.
>
> We can be more explicit regarding what responsibilities are
> at an intermediary node here, but IMHO, there really is no
> difference here between a routing "application" and an endpoint
> business "application" in that the MSH has a responsibility to
> ensure that the "application" processes the message.
>
> The B node above could all be a single piece of software,
> operating as a routing intermediary (which would certainly make
> it more robust), but we have nothing to say on the matter
> as far as our specification is concerned.
>
> I don't think that we need to address the situation where two
> adjacent nodes don't support the same RM protocol. That would
> be (IMHO) no different that an SMTP node trying to foist the SMTP
> protocol on an HTTP server. They speak different protocols
> and can never interact directly without some manner of gateway.
>
> Cheers,
>
> Chris
>
> David Fischer wrote:
> >
> > Chris,
> >
> > What do you mean by unreliable?  I will agree there is no unreliable IM but
> > there can be an IM which does not support ebXML RM (e.g. uses MQSeries
> instead).
> > This is the whole point of the reliableMessageMethod parameter.
> >
> > David Fischer
> > Drummond Group.
> >
> > -----Original Message-----
> > From: Christopher Ferris [mailto:chris.ferris@sun.com]
> > Sent: Friday, September 14, 2001 1:13 PM
> > To: Martin W Sachs
> > Cc: Dan Weinreb; david@drummondgroup.com; ebxml-msg@lists.oasis-open.org
> > Subject: Re: T2 Retry with Delivery Receipt
> >
> > Marty,
> >
> > The SMTP "intermediaries" are not ebXML MSH intermediaries
> > and thus there is no analogy at all.
> >
> > The whole point I make is that there isn't an unreliable
> > ebXML MSH intermediary involved when OnceAndOnlyOnce is
> > in play for a message.
> >
> > Cheers,
> >
> > Chris
> >
> > Martin W Sachs wrote:
> > >
> > > 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>