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

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

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