[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] some optimization
Duane, The (current) schema for wsrm uses attributeFormDefault="unqualified" so the attributes aren't namespace qualified to begin with, nor are they qualified in the examples I cited 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 Duane Nickull <dnickull@adobe.com> wrote on 08/16/2005 11:04:44 AM: > Chris: > > We could possibly further optimize it by removing the qnames for the > attributes. If the attribute is already namespace qualified and the > attribute list is lexically scoped for each element, is there any reason > the attributes also need namespaces? > > Duane > > Christopher B Ferris wrote: > > >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 > >>> > >>> > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]