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

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

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. Rather than ignore "WS-A faults" (whatever that means), 
which I believe is potentially a bad idea from the composability 
perspective, I'd prefer us to make some explicit statement in the 
specification to make it clear what we mean and why.

>
> Nothing in Proposal 2 or in what I have laid out here demands or 
> assumes HTTP or TCP/IP. The ordered conversation/endless retry model 
> which underlies WS-TX protocols allows them to operate over highly 
> unreliable protocols where messages may be lost, misordered, 
> duplicated, and where no notification of receipt or processing is 
> received. If acks are available then they can be exploited, but they 
> are not required.

You're right in that if we mandate that all information relevant to the 
specifications must be conveyed as first-class messages that are tied 
together or routed/directed via mechanisms prescribed solely within our 
specifications, then it all works. But I think one of Bob's points is: 
why? What's the reason for doing so, when WS-A provides support for this 
which is being built on in WS-RX and WS-SX, to name but two other 
standardisation efforts. Maybe this is something that was discussed 
during the last telecon, and is covered in the minutes (where are they ;-)?

> I agree that WS-Addressing has no template for "one way message" and 
> "request reply". It has optional properties and rules for their use, 
> and these need to be referenced concretely and specifically. But WS-TX 
> does need one-way messages (and it only needs one-way messages).

Which comes back to the question above: if WS-A supports one-way 
messages (which it does), why not use it?

Mark.