Comments in line, some bits of your post snipped for brevity.
*"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!
Yes, I agree. What I meant to say (the emphasis was invisible) was:
"you need know nothing ...". It can be useful to get acks
(they are not harmful, and may be beneficial) but they are not
necessary in the model that I described, which is the coordination
protocol model we are dealing with where the ack is inherent in the
conversation, and where retrying is assumed to achieve fault tolerance.
Some underlying carriers will ack away, and others may not. We need to
design against the limit condition (weakest transport), which I think
was one of Bob's points.
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.
Proposal 2 does not prevent the use of [fault endpoint], it does not
require it. See next comment below.
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.
An explanation would be useful, but is not strictly necessary. I think
that others in the TC are hotter on minimalism, but that is a stylistic
preference.
*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.
I don't think Proposal 2 in any way prevents composition. The proposal
uses [source endpoint], a standard WS-A property. There are no
vendor-specific (or even WS-TX specific) extensions necessitated. As
for not breaking against future values of x: that can always happen
(imagine that the WS-A WG decided in the future to reverse its decision
to retain [source endpoint]). The less we mandate of WS-A (the more
minimally we compose), the less likely we are to break in the future.
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.
Don't believe that is the case. Security might be a concern here -- I
haven't had a chance to examine any requirements in this area that
might be imposed by the security cluster. Have you got any insights on
that?
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?
The ones defined in the WS-A SOAP Binding, which I refer to by name in
my reply to Bob a few posts ago.
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.
In one dimension, I think you are right to logically group the Invalid
State and Invalid Parameters with the WS-A SOAP Binding predefined
faults: they report "bozo bugs" (non-conformant implementation errors
that ought to get eliminated in testing, like the malformation errors
that can occur at the WS-A level).
In another dimension, as Max points out, they belong in WS-TX because
they are logic error faults at the WS-TX layer. I think that his
argument against layer violation is compelling. You could argue that
they are unnecessary faults, i.e. that they SHOULD or MAY be sent to
help debugging and testing, but I think they belong to WS-TX, and
should use its mechanisms.
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.
Yes, this is a message that a correct implementation should send and
receive, not a report of incorrectness (non-conformance).
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.
|