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