rehabilitating asynchronous pull

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

After talking with some SCM users, I decided to revisit the proposal for handling "intermittent connectivity". I think this new version is much more agreeable.

 

It makes the case for asynchronous Pulling, something vaguely discussed in the past but without much rationale for it.

 

Jacques

 

-------------- handling intermittently connected partners: ---------------

 

Use cases / Requirements:

 

- Some gateways may be down for a while, in an unexpected manner.

Other parties must be aware of this if they do not want to waste cycles trying to send or resend.

 

- "small" partners will not be connected all the time. Their availability windows

are usually known. Their partners must have a way to deal with this preferably in a

transparent way for the application layer.

 

Proposed approach:

 

- avoid using extra signaling to notify downtime / uptime.

- avoid resorting to "preventive" synchronous pulling, which would require the intermittent partner to *always* pull its messages so that its partners are not inconvenienced by unsuccessful pushing in case downtime happens. (synchronous Pull has a higher cost than push).

- Awareness of partner downtime can be established in two ways (matching two above use cases):

(a) sender relies on CPA info to store availability windows of partner when known (V2.1 has extensibility points)(the use of this info by MSH is implementation specific, its definition out of ebMS scope)

(b) after several consecutive delivery failures (no ack), an MSH may infer that this partner is unavailable.

- Behavior of sending party: When downtime is established for a partner (e.g. by (a) or (b) above) either the sending MSH notifies its application that the partner is not available and rejects new submissions, or is queuing submitted messages until the partner is available. The queuing is the same as for the Pull feature: these messages become available for subsequent Pull.

- Behavior of receiving party: When its downtime is over, the receiving party can either synchronously pull each message from the sender 1 by 1, or can send a single "asynchronous" pull request. The asynchronous Pull will simply tell the other MSH that it can now push the messages it has queued, like it would have done had a downtime not occurred.

 

What is new:

 

- the notion of "partner downtime", which leads to a specific behavior of the sender (automatic switch from a push behavior to a queuing behavior, and a new failure notification to application when queuing not possible.)

- the (re)introduction of the asynchronous Pull which means adding a mode sync/async to the Pull signal.