OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Need volunteer to draft definition of reliable messaging,wasRE:reliable messaging - hop by hop


   Date: Tue, 4 Sep 2001 11:18:15 -0500
   From: "David Fischer" <david@drummondgroup.com>

   On your points, while I don't disagree with any of them per-se, I think many of
   them would be considered a layering violation if we took them up -- like making
   sure the message is received by the application.  Isn't that BPSS's job?  Maybe
   we need to work on the interface but certainly nothing more.  We need to stick
   strictly to Transport.  

I agree that we have to stick to the transport layer.  What I'm
suggesting is that the transport layer includes the *contract* of the
transport layer, i.e. the exactly definition of the set of services
that the transport layer provides to its caller.  We should not have
anything to say about who the caller is.  But I think we'll find that
the only way to coherently describe the transport layer is in terms of
a set of services that the transport layer provides and promises to
undertake.

So I do think it's appropriate to talk about the caller handing a
message to the transport layer, and saying "please send this", so that
we can define exactly what the transport layer undertakes to do when
told to send something.  And it's appropriate to say that the
transport layer can tell its caller "OK, the message definitely
arrived" or "OK, the message did not (and will never) arrive".

			   As such, I still think NRR is MSH only and BPSS is
   really violating our layer to deal with that.  However, I am not sure they do.
   It looks to me like they simply have true|false flags dictating functionality.
   Perhaps they only send a signal or set a flag for the MSH level to
   request/perform the NRR functionality.

I agree, that seems to me like the most sensible interpretation.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC