Re: [ws-tx] Issue 030 - 2 proposed resolutions

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

Ian,

In the document on this issue that I submitted just after the last meeting, I raised four possible solutions:

    http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17588/2006-04-07.WS-Addressing.and.WS-TX.doc

Your proposal 2 is very close to my Option 2 (Minimal Use of WS-A). This is the cleanest and best approach, in my view.

My Option 3 somewhat resembles your proposal 1, but avoids active (non-none) use of [reply endpoint]. I believe that active use of [reply endpoint] has always been a source of confusion, and should be avoided in any resolution.

Your Proposal 1 is probably closest to my Option 4, but deftly avoids the MUST use of a [reply endpoint]. I raised Options 1 and 4 as "strawmen" to elucidate the spectrum.

* * *

Your Proposal 2, while very close to my Option 2, does not fully deal with all the points that must be tackled.

My Option 2 bullet points were:

2.A)      Use either WS-A [source endpoint] or a WS-TX [ws-tx amnesia endpoint] for non-terminal messages 

2.B)      Do not mandate (but tolerate) presence of [fault endpoint] and [message id] on any  message. Or, ban use of these two properties. Or mandate that they must be ignored if received.

2.C)      Treat WS-TX faults as terminal notifications, which can always be delivered, either to cached EPR or to supplied amnesia address. WS-A fault delivery rules (part of reply-processing model) do not apply. 

2.D)      Set [reply endpoint] to “none”, to avoid dragging in “anon” default. This is necessary because infrastructure fault delivery might pick up on an anon value in some circumstances. 

2.E)      Incorporate a statement in the spec making it clear that the reply-processing model of WS-A is not being used. If we choose to process [fault endpoint] and [message id] if supplied by the sender, then Section 3.4 reply-formulation rules may apply to faults, and that should be explained.

2.F)      Treat WS-A predefined (infrastructure) faults as undeliverable (or potentially undeliverable), because 

i.        [fault endpoint] will or may be omitted

ii.      [reply endpoint] is set to none to avoid use of anon, which is forbidden

iii.    WS-A does not send faults when [fault endpoint] is absent, and [reply endpoint] is set to “none”

iv.      [ws-tx amnesia endpoint] is unknowable to infrastructure (layer violation)

I believe that your proposal 2 does not yet address bullet points 2.B), 2.E) and 2.F).

* * *

If we are not going down the Option 2/Proposal 2 route, then, in my view, Option 3 is preferable to your proposal 1 in a couple of respects.

My Option 3 bullet points are repeated here:

3.A)      Use either WS-A [source endpoint] or a WS-TX [ws-tx amnesia endpoint] for non-terminal messages 

3.B)      Mandate presence of [fault endpoint] and [message id] on all messages

3.C)      Treat WS-TX faults as WS-A faults. WS-A fault delivery rules (part of reply-processing model) do apply. All faults are always deliverable, because of B). 

3.D)      Set [reply endpoint] to “none”, to avoid dragging in “anon” default. This is strictly unnecessary because the receiver will never use the [reply endpoint], but it does help make it clear that [reply endpoint] is not part of the picture, and that the “anon” endpoint will never be used.

3.E)      Incorporate a statement in the spec making it clear that the reply-processing model of WS-A is not being used, other than for faults

I believe we should avoid the tangle with [reply endpoint] altogether: the combination of [source endpoint] and [fault endpoint] properly differentiates the two models for two kinds of messages.

It is not made clear that all messages must have message ids. They must, to apply reply-formulation rules for faults, and this should be clearly said. (Equally, if your proposal 1 is adopted, it is impossible to follow the reply-formulation rules for "amnesia" unless [relationship] is used, which requires [message id].) If you omit message id then you can legally create an undeliverable response which seems unnecessary.

* * *

