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.
Regards,
jacques
-----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
>
>