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] PR Issue 22: concrete proposal


Dan:

 

In the absence of :

(1)     a requirement document for WS-RX

(2)     Delivery assurance definitions that drive the need for protocol features,

 

I admit that it is very difficult to give a solid ground to actually any protocol feature.

 

Your assumption that “AS doesn't care, in which case … AD doesn't care either”

Is as good as any other, but you can’t rule out scenarios like:

 

- RMS is in a mobile device sending a sequence over a business day, and needs to shut down overnight before resuming next day.

- AD needs to have all messages of the day (variant: a good percentage of these) before processing them further. RMD wants to know at the end of each day if it got all the messages or not, because if yes their processing by AD can move on overnight, instead of waiting next day for hopefully more successful resending of the previous day misses, in another sequence.

 

 

Jacques

 

 

 


From: Dan Leshchiner [mailto:dleshc@tibco.com]
Sent: Thursday, November 16, 2006 10:07 AM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] PR Issue 22: concrete proposal

 

Current spec:

"<CloseSequence> indicates that the RM Destination MUST NOT accept any new messages for the specified Sequence"

Observe:

if RMS issues CloseSequence before receiving all the acks, RMS is implying that is is not interested in completing current sequence as is.

Implications:

- if RMS wants to complete the sequence, it MUST NOT issue CloseSequence until RMS receives all the acks.
- if RMS does not want to complete the sequence, then
 (a) it is because AS doesn't care, in which case there is no error and there is nothing to log on RMD side and AD doesn't care either, or
 (b) RMS intends recovery by analyzing FinalAck and placing un-acked messages into a new sequence; once again any logging or other RMD action are spurious, since "protocol" hasn't completed yet.

- if RMD does not care (by configuration) about completing incoming sequence, there is no error to log if sequence is incomplete
- if RMD does care about completing incoming sequence, RMD needs to force certain behavior out of RMS, namely, RMS waiting to issue CloseSequence until RMS receives all the acks, perhaps, through the use of an appropriate policy assertion. then, if RMS is compliant, receipt of CloseSequence indicates to RMD that sequence is complete and HighestAssignedSeqno field provides no additional value.

Conclusion:

HighestAssignedSeqno is useless.

Durand, Jacques R. wrote:

Gil:
inline
 
-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] 
Sent: Wednesday, November 15, 2006 2:51 PM
To: Durand, Jacques R.; Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
 
Jacques:
 
Point by point:
 
(1) It's not clear whether you support LastMsgNumber as a MUST in
TerminateSequence. The requirement for supporting this depends upon the
requirement for sending CloseSequence.
 
<JD> Given that we seem to agree on (2) below, I think we don't need to
make LastMsgNumber mandatory in TS - it should normally be always
communicated via CloseSequence.
 
(2) If it would allay your concerns, I would support the notion of
adding a
"Advize" value to IncompleteSequenceBehavior. The algorithm would be, if
IncomplateSequenceBehavior=[DiscardEntireSequence | Advise], then the
RMS
MUST send a CloseSequence message. What do people think about this?
 
<JD> I find this reasonable.
 
 
(3) While I think Bob's idea of requiring the CloseSequence message to
be
treated like a Sequence Traffic Message is interesting, it represents
too
great a change to make at this time. I'm also against the idea of
requiring
the RMS to retry either the CloseSequence or TerminateSequence messages
although we could note that an RMS MAY do so if it's willing to handle
the
possible fault(s) that may result.
 
<JD> Not saying anything in the specification about this is fine.
An RMS that needs a final Ack will normally send CloseSequence and
repeat it if needed to get this finalAck along with the ClSR. This
repeat is not required, but supported by those who care about this
feature. Same here: could be controlled by some out-of-scope policy
detail that only recommends a level of retries, for those who care.
Bob's idea, regardless of its merits, brings change to the model of
separation traffic/lifecycle message, and may have ripple effect
throughout the spec.
 
