[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 030 - Proposal 2 silence on WS-A faults
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:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]