OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: some optimization


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

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

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]