[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Proposal for i004
Jacques,
Discussion of wsa: header blocks, aside from specifying the values for
wsa:Action for WS-RM
operations, etc. is outside the scope of this spec.
The WS-Addressing spec says that it MAY be the same. It's their call.
What if the RM spec said it MUST be the same and the WS-TX spec said that
it MUST NOT?
Frankly, it isn't our call. The RM layer might inspect WS-Addressing
headers, but frankly, I don't
think it needs to do so for any reason.
What possible reason could you see for the RM layer to be concerned with
the wsa:MessageId?
It has its own identifier, the Sequence Identifier+MessageNumber. That is
all it should care about.
Separation of concerns.
If you want to influence treatment of wsa:MessageId, then IMO it needs to
be either via WS-Addressing
or a WS-I Profile. I suggest that you bring this up in the WSA WG if you
think that it needs to b tighter
than a MAY in their spec.
Cheers,
Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295
Jacques Durand <JDurand@us.fujitsu.com> wrote on 08/31/2005 02:51:43 PM:
> Doug:
>
>
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Saturday, August 27, 2005 6:42 AM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Proposal for i004
>
>
> Jacques,
> thinking some more about this...I'm starting to convince myself that
adding the text you want
> isn't just possibly misleading or unnecessary but actually _can't_ be
added. The WS-A spec,
> as you point out, says when the messageID can be reused but it doesn't
say anything about
> when it must/should be reused. This is very important. Some people may
choose to implement
> their soap stack such that WS-A stuff is done before RM, and in those
cases it makes sense
> that the messageID would be reused. However, this is simply an
implementation choice. There
> is no reason why WS-A processing can not come after the RM logic. Its
up to the implementation
> to make sure that whatever messageID is ultimately used will work for
proper message
> correlation of any possible response messages.
> <JD> Right. My concern was mostly to bring to the attention of an RM
developer that *in case the
> message that is retransmitted already has a wsa:MessageId header* , the
decision of what to do
> with this wsa:MessageId is not
> without consequences on the ability to compose with other wsa features.
I think that such a reminder
> cannot hurt given the special role of such a header.
> Now, we could say that is the job of a future profile (WS-I) to do so,
but from a pragmatic
> standpoint, before a profile is rolled out that specifies this, several
WS-RM implementations
> could be rolled out with a handling of wsa:MessageID that will conflict.
I know I am expressing a
> preference that may restrict some option... my rationale is that at this
point I do not see
> a convincing use case that would go against *recommending* preserving
wsa:MessageId (when it is
> there) during retransmissions,while I see some potential trouble when
not recommending so.
>
> All of this talk about reuse of messageID header is actually incorrect
- what is really important
> is the messageID that's in the wsa:RelatesTo header. That is actually
the value that MUST NOT
> change during a retry if the sender of this reply message ever hopes for
proper correlation back
> to the request message.
>
> <JD> Indeed. But I think that the chances that an implementor touches
other wsa headers other than
> wsa:MessageId
> are minimal: only wsa:MessageId lends itself to legitimate alteration
because after all, a
> retransmission is a new message.
> So if left without guidance, maybe 50% of implementers would go that
way, while very few if none
> at all would have a reason to change other headers.
> But I think a statement about the consequences of altering wsa:RelatesTo
header (or any wsa
> header?) cannot hurt.
>
> Whether the WS-A logic on the requester side uses some WS-A
> messageID generated before or after the RM logic is simply an
implementation choice. What
> matters is that the correlation _can_ take place and not how it takes
place by implying it _should_
> be on a messageID generated before the RM logic. And by implying that
the messageID should
> not change is implying an implementation choice, which I don't think the
RM spec should do.
>
> <JD> I guess it is a matter of trade-off: it is one of these areas where
my preference goes for
> removing some options because the potential composability trouble I
perceive is greater than the
> benefit from keeping this option open.
> There may be use cases I don't see, so I'd go only for a recommendation
(not a must) - or just a
> warning like:
> "NOTE: in case wsa:MessageID is present in the message to be
retransmitted, any alteration of this
> value for retransmission may impede other wsa features such as
correlation via wsa:RelatesTo."
> Would that address your concern about limiting options?
>
> Not sure how contrived this example might be but... let's say an RMS
wants to be able to do some
> sort of analysis of the network stability. So, it actually uses a
unique messageID for all retries and
> saves the list so that when it gets a response it can examine the
wsa:RelatesTo messageID to
> know which specific request retry actually made it. This could provide
additional information
> beyond just "it took 3 retries to get there" - it might be useful to
know that even though it took3 retries
> message 1 was the one that got there each time - which means that the
network might not be
> dropping messages but instead my retry interval is too small. maybe???
:-)
>
> <JD> your use case is beyond my network expertise ;-) but if I have to
make a choice between
> enabling it vs forcing network guys to find another monitoring technique
and prevent some
> inconsiderate alteration of wsa:MessageId, (even via just a warning or
recommendation) I'd go for
> the latter... take it as a stubborn but friendly dissent J.
> -J
>
> thanks,
> -Doug
>
>
> Jacques Durand <JDurand@us.fujitsu.com> wrote on 08/26/2005 07:25:45 PM:
>
> > Doug:
> >
> > Staying out of the murky waters of retransmission semantics:
> >
> > Plain and simple, I actually see issue i004 as being about
composability with WS-
> > Addressing: if a node XYZ that has added the wsa:MessageID header is
composed with
> > RMS (and before it) , then if the RMS generates a new wsa:MessageID
for each
> > retransmission, clearly that makes it impossible for XYZ to rely on
wsa:RelatesTo
> > in a received response message (the wsa:MessageID it refers to may be
different
> > from the original one.)
> >
> > Now, should we bother warning about this in the spec? I think so: it
is not just
> > about dealing with a broader bucket of bits, but affects composability
with WS-A
> > (in charter). I suspect many developers might face the same question
as Steve who
> > raised this issue: without additional guidance, it is perfectly
legitimate for them
> > to treat retransmissions as new messages that must be "uniquely
identified in time
> > and space" according to WS-Addressing - and to restrict composability
when doing so.
> >
> > Now, WS-A says: "A message MAY be retransmitted for any purpose
including
> > communications failure and MAY use the same [message id] property."
But again, that
> > is just a MAY. The one thing that an RMS developer understands when
reading that
> > statement, is that it is OK to manipulate this header when
retransmitting. So I am
> > in favor of either warning about manipulating this header in RMS, or
just prohibiting this.
> >
> > Jacques
> >
> >
> > From: Doug Davis [mailto:dug@us.ibm.com]
> > Sent: Thursday, August 25, 2005 4:34 PM
> > To: ws-rx@lists.oasis-open.org
> > Subject: RE: [ws-rx] Proposal for i004
> >
> >
> > I would not be comfortable with this because it implies some
understanding on the
> > part of the RMS
> > on what the intent/meaning... of the message is. It also implies there
is a certain
> > bucket of bits
> > that RM considers important when comparing two messages (e.g.
wsa:MessageID), and I don't
> > believe RM should get into that business. I would much prefer if RM
remained silent anything
> > having to deal with the content of the message with the exception of
the RM headerswhich are
> > clearly under its control.
> > To that end, for retransmission the RM spec should simply say that the
SeqID + Msg#need to be
> > the same. Scanning the spec I'm not sure if actually says that but I
think it
> > does imply it. If it says it
> > then I don't think any change is needed. If it doesn't actually come
right out and
> > say it then we should
> > add the appropriate text (to section 3.1 perhaps?)
> > thanks,
> > -Doug
> >
> >
> > Jacques Durand <JDurand@us.fujitsu.com> wrote on 08/25/2005 06:31:31
PM:
> >
> > > I think that two notions need be clearly distinguished:
> > > 1. what a duplicate is.
> > > 2. what a "retransmission" is, or should be w/r to the duties of the
RMS or to its
> > > scope of action.
> > >
> > > Regarding (1), I think that we are in agreement that a duplicate is
solely detected
> > > based on sequenceID/number.
> > > Regarding (2), as Anish said there is still an implicit contract
that a
> > > retransmitted message be "equivalent" to the original, not just a
message with same
> > > RM headers.
> > >
> > > Now I believe that any developer with a sound mind understands how
to implement an
> > > RMS so that within its scope of responsibility, (2) will be achieved
the best it
> > > can. However, some header elements such as wsa:MessageID are on the
borderline of
> > > what application semantics is, and could be interpreted either in or
out of the
> > > contract (2). The simple fact that issue i004 was raised, indicates
an ambiguous
> > > situation. I can see that some RMS developer with the current text,
may rightfully
> > > decide to alter wsa:MessageID.
> > > But preserving wsa:MessageID is key to the composability of WS-RM. A
processing
> > > module upstream to RMS (lets call it "PSource") that has added the
wsa:messageID
> > > header, may need to be assured that the message that has reached its
destination
> > > counterpart ("PDest"), has the same wsa:messageID as the one it has
sent.
> > > I think it is worth an explicit statement.
> > >
> > > Avoiding the minefield of trying to define "equivalent" messages, a
minimal
> > > proposal I would back for i004 is one where it is clear to
implementers that an RMS
> > > must not alter wsa:messageId when retransmitting.
> > >
> > > Now, it is also in the scope of this specification (RM Policy
Assertion) to define
> > > precisely (enough) the semantics of the concepts expressed in
policy assertions,
> > > including "retransmission". Being more precise than the current text
without being
> > > too tight, a definition "by intent" could be like: "Retransmission
is an operation
> > > that ensures that the retransmitted message has the same effect on
its consumer as
> > > the original message would have, given the expected processing up to
consumption
> > > and all other things being equal."
> > > I think a definition like this would be an improvement, but that
does not remove
> > > the need to separately disambiguate the case of wsa:messageID.
> > >
> > >
> > > Jacques
> > >
> > >
> > >
> > > From: Jacques Durand
> > > Sent: Thursday, August 25, 2005 11:26 AM
> > > To: 'Anish Karmarkar'; Marc Goodner
> > > Cc: ws-rx@lists.oasis-open.org
> > > Subject: RE: [ws-rx] Proposal for i004
> > >
> > > I think Anish has a point.
> > > I believe that Resending MUST not alter wsa:messageId, nor anything
in the SOAP envelope.
> > > - wsa:messageId may have some relevance w/r to MEPs, and whoever on
the Sender side
> > > will verify that a wsa:RelatedTo is correlating with a previous
wsa:messageId must
> > > be sure of the messageId that has been received, regardless of which
retry made it
> > > to the RMD. If messageId may be altered by the RMS or further
intermediary, that
> > won't work.
> > > - also, that may affect the validity of signatures. In 6.3 of SOAP
Binding for WS-
> > > Addressing, there is clear requirement that "To avoid breaking
signatures,
> > > intermediaries MUST NOT change the XML representation of
WS-Addressing headers when
> > > relaying those headers." The RMS may act as intermediary, and
resending is just a
> > > relaying technique...
> > > Jacques
> > > -----Original Message-----
> > > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> > > Sent: Thursday, August 25, 2005 10:46 AM
> > > To: Marc Goodner
> > > Cc: ws-rx@lists.oasis-open.org
> > > Subject: Re: [ws-rx] Proposal for i004
> > > Marc,
> > > The reference you have provided is the submission document. That
> > > sentence has been removed from the CR docs [1] [2].
> > > The spec does not say anything about the content of the message on
> > > retransmission and I don't see [message id] as being special (as far
as
> > > WSRM is concerned). Therefore, I don't see any reason to say
anything
> > > specific about [message id].
> > > But I'm curious as to why you used a 'may' in your proposal. Do you
see
> > > any reason why this [message id] would be different? I had assumed
> > > (since the spec does not say) that the retransmission would have the
> > > same message content at the Infoset level. Do you see it otherwise?
> > > My concern about [message id] is that:
> > > a particular message may be part of an MEP (such as a request
message in
> > > a req-res MEP). The reply message then has to use the [message id]
of
> > > the request message in its [relationship] property. This is used to
> > > correlate the reply message with the request message. If the
[message
> > > id] on retransmission is changed by the RM layer this will lead to
problems.
> > > In any case, reliability is based on the fact that the receiver can
> > > detect duplicates (based on seq id/message no) and duplicates are
copies
> > > of the same message and can be discarded by the receiver.
> > > -Anish
> > > --
> > > [1] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/
> > > [2] http://www.w3.org/TR/2005/CR-ws-addr-soap-20050817/
> > > Marc Goodner wrote:
> > > > "A message MAY be retransmitted for any purpose including
communications
> > > > failure and MAY use the same [message id] property."
> > > >
> > > >
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/#_Toc77464
> > > > 322
> > > >
> > > > So as I said no further clarification should be needed in WS-RM.
> > > >
> > > > -----Original Message-----
> > > > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> > > > Sent: Thursday, August 25, 2005 12:29 AM
> > > > To: Marc Goodner
> > > > Cc: ws-rx@lists.oasis-open.org
> > > > Subject: Re: [ws-rx] Proposal for i004
> > > >
> > > > Marc Goodner wrote:
> > > >
> > > >>I've looked into this issue and I believe it is not an issue and
> > > >
> > > > should
> > > >
> > > >>be closed as follows.
> > > >>
> > > >>
> > > >>
> > > >>Proposal:
> > > >>
> > > >>Web Services Addressing says that the wsa:messageID may be the
same
> > > >
> > > > for
> > > >
> > > >>a retransmitted message. Therefore when a message is retransmitted
> > > >
> > > > with
> > > >
> > > >>the same wsrm:{Identifier, MessageNumber} pair the wsa:messageID
may
> > > >
> > > > be
> > > >
> > > >>the same. The correct use of wsa:messageID need not be
redocumented in
> > > >
> > > >
> > > >>this specification therefore this issue should be closed with no
> > > >
> > > > action.
> > > >
> > > >
> > > > Shouldn't it say 'MUST' rather than a 'may'? Why would the
wsa:MessageID
> > > >
> > > > (or more appropriately [message id]) be different for a
retransmission
> > > > in the context of WSRM? Or for that matter anything else in the
Infoset
> > > > that is transmitted.
> > > >
> > > > Also, can you point me to the text in WSA where it says this?
> > > >
> > > > Thx!
> > > >
> > > > -Anish
> > > > --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]