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

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

 Jacques,

 Some comments below.

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?
 

 It all should  depend on the mustUnderstand (mU) attribute.
If the mU=1, and the
 receiver doesn't understand it, then it MUST generate a Fault
and message should
 not be delivered.

 If mU=0, then if the receiver understands it, then it will deliver and send an Ack. back
 and if if the receiver doesn't understand it, it MUST still 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?
 

 The mU attribute is on the Request element/Header and hence either
both should be
 supported or Fault is generated. The spec. doesn't allow the
liberty of pick n' chose.
 between various RM features sent in the same Request Header/element.

 
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.

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.
 

 I think we are trying to solve the policy negotiation problem to
some extent which is
 outside the scope of out charter.
>  
> 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.
>  
 Atleast for this release, we need to keep it simple and less ambiguous.

-Sunil