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

[Alastair Green <alastair.green@choreology.com>]

Hi Mark,

"One way messages"

What does a true one-way message look like? You send it, and you need know nothing about its passage, delivery or processing thereafter, other than application-observable effect on application data. In our context: I send Prepare and get Rollback, Prepared or ReadOnly. I don't get back a message about the message (a delivery ack): the fact of delivery or non-delivery has to be inferred by future app-level interactions (where WS-TX is the app).

Bob said that one-way messages are rarely seen in the wild, and he defined them as ones that neither receive a correlated reply, nor a fault reply (I am paraphrasing an older, very useful summary he posted 2 or 3 weeks ago). That is exactly the kind of message we need in WS-TX (and nothing more).

How do you define such a message using WS-Addressing? By using a WS-A-defined endpoint, e.g. [source endpoint] that does not imply the sending of faults or correlated replies. The rules we're interested in are 3.3 (how to use an EPR). The ones we're not interested in are in 3.4 (formulating a reply). Avoiding dragging in those latter rules is where this all started.

So, in answer to your question below: "... if WS-A supports one-way messages (which it does), why not use it?" -- Proposal 2 does exactly that. It's a pennyweight kind of message, and it requires a featherweight of WS-Addressing.

Composition

Composition is a means to an end, not an end in itself.

There is an argument for using WS-Addressing ubiquitously, in order to facilitate management infrastructure (easy to find the routing headers), although any management facility that doesn't support detection of headers from non-standard namespaces is going to be nigh on useless. Existing implementations would be more radically affected than necessary if WS-Addressing were removed. And the use of WS-Addressing in a full request-reply model for WS-C (which I think is a pointless complication) obviously implies the presence of WS-Addressing.

Beyond that, we should compose to avoid reinventing the wheel (which applies here), but we should compose to the minimum. External spec dependencies are necessary evils, not virtues, because they introduce sympathy sickness: sloth in creation, and difficulty in evolution.

WS-RX and WS-SX deal with different domains. I suspect that any attempt to produce an *X-WS-A composition spec would be a good example of excessive composition. WS-TX doesn't need the WS-A predefined faults because of its specific character (ordered conversations, infinitely retriable message transmission to achieve state synchronization despite intervening failures). So why mandate their use?

A smart thing about Proposal 2, as argued by Max and Ian, is that its silence on WS-A fault traffic allows implementations to pass that traffic, if they choose to collaborate to do so. It also allows that level of fault to be passed on a transport-level response, if the sender desires, and again, if the receiver decides to play ball. Presumably, absent special configuration, a layered WS-Addressing implementation will tend to play ball.

(I would not object at all to a statement that a receiver SHOULD play ball, if the sender either specifies a [fault endpoint] of "anon", or a non-anon, non-none [fault endpoint], and a [message id]. That would make things a bit more explicit. I think Max and Ian were keen to hear the sound of silence, judging from their comments on the call, and that was codified in a motion that was passed at the meeting.)

Faults and messages

On "WS-TX fault being a misnomer". I truncated my argument to avoid too much info in one go.

There are messages which simply express unusual paths to completion in a correct implementation, and these are first-class messages that need to be communicated. Expressions of endpoint incapacity (resource exhaustion, policy or authorization violations) are examples. Informational messages ("get status", "status", which WS-TX currently lacks) would have similar characteristics. If we define a mechanism for moving this type of message (which we have to), then we can move all other types of message. You could argue that Invalid State or Invalid Parameters are similar to some of the WS-Addressing "bug" faults: conformant implementations shouldn't produce them. But there is no overhead in supporting their transmission, if we define the ability to send any WS-TX-level message. Proposal 2 defines a mechanism that will allow normal, abnormal, frequent, and infrequent messages to be passed identically, and I think that is progress.

Two side notes:

A) The messages Invalid Parameters, Invalid State or Invalid Protocol could be returned in response to a "terminal" message. At first glance that could suggest that terminal messages need to specify [source endpoint] as well.

B) I think the one specific (optional) WS-A fault which is relevant (the "don't bother me again until n seconds later" semantic) should not be sent as a WS-A fault in our context, but should be sent as a WS-TX message (it is most relevant for WS-BA). I say this because there could be a need to send this either as a spontaneous utterance (the sender is about to quiesce or passivate on application instructions), or as a "cool it" response to a "pushy" message from the counterpart. It is not always a reply, therefore.

Alastair

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. 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.