-Jacques
 
 
- gp
 
  
-----Original Message-----
From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] 
Sent: Tuesday, November 14, 2006 8:14 PM
To: Gilbert Pilz; Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
 
Gil:
 
I see three aspects in your proposal that need to be looked 
at - or agreed on:
 
(1) Whether the LastMsgNumber is a MAY or a MUST in CloseSequence.
(2) Whether the CloseSequence message MUST be sent by the RMS 
(or MAY, as of today). Similar issue with TerminateSequence.
(3) Whether any extra effort may be required to ensure the 
reception of this LastMsgNumber marker, which is important 
after all to your goal.
 
On (1), based on off-list conversations in our little task 
force, I have no qualms anymore making it an unconditional 
MUST. We see this creates no extra burden on an 
implementation and that reduces the number of options. In the 
same way as CloseSequence is the means to query a final ack 
(for whatever use it serves), we could just decide it is also 
the means to communicate a final sequence account. So fine.
 
On (2) I am not comfortable making this an unconditional MUST 
as a general rule. After all, in many cases (where precisely 
the RMD awareness you want to support is not required) the 
RMS should not have to bother sending these lifecycle 
messages. But I think you could achieve your goal at protocol 
level (without conditioning this MUST to an external 
agreement or DA), by relying on IncompleteSequenceBehavior 
(ISB).  Clearly if ISB is DiscardEntireSequence, it makes 
sense that RMS be required to always close such sequence. We 
could imagine another value for it like "JustAwareness" that 
does not discard the sequence but requires awareness of 
incompleteness, meaning also required closure.
 
On (3), I'd say some retry of CloseSequence would be expected 
but should not be more specified than the retry of traffic 
messages - left to external policy / agreement. Bob's 
solution is tempting, but need to look at the implications of 
making a lifecycle message also be a traffic message. Now I 
think if you add a Sequence header to CloseSequence, you do 
not need anymore LastMsgNumber...
 
 
Jacques
 
 
-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Tuesday, November 14, 2006 3:27 PM
To: Durand, Jacques R.; Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
 
Jacques:
 
You are right, there is a difference between (b) and (a). In 
my mental model
(b) is inclusive of (a). That is to say, whenever the "all 
messages received scenario" (described) below occurs, the RMD 
knows that it has received all the messages that were sent.
 
I think we are in agreement about the expected behavior of 
both the RMS and the RMD, we just need to agree on the 
language to describe it.
 
- gp
 
    
-----Original Message-----
From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: Friday, November 10, 2006 7:48 PM
To: Gilbert Pilz; Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
 
Gil:
 
Actually, your initial goal as stated in your proposal:
 
(a)
" [In order] to allow the RM Destination to determine if it has 
received all of the messages in a Sequence,..."
 
Is not quite the same as:
 
(b)
      
All we want is for the receiver
to have the ability to determine if this scenario 
        
occurred or if it
    
didn't
 
The difference between these, is that in (b) you do not care at all 
about receiving a TS/CS or not (in case not, the scenario 
      
just did not 
    
occur...), while in order to achieve
(a) you absolutely need a TS+LM or a CS+LM, otherwise you can NOT 
determine if the messages you received form a complete 
      
sequence. Now 
    
we know that this last goal (a) is not always achievable 
      
due to loss 
    
of CS/TS. But we know it is desirable that the protocol 
      
does its best 
    
to ensure it.  Which is why Stefan's question is legitimate.
 
Let's assume (a).
 
My take on this, is:
- an implementation should not be required to do this extra 
      
effort of 
    
resending CS or TS (concede it may not be clear in my 
      
previous mail).
    
- in case an implementation decides to support this extra effort 
(controlled by an external agreement, like details of 
      
traffic message 
    
resending), it is sufficient to do resending of CS, not of TS.
- In all cases, and RMD implementation never needs to keep sequence 
state after it got the TS.
 
Not sure where the "overkill" is :-)
 
Jacques
 
-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Friday, November 10, 2006 3:36 PM
To: Durand, Jacques R.; Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
 
This is a giant overkill. Consider the following scenario:
 
1.) RMS and RMD exchange CS/CSR
 
      
 
  
2.) RMS sends a number of messages. Very few, if any, are lost.
 
3.) RMD acks the messages.
 
4.) RMS re-sends any messages that aren't acked; RMD 
      
eventually gets 
    
them and acks them.
 
5.) RMS and RMD exchange TS/TSR.
 
I would argue that this scenario will apply to an overwhelming 
majority of the WS-RM Sequences that are ever created. All 
      
we want is 
    
for the receiver to have the ability to determine if this scenario 
occurred or if it didn't.
It's a very simple idea. If some of the messages never get through 
(including CS or TS) that falls into the "something went wrong with 
the Sequence" bucket.
 
- gp
 
      
-----Original Message-----
From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: Thursday, November 09, 2006 3:29 PM
To: Stefan Batres; Gilbert Pilz; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
 
Stefan:
In the light of today's discussion, and looking at this from an 
"agreement" perspective, where the requirement for an RMD 
        
to notify 
    
its party if it missed any message in a sequence is
        
conditioned by an
      
[out-of-scope] agreement that would be known from both parties:
 
- if there is such an agreement, then I would assume the RMS must 
ensure the RMD got its LM (and if it failed to do so,
        
should notify,
      
etc.) But this agreement could mean for RMS to do LM in
        
CloseSequence
      
and retry as much as needed, until getting the CSR, instead of 
focusing on TS. That seems more appropriate because the
        
time between a
      
CloseSeq and a TS is precisely intended for both parties 
        
to get in 
    
sync.
 
- It does not have to mandate more from TS/TSR, which 
        
would be more 
    
demanding on implementations: if RMD sent its TSR, it
        
should be free
      
to reclaim resources immediately, regardless if RMS got 
        
it. RMS may 
    
try to resend TS with no success but there is no harm:
        
TS/TSR are just
      
resource optimization features as before, once LM has been
        
secured by
      
CloseSequence exchanges.
 
-Jacques
 
-----Original Message-----
From: Stefan Batres [mailto:stefanba@microsoft.com]
Sent: Thursday, November 09, 2006 1:00 PM
To: Gilbert Pilz; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
 
Gil,
 
This seems sane too me. I do have an issue that is not directly 
related to PR0022 but seems somewhat related to how we address it.
With the spec as-is and with your proposed changes we 
        
don't have a 
    
quick resource reclamation mechanism like we did in the submitted 
spec. For example:
 
I am an RMS.
I send one of these TS with LM.
Should I retry if I don't get a response? Probably yes.
 
You are an RMD.
You get my TS with LM.
You send a TSR.
Since the TSR might get lost, and because I might retry 
        
the TS, you 
    
should be ready to respond to my TS retry.
How long do you remember the sequence in case I retry?
In the submitted spec, if you got the TS you could
        
immediately forget
      
about the sequence and never respond again. This worked
        
because we put
      
the LM in a Sequence header.
 
Thanks
 
--Stefan
 
 
-----Original Message-----
From: Gilbert Pilz [mailto:gpilz@bea.com]
Sent: Thursday, October 26, 2006 12:49 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] PR Issue 22: concrete proposal
 
Attached is a proposal for PR i022 in the form of a diff against 
CD-04.
The main points are:
 
1.) wsrm:TerminateSequence has been expanded to include a 
        
mandatory 
    
LastMsgNumber element the value of which is, surprisingly
        
enough, the
      
number of the last message in the Sequence.
 
2.) Sending wsrm:TerminateSequence is now mandatory; 
        
basically the 
    
whole thing won't hold together unless the RMS is required
        
to send a
      
wsrm:TerminateSequence.
 
 <<wsrm-1.1-spec-pr-i022.pdf>>
 
        


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