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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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


Subject: Re: [ws-rx] NEW ISSUE: semantics of "at most once" delivery assurance


Christopher B Ferris wrote:

>Now, for my comments.
>
>Cheers,
>
>Christopher Ferris
>STSM, Emerging e-business Industry Architecture
>email: chrisfer@us.ibm.com
>blog: http://webpages.charter.net/chrisfer/blog.html
>phone: +1 508 377 9295
>
>"Bergersen, Rebecca" <Rebecca.Bergersen@iona.com> wrote on 07/26/2005 
>11:06:09 AM:
>
>  
>
>>Chris,
>>
>>I disagree.  'At Most' does not have the same semantics as 'Exactly'.
>>    
>>
>
>I never claimed that it did.
>
>  
>
>>'Once' does imply duplicate detection, as you said, but 'At Most' does
>>not imply best effort.  It simply means 'maybe fewer but no more than'.
>>    
>>
>
>Okay, I'll agree with that characterization as to what it *means*. But in 
>practice,
>it is used to imply best effort coupled with duplicate detection.
>
>  
>
>>If you think Best Effort should be the semantic,  then AtMostOnce should
>>be dropped.  A threshold on 'ExactlyOnce' such as you suggest can be set
>>by default at a Very Large Number thereby specifying the absolute best
>>effort with smaller values providing 'good enough effort' at delivering
>>a message exactly once.
>>    
>>
>
>When I think of ExactlyOnce, I think of it as meaning, "short of some 
>cataclysmic
>event in which either the RMD or AD can not be recovered, or in which the
>AD is decommissioned, the message will be delivered". 
>
>  
>
The protocol only ensures deliivery if both endpoints are cabable of 
fulfilling the oblications associagted with a given DA level.

Thus, exactly once, means that as long as the protocol machine is 
working, that DA level will be met.

>>That would give you what you want, but for different reasons I'm not
>>convinced that AtMostOnce  has any place at all in a "Reliable Message'
>>    
>>
>
>As I have said before, the DA is not reflected in the protocol at all.
>It is a function of the contract between the RMD and AD (and possibly
>between the AS and RMS).
>  
>
Use case: a receiver might want to apply a monotonic filter on teh 
incoming stream of messag ids for a sequence of stock quotes.
.  It does not care if it loses a quote every now and then, but does not 
want to receive the same or an older one than one it has already received.

However, at most once, with no other assurances seems to be a weak 
assurance, which should not require the sender to retransmit unacked
messages if it does not want to.

Tom Rutt

>  
>
>>protocol.  AtMostOnce (maybe zero but no more than one) implies the
>>message can be lost or dropped without significant consequence.  As a
>>result, the sender can send it and forget it and the receiver can deal
>>with it if it gets it (and avoid more than one copy being given to the
>>application) but not worry about it if it doesn't get it.  If less than
>>one is acceptable, there is no requirement for reliability here.  This
>>type of message can be sent outside the 'Reliable Message' protocol.
>>    
>>
>
>Which gets back to why I think that in the context of RM, best effort IS
>implied for AtMostOnce. Otherwise, I would agree.
>
>  
>
>>Regards,
>>Rebecca Bergersen
>>Principal Architect, Middleware Standards
>>rebecca.bergersen@iona.com
>>-------------------------------------------------------
>>IONA Technologies
>>200 West Street Waltham, MA 02451 USA
>>Tel: (781) 902-8265
>>Fax: (781) 902-8001
>>-------------------------------------------------------
>>Making Software Work Together TM
>>
>>-----Original Message-----
>>From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
>>Sent: Tuesday, July 26, 2005 6:43 AM
>>To: wsrx
>>Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once" delivery
>>assur ance
>>
>>Umit,
>>
>>I actually *do* see use cases for AtMostOnce DA observed between the RMD
>>
>>and AD. It relates to
>>best effort with duplicate detection, really. Again, consider an
>>endpoint 
>>with constrained resources.
>>It will provide reliable delivery with ExactlyOnce semantics until or 
>>unless the aggregate store of
>>unprocessed messages exceeds some threshold.
>>
>>Would I want that level of assurance for deposits to my bank account? 
>>Probably not. However, 
>>I suspect that there are probably quite a few applications for which a 
>>best effort with duplicate 
>>detection (AtMostOnce) would be more than adequate to the task.
>>
>>Cheers,
>>
>>Christopher Ferris
>>
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133




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