[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] some optimization
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]