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] New proposed issues 8/25 - 8/31

We should address the new use cases the same as issues; basically a quick decision as to whether they should be included in our document or not.
- g

From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Wednesday, August 31, 2005 7:48 PM
To: Patil, Sanjay; paul@wso2.com; ws-rx@lists.oasis-open.org
Subject: [ws-rx] New proposed issues 8/25 - 8/31

Please let me know if I missed any.  Regards, Marc g




Title: What are the obligations on RMD for use (or not) of Offered Sequence?
Description: When an RMD accepts an offer of a bilateral Sequence, is it Obligated to use that Sequence for response messages to the endpoint that requested creation of the Sequence in which the offer was made?
Justification: The text in section 3.4 makes no mention of the obligations, if any that the RMD has in accepting a CreateSequence with an Offer. The text at 480(pdf) reads:
    This element, if present, enables an RM Source to offer a corresponding Sequence for the reliable exchange of messages transmitted from RM Destination to RM Source.
Target: core
Type: design
Proposal: As the wsrm:Offer is intended as an optimization, I believe that the RMD should be under no obligation to actually use the offered Sequence. Similarly, I believe that it should be made clear in the spec that the RMS MUST NOT presume that the offered Sequence will actually be used to ensure that there are no interop issues that might arise from one implementation making such an assumption and another that chooses not to use the offered Sequence (for what ever reason). I suppose that we *could* devise a wsrm:Decline child of wsrm:CreateSequence as a courtesy to the RMS that made the offer so that it could reclaim the associated resources rather than having to wait until the offered (but unused) Sequence expired. That would make it abundantly clear that there was no association. If we pursued the wsrm:Decline, then the text around lines 536-566 will need to be fixed accordingly.




Title:  Inconsistency between spec and schema (AckRequested)
Description: There is an inconsistency between the spec and the schema for the child element of the <AckRequested> directive. Is the child element wsrm:MaxMessageNumberUsed (as per the schema) or is it wsrm:MessageNumber as per the spec?
Here's the prose from line 427 (pdf) of the wsrm spec:
        This optional element, if present, MUST contain an xs:unsignedLong representing the highest
        <MessageNumber> sent by the RM Source within a Sequence. If present, it MAY be treated as a
        hint to the RM Destination as an optimization to the process of preparing to transmit a
Here's the relevant fragment from the schema:
<xs:complexType name="AckRequestedType">
    <xs:element ref="wsrm:Identifier"/>
    <xs:element name="MaxMessageNumberUsed" type="xs:unsignedLong" 
    <xs:any namespace="##other" processContents="lax" minOccurs="0" 
  <xs:anyAttribute namespace="##other" processContents="lax"/>
Justification: there is a clear discrepancy between the spec and the schema
Target: core, schema
Type: editorial
Proposal: I believe the intent was to have the element named as per the schema. Change the text at line 427 as follows:
        This optional element, if present, MUST contain an xs:unsignedLong representing the highest
        <MessageNumber> sent by the RM Source within a Sequence. If present, it MAY be treated as a
        hint to the RM Destination as an optimization to the process of preparing to transmit a




Title: protocol serialization optimization proposal
I've been thinking a bit about how we might optimize the serialization of the elements in the protocol; doing so without actually changing the abstract properties of the protocol itself.
Here's what we have today:
<wsrm:Sequence xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@";>
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"
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:
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'/>
The ranges are expressed as "low hi low hi low hi ..."
In the example above, message #2, 3 and 4 are missing. Here's an example of a nack:
seqID="http://example.org/mysequence/1234"; nack="2 3 4">
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.
The point of this proposal is not limited to byte savings of serialization.
Rather, it has more to do with the efficiency with which the protocol properties can be serialized and deserialized. Especially with the @range attribute, there are far fewer nodes involved.
In terms of creation/serialization performance, I found an average savings in serialization (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. 
The sheer volume of messages that they expect to be able to process daily is mind-boggling.
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.
Target: core, schema
Type: design
Proposal: This isn't fully fleshed out in terms of line numbers and prose, etc. However, the gist would be to have the protocol elements be as follows:
<wsrm:Sequence seqID="[xs:anyURI]" 
    last="[xs:boolean]"? .../>
<xs:simpleType name='rangeType'>
<xs:list itemType='xs:unsignedLong'/>
<!-- The ranges are expressed as "low hi low hi low hi ..." -->
<wsrm:SequenceAcknowledgement seqID="[xs:anyURI]" 
    [ranges="[wsrm:rangeType]"|nack="[wsrm:rangeType]"] .../>
<wsrm:AckRequested seqID="[xs:anyURI]" 
    msgNum="[xs:unsignedLong]"? .../>



I have no idea how the use cases that were sent in are expected to be logged, for reference here they are.



Broker Interface



Commodity Quotes Service



Smartphone Subscribes to Service




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]