an assessment of the reliability of pulled messages

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

Title: an assessment of the reliability of pulled messages

About relying (after all) on WS-Reliability for ensuring the guaranteed delivery of pulled messages (ebMS Pull responses):

-------------------------------------------------------------------------------------------------------------

One of the reasons we did not consider this was the fact that this reliability case falls
under the more general reliability of  [synchronous] response messages (speaking in terms of SOAP MEPs)
and we knew that this is something WS-Reliability will very likely have to address, but in the next release.

Having now a second look at this, and at how much interpretation leeway WS-Reliability 1.1 would allow for this:

First, summarizing the best we can hope for:

- ensure guaranteed delivery of pulled messages in the same way as for any other message,
but with a resending mechanism that includes the Pull signal (since we can't just resend the response).
- in case of delivery failure, the pulled party will know and notify its Producer party the same way
as for pushed messages that fail.
- we get all this without introducing new ebMS signals (e.g. an Ack for pulled messages)

And then looking at how well WS-Reliability 1.1 can handle this:

- It is clear that the resending behavior can't be same for pulled messages as for pushed messages.
WS-R 1.1 states (3.2.1) that "a resending technique MUST be used ... [ for messages under GuaranteedDelivery agreement)"

but is not more specific. So it can be interpreted as resending of the Pull ebMS signal (which would cause
resending of the cached pulled message). More on this later.

- the Reply Patterns as defined in 2.4 do not preclude "reliable" responses (of a SOAP request-response MEP) that
have themselves wsrm:Request headers (of course, a "response" reply pattern would not make sense here)

- Which RMP operation is used for submitting a "reliable" pulled message is TBD. DO not see major issue here though
would need be clarified by implementors. Both Respond and Submit seem open (yet reliability of Respond unspecified.)

Conclusion: Reliability of pulled messages is certainly underspecified in WS-Reliability 1.1
meaning it is not precluded, but 1.1 is mute about associated restriction(s)
(e.g. about usable reply patterns, related faults)
Certainly WS-Reliability implementors would have to be aware that these features are needed in addition to what 1.1 requires, for use in ebMS.

One more word about the resending mechanism for the Pull:

- It has been suggested in the meeting this afternoon that a Pull resending could be handled at ebMS MSH level.
I would advise against that for several reasons.
First, nothing prevents a pulled message to have both wsrm:Request header and wsrm:Response header for acking of the Pull.

So I would just rely on guaranteed delivery of the Pull message itself and associated resending at RMP level.
Then, the Pull is not really idempotent (ebMS queue management).
Also: the pulled party is waiting for an Ack that targets the pulled message that was initially submitted to RMP.
The receiving RMP can associate successive resends of a Pull request with this same (cached) pulled response,
but only if the resending is done by sending RMP (if done by MSH, would look as different requests for receiving RMP,
mandating different responses - at least looking different from RMP viewpoint - each of these asking for a different Ack).

Correct interpretation of a Callback Ack for these copies, and correct delivery failure notification to the pulled party depends on this.

-Jacques