I don't understand a number of Mark's arguments here.

1. A context that flows back on a response is not an OTS concept. There is no such concept in OTS. This is a BTP concept, called "context reply". In OTS there is assumed to be application message pairing, equivalent to return of a function call in X/Open DTP's modelling mindset. OTS wrongly applies the X/Open synchronous model to the distributed checking problem.

2. OTS has a concept of "reply checking". This states that one must count back the application responses that match each application request. This is crude and excessive.

OTS states that checking in a distributed tree is tantamount to

that all transactional work of all leaf nodes has been completed.

In fact:

a) an application response may be the first or nth of a conversational stream, and its arrival cannot be construed as equalling completion of anything other than its role in the application's own protocol;

b) the danger of unchecked behaviour arises, not from attempting

processing until all transaction work has been accomplished, but from attempting confirmation before all participants are enrolled.

A one-way message-based transaction completion protocol can begin to pass two-phase requests downtree long before all leaf node work is completed. The key point is that, while a PREPARE downtree may stall waiting for a PREPARED (wait for work to complete), we must not send PREPARE to only some of the required participants. If we do then we

leaving them in a solitary state of preparedness (a state from which they can never escape short of a brutal backstop timeout on their attempts to retry obtaining a second-phase instruction). The terminator application should be able to leave transaction completion to occur without regard to its own lifecycle.

3. BTP correctly addresses these two problems a) and b). It introduces

signal that means: "all enrolments stemming from an application message have been processed". This signal is a BTP message CONTEXT-REPLY. It

be sent independently of application responses or as part of an application response message (as a header element). This signal logically terminates the stream of 0..n ENROL signals that may arise as a result of a service receiving an inbound CONTEXT message:

CONTEXT ENROL/ENROLLED ENROL/ENROLLED ... CONTEXT-REPLY

This sequence could be thought of as the "checking sub protocol".

(This is a simplification: the reply can be used to communicate failure of required enrolments, and there can be a stream of context replies to indicate to the app that it's in business, but that the protocol level checking hasn't been completed.)

4. The point I have been trying to get across in the last week or so is that the need satisfied by CONTEXT-REPLY is separate from the issue of "boxcarring".

BTP has all kinds of (useful) network traffic optimizations. It can concatenate any number of protocol messages together in a wrapper element holding BTP messages ("bundling"). And it can also "group" messages to create compound semantics (e.g. CONTEXT-REPLY & ENROL & PREPARED).

Mark says:

Mark then goes on to explain that his approach i) -- so sedulously distinguished from BTP -- is in fact to have a bunch of enlistment messages that accompany a one-way response message called ... a

context, which sounds awfully like approach ii).

Without vectorization we cannot group the context reply ("checked")

the enlistments or registrations that must succeed to achieve the checked state. The checked message has no magical power on its own to achieve vectorization.

5. Mark is right to say there are two ways of achieving vectorization: by relying on the infrastructure, and by doing it yourself. I have to smile when I read that the SOAP infrastructure will do it for us. I

been hearing this for four years. In what decade, and through which well-known protocol nearing maturity within the WS architecture will this occur?

In BTP we did three wise things as a TC on this kind of question -- refused to reference incomplete specs, defined all the facilities we needed abstractly, and defined a "today's technology" binding that concretely expressed them -- while defining how a "tomorrow's technology" binding might be created when the time came. The abstract EPR/WS-A issue. Are these WS-CAF specs to be capable of implementation this or next year? If so then I suggest we need to define how

is going to be done, or drop the attempt to support it altogether.

6. Which brings me back to Mark's proposed text. Boxcarring is achieved by stating that the context will contain enlistments as extension elements. Mark comments:

having a context reply by using an extended context]

general

I summarize this as:

Approach i) [Nothing to do with OTS, original Mark proposed text]

= have a context response and put a number of enlistment elements

it.

Approach ii) [BTP]

= put a number of enlistment elements within a wrapper, and then optionally carry that freestanding or grouped with a context reply.

Approach iii) [Mark musing on an alternative]

= "have addParticipant (enlistments) messages in a vector".

On iii) How, where? As free-standing header elements (which implies

must run alongside application messages (which is not required)? As children of an element specifically for bundling WS-CAF protocol messages -- exactly what <btp:messages/> does in BTP? This would allow transmission alone or piggybacked as a header element on an app

This leads to a wrapper, and thence straight to approach ii), as in

I think it would be brain-bending to use the context itself as such a wrapper, but someone might come up with that suggestion.

[Incidentally I cannot see why one would restrain oneself from using

technique in i) as a technique for *any* bundle of messages. And I also cannot see why you would hold back from allowing a wrapper to contain anything CAFish.]

I simply do not understand what "contextualizing all the one-way messages" has to do with this. The one-way messages of the application must *all* be contextualized, even if they have no need? What if the protocol semantics have nothing to do with app messages and are out-of-band to the app? The one-way messages of the protocol(s) must

be contextualized? What would that mean?

7. WS-CF and transactions: how do they interrelate in this area?

Finally, to pull it all together -- WS-CF needs boxcarring to allow vectorized tree-building or graph-painting. WS-TXM (and it won't just

WS-Acid, which raises the need for a general TXM level protocol), needs to have a way of saying "checked, enrolments done".

They may or may not be combined in a single message, but they are semantically distinct.

If they are combined then they need a bucket to travel in together. An augmented context can be used as the bucket. It needs to have an extension element for checked that belongs to WS-TXM (and undefined message in the current spec). It needs to be able to contain multiple addParticipants for WS-CF.

But a context is not usually thought of as a body element, and it is unclear why context is being used just as a bucket, aka a wrapper. And it is unclear why the checked message should have to travel with an app message, as a header etc. And it is unclear why addParticipants should have to travel in something called a context to achieve multiple registrations in one go.

This points to a WS-CAF bucket for multiple messages, that can be used as a header element, as a body element, as an extension element of context if need be etc. This is what BTP does. It works. It addresses all use-cases.

8. Checking can also be achieved by counting of identified enrolled inferiors. This can be dealt with separately, but it should not be forgotten. It is a WS-TXM-general need, not specific to WS-Acid.

* * *

This entire discussion begs the question: why are we trying to reinvent the wheel of BTP in these areas? I venture to suggest that the same unavoidable question will plague most other discussions as we proceed with WS-TXM. This is exactly what I meant by "needless variation".

We would perhaps do ourselves and the wider audience a favour if we frankly set out to copy BTP as faithfully and as literally as makes sense given the layering of WS-Context and WS-CF. That way we would end up with a workable and proven solution of equal power, in a short space of time, on this issue, and on many others.

Alastair

Alastair J. Green CEO and CTO Choreology Ltd 68 Lombard Street London EC3V 9LJ www.choreology.com

+44 870 739 0050 +44 870 739 0051 (fax) +44 795 841 2107 (mobile)