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

Title: RE: [ws-rx] i0019 - a formal proposal - take 4



I guess you can look at my example from the other side too: there is still value in the AS being made aware of delivery failures asap - even those that occur after reception -, meaning not waiting for a business-level handling, and if possible without relying on out-of-band signals. My example can also be used to make the point that the more the protocol is aware of, the better...

But that is another debate, if we ever get into it.




From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Tuesday, September 06, 2005 11:47 AM
To: Jacques Durand; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a formal proposal - take 4




I completely agree with you. That's why I think that, in general, it is a waste of time for the RMS to worry about whether or not the RMD has delivered a message to the AD.


- g


From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Friday, September 02, 2005 4:18 PM
To: Gilbert Pilz; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a formal proposal - take 4

+1 on deleting this paragraph too. I missed it before: this behavior is purely DA driven (and BTW, it also makes a strong assumption on all InOrder DAs, while I have not read anything in the spec that prevents me from interpreting bare-bone InOrder DA and even AtLeastOnce+InOrder DA as allowing gaps in an ordered delivery - knowing that atLeastOnce does not guarantee reception... am I missing something ???)

Gil, to answer your second paragraph:

-In the case you mention, the message may have been lost, but that happened under the responsibility of other parts of the system: the RM contract is satisfied as far as the RMD is concerned. Sure there are some freak cases where the message may fall through the cracks, but that does not mean that even your case is undetectable or unrecoverable: only that would take place by other means, probably more "costly" e.g. a "verification list" of all purchase orders IDs sent over the week can be sent out to the application for last double-check, and missing ones would finally be detected and dealt with at business level (e.g phone call). The value of RM would be to reduce greatly the delay and the cost of dealing with such misses at business level, by dealing with as many failures as possible at protocol level.


-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Thursday, September 01, 2005 11:48 AM
To: ws-rx@lists.oasis-open.org
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

BEAWorld 2005: coming to a city near you.  Everything you need for SOA and enterprise infrastructure success.

Register now at http://www.bea.com/4beaworld

Santa Clara 27-29 Sep| London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec

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