Rel 56 and more

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: Rel 56 and more

Here is a proposal for Rel 56, attached, for further review.
It already reflects some earlier comments from some of you (most from Doug).

As for the former list of REL 83-84-85-86:

REL 83: current proposed resolution for R83 is assumed by R56, although parameter is renamed in R56.
REL 84: current proposed resolution for R84  is assumed by R56, although parameter is renamed in R56.
REL 85: propose to close without action: not relevant anymore since we can guarantee to NOT deliver duplicate
regardless of scope (i.e. "forever", thanks to the semantics of ExpiryTime)
REL 86: propose  to close without action: REL 57 is handling the termination of  pending out-of-order sequences.
Any other reason to cancel an out-of-order sequences hinges on storage capacity, which should be
handled separately (and in a consistent way across several other RM features. E.g. with appropriate Faults.)

Jacques
<<RM-agreement.txt>>

REL 56: Proposal
================

Summary:

- the proposal is independent from resolution for REL 83-84-85-86, although
we assume here that REL 85-86 are dropped. (rationale to be sent separately)

- Instead of talking of "configuration parameters", this proposal will talk
more abstractly (and more generally) of "reliability agreement items", or RM-agreement items.

- "RM-agreement items" describe the reliability contract between parties. 
They covers both the RM parameters that show up in the protocol, and those which do not 
(like "retry interval", "number of retries"). This distinction is not essential at this level.
Some items may, at implementation level, translate into configuration parameters for RMPs.

- the proposal is that the spec identifies and describes the RM-agreement items, so they
have a formal existence independent from their protocol representation (as some do not
appear in protocol). This allows for treating all of them in a uniform way in the spec.
The proposal does not mandate a concrete representation. 
Later on, a formal representation could be recommended (e.g. a policy language, 
an agreement representation...)


Detailed proposal:


Reliability Agreement (or RM Agreement):
-----------------------------------------

An RM Agreement describes the set of agreed contracts between:
- a Sending "application layer" and the associated RMP.
- a Sending RMP and a Receiving RMP.
- a Receiving "application layer" and the associated RMP.

The way these contracts are established or communicated to each party is out of scope,
although for the contract RMP-RMP, the assumption is that all the needed synchronization
is achieved through the message protocol, i.e. the Receiver RMP does not need other
input than the message headers.

The highest-level items of the RM Agreement are the main RM features themselves:

- Guaranteed delivery (or at-least-once delivery): 
When a Sender application submits a well-formed business payload to the RMP,
the agreement requires that either:
(1) the payload is delivered to the Receiver application, or 
(2) the Sender application is notified in case of failure.
 
- Duplicate elimination (or at-most-once delivery):
When an RMP delivers a business payload to a Receiver application, the agreement requires
that no future business payload from a message with same identity as the message containing
the first payload (GroupId and SequenceNumber if any) will ever be delivered 
to the Receiver application.

- Guaranteed ordered delivery: 
When a Sender application submits an ordered sequence of business payloads to an RMP, 
the agreement requires that when delivering a business payload to the Receiver application, 
all previous payloads in the sequence have already been delivered.


RM Agreement Items:
-------------------

An RM Agreement is a list of Agreement Items.
An RMP implementation MUST be capable of:
(1) taking knowledge (e.g. either via configuration, or via an API call, or via a message, 
or via the result of an algorithm) of a set of values that represent the RM Agreement Items 
described in this specification, 
(2) processing them according to the semantics described in this specification.

Some of these items will map to some message header field, some will not.

They are:

- GuaranteedDelivery (enabled/disabled):  for setting guaranteed delivery.
- GuaranteedOrdering (enabled/disabled):  for setting guaranteed message ordering.
- AtMostOnceDelivery (enabled/disabled): for setting message delivery without duplicates.
- GroupMaxIdleDuration (number of seconds):
For setting the elapsed time limit from the last message sent or received in a group, 
after which the group can be terminated.
- GroupExpiryTime (number of seconds):
For setting the date and time after which the group can be terminated.
- ExpiryTime (number of seconds):
For setting the date and time after which a message must not be delivered 
to the receiving application.
- RetryMaxTimes (integer number):
For setting how many times a message must be resent if not acknowledged.
- RetryTimeInterval (number of seconds):
For setting the minimal elapsed time between two re-sending of the same message. 
- ReplyPattern ("response", "callback", "poll")
For setting the mode of response for Acks or Faults.


Messaging Scope of Agreement Items:
-----------------------------------

The messaging scope of these agreement items may be:
(s1) All messages sent over a connection between a Sender RMP and a Receiver RMP (default).
(s2) All messages sent within a Group.
(s3) a single message, within a group of several messages (non-singleton group).

Some agreement items obviously relate to a particular scope, e.g. ExpiryTime
is affecting each message separately, while GroupExpiryTime is an agreement about groups. 
Such scopes are "required" scopes that must be supported.

The smallest required scope for each RM agreement item is:

Message scope (s3):
- ExpiryTime
- RetryMaxTimes
- RetryTimeInterval
- ReplyPattern  
- GuaranteedDelivery
- AtMostOnceDelivery

Group scope (s2):
- GuaranteedOrdering
- GroupExpiryTime
- GroupMaxIdleDuration

NOTE: although an RMP must support each agreement item at the scope level above, 
the RMP implementation may also provide a way to specify these values for a broader scope.

Example: an RMP implementation may decide to provide a way to specify the ExpiryTime 
value for all messages of a group. 


Rules about Agreement Items, when used in an RM Agreement:
---------------------------------------------------------

- If GuaranteedOrdering is enabled for a messaging scope, then GuaranteedDelivery and
AtMostOnceDelivery MUST also be enabled for that messaging scope.

- If GuaranteedDelivery is enabled for a messaging scope, then the items 
(RetryMaxTimes, RetryTimeInterval) MUST also be defined for that scope.

- If GroupExpiryTime is enabled for a messaging scope, then the item GroupMaxIdleTime 
must not be enabled, and vice versa.