[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New Issue: serialization optimization proposal
All, Here's a formal issue proposal for my thoughts on optimization. Title: protocol serialization optimization proposal Description: I've been thinking a bit about how we might optimize the serialization of the elements in the protocol; doing so without actually changing the abstract properties of the protocol itself. 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"/> 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, 3 and 4 are 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 3 4"> 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. Justification: The point of this proposal is not limited to byte savings of serialization. Rather, it has more to do with the efficiency with which the protocol properties can be serialized and deserialized. Especially with the @range attribute, there are far fewer nodes involved. In terms of creation/serialization performance, I found an average savings in serialization (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. The sheer volume of messages that they expect to be able to process daily is mind-boggling. 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. Target: core, schema Type: design Proposal: This isn't fully fleshed out in terms of line numbers and prose, etc. However, the gist would be to have the protocol elements be as follows: <wsrm:Sequence seqID="[xs:anyURI]" msgNum="[xs:unsignedLong]" last="[xs:boolean]"? .../> <xs:simpleType name='rangeType'> <xs:list itemType='xs:unsignedLong'/> </xs:simpleType> <!-- The ranges are expressed as "low hi low hi low hi ..." --> <wsrm:SequenceAcknowledgement seqID="[xs:anyURI]" [ranges="[wsrm:rangeType]"|nack="[wsrm:rangeType]"] .../> <wsrm:AckRequested seqID="[xs:anyURI]" msgNum="[xs:unsignedLong]"? .../> 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]