Fw: Sequence termination, and issue 19

[Daniel Millwood <MILLWOOD@uk.ibm.com>]

Forwarding on behalf of a colleague who's not a full member of the TC. --
Matthew Lovett

I've been thinking around the topic of sequence shutdown (I'm avoiding the
term 'termination' for now). The spec seems clear on the fair-weather case:
the source is in control, is always able to get ack state, and explicitly
terminates the sequence when it is happy. It is less clear in error case,
where the provider has rased a fault.

I think a guiding principle is that the source should always (within
reason) be able to get accurate ack state. That state should give them as
much information as they need to make sensible recovery decisions. That
state is also governed by the remit of WS-RM - it should only express
information about the contract between the RM endpoints, and should not try
to consider the relationship between RM and the application.

I think we should introduce a 'final' flag to the Acknowledgement header.
If final is true, then the source can be sure that the ack state will never
change. That implies that any new / retransmitted application messages will
be ignored by the provider. See below for detail on the use of this flag.
(It's also worth noting that a complete sequence that included a last
message indicator would send 'final' ack messages.)

There are a variety of possible faults, each with their own impact. I don't
think we can hope to enumerate them all, but we can define some broad
cases, and define the protocol behaviour for each:

1: Fault such that no new messages may be added to the sequence (example:
LastMessageNumberExceeded)
- From the source point of view we should be able to fill in 'gaps' in the
sequence, before terminating it cleanly
- Protocol response is an fault message including the current ack state.
The source may re-transmit gaps, and may request ack state. If the state is
ever a complete sequence from 1 - limit, then the state becomes final. The
client may send a terminate sequence message at any time. If the source
sends a new message (e.g. a higher message number) then the RM destination
should respond with LastMessageNumberExceeded fault.

2: Fault such that no new messages may be added to the sequence, and the
destination cannot accept re-transmission of older messages
- From the source point of view we are quite stuck, and need higher
intervention to sort it out [see below]
- Protocol response is a fault message, including SequenceAcknowledgement
in 'final' ack state. The source may request ack state, or terminate the
sequence. If the source does retransmit a message then the destination
should reply with 'sequence is final' fault. If the source sends a new
message (e.g. a higher message number) then the RM destination should
respond with LastMessageNumberExceeded fault.

3: Fault such that all bets are off (provider no longer has any reliable
ack state for the sequence)
- From the source point of view we are quite stuck, and need higher
intervention to sort it out.
- Rather than define some new fault messages, the provider should dump it's
state and respond to source requests with 'sequence not known'. (We could
define a new 'sequence corrupted' fault, but the source is unlikely to be
able to do any more recovery than if it gets 'sequence not known', so there
is little benefit. In addition, in this failure mode, the provider may not
have any record of the sequence anyway!)

Note that I have said that all these cases should result in no new messages
being added to the sequence. There may be some faults where that need not
be true, but to accommodate it would require another flag. That seems like
an edge case that brings more problems, and it is not strictly needed
anyway - the client is free to create a new sequence.

The final flag exists to distinguish between cases 1 and 2. In case 1 the
client is able to recover, regardless of the delivery assurance between RM
destination and application. In case 2 the client recovery processing is
more complex - to recover automatically the client needs to know if the DA
was in-order or not, and as it cannot know that it must trigger higher
level processing to sort it out. By adding the flag we allowed many faults
to be handed at the protocol level, without needing higher intervention.

In summary:
The RM source may send ack requested, even after a fault has occurred. The
RM source should send an explicit terminate sequence message for every
sequence, even after a fault. The RM destination should not drop the
sequence state until it receives the terminate message (or the sequence
times out). If the destination is unable able to clean up 'gaps' in the
sequence then it marks the ack state as final.

Matt


Thanks,  Dan

WebSphere Platform Development
MP 211
Hursley
Tel. Internal 248617
Tel. External +44 1962 818617
Email. millwood@uk.ibm.com