OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


Title: RE: [ebxml-msg] some issues affecting header design

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]