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
I meant RM-Reply as defined in the WS-Reliability 1.1 specification.
On 20-Sep-04 16:25, Jacques Durand wrote:
> Doug:
>
> Let me try to cut short on commenting on a previous unclear comment..:
> I believe we'll need an ebMS message ID in addition to the RM ID,
> even if an implementation could weasel its way out - which I am not even
> sure yet.
>
> My turn to be puzzled by your fisrt paragraph below:
> Because RM-Replies are only visible to RMPs and are correlated by these
> to reqeust(s) based on RM IDs.
> I guess by RM-Reply you mean [business] response that uses "response"
> reply pattern?
> So the use of RefToMessageId seems rather orthogonal to this - it would
> allow for correlating in ebMS
> where RM headers are no longer visible.
>
> Jacques
>
>
>
> -----Original Message-----
> From: Doug Bunting [mailto:Doug.Bunting@sun.com]
> Sent: Monday, September 20, 2004 2:32 PM
> To: Jacques Durand
> Cc: 'Jeff Turpin'; ebxml-msg@lists.oasis-open.org
> 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]