Re: reliable messaging - hop by hop

[Scott Hinkelman <srh@us.ibm.com>]

>MWS:  In the HTTPR spec it doesn't just assume; it
states an assumption that intermediaries
store and forward reliably.  This is crucial to understanding how
the hop by hop reliability can work.  Without such a statement in
the MSG spec, it is necessary to not trust the intermediaries. That's
why (I agree) we must be clear about stating assumptions on how the
endpoints and intermediaries are designed.  We don't want to do the
design but we must say things like "this assumes that the intermediaries
store and forward reliably".

I agree completely. And as far as I'm concerned, "we must be clear about
stating assumptions on how the endpointes and intermediaries are designed"
means defining a formal language-neutral API that tightens the behavior of
those 'clear statements' beyond english prose, and would formally express
the logic layering so I can finally tell what exactly *is* an MSG versus
somebody's notion of an *application* and where NRR for example really
sits. Formal behavior specification, beyond wire format, seems to be the
best approach to finalizing some of this.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Martin W Sachs/Watson/IBM@IBMUS on 08/29/2001 08:51:28 AM

To:   Dan Weinreb <dlw@exceloncorp.com>
cc:   david@drummondgroup.com, John Ibbotson/UK/IBM@IBMGB,
      ebxml-msg@lists.oasis-open.org
Subject:  Re: reliable messaging - hop by hop




Some comments below.

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 08/29/2001 11:19:07 AM

Please respond to Dan Weinreb <dlw@exceloncorp.com>

To:   david@drummondgroup.com, John Ibbotson/UK/IBM@IBMGB
cc:   ebxml-msg@lists.oasis-open.org
Subject:  Re: reliable messaging - hop by hop



It seems to me that there is still some disagreement about exactly
what is meant by "reliable messaging".  It can mean either:

(1) If I sent a message reliably, then even in the face of certain
(enumerated and well-specified) failure modes, the message will
eventually get delivered to its final destination [1]

or

(2) If I sent a message reliably, I will get a positive
acknowledgement from the final destination saying that
the message was received.


(1) can be accomplished in a hop-to-hop fashion, whereas whether (2)
can or not depends on the set of failure modes.  My impression is that
MQSeries and HTTPR are both assuming a certain degree of trust in the
reliability intermediaries, whereas some conversations on this mailing
list have basically assumed that our set of failure modes must include
total distrust of intermediaries, i.e. an intermediary might just drop
a message at any time.  I think that in order to resolve the debates
about hop-to-hop, we have to be clear about whether our set of failure
modes includes total failure of intermediaries.

MWS:  In the HTTPR spec it doesn't just assume; it
states an assumption that intermediaries
store and forward reliably.  This is crucial to understanding how
the hop by hop reliability can work.  Without such a statement in
the MSG spec, it is necessary to not trust the intermediaries. That's
why (I agree) we must be clear about stating assumptions on how the
endpoints and intermediaries are designed.  We don't want to do the
design but we must say things like "this assumes that the intermediaries
store and forward reliably".

My impression from looking at the HTTPR spec is that it does not
actually address (2) in a multi-hop environment; is that right?

MWS:  I am still reading HTTPR.  If anyone knows the answer, please post
it.

-- Dan

[1] Better, all reliable messages should have a time-to-live, and the
guarantee should be that either the message be delivered to its final
destination before expiration, or else it will not be delivered (or
that the original sender is reliably informed that the message was not
sent).  The time-to-live is really essential anyway, for duplicate
elimination purposes, as discussed earlier.

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