FINAL REL 94 Proposal.

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

  Here is a "final  final" proposal for REL-94.

  <FinalRel94ProposalBegin/>

  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:
        o There can be one or more GroupId sub-elements.
             + Values can be same or different.
        o There can be zero or more SequenceNumberRange sub-elements
            under a GroupId.
        o 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.
     [AI: Add this as a new issue and close it as Resolved.]
 

 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
 all the patterns. [REL 75]
 [Open Issue: Whether we need to restrict the semantics for Response
              Reply pattern has to be decided.]

 
 Tidbits:

  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 if it is 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.
 

 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.

 <FinalRel94ProposalEnd/>