[REL-94] Amended Poll Reply Pattern Binding Proposal

Hi Tom,

 I'd like to table the following proposal for the Poll Binding
pattern for further discussion.

 It is the revised Poll pattern  proposal based on comments
I've received from Iwasa and others.

 

 It is still based on Headers. It involves overloading the <AckRequested>
sub-element instead of

 new Headers so that it is more consistent with others. The new
proposal doesn't involve any new

 Headers.

 <ProposalBegin/>

 <MessageHeadre>

   ....

   <ReplyPattern>Poll</ReplyPattern>

 </MessageHeader>

 <Request>

    <AckRequested>

        <GroupId value="a.b.c.com/xyz/001"
>

           
<SequenceNumberRange From="1" To="10" />

        </GroupId>

        <GroupId value="a.b.c.com/xyz/002"
/>

    </AckRequested>

  </Request>

 Specifics:

 

 <AckRequested> should not have any child elements if the ReplyPattern
is not Poll. It should result in a Fault (InvalidRMRequets) if it has child
elements for other patterns.

If the ReplyPattern is Poll, it may or may not have child elements.

If <AckRequested> element is empty, then it is indication to the receiver
that sender may poll for a message receive at a later stage.

If it has one or more GroupId sub-elements, then it is a indication that 
sender wants to Poll previously sent message(s).

If it has one or more GroupId sub-elements, then <DuplicateElimination>
and <MessageOrder> should not exist and if exists are ignored.

There can be zero or more GroupId sub-elements.

Values can be same.

There can be zero or more SequenceNumberRange sub-elements under a GroupId.

If there is no SequenceNumberRange sub-element, Response should include
all received messages in that Group.

For simplicity sake, we should mandate that all the messages in a group
should use the same ReplyPattern.

 So possible requests are (assume ReplyPattern is Poll for
all the below):

 1)  <Request>

       <AckRequested>

        <GroupId value="a.b.c.com/xyz/001"
>

           
<SequenceNumberRange From="1" To="12" />

        </GroupId>

      </AckRequested>

     </Request>

 2) <Request>

      <AckRequested>

        <GroupId value="a.b.c.com/xyz/001"
>

           
<SequenceNumberRange From="1" To="5" />

           
<SequenceNumberRange From="7" To="7" />

            
<SequenceNumberRange From="10" To="12" />

        </GroupId>

     </AckRequested>

   </Request>

 3) <Request>

      <AckRequested>

        <GroupId value="a.b.c.com/xyz/001"
>

           
<SequenceNumberRange From="1" To="5" />

        </GroupId>

        <GroupId value="a.b.c.com/xyz/001"
>

           
<SequenceNumberRange From="6" To="12" />

        </GroupId>

      </AckRequested>

   </Request>

 

 While all the 3 cases are valid, (1) will be the most efficient
and should be recommended.

 And the receiver is REQUIRED to send back requested Acks for message(s)
that were received already.

 Note that the Response will include all received messages in
the range mentionded in the Request, not just

 previously un-acked messages.

 <Response>

     <RefToGroupId value="a.b.c.com/xyz/001">

         <RefToSequenceNumberRange
From="1" To="5" />

         <RefToSequenceNumberRange
From="7" To="7" />

        <RefToSequenceNumberRange
From="10" To="12 />

   </RefToGroupId>

   <RefToGroupId value="a.b.c.com/xyz/002">

         <RefToSequenceNumberRange
From="1" To="8" />

   </RefToGroupId>

 </Response>

 Tdibits:

  1.This request will be sent to the same endpoint as the original
message(s) are sent..

  2.Poll request for a message sent to another endpoint MAY result
in InvalidGroupId fault.

  3.Since it is defined as a Header, it could be defined in the
SOAP Binding part in the WSDL if desired.

 

 Possible failure faultcodes are:

  1.InvalidGroupId:  Even if one of the GroupIds are wrong
or invalid, this fault will be sent.

  2.InvalidSequenceNumber: Even if one of the SequenceNumbers
is wrong or invalid, this fault will be

    generated and sent.

  3.InvalidRMRequest: If the AckRequested element has one or more
child elements for Response or

    Callback poll pattern.  Or, if there is some
mis-match of ReplyPatten types for the messages in the

    same group.

 Essentially, all or none approach wrt to Faults. We should be
able to share the above Status values with

 Fault  Codes. Note both  are QNAME types and hence
shareable.

 Piggybacking of a Poll request could either be disallowed or should
be tackled along with the general

 piggybacking problem.

 <ProposalEnd/>

 No Comments on Email :-(

 Lets discuss at the F2F.

 -Sunil