My point 3.B) does not take account of the possibility of a [fault endpoint] = "none". Your proposal 1 does not address the possibility of a [reply endpoint] = "none" in the amnesia case. Can we not mandate that [fault/reply/souce endpoints] are non-anon, non-none unless specifically stated otherwise (e.g. to  switch off [reply endpoint])? I think we may be in danger of losing an aspect of the original, intended content of the term "physical address" (i.e. a repliable, usable address, not a null value, nor an anon).

***

Independently of the option chosen, and in line with dropping the term "physical address", the WS-Addressing spec definitions of "request-reply" or "one-way" do not exactly line up with what WS-TX is up to. One-way is defined as "no indication of future interactions", and that is not true of our messages. "Request-reply" is rather loosely, or flexibly, defined, and it would be hard to argue that some of the behaviours we have fall cleanly outside the scope of that term as described in WS-A. The point here is that we use the WS-A properties in a complex and partial way, to describe a bilateral conversation. References to the terms "one way" and "request-reply" could simply be avoided in favour of concrete descriptions of how WS-A properties are actually used, and direct reference to use of EPRs (WS-A Core 3.3) and reply-formulation (WS-A Core 3.4).

This is most significant in WS-Coordination, where greater explicitness than you suggest would be appropriate (specify that [reply endpoint] and [message id] must be present on request messages, and that 3.4 should apply to all responses, fault or otherwise).

***

I also suggested a procedure for triage of the various sub-points, which I still think would enable the discussion to effectively proceed from primary to secondary points in a clear way:

1. Which option? My Option 2/Your Proposal 2 (which have same broad thrust)
                            My Option 3
                            Your Proposal 1
                           [any other proposals raised]

[If we want to make this simple procedurally, then I would suggest that we vote first on a motion to adopt the thrust of my Option 2/your Proposal 2. If that wins then the rest can fall away. That is the big fault line, if you will pardon the pun.]

2. If Option 2 (Your proposal 2) selected:

a) [source endpoint] or [ws-tx amnesia endpoint]? 

b) Permit and optionally process [fault endpoint] + [message id] if supplied. OR

Permit and forcibly process [fault endpoint] + [message id] if supplied, OR

Pemit but ignore [fault endpoint] and [message id] if supplied. OR

Ban [fault endpoint] and [message id]?

3. If Option 3 selected:

a) [source endpoint] or [ws-tx amnesia endpoint]? 

b) Do we set [reply endpoint] to “none”, or allow it to default to “anon”?

4. Remove wording on “physical addresses”, replace with ban on “anon”? [mandate non-none values for [source/fault endpoint]?

[Remove refs to one-way or request-reply?]

5. Revisit use of reply-processing model in WS-C?

Yours,

Alastair

Ian Robinson wrote:

Max and I have been working on some options for resolving issue 030 [1].
There has been a lot of good discussion on this issue already; we have
suggested 2 (different) concrete resolutions that we can discuss on the
call.
Proposal 1 is closer to the status quo; it retains the use of the
wsa:ReplyTo MAP for non-terminal notifications but adds a requirement for
terminal notifications to set wsa:ReplyTo to 'None'.

Proposal 2 replaces wsa:ReplyTo with wsa:From to further emphasize that
protocol message are never replies. This proposal also classifies WS-TX
"faults" raised during the agreement protocols (e.g. 2PC) as terminal
notification messages.

Proposal 1 (Issue30_Propsal_1_WSAT.doc)   (See attached file:
Issue30_Proposal_1__WSAT.doc)


Proposal 2 (Issue30_Propsal_2_WSAT.doc)   (See attached file:
Issue30_Proposal_2__WSAT.doc)

For either of these proposals, we believe WS-Coordination simply needs to
remove text that is already stated in WS-Addressing:

(See attached file: Issue30_Proposal__WSCOOR.doc)

[1] http://docs.oasis-open.org/ws-tx/issues/WSTransactionIssues.xml#i030

Regards,
Ian Robinson
STSM, WebSphere Messaging and Transactions Architect
IBM Hursley Lab, UK
ian_robinson@uk.ibm.com