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: FW: [ws-rx] PR Issue 22: concrete proposal



>
> Let's say a certain AS sends 5 messages.  After some point in time
> the corresponding AD gets 5 messages and then asks the RMD whether or
> not it got all of the messages.  The following answers are all valid:
> 1 - yes, as the RMD, I got all 100 out of 100.
> 2 - no, as the RMD, I only got 99 out of 100 - msg 100 is missing
> 3 - yes, as the RMD, I got 1 out 1 messages
> 4 - yes, as the RMD, I got 5 out of 5 messages
>
> 1 can be true if the sequence is being used for more than one 
> application.
> 2 can be true because there's no relationship between the AS's unit of
> work and the RM sequence so the RMD has no idea if msg 100 is 
> important or
> not to this particular AD - so this info is pointless.
> 3 can be true if the RMS decides to send each message in a new Sequence.
> Unless we're doing InOrder delivery the RMS is free to make this choice.
> And even then there are ways of doing InOrder when spanning multiple 
> Sequences.
> Related to this is the assumption that the AD can ask for the status of a
> particular sequence for its messages - and if there are multiple 
> sequences
> then which one is it asking about?
> 4 can be true, and I bet this is the answer some people are expecting, 
> however
> what if the messages were split across several sequences - not all 5 
> of these
> messages could be the ones related to this AD's unit of work.  So, the 
> RMD
> saying it got all 5 messages could be totally useless information 
> w.r.t this
> AD's messages.
I agree that we have to be very careful about talking about the RMD 
reporting to the application. As your examples point out the allocation 
of application messages to sequences is out of scope. However, that does 
not mean that the RMD cannot (and should not) report the sequence state 
to an administrator. I think your examples highlight the dangers of 
talking at two different levels.

I suggest instead we focus just on the RMS and RMD. In the case of the 
RMS, if the RMS receives 5 messages for a given sequence, then it MUST 
allocate message numbers for them. At this point we can talk about which 
of *these* sequence messages are received at the RMD. There is only one 
correct answer to this.
> Its these types of ambiguities that I'm concerned about when we start 
> to add
> a new bit of information into the protocol and people immediately want to
> use it to convey other information that isn't clearly spelled out.  If we
> were talking about having this extra info just as an FYI for the RMD
> (meaning its useless in all cases but when 
> IncompletSeqBehavior=DiscardEntireSeq)
> then that _might_ be ok, but we've already heard that some people 
> think it may
> be useful to pass this information on to the application - and that's 
> when I
> get concerned because its then becomes an interop issue.
The "Highest Assigned Message Number" for a sequence is a new piece of 
information. It is a well-defined concept that is a logical consequence 
of the definitions in the spec.
> I would also point out that making the sending of a Close/Terminate a 
> MUST is actually
> something that is almost totally unenforceable.  Not that that alone 
> means we
> shouldn't add it, but if we're talking about adding a MUST I think we 
> need to clearly
> understand why.  I follow the logic that says Close/Terminate MUST be 
> sent when
> IncompleteSeqBeh=DiscardEntireSeq because the protocol can't complete 
> its job
> w/o the final bit of information (LastMsgNum) - this is the one case 
> where sending
> a close/terminate is basically enforceable because the RMS knows that 
> the RMD will
> not deliver any messages until it get this info.  But when its set to 
> all other
> values the protocol can still do everything, and if we can't rely on 
> the RMS
> ever sending a Close/Terminate then how can an RMD impl ever use data 
> that
> may actually never be sent?
If we make it a MUST, then the fact that the Close or Terminate is not 
received can be taken as evidence that the protocol did not correctly 
complete.
Almost every MUST we have in the spec is unenforceable. If I'm running 
my RM messaging engine down a North Korean mineshaft, then chances are 
all MUST bets are off very shortly. That doesn't mean these aren't 
useful in the context of a specification.

Paul

-- 
Paul Fremantle
VP/Technology and Partnerships, WSO2 
OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com
(646) 290 8050

"Oxygenating the Web Service Platform", www.wso2.com




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