[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-msg] some issues affecting header design
Jacques, I am not sure I understand your last comments below. In WS-R, correlation of the response using the "layer below" is unnecessary[1] in general. While that may be the most obvious way to do some correlations, RM-Reply information MUST be correlated with the original message using the RefToMessageId mechanism because multiple RM-Replies may always be grouped together. It is true, the business payload might be correlated using the underlying protocol. This results in a bizarre architectural layering: SOAP extensions supporting the "infrastructure and the underlying protocol supporting the "application". It is also unspecified in the WS-Reliability specification. Other mechanisms (such as identifying the relevant request in the first RM-Reply) are possible through out-of-band agreement. In short, "supported by the layer below" does not immediately imply "necessary". Could you please explain your thinking more completely? thanx, doug [1] ... as in REQUIRED in the RFC 2119 sense On 20-Sep-04 11:58, Jacques Durand wrote: > 5. Message identity: > do we need an identity in addition to RM identity. That is still > unclear. > Implementation aspects (which MSH+RMP architectures will/not handle > a single indentity?) need be considered. > > [JWT] Although multiple identities(MessageIds) in the Message would > seem redundant and confusing, it might be necessary to correlate > messages within an MEP at the MSH level. However, you are correct, > this is still unclear, and arguments can be made for and against > this. We definitely need to discuss this further. > [Jacques Durand] I see one case where the MSH needs to correlate > Response wirth Request . In case this is implemented with SOAP > request-response MEP, we can assume the correlation is supported by > the layer below. But depending on what kind of duplicate scenarios > we expect, and whether we still want this correlation even for > asynchronous ebMS Request-response MEPs, we may need a distinct ebMS > ID. It also depends on the role we expect from RefToMessageId. > > > > Jacques
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]