OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


Subject: Re: [wsrm] Proposal to resolve rel 108/115




Tom Rutt wrote:

> Sunil Kunisetty wrote:
>
> >Tom Rutt wrote:
> >
> >
> >
> >>Sunil Kunisetty wrote:
> >>
> >>
> >>
> >>> Tom,
> >>>
> >>> Why not simply add a sub-element by name FaultCode to
> >>>SequenceNumberRange.
> >>> It will be of cardinality of minOccurs=0. If present, then that range
> >>>messages have
> >>> fault. If not, they are non-fault messages.
> >>>
> >>>
> >>>
> >>because there are singlton groups which do not have the sequence number .
> >>
> >>
> >>
> >
> > Duh! forgot about that. In that case, we could have this element/attribute of the
> > RefToMessageId itself and define the scoping rules clearly.
> >
> > I prefer not to have different sections for fault and normal messages in the
> > Response.
> >
> >
> But won't this cause the group ID to be repeated if you are reporting
> both delivered and faulted message IDs for the same group.?

 No. here are some  examples.

 For a fault with singleton  case:

 <Response>
     <RefToMessageId groupId="http://www.oracle.com";  faultCode="....">
  </Response>

 For a grouped case:

  <Response>
    <RefToMessageIds groupId="http://www.altova.com";>
          <SequenceNumberRange from="4294967291" to="4294967295">
                 <FaultCode>wsrm:InvalidMessageHeader</FaultCode>/
           </SequenceNumberRange
           <SequenceNumberRange from="4294967296" to="4294967298"/>
    </RefToMessageId>
   </Response>

  Note that group id is  mentioned only  once per group.

  While there are advantages with this approach, such as:
         - No new elements
         - Potential sequential processing of acks and faults, i.e.,
           response will 1-4 are acks, 5-6 are faults, 7 is an Ack,
           8,9 are faults etc...

  There are also some dis-advantages:
      - Schema validation will be difficult
      - Need to explain scoping rules more clearly.

 As I also mentioned earlier, PollRequest also refers to the same
 SequenceNumberRange. To solve this,
   i) we can maintain both sets of SequenceNumberRange, with different names,
      and refer one with faults to response and one without faults to poll-request.
    ii) or use the same element and mention in the spec. that
        poll-request should not  have the FaultCode sub-element.

>
>
> >
> >
> >
> >>> Schema change would be:
> >>> <xsd:complexType name="SequenceNumberRangeType">
> >>>  <xsd:complexContent>
> >>>   <xsd:extension base="wsrm:EmptyType">
> >>>    *<xsd:sequence>*
> >>>*     <xsd:element name="FaultCode" type="wsrm:FaultCodeEnum"
> >>>minOccurs="0"/>*
> >>>*    </xsd:sequence>*
> >>>    <xsd:attribute name="from" type="xsd:unsignedLong"/>
> >>>    <xsd:attribute name="to" type="xsd:unsignedLong"/>
> >>>   </xsd:extension>
> >>>  </xsd:complexContent>
> >>> </xsd:complexType>
> >>>
> >>> Only change would be adding a sub-element. If desired, we can change
> >>>this to
> >>> an attribute also.
> >>>
> >>> Message sample would be:
> >>><?xml version="1.0" encoding="UTF-8"?>
> >>><!--Sample XML file generated by XMLSPY v2004 rel. 3 U
> >>>(http://www.xmlspy.com)-->
> >>><Response
> >>>xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1";
> >>>xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
> >>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >>>xsi:schemaLocation="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1
> >>>
> >>>C:\work\ws-reliability-2004-01-27.xsd" soap:mustUnderstand="1">
> >>> <RefToMessageIds groupId="http://www.altova.com";>
> >>>  <SequenceNumberRange from="4294967291" to="4294967295">
> >>>   /<FaultCode>wsrm:InvalidMessageHeader</FaultCode>/
> >>>  </SequenceNumberRange>
> >>>  <SequenceNumberRange from="4294967296" to="4294967299">
> >>>   </FaultCode>wsrm:InvalidMessageParameters</FaultCode>/
> >>>  </SequenceNumberRange>
> >>> </RefToMessageIds>
> >>> <RefToMessageIds groupId="http://www.oracle.com";>
> >>>  <SequenceNumberRange from="294967291" to="294967295"/>
> >>>  <SequenceNumberRange from="294967296" to="294967297">
> >>>   /<FaultCode>wsrm:InvalidMessageId</FaultCode>/
> >>>  </SequenceNumberRange>
> >>>  <SequenceNumberRange from="294967298" to="294967299"/>
> >>> </RefToMessageIds>
> >>></Response>
> >>>
> >>> I do realize that PollRequest also refers to the same
> >>>SequenceNumberRange.
> >>> To solve this,
> >>>    i) we can maintain both sets of SequenceNumberRange, with
> >>>different names,
> >>>       and refer one with faults to response and one without faults to
> >>>poll-request.
> >>>    ii) or use the same element and mention in the spec. that
> >>>poll-request should not
> >>>        have the FaultCode sub-element.
> >>>
> >>>
> >>> -Sunil
> >>>
> >>>Tom Rutt wrote:
> >>>
> >>>
> >>>
> >>>>I proposae that we resolve rel 108  and 115 with the following
> >>>>resolution:
> >>>>
> >>>>a) accept the unified response schema (eliminating the fault element)
> >>>>posted at:
> >>>>http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5496/ws-reliability-uniresponseOpt.xml
> >>>>
> >>>>
> >>>>The following restrictions are to be applied:
> >>>>
> >>>>1) for response reply pattern, only one ack or only one fault can be
> >>>>reported in the response.
> >>>>
> >>>>2) for callback reply pattern, acks may be batched, but only one fault
> >>>>can be reported in the callback. (this is to use the underlying fault
> >>>>mechanisms for timely repoting of fault conditions via callback).
> >>>>
> >>>>3) for poll requests (on messages send using any reply patternt), both
> >>>>acks and faults must be batched in the poll response.
> >>>>
> >>>>Tom Rutt
> >>>>
> >>>>--
> >>>>----------------------------------------------------
> >>>>Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
> >>>>Tel: +1 732 801 5744          Fax: +1 732 774 5133
> >>>>
> >>>>To unsubscribe from this mailing list (and be removed from the roster
> >>>>of the OASIS TC), go to
> >>>>http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
> >>>>
> >>>>
> >>>>
> >>--
> >>----------------------------------------------------
> >>Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
> >>Tel: +1 732 801 5744          Fax: +1 732 774 5133
> >>
> >>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
> >>
> >>
> >
> >
> >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
> >
> >
> >
>
> --
> ----------------------------------------------------
> Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.



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