RE: Can anyone point us to information on WS-Reliability

Assaf, a few following questions about your comments ...


>2.2.3 There are cases where message loss is not an issue and therefore
>persistence is not required (best-effort). Would be great to have
>best-effort guarantee that does not require any persistence.

Isn't "best effort" always the case today when "guaranteed" is non-existent 
?  If message is affordable to be lost, then we already have it today, 
which then is out-of-scope of the WS-Reliability.
But I agree that it doesn't require persistence at the sending end to 
achieve guarantee delivery.  For example, the sender-RM layer can hold the 
sender-App waiting until it get back an ACK from the receiver-RM.  In other 
words, we reduce the need of persistence by using a more synchronized approach.


>3.3.1 I'm not a big fan of the start/continue/end approach as presented
>here. I think it actually makes implementation using a process engine less
>efficient, especially if your conversations are open-ended, and we are
>starting to see more and more of that in business scenarios. Of course you
>can always have arbitrary sequences (e.g. week long sequence with
>removeAfter set to true at the end of the week), but then you can't tolerate
>message loss in the sequence and you need
>yet-another-state-management-thingy. Alternative approach for sequencing
>(e.g. m' follows m) would be much easier to support and tolerate message
>loss.

I think "conversation" is a different thing.  Only part of your 
conversation requires the message sequence ordering to be preserved, in 
such case you use the "start/continue/stop" to specify that.
Can you elaborate why (m' follow m) is better than sequence number ?  I've 
seen some characteristics of your approach
a) The receiver never know if message ordering need to be preserve and also 
don't know when to stop tracking
b) Once message lost happen, the receiver has no idea how many messages has 
been lost


>For issue 4, receiver should hold to out-of-sequence message until it
>decides to expire it at which point it should not process any previous
>message. That would require a denied fault which the received should be able
>to communicate indicating it received the message, there's nothing wrong
>with the message, it simply has no intention of processing it.

What is unclear about the spec. is how the "expiry time" is related for 
those messages within a sequence ordering guarantee.
For example, if the receiver get message 1, 2, 3, 4 and discover message 2 
is already expired, does it still keep 3 and 4.
Another case, if the receiver get message 1, 3, 4 and then get message 2 
later but it already expired, does it throw away 3, 4 (it may already send 
ACK for 3, 4)

Best regards,
Ricky

Received on Friday, 10 January 2003 11:31:37 UTC