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

[Paul Fremantle <paul@wso2.com>]

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