New PR Issue: Piggy-backing problematic

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

Title: New PR Issue: Piggy-backing problematic

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