Re: [REL-94] Amended Poll Reply Pattern Binding Proposal

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

 All -

 The group agreed to accept the proposal with one change:
        - Move the "request for poll" into a new Header rather than
          overloading "AckRequested".

 Here is a final proposal for REL-94 with the required changes.

  <Rel94ProposalBegin/>

  So the initial msg. with the intent for Poll ReplyPattern Binding will have
  ReplyPattern set to Poll and it will have AckRequested sub-element
 

   <MessageHeader>
      ....
      <ReplyPattern>Poll</ReplyPattern>
   </MessageHeader>

   <Request>
       <AckRequested/>
     ...
  </Request>

 The poll request will have a new Header called PollRequest.
 An example is as follows:

   <PollRequest>
         <GroupId value="a.b.c.com/xyz/001" >
            <SequenceNumberRange From="1" To="10" />
        </GroupId>
        <GroupId value="a.b.c.com/xyz/002" />
   </PollRequest>

 Specifics:

• Intent for Poll pattern is done using ReplyPattern set to Poll and existence of the AckRequested sub-element in Request Header.
• Actual Poll request will be sent in a  separate Header called PollRequest
• PollRequest Header could be the one of  following:
• 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 Poll Request, it should only have MessageHeader and PollRequest Header. It shouldn't have the Request Header. So essentially one can't Ack a Poll request. No useful use case to support it.
• For simplicity sake, we should mandate that all the messages in a group should use the same ReplyPattern.
• The Response for a Poll request will have a MessageHeader and the ReplyPattern sub-element will be set to Poll. [The group agreed to generalize the rule  for all patterns].

 So possible requests are (assume ReplyPattern is Poll for all the
below):
 1)  <PollRequest>
        <GroupId value="a.b.c.com/xyz/001"
>
           
<SequenceNumberRange From="1" To="12" />
        </GroupId>
     </PollRequest>

 2) <PollRequest>
        <GroupId value="a.b.c.com/xyz/001" >
            <SequenceNumberRange From="1" To="5" />
            <SequenceNumberRange From="7" To="7" />
             <SequenceNumberRange From="10" To="12" />
        </GroupId>
   </PollRequest>

 3) <PollRequest>
        <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>
   </PollRequest>

 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 mentioned 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>

 It was also decided to use the same syntax for bataching acks in
 Callback pattern case. [REL 75]

 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
     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/>
 

 -Sunil