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

[Paul Fremantle <paul@wso2.com>]

Gil

Didn't we discuss this at great length during the TC deliberations :-)

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.

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.

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.

Paul


Gilbert Pilz wrote:
>
> *Title*: Use of piggy-backing problematic
>
> *Description*:
>
>       WS-RM allows for the possibility of adding the wsrm:AckRequested
>       and wsrm:SequenceAcknowledgement headers to unrelated messages
>       that are targeted to the "same" endpoint; a concept it refers to
>       as "piggy-backing". There are a number of problems with this
>       concept:
>
>             1.) It complicates the processing of all SOAP/HTTP
>             messages (not just WS-RM messages). Most SOAP
>             implementations assume that SOAP header blocks relate in
>             some way to the body of the message in which they appear
>             (SOAP 1.2 Primer [1]) (this could be due to the fact that
>             SOAP provides no way of generically categorizing headers
>             as either related or non-related). The possible appearance
>             of non-related headers hinders the ability of SOAP nodes
>             to process messages as individual, atomic units. This is
>             apparent in lines 667-670 and 697-700 of WS-RM [2] where
>             exceptions to the normal SOAP fault processing rules are
>             called out in order handle errors related to piggy-backed
>             headers. There is little difference between inserting
>             unrelated headers into a message and "boxcarring" multiple
>             messages into the entity bodies of individual HTTP
>             requests or responses. In both cases the "one HTTP entity
>             == one SOAP message" relationship is broken.
>
>             2.) The specification of piggy-backing is "MAY". Thus it
>             is possible for one RMS node to support piggy-backing
>             while the other does not. There is no mechanism defined by
>             WS-RM for two nodes to agree on whether or not
>             piggy-backing will be in effect for a particular sequence;
>             neither are there any WS-Policy assertions or parameters
>             defined in WS-RM Policy that would allow this behavior to
>             be discovered. For example, an RMD that supported
>             piggy-backing might choose to add acknowledgment headers
>             to various messages bound for the same endpoint. An RMS
>             that did not support piggy-backing would never receive
>             these acknowledgments simply because it never had
>             visibility (due to the way message handlers were
>             implemented on that system) into the messages that
>             contained the acknowledgment headers.
>
>             3.) WS-Addressing is deliberately silent about endpoint
>             comparison. WS-RM defines a method of address comparison,
>             but only in the context of the MakeConnection operation.
>             Section 3.2 of WS-RM states that "Reference parameters
>             MUST be considered" but it doesn't describe what it means
>             to "consider" a reference parameter. For example what, if
>             any, canonicalization method should be used when comparing
>             the reference parameter of one EPR with another? Thus it
>             is unclear as to whether an RMS and an RMD would
>             necessarily agree on the definition of what it meant for
>             two endpoints to be "the same". This breaks down into the
>             following two scenarios:
>
>                   3.a) False negative comparison: the sender of a
>                   message thinks two endpoints are different when the
>                   receiver thinks they are equivalent. This results in
>                   lost opportunities for piggy-backing. This case may
>                   sub-optimal from a performance perspective (though
>                   probably not - see below) but the WS-RM protocol
>                   will continue to function.
>
>                   3.b) False positive comparison: the sender of a
>                   message thinks two endpoints are equivalent when the
>                   receiver thinks they are different. This results
>                   either lost acknowledgments or lost acknowledgment
>                   requests (depending upon whether the sender is the
>                   RMD or RMS). This case is severe as the impact of
>                   lost acknowledgements is damaging to the operation
>                   of the WS-RM protocol. The severity is relative to
>                   the percentage of acknowledgments that are
>                   incorrectly piggy-backed.
>
>       In the general case the performance benefits of piggy-backing
>       are likely to be minor. The majority of the cost in sending
>       small messages is in TCP connection setup. Given the use of HTTP
>       1.1 with persistent connections, saving ~ 750 bytes [3] per
>       acknowledgement isn't likely to make a significant difference.
>       In the case of high-traffic situations where the number of
>       acknowledgements is an issue, implementations can choose to send
>       fewer acknowledgments by including more message numbers per
>       acknowledgement (i.e. only ack every 10th or 20th message).
>
>       In summary, piggy-backing is a classic case of "premature
>       optimization" [4]. It attempts to achieve un-quantified
>       performance benefits at the cost of complicating the general
>       SOAP/HTTP processing model of every implementation that supports
>       WS-RM.
>
> *Proposal*:
>
>       Remove all references to the concept of "piggy-backing". Note
>       that adding an AckRequested header to a Sequence Traffic Message
>       where (/wsrm:AckRequested/wsrm:Identifier ==
>       /wsrm:Sequence/wsrm:Identifier) should* not* be considered as
>       "piggy-backing"; neither should adding a
>       wsrm:SequenceAcknowledgement header to the response message of a
>       request that carried an AckRequested header (correlation
>       determined using wsa:MessageID and wsa:RelatesTo).
>
> *References*:
>
>       [1] _http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L1165_
>       [2]
>       _http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf_
>
>       [3] The size of the basic HTTP headers plus the SOAP envelope
>       plus some basic WSA headers (size of the SequenceAcknowledgement
>       element doesn't count since it counts equally regardless of
>       where it appears).
>
>       [4] “Premature optimization is the root of all evil (or at least
>       most of it) in programming.” — _Donald Knuth_
>       <http://en.wikipedia.org/wiki/Donald_Knuth>
>

-- 
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