Re: [wsrm] Rel-113 (Message delivery/processing after fault)

[Tom Rutt <tom@coastin.com>]

Jacques Durand wrote:

> Rel-113 (Message delivery/processing after fault):
>
> Current listed proposal:
> "Any message which results in a fault should have no further 
> processing done to it.
> Unexpired message which results in a fault will not result in the 
> delivery of that message."
>
> Discussion:
>
> First I think we should state the issue in terms of Delivery: 
> "processing" is too vague:
> "Any message which results in a fault MUST NOT be delivered. Any 
> delivered message MUST NOT generate
> a fault."  I would drop the Expiry line, as it is a repeat of what the 
> spec already says (see def ExpiryTime)
>
> Second, we should address separately the special case of unsupported 
> features:
> It is unclear whether some Faults should actually prevent delivery or 
> not.
> Consider "NotSupportedFeature" fault.
>
> Case 1- a message requires an Ack, yet the receiver does not implement 
> this feature.
> Should the Receiver drop the message and just send back the Fault? Why 
> not deliver
> the message?
>
> cons: the Sender may  not want to deal with an unreliable party at 
> all. If it wants
> it can always resend the message without AckRequested (might be a 
> configurable policy for RMP).
>
> pro: the policy could be that when one party cannot fulfill the RM 
> contract,
> behavior w/r applications is same as if there was no contract at all. 
> Meaning always
> delivering the received message (while sending back an RM Fault.)
>
> Case 2- a message requires an Ack + Dup elim, yet the receiver only 
> implements Acks.
> Should the Receiver drop the message and just send back the Fault? Why 
> not deliver
> the message?
>
> cons: the Sender may not want to deal with an unreliable party at all. 
> In fact, delivering
> may be harmful as duplicates may be delivered while it was not 
> expected from Sender.
> If the Sender still wants delivery, it can always resend the message 
> with AckRequested
> but without Dup elimination. (might be a configurable policy for RMP).
> Another policy could be to never deliver and notify application.
> So either policy should be configurable and depends on app needs.
>
> pro: the policy could be that when one party cannot fulfill the RM 
> contract,
> behavior w/r applications is same as if there was no contract at all. 
> Meaning always
> delivering the received message (while sending back an RM Fault.) even 
> duplicates.
>
If the message is non idempotent, there may be harm in duplicate 
delivery (e.g., sending a debit transaction twice).

> My recommendation: Go along the "cons" cases above. Although Case 1 
> could go either way,
> it is hard to support Case 2 falling back on a default "no RM" policy.
> The "cons" cases above would still allow for non-RM behavior, via 
> configurable RMP
> "default policies", as hinted above. So the current listed proposal is 
> OK, after
> proposed rewording.
> We should mention that it is OK for an RMP to follow a default policy 
> where a message may be resent (with a
> different ID) with header adjustment so that it does not clash with 
> unsupported RM features on the other end,
> and therefore be delivered. That is the option of removing parts of 
> the RM contract that can't be fulfilled.
> Note that it would just be a convenience feature, as the application 
> may always decide to do so.
>
> In a future release, the spec may require that an RMP be able
> to implement at least two default policies: "do nothing and notify 
> app", "remove the unsupported
> RM faeture and resend"(can be adjusted for each RM features).
> I think it is important for interoperability to require this.
>
Does this mean we do not deliver after fault?



-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133