Re: [wsrm] REL-13 proposal

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

I agree with Magdolna.
RM and message addressing/routing should be orthogonal. I don't think RM requires its own (or any specific)
addressing  protocol. RM specifies how the endpoint should handle messages to achieve the three reliable features.
It does not have to specify who is the endpoint.

Magdolna wrote:
> I think, we should separate two things:
> 1. what the Reliable Messaging requires
> 2. how the SOAP stack multiplexes the messages based on the entity identifiers of the endpoint applications (these are NOT WS-RM entities)

I think we should and CAN separate those two things. See the following discussion.

Iwasa wrote:
> If we use HTTP on TCP/IP, we can get those information from
> those transport protocol, but WS-R spec should be used with
> other transport protocol also. And it is better to be consistent
> to identify a message sender and receiver regardless the
> underlying protocol.

Here, a question arises: Do RM nodes have to identify message senders and receivers
for the RM features?

Suppose there is an unreliable SOAP messaging path to which we are about to add RM features.
Let's see if we need From/To to establish reliable messaging step by step:

1) [SLA] The endpoint ID may be required to establish parameter configuration on which both the sender
and receiver agree.
-- Even if it is true, do we need the endpoint id in each message?

2) [header creation] The sender may need the endpoint ID to assign sequence numbers for ordered messages.
-- This is a platform API issue. Once a message id is set, the node does not have to know the endpoint id to 
manage ordering.

3) [sending] The sender has to specify the final destination (i.e., endpoint) of message to send.
-- This feature is independent of RM (the original unreliable messaging has implemented this).
Even though the node has to keep the endpoint URI for resending, it is an implementation issue
and it does not require From/To in a message header.

4) [intermediary] Intermediary nodes have to transfer a message from the sender to the receiver.
-- This feature is independent of RM (the original unreliable messaging has implemented this).

5) [receiving] The endpoint receiver has to be aware that it is the endpoint. 
-- This feature is independent of RM (the original unreliable messaging has implemented this).

6) [handling] The endpoint node has to handle ack, duplicate elimination, and ordering 
-- It can be done without From/To.

7) [delivery] The endpoint node has to deliver messages to the application which may be related to
the endpoint URI.
-- This is a platform API issue.

My conclusion:
Since RM and addressing are not interrelated, we do not need RM's own From/To in a message
header regardless of underlying transfer protocols, or accompanying addressing/routing protocols.

Note:
- ReplyTo is another story.
- Some intermediaries may correlate RM info and the endpoint info for optimization
(e.g. control resend interval, ack for duplicated messages). -- its an implimentation issue.
- The parameter configuration issue should be discussed separately.

----- Original Message ----- 
From: <magdolna.gerendai@nokia.com>
To: <kiwasa@jp.fujitsu.com>; <marc.andrue.goodner@sap.com>; <wsrm@lists.oasis-open.org>
Sent: Friday, July 04, 2003 7:36 AM
Subject: RE: [wsrm] REL-13 proposal


> Hi Iwasa and all,
> 
> I think, we should separate two things:
> 1. what the Reliable Messaging requires
> 2. how the SOAP stack multiplexes the messages based on the entity identifiers of the endpoint applications (these are NOT WS-RM entities)
> 
> 1. Again, the Reliable Messaging doesn't require these entity identifiers, as it works appropriately without them (From/To/Service elements) as well. 
> We already decided to remove the MessageID from this header, though the unique message identifiation is needed for the reliability. Our resolution, to use the GroupID and the sequence number concatenated good enough, and keeps the reliable messaging identification in the realiability layer.
> 
> 2. The multiplexing of the messages based on the carried entity identifiers generally a usable idea, and likely will be required in the Web Services, but doesn't belong to the Reliable Messaging functionalities as it could be used well without reliability. I understand, that you argue to keep them, because currently there is no any standardized way of doing. Based on this argument we also may introduce some more elements into the protocol saying, no standardized solution exists yet, but nice to have. The problem, what I see if we keep them, that this is a "temporary" solution in the meaning, that they don't belong to the reliability. 
> 
> Last, but not least, neither of the other reliability protocols define that kind of elements in frame of reliable messaging. The WS-ReliableMessaging protocol uses additionally the WS-Addressing protocol for this purpose, the WS-Acknowledgement protocol doesn't define any of this kind of informations and even for the callback addressing uses the WS-Callback protocol.
> 
> Comments ?
> 
> br,
> Magdolna
> 
> -----Original Message-----
> From: ext iwasa [mailto:kiwasa@jp.fujitsu.com]
> Sent: July 01,2003 6:51
> To: Gerendai Magdolna (NMP/Budapest); marc.andrue.goodner@sap.com;
> wsrm@lists.oasis-open.org
> Subject: Re: [wsrm] REL-13 proposal
> 
> 
> Magdolna and all,
> 
> I think the issue is there is no standard specification for general header
> at this point. Not only From and To, but also message identification
> element might be defined in the general header specification
> if there is such specification.
> 
> And I don't believe just removing From and To from the spec is a good
> resolution, since there is no other way to identify the sender and
> receiver with consistent way regardless of the underlying protocol.
> 
> From and To can be used to identify a sender and a receiver
> of the message.
> 
> If we use HTTP on TCP/IP, we can get those information from
> those transport protocol, but WS-R spec should be used with
> other transport protocol also. And it is better to be consistent
> to identify a message sender and receiver regardless the
> underlying protocol.
> 
> In my opinion, we have two choices:
>   1) We keep From and To element in WS-R specification until
>        the standard spec for general header is standardized.
>   2) We create a separate specification for general header specification.
>        From/To, Message identification element, and some other general
>        elements can be defined in the specification. And WS-R spec
>        refers to the specification.
> 
> And I feel the option 1) above might be better for now, since we
> have limited time for the spec finalization. We may want to
> use general header spec with the next version(2.0?) of RM spec,
> but not with this version(1.1?).
> 
> Thanks,
> 
> Iwasa
>