Re: [ebxml-msg] some issues affecting header design

[Doug Bunting <Doug.Bunting@Sun.COM>]

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
>