[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
I believe we can't avoid talking
about DA at some point, when defining the ultimate problems we solve... The fact is, the protocol -
regardless on how independent we want its *operation*
to be from DA concerns - is ultimately serving the DAs. Even if the TC
decides that the protocol must have a life on its own (I am not saying I am a
big fan of this), the value of every feature in it depends on how well it
serves the DAs. The way I see it, the Ack mechanism is not
just serving a resending protocol mechanism (which itself serves AtLeastOnce),
but it is also serving the raising of errors - delivery failures - on the
proper endpoint (an other aspect of AtLeastOnce). A lack of accuracy in the acknowledgement
mechanism will affect this error raising and affect the related DA, here
AtLeastOnce. Issues i019 and i028 have been only pointing at the protocol
shortcomings here, though there is the DA concern I just described behind it. Now, on a more touchy subject, DA
continuity through sequence transition is another issue that has not been clearly
stated from the start although extensively alluded to in this thread, and I would
argue that it is within scope of this TC to *enable*
continuity of DA, if not to prescribe how to resolve it. DA definitions in
WS-RM actually never scope these DAs to an arbitrary set of message e.g. by
saying : "within the scope of a sequence". The notion of "sequence"
appears to just be a means to an end, an arbitrary scoping of protocol behavior.
Since sequences may be terminated for diverse reasons, it is legitimate to
worry about the continuity of DA support across sequences. It is clear to me
that a pre-condition to this continuity (regardless of how it is implemented,
which we may want to remain out of specification scope), is that the protocol enforces
clean termination of sequences and accurate status. This is again what the
proposal to i019 and i028 supports. Regards, Jacques From: Giovanni Boschi
[mailto:gboschi@sonicsoftware.com] Two <GB> Inline comments
below. At this point I feel we are proposing to significantly complicate
the protocol, without solving any clearly identifiable problem. Regards, G. From: Doug Davis
[mailto:dug@us.ibm.com]
<GB> At least when we started, there
was an actual problem we were trying to solve. Now it sounds like the
proposal doesn't solve it, but we like the proposal anyway for some other
reason, and what I'm reading is that this is all OK as long as we are
careful not to suggest that the proposal solves any particular problem. This is very important. It
purposely does not get into that area because, as others have stated, things
like linking of sequence should probably be done by some higher level
processing, which is out of scope (as of now anyway). <GB>
Forget linking of seqences. From the language in proposal 3,
("After line 396, ...") "...this would
leave the RM source unsure of the final ranges of messages that were delivered
to the destination". Please explain how, without knowledge of the
destination DA, this problem isn't still there. Please don't
tell me it doesn't matter, or that we'll deal with it later, in a
separate issue, because I don't know if we will or not; We will be
asked to consider this proposal on its own, and decide if it solves the
problem. At this point I have to conclude that it does not. And 2) this problem exists for
other areas of the spec, not just this proposal. Let's say the an RMS
reaches the MaxMessageNumber, as defined by the RMD. The way to resolve
this is to create a new sequence to continue - well how can we guarantee the
ordering will be preserved across the sequences? Same problem. So
this proposal does not introduce a new problem, the problem is already there.
However, that being said, and even though several people have said that
doing things like preserving the order across sequences is something for a
higher-level processing, I do personally believe that the spec should provide
an aide to that processing. But I view that as a separate issue and not
part of this one.
Clearly
1) and 2) are outside the scope of the TC and, in my view, this proposal might be
defining 2) in an informal way that is specific to WS-RM.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]