MHonArc v2.5.0b2 -->
ebxml-msg message
[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]