[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] some optimization
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]