LC107 Discussion

Here is my attempt at framing the discussion of issue 107, as per the
action item I took last week. I believe in the last call we covered two
separate problems:

1. WSDL 1.1 alignment: The original formulation of the issue suggested that
we align the terminology in Section 3 of the spec with that of the WSDL 1.1
specification when referring to one-way and request-reply patters. In the
case of "request-reply", the misalignment was intentional on the part of
the original authors of the submission. The reason is that it is important
not to constraint the use WS-Addressing's support to replies that are
explicitly reflected by a WSDL request-response MEP, since that would leave
out many use cases of asynchronously correlated responses (two one-way
messages in different directions) or, potentially, protocol level message
exchanges. The same concern applies in part to the one way vs. "One-way"
terminology alignment, for the same reasons (we don't want to restrict the
notion of a one way message to WSDL described ones).

My position is that it is very important that make it very clear request
reply pattern that WS-Addressing supports is not limited to WSDL 1.1 or 2.0
described message exchanges. This was already concluded when we resolved
issue 38, so from my point of view the only thing that needs to be done is
to restate this fact more clearly (clearer than in the third introductory
paragraph to section 3).

- A second related concern, raised, I believe, by David H. is whether or
how the "request reply" notion should fault messages. This concern relates
to the current "asymmetry" between replyTo and faultTo. I believe that this
problem has implications that go well beyond LC 107, so it should be dealt
with in a separate discussion. My position is that faults are different
form replies and that they should not be covered in the "request-reply"
discussion. My reasons for this position (which, again, seem to be clearly
beyond this LC issue) are below. In any case, I suggest that we move
forward to close LC 107 w/o waiting for the fault/reply discussion to be
closed, presumably as part of LC 83, and review as necessary.

Unlike replies, faults are almost never "expected"; a fault is always the
consequence of an unexpected error, an that is why it is no natural to
require clients to decide when they "expect" a fault - they would just not
send a fault-generating message to begin with. So it makes sense both to
treat them as separate and to maintain the asymmetry between faultTo and
replyTo, with the current defaulting of the destination of faults to the
replyTo address when faultTo is absent.

Paco

Received on Monday, 23 May 2005 03:43:27 UTC