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.

I tend to break this problem into multiple layers. First, asynchronous
delivery and processing. I don't even call it best-effort. Second,
asynchronous delivey with retries and duplicate elimintation which increases
reliability. Best effrot. Third, persistence which allows you to keep
resending a message after a point of failure.

If I get to the point where my app is blocking, I might as well use
synchronous messaging and put a transaction around it. So I might be using
WS-Tx or BTP.

What I want is send & forget. And send & forget is where I could experience
message loss, so I need reliable messaging. Now, if WS-Reliability only does
reliable send & forget, that's not a bad proposition. But if some other
specification does send & forget and also have reliability as an option, I
would tend to use the more generic one because it applies in more cases.

I would definitely favor the specification that addresses all the levels of
asynchronous communcation.


> 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.

I understand that, but it requires a lot of state management. And
practically, makes no difference. If you just keep a sequence for all
messages sent in the same week, and you use that sequence of numbers in all
your conversations, you would get the same thing. And that would require
less state management. So it doesn't "look clean" but its more efficient and
you don't lose anything.

True, the sequence numbers are not consecutive within a conversation. But
then group is not a conversation, if it was a conversation it would have to
address open-ended conversations. And if you run out of numbers you have to
switch to a different group, even if you're in the same conversation.

So the whole mechanism of group state/continue/stop doesn't seem to buy you
much,

> Can you elaborate why (m' follow m) is better than sequence
> number ?

Very simple. I send you message m1 in conversation A. I send you message m2
in conversation B. I send you message m3 in conversation A which I say
follows message m1. I expect you to process m1 ahead of m3, so if you
haven't received m1 one yet, don't begin processing m3. But if you received
m1 and m3 you can start processing them even if m2 is lost. Conversation A
may progress faster than conversation B, but that's ok because the
conversations are not related. So it also provides better failure isolation

> 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

The receiver doesn't need to know or care whether messages were lost per se.
What you actually need to do is preseve casual ordering of messages. So
messages have to be ordered with respect to each other within a
conversation, but overall messages can be lost, or discarded.


> >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.

That's my point. If message 2 arrives after it expires that is considered
message loss. Loss doesn't mean just lost in transient. Receipt of message
after its expiration is also considered message loss. The way to counteract
this is to say, 3 you can process after 1 even if 2 was lost, so go right
ahead and process it. 4 you need to process after 2, so we'll deal with loss
of 2 but not preclude processing of 3.

Not argurable I could get the same behavior by putting 1/3 and 2/4 in
different groups as 1/2 in each group. In this case a group is a sequence
that observes casual order of all messages, in other words a conversation.
But then start/continue/end become problematic. Here's why:

- The first message in a group is always the start and it's always numbered
0. So the 'start' identifier is redundant you can derive that from the
message number.

- Conversations are open ended. For example, I can send message m3 and based
on the reply I may or may not send message m4. So is message m3 'end' or is
there no 'end' message in this group, or do I need to invent an empty
message to signify 'end'?

arkin

> 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 14:20:38 UTC