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] i0019 - a formal proposal - take 4


+1 on deleting the paragraph containing "the RM Destination MUST NOT
deliver those messages". This clearly bleeds over into the idea of the
RMS "knowing" whether the message was delivered to the AD.

To be honest I've never understood what is so magical about knowing that
a message has been delivered to the AD. It's not as if the destination
application couldn't crash with a complete loss of state a millisecond
after the message was delivered. The RMS might report the message as
being "delivered" but is that really more useful than simply knowing the
message was received by the RMD?

- g


> -----Original Message-----
> From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] 
> Sent: Thursday, September 01, 2005 8:45 AM
> To: Doug Davis
> Cc: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] i0019 - a formal proposal - take 4
> 
> Doug,
> 
> A few smaller, potentially editorial questions:
> 
> On 01/09/05 06:41, Doug Davis wrote:
> ...
> 
> >  In the case where the RM Destination wishes to discontinue use of a
> >  sequence it may choose to 'close' the sequence itself.  In cases 
> >where
> >  the RM Destination wishes to generate a Fault but still allow RM 
> >protocol
> >  messages (for example, AckRequested) but not allow any new 
> >application
> >  messages to be processed it may use the SequenceClosed 
> Fault in place 
> >of the
> >  SequenceTerminated fault.  Since the SequenceTerminated fault may
> >  result in the state information about the sequence to be reclaimed,
> >  use of the SequenceClosed fault will allow the RM Source to still
> >  retrieve a final and accurate accounting of the state of 
> the sequence.
> >  
> >
> I find the above fairly difficult to parse.  The choices I 
> see for the RMD are to send a <SequenceAcknowledgement/> 
> containing <Final/> or to issue a Sequence Closed fault.  The 
> first choice is not covered above.  
> The second choice is covered but might be more clear without 
> repeating text from elsewhere.  How about:
> 
>     In the case where the RM Destination wishes to 
> discontinue use of a
>     sequence it may 'close' the sequence itself.  Please see 
> wsrm:Final
>     above and the Sequence Closed fault below.
> 
> >  When a Sequence is closed and there are messages at the RM 
> Destination   
> >
> >  that are waiting for lower-numbered messages to arrive 
> (such as the   
> >  case when InOrder and ExactlyOnce delivery assurance is being 
> > enforced)
> >
> >  before they can be delivered to the RM Destination's 
> application, the 
> > RM
> > 
> >  Destination MUST NOT deliver those messages.
> >  
> >
> The above seems untestable and invisible on the wire.  It 
> also applies MUSTs to the RMD to AD interface which go much 
> further than the rest of the WS-RM specification, potentially 
> to the detriment of the DA ("almost perfect in-order with 
> warnings" anyone?).  A RMD implementation which delivers all 
> messages to the AD but clearly identifies the existence of 
> gaps should be allowed.  I recommend deleting this paragraph.
> 
> >  The following exemplar defines the <wsrm:Closed> syntax:   
> >
> >  /wsrm:CloseSequenceResponse
> >
> I hope you mean <wsrm:CloseSequenceResponse> on the line above.
> 
> thanx,
>     doug
> 
> 


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