RE: [ws-rx] New PR Issue: Piggy-backing problematic

["Gilbert Pilz" <Gilbert.Pilz@bea.com>]

Inline . . .

---

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, October 23, 2006 5:19 PM
To: Gilbert Pilz
Cc: Paul Fremantle; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] New PR Issue: Piggy-backing problematic

The RM spec says:

Some RM header blocks may be added to messages that happen to be targeted to the same Endpoint to
which those headers are to be sent (a concept often referred to as "piggy-backing"), thus saving the
overhead of an additional message exchange. Reference parameters MUST be considered when
determining whether two EPRs are targeted to the same Endpoint.

Doesn't this guarantee that we're not just looking at the URI, and thus eliminating your concerns? 

 

<gp> I can't tell you because I don't know what it means to "consider" a reference parameter. Does "consider" mean "compare" and, if so, does it mean compare all the reference parameters or just the ones I understand? If the former, tell me how to generically compare arbitrary XML elements (canonicalization, etc.). If the later, what if there is a significant difference in the reference parameters I don't understand?

If AckReq can only be on messages with a Sequence header with the same identifier, then we might as well
just add a "forceAck" flag to the Sequence header element. 

 

<gp> I'm confused. I thought you could still send an AckReq in a message with an empty body? It would probably make more sense to re-define AckReq as a stand-alone message, but I still think its valuable for the RMS to be able to prod the RMD in the absence of any Sequence Traffic Messages.   

I don't see how we can do a restricted SeqAck piggy-backing - I think its either we can piggy-back or we have
to kill it entirely.  If we try to restrict it to cases where there is
already some RM header in the message then it has to be the Sequence header but that's pointing to the
wrong Sequence. wsa:RelatesTo doesn't help because how do we know that the wsa:ReplyTo of the
request message (or the wsa:To of this message) points to the AcksTo EPR w/o basically doing EPR
comparing - and that's what the stuff in bold above talks about. And, of course, you have the whole issue
that using wsa:RelatesTo tries to draw some linkage between the two Sequences which just isn't there.
You MUST look at the AcksTo EPR, not the SeqID of the request message. 

 

<gp> Maybe I want too far when I tried to tie the two sequences together. All you're looking for is some indication that the message will be processed by a WS-RM message handler. I think the presence of a sequence header should be sufficient proof of that. Don't forget you can always send an Ack in a message with an empty body at the cost of ~750 bytes!

thanks
-Doug

"Gilbert Pilz" <Gilbert.Pilz@bea.com>

10/23/2006 06:35 PM

To	"Paul Fremantle" <paul@wso2.com>
cc	<ws-rx@lists.oasis-open.org>
Subject	RE: [ws-rx] New PR Issue: Piggy-backing problematic

Comments in line . . .

> -----Original Message-----
> From: Paul Fremantle [mailto:paul@wso2.com]
> Sent: Saturday, October 21, 2006 3:44 AM
> To: Gilbert Pilz
> Cc: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] New PR Issue: Piggy-backing problematic
>
> Gil
>
> Didn't we discuss this at great length during the TC deliberations :-)

I raised this PR issue at the request of the WS-I RSP Working Group. I
had raised an issue with that group, the goal of which was to profile
piggy-backing down to what I considered to be a safe subset (pretty much
what you defined below) of the possible piggy-backable messages allowed
for by WS-RM. Their response was "If piggy-backing is so bad, why don't
we fix it by completely removing it from WS-RM", hence this new issue.

> I'm at a loss to where this sentence comes from: "Most SOAP
> implementations assume that SOAP header blocks relate in some
> way to the body of the message in which they appear".
> Is that true? I'm actually having a hard time understanding
> what that would mean in terms of code. From my detailed
> experience with 5 different SOAP implementations, the header
> blocks are processed by some kind of "handler" that does
> something with the header, and is in no way constrained to
> restrict the processing in any way to activities that are in
> "some way" related to the Body. In fact I don't really
> understand how a handler would be restricted to only
> performing processing that related in some way to the body of
> the message.

But aren't the handlers that get called determined by the "route" the
message takes through the system and isn't that route mainly determined
by the intended semantics of the message? I'm just concerned about the
assumption that any and all messages sent to a particular URI will
necessarily pass through a WS-RM handler that will spot the piggy-backed
headers. For a group that has been so stridently opposed to assuming any
kind of implementation detail, it seems strange to be presuming that
this will always be the case.

> It also seems strange you are worried about either false
> negatives or false positives if you wish to remove this
> capability. In both cases it equates to the same as you are
> proposing, minus some bandwidth.

Not at all. As I tried to make clear, I have no problems with false
negatives. This just means you don't end up trying to piggy-back when it
may have worked. Not a big deal because piggy-backing doesn't save you
that much anyway. False positives, on the other hand, *are* a big deal
because you end up piggy-backing your ack (or ack request) on a message
that never reaches a WS-RM handler and you break the protocol.

> I would be happy to add an extra condition to piggybacking -
> that it only occur when either the message has a <Sequence>
> header or is a <wsa:RelatesTo "reply"> to a message that had
> a <Sequence> or <AckRequested> header.
>
> I think that would ensure that the message was already being
> dealt with by an RM Agent.

I would be happy with this restriction (which was the goal of my
original RSP issue) except that you haven't covered my second point: the
specification of piggy-backing MAY but that "MAY" is really
sender-optional. If we are going to keep piggy-backing (constrained as
you have above) I think we need to make clear that conforming RMS and
RMD implementation MUST be capable of processing piggy-backed headers if
the other side chooses to use them.

- gp