Re: [wsrm] Rel 33: some thoughts and proposal...

[Jun Tatemura <tatemura@ccrl.sj.nec.com>]

Sunil,

Can we call it "delivery"?
Because RM is about "delivery guarantee,"
we need to somehow define "delivery" anyway
by stating the boundary of RM's responsibility.

The definition can be something like this --
"Delivery of a message" means
to make the message available to the receiver (i.e., the next layer).
At the time of delivery, the responsibility of message preservation
is transferred to the next layer.
Note that the delivery does not mean the message has accepted
or processed by the user application. For example massages may
be queued or stored (in the next layer) for later processing.


----
The rest of this mail is my thoughs on Ack semantics.

Ack semantics can be defined with transfer of message preservation
responsibility:
[1] peer-to-peer Ack semantics (the current spec)
Ack means that the message preservation responsibility has been
transferred from a node to the next node.
[2] end-to-end Ack semantics (Jaques' proposal)
Ack means that the message has been "delivered"

I agree with Jaques' point, that is,
by taking the semantics [2], the spec and implementation
can be simplified significantly.

The message preservation responsibility will be transferred in the
following order:
1. sender application (layer)
2. sender node
3. receiver application (layer)

Note that the receiver node(and intermediaries if any) does not appear
in the above transition list.

The receiver node is no longer responsible for message content
preservasion. The only responsibility of the receiver node
is preservation of message metadata (for duplicate elimination and
ordering) until expiration time. The receiver can discard received
messages anytime. The receiver node may preserve disordered messages
for better performance.

An intermediary node may preserve, resend, eliminate, or order
messages, but it is not responsible for either message content
or message metadata preservation.

For performance issues, there can be additional
peer-to-peer control messages (e.g., between
the sender and an intermediary), but it would be out
of scope of the first spec.

Jun Tatemura

Sunil Kunisetty wrote:
>  
>  Peter,
> 
>  We are indeed referring to  RM Ack and not Application/Business App. We 
> discussed this
>  in the Oracle F2F and we definitely said the latter is outside our 
> realm.  The current proposal
>  for REL 33 is more like a transport Ack and Jacques and I are 
> suggesting to make it more like
>  a RM Ack. So seems like you are in agreement with us and your only 
> concern is the usage
> of words.
> 
>  Before I list the choices, I just want to re-emphasize that this 
> (correct usage of words)  issue is
>  sort of orthogonal as we use the same phrase in defining the Ordering 
> semantics also.
>  
>  So let me list the choice of words:
>    1) "make it available to the application/user".
>    2) "make it available to the next layer".
>    3) "RMP passing responsibility for the message to the user"
>       [I copied this from the Tom's meeting minutes as Pete W. saying so]
>    4) "Transferring the responsibility to the next layer".
>       [i vaguely recollect someone saying it in the call.]
> 
>  Does any one have any other suggestions? In the above list, I prefer 
> option 2 with a comment
>  that the next layer could be the application user itself.
> 
>  Thoughts?
> 
>  -Sunil