Re: [ws-tx] Issue 030 - Proposal 2 silence on WS-A faults

[Mark Little <mark.little@jboss.com>]

Mark Little wrote:
>
>
> Alastair Green wrote:
>>
>>
>> The exception is Endpoint Unreachable/transient. It is useful to 
>> communicate the semantic: "Not yet. Come back in half an hour and I 
>> will be ready for you". This is a feature that BTP included in the 
>> 1.1 revision in November 2004, to reduce network chatter in 
>> long-running transactions. However, this is a semantic that has to be 
>> communicated and understood at the TX level: TX retry strategies 
>> cannot always be depressed to a lower layer, and I believe a new TX 
>> message (so-called "fault") should be created to  convey it.
>>
>> The TX "protocol faults" are really messages that express unusual but 
>> legitimate paths of conformant execution (or at least, that is the 
>> class of message that we /must/ be able to convey). Examples include 
>> any message that conveys incapacity to process because of receiver 
>> state (which could include security breaches, resource limitations, 
>> desynchronized state shifts). These are  not expressions of bugs, 
>> they are first-class protocol messages. The term "fault" is a 
>> misnomer, as I think Tom Rutt has pointed out.
>
> That all depends on how you interpret wsa:FaultTo. In other 
> specifications/standards (e.g., the CORBA Object Transaction Service), 
> such erroneous behaviour (still protocol specific messages) is 
> conveyed either through SystemExceptions or UserExceptions. The 
> distinction between the two is really one of signatures on the method 
> invocations, which is then related to likelihood of occurrence: if it 
> can happen at any point, then it's a SystemException, otherwise it's 
> specific to only a subset of the invocations and probably makes more 
> sense to be a UserException.

BTW, yes I know this is a gross simplification of SE versus UE, but do 
we really want to get into the many-month long debate we had in the OMG 
about retriable errors versus non-retriable ;-)?

Mark.
>