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: 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]