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

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

Paul,

It seems we are in agreement about what we want to do although we may
not agree on why we want to do it. I would be overjoyed if you wrote up
such a proposal. I'll help with editing and tweaking if you'd like . . .

- gp 

> -----Original Message-----
> From: Paul Fremantle [mailto:paul@wso2.com] 
> Sent: Monday, October 23, 2006 3:59 PM
> To: Gilbert Pilz
> Cc: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] New PR Issue: Piggy-backing problematic
> 
> Gil
> 
> Thanks for the detailed response.
> 
> I'll try to address your points here rather than inline, my 
> brain can only cope with minimal levels of recursion and inlining ;-)
> 
> 1) Thanks for making it clear this is on behalf of RSP.
> 2) Regarding whether an RM handler will always get the ack, I 
> personally agree that this is a possible problem. I think my 
> proposed amendment solves this, by ensuring that the message 
> has already got RM handlers anyway.
> 3) I'm not sure I agree with the false positives argument. 
> After all, the only ack the RMS can be sure of getting is a 
> response to an ackRequest. In addition, even without false 
> positives, acks can be lost due to network failures. So if 
> the RMS misses piggybacked acks it might reduce the 
> efficiency, but it can't change the reliability guarantee.
> 4) As regards the optionality, I agree with you. It's only 
> really optional on the RMD side, give or take my argument 
> regarding false positives above.
> 
> I would support the changes to clarify the optionality and 
> add the extra conditions. I'd be happy to write this up if 
> you think its valuable.
> 
> Paul
> 
> Gilbert Pilz wrote:
> > 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
> >
> >   
> 
> --
> Paul Fremantle
> VP/Technology and Partnerships, WSO2
> OASIS WS-RX TC Co-chair
> 
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
> (646) 290 8050
> 
> "Oxygenating the Web Service Platform", www.wso2.com
> 
> 
>