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

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

First of all let me be clear about something: as I said at the f2f, I'm 
still of the opinion that the specifications currently use WS-A in a 
confusing manner, which is why I suggested removing wsa:ReplyTo in 
favour of something else (wsc:ReplyTo was the placeholder). However, as 
we've seen there are a number of different ways in which this could be 
tackled and I think this is an important enough issue that it's worth 
playing a bit of Devil's Advocate for a while longer. Apologies if this 
has been covered in the last telecon, but since the minutes haven't been 
posted yet I can't tell.

Alastair Green wrote:
> 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).

It can be argued that a one-way message includes delivery ack (it's just 
not the processing/processed-ack that you get). What you've described is 
a fire-and-forget message (c.f., vanilla UDP), whereas it's entirely 
possible to have a one-way message that is reliably delivered (c.f., 
TCP). The acknowledgement of delivery (or not) of the message is an 
implementation detail: both are one-way messages in my book because (as 
you've done, I think) I'd separate the act of delivery from the act of 
processing - fairly typical for reliable (and group) communications 
protocols BTW. But that's a slight aside!

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

Not quite true: it was avoiding imposing our own semantics on their use, 
i.e., overloading the meaning of wsa:ReplyTo, which was leading to 
confusion. I don't think we can (or should) prevent the use of 
wsa:FaultTo, for example.

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

So I agree, but as I've said in previous emails and at the f2f, we need 
to be clear in the specifications why we aren't using wsa:ReplyTo. 
That's not a difficult thing to articulate, but I do think we need to 
say something. I'll dig out some of my previous emails and can propose 
some text based on cut-and-paste if necessary.

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

Absolutely, but we shouldn't be doing anything here that prevents 
composition. I want to be able to run secure, reliable and transacted 
sessions without having to a) introduce vendor specific extensions, or 
b) raise issues against 1.x versions of the specification, where x> the 
current minor revision number.

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

OK, so I think there may be some confusion around the term 
"composition": I'm not suggesting that this is composition between WS-TX 
and WS-A, but rather that through our use (or not) of WS-A in WS-TX, we 
do not impose any implementation restrictions on the use of WS-SX, WS-RX 
or anything else that may also use WS-A and concurrently.

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

Which "WS-A predefined faults" do you mean?

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

WS-A doesn't say what a fault is:

[fault endpoint] : endpoint reference (0..1)

    An endpoint reference for the intended receiver for faults related
    to this message.

So obviously it's assuming a pattern where the receipt (and processing) 
of a message generates some fault/error, rather than, in our case, the 
fault/error is a natural part of the protocol (e.g., aborted). I'd like 
to see us using wsa:FaultTo in cases where it does make sense and I'd 
say that InvalidState or InvalidParameters are such situations: they are 
not a natural part of the protocol - they truly are erroneous conditions.


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

I agree: that could be modelled as a protocol message.

Mark.

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