[REL-94] Amended Poll Reply Pattern Binding Proposal

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

 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