Re: [ws-rx] some optimization

[Christopher B Ferris <chrisfer@us.ibm.com>]

Anish,

Good questions. My responses inlined below.

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

Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 08/15/2005 05:11:45 
PM:

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

All of the elements in the protocol are extensible via elements and 
attributes
as a general rule of extensibility.

It isn't abundantly clear to me that the identifier URI itself has 
explicit
need of attributes though. If you want to sign the Sequence or 
SequenceAcknowledgement
header, then you'd simply add an attribute of type ID to the header so 
that 
it could be referenced by the signature.

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

Correct. I should have made that clearer.

> 
> And the attributes 'nack' and 'ranges' cannot appear at the same time on 

> an instance of SeqAck.

Right. That would have to be expressed in spec-ese as it cannot be 
expressed
in schema (although we could add co-constraints using schematron in an 
xs:annotation/xs:appInfo I suppose).

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