Re: [ws-rx] some optimization

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Two comments/questions inlined below.
-Anish
--

Christopher B Ferris wrote:
> All,
> 
> I've been thinking a bit about how we might optimize the serialization of 
> the
> Sequence and SequenceAcknowledgement elements in the protocol; doing so 
> without
> actually changing the abstract properties of the protocol.
> 
> Here's what we have today:
> 
> <wsrm:Sequence xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@";>
>   <wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>
>   <wsrm:MessageNumber>1</wsrm:MessageNumber>
>   <wsrm:LastMessage/>
> </wsrm:Sequence>
> 
> I think that if the properties were serialized as attributes, we would 
> have a much more compact
> serialization:
> 
> <wsrm:Sequence xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@"; 
>         seqID="http://example.org/mysequence/1234"; msgNum="1" 
> last="true"/>
> 

Currently, the Sequence Identifier is an attributed URI. Not completely 
sure if it is important, but this change removes the ability to have 
attributed URIs for identifiers.

> The serilaization savings for a Sequence element is 91 bytes per message.
> 
> For the SequenceAcknowledgement, we could collapse the acknowledgement 
> range elements into a single
> attribute value that was a sequence of integers. e.g in the simplest case, 
> here would be an example SeqAck:
> 
> <wsrm:SequenceAcknowledgement 
> xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@"; 
>         seqID="http://example.org/mysequence/1234"; ranges="1 1 3 10">
> 
> where the @ranges attribute is a list of unsignedLongs. e.g.
> 
> <xs:simpleType name='rangeType'>
>   <xs:list itemType='xs:unsignedLong'/>
> </xs:simpleType>
> 
> The ranges are expressed as "low hi low hi low hi ..."
> 
> In the example above, message #2 is missing. Here's an example of a nack:
> 
> <wsrm:SequenceAcknowledgement 
> xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@"; 
>         seqID="http://example.org/mysequence/1234"; nack="2">
> 

Since one can NACK multiple messages in the same SeqAck header, I assume 
that the 'nack' attribute is of type rangeType. Right?

And the attributes 'nack' and 'ranges' cannot appear at the same time on 
an instance of SeqAck.

> The savings on the SequenceAcknowledgement are 99 bytes/message using the 
> optimized serialization for a 
> SequenceAcknowledgement with no gaps, 148 bytes for one with one gap, 195 
> bytes for one with two gaps, 
> and 242 for one with three. Basically, it boils down to an additional 47 
> bytes per gap (in this case using namespace
> prefix of wsrm) or 42 bytes using the default namespace.
> 
> In terms of creation/serialization performance, I found an average savings 
> (using java) of:
> 
> Sequence - .0478 ms 
> SequenceAcknowledgement (with 2 gaps) - .19765 ms
> 
> I haven't had a chance to assess parsing performance benefits yet, but I 
> have to imagine that there
> would be some benefit.
> 
> Sure, scoff if you will, but in the context of an server implementation 
> processing a gazillion messages, the
> performance savings are non-trivial. Think about providing RM support for 
> a customer such as a Ford or FedEx.
> 
> Of course, in the context of a message with a WS-Security header, the RM 
> performance and bandwidth overhead 
> pales in comparison for the processing of the overall message, but IMO, 
> there's no reason that RM should 
> exacerbate the issue. If there is a performance and bandwidth optimization 
> that we could effect without actually 
> changing the protocol, I think we should give it serious consideration.
> 
> As for extensibility, we could still have the Sequence and 
> SequenceAcknowledgement elements extensible
> via both attributes and elements. There's no reason to change that.
> 
> Thoughts?
> 
> Cheers,
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295