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.