Re: Why is [message id] required for requests but not for other messages?

Conor P. Cahill wrote:

>
> PS.  I'm sure the reason why this was called MessageId originally was 
> that people thought that it would be good to reuse the same unique 
> identifier in some cases of messages where this makes sense (clearly, 
> this would work with point-to-point messaging).    WS-A could handle 
> this by defining a specific correlation URI that states that the 
> correlation Id is carried in the message identification context of the 
> message and set this as the default should the CorrelationID not be 
> specified.

I think if we're going to get into the notion of sessions and 
correlation ids, that we should step back a moment. The WS-Context 
specification (http://www.oasis-open.org/apps/org/workgroup/ws-caf/) has 
been developed to cover that area and it would be best not to reinvent 
the wheel here. If you're not considering multi-message exchange 
correlations, then I'd suggest we stick with MessageId.

Mark.

>
> On a related note, the current model of determining whether or not a 
> reply is expected based upon the presence or lack thereof of some 
> sort-of-related data (ReplyTo, MessageID) seems kind of broken to me.  
> Why don't we just have a flag somewhere (perhaps an attribute on the 
> wsa:To) that says a reply is expected.   I'm normally the one for 
> arguing against bits being added to a message, but I think this makes 
> things much clearer from an implemetnation point of view.
>
> Conor
>
> Conor P. Cahill wrote on 6/15/2005, 9:43 PM:
>
>>
>>
>> David Hull wrote on 6/14/2005, 2:40 PM:
>>
>>> We are currently trying to define the semantics of [message id], and 
>>> I would like to understand the use cases.
>>
>>
>> I think the problem is that we aren't really talking about a 
>> MessageID at all.   The object that the spec refers to is really a 
>> CorrelationID and not a MessageID and the name is confusing everybody 
>> into trying to add semantics to it that shouldn't be there.
>>
>> I think you need to be able to track the Correlation ID separately 
>> from the MessageID (if some other spec ever defines a MessageID) 
>> because in the case of intermediaries that are relaying messages, I 
>> would expect them to assign their own messageID as they sent off the 
>> message, but leave the Correlation ID alone.  This would be 
>> especially useful in the case where the submission path across 
>> intermediaries did not match the return path (which is very possible).
>>
>>
>> Conor 
>

Received on Thursday, 16 June 2005 12:50:35 UTC