[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] some optimization
D'oh!! Sorry - I misread it. My bad. I hate how quickly the relaxation of a good vacation wears off the morning of going back to work. D Christopher B Ferris wrote: >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]