RE: T2 - Intermediaries/Message Status Request

["HUGHES,JIM (HP-Cupertino,ex1)" <jim_hughes@hp.com>]

Chris -

Statements about "most of the time" are really quality assertions.
Certainly, if one knows and trusts the transport, then RM might never be
used. However, the ebXML assertion is that Messaging Services is agnostic to
the transport and the sender needs the RM functionality... unless he can
specify the actual transport, as you suggest for MQseries.

BTW, once you presume that the underlying transport is known (and maybe
homogeneous through all links, as MQseries is), then you can introduce other
APIs as you note. But now you've changed the basic ebXML structure, I think.

jim



> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Saturday, August 11, 2001 7:03 AM
> To: Martin W Sachs
> Cc: Burdett, David; 'David Smiley'; ebxml-msg@lists.oasis-open.org
> Subject: Re: T2 - Intermediaries/Message Status Request
> 
> 
> Please see below.
> 
> Cheers,
> 
> Chris
> 
> Martin W Sachs wrote:
> <snip/>
> > 
> > MWS:  The post example is a good example of an intermediary 
> which simply
> > forwards the message.  In the case of the post office, 
> there may well be
> > multiple hops in the process.  However in the case of the 
> post office,
> > the reliable messaging algorithm is definitely end to end.  
> I send it
> > certified or registered and the delivery receipt confirms that the
> > letter was received by the destination party.
> 
> How frequently do you send a letter certified or registered?
> 
> It costs more for starters. It isn't very practical, especially
> if you're expecting something in return from the recipient in
> the near future.
> 
> You send you bill payments via the post service, and you get 
> a new statement in about two weeks which would indicate whether
> your payment was processed.
> 
> Most people and most businesses don't send mail registered
> or certified unless there's either something compelling
> that warrants the additional cost. Maybe submission of a bid
> or a time-sensitive or legal document.
> 
> My point is that most of the time, you don't need a positive
> ack from the ultimate recipient to achieve end-to-end reliability.
> 
> Consider MQSeries. The MQSeries infrastructure doesn't do end-to-end
> acknowledgments within its own infrastructure. It is for the most part
> only concerned with the next hop.
> 
> It *does* provide an optional application API that the application
> can use to tell the sending application (not the MQSeries 
> infrastructure)
> that the message was received. But this isn't part of the reliable
> messageing exactlyOnce delivery semantics that MQSeries offers.
> 
[rest snipped]