Re: [ws-caf] Relationship of WS-CAF to WS-TX

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

Eric,

I appreciate your thought-provoking comments.

It is not clear to me that WS-Context is maximally useful unless it 
becomes in some way related to WS-Coordination. Presumably 
WS-Coordination can become the dispenser of WS-Contexts? Do you have 
this in mind?

I certainly agree that WS-TXM BP is the least overlapping of the three 
transaction protocols. As you know, in my view it is unfortunate that 
such a segmented approach has ever been taken to this problem space, but 
that is the reality we are working with.

In this context, a protocol that seeks to permit bridging of protocol 
domains (the primary purpose of BP as I see it) is an interesting 
notion, although considerably at odds with the multi-protocol intent of 
the WS-Tx family.

To bridge protocols there must be mappable messages with identical 
semantic intent. A bridging protocol must superset all protocols to be 
bridged, in order to permit any known semantic to be transmitted. 
Clearly, if a particular protocol does not express a particular semantic 
then the bridging protocol will not be required to transmit it; and 
there may be semantic loss if the protocol-to-be-bridged-to is less 
expressive than the protocol-to-be-bridged from.

Let me give one example. WS-BA does not permit a close message to be 
faulted: it is assumed that no errors can occur in processing the close, 
because the work of the close is purely technical (log dropping). WS-AT 
does not permit faulting of either commit or rollback. WS-BA does permit 
faulting of a compensate message.

A bridging protocol will clearly have to have a fault message for at 
least compensate. If you wish to bridge BTP (which permits heuristics on 
both confirm and cancel) then the BP will have to do faulting for both 
messages.

With this facility, it will be possible to communicate heuristic 
faulting upwards until a bridge node is reached which cannot map the 
message. At that point the message will be converted into a "finished" 
message that does not communicate the failure semantic.

There are several interesting points here:

In the collective mindset of the WS-Tx authors, there is a notion of 
disjoint transaction models. This is sometimes implicit, and sometimes 
forcibly expressed. It is assumed or asserted that if one participant is 
ACIDic, then all must be ACIDic, otherwise "it is not possible to reason 
about the behaviour of the whole system", to paraphrase Mark Little and 
Tom Freund. The very division between AT and BA is an expression of this 
mindset. How popular will it be to provide a means of breaking down 
these barriers?

Example: A root transaction that controls two sub-transactions via a BP. 
:Root R and S1 and S2 communicate via BP. S1 uses AT internally (in its 
branch of the tree) and S2 uses BA internally. This is a transaction 
tree that I find entirely acceptable conceptually, because I consider 
blocking (e.g. 2PL in the AT tree) to be a local matter -- if the S1 
participants are happy to block (act in an isolated manner) while the 
transaction R is incomplete, then this has no necessary implications for 
the S2 participants, who are likely to act in an open, non-isolating 
manner. Is this behaviour acceptable to the advocates of segmented 
coordination protocols each dedicated to a particular task?

The bridging protocol will be a protocol fully capable of independent 
use (i.e. it could be used to communicate directly with application 
endpoints at the leaf nodes of the tree, because it is impossible to 
distinguish between a leaf node and an inner node, from the perspective 
of a superior, parent node). This would mean that a third, interoperable 
protocol had been created, over and above, but also alongside WS-AT and 
WS-BA. In the my example, why use AT and BA to do S1 and S2 work 
internally? -- the bridging protocol will be more than capable of doing 
the work of both branches.

You are moving dangerously close to the BTP heresy: that one protocol 
can equally well manage all two-phase outcome behaviours, and that 
endpoints define their own isolation and other behaviours in an 
encapsulated manner.

Less politically: the BP will have to specify rules for the collision of 
unequally expressive protocols.

I appreciate BP has a checkpointing aspect. I don't agree with the idea 
of global checkpointing, but I think the idea has been little discussed 
and explored. I also think that there is considerable room for a more 
reliable and general scheme for transaction outcome notification, and I 
think BP contains some thinking on that issue.

To summarize: I think that you would need to establish the motivation 
for BP to ensure that it has sufficient independent use and value to 
warrant continued effort. What are its goals, what will it permit that 
is otherwise impossible, and how do those goals mesh with those of WS-Tx?

Alastair

Newcomer, Eric wrote:
>
> Hi,
>
> I promised during the last concall to send email summarizing my 
> suggestion for continued WS-CAF work to complement work planned by the 
> WS-TX TC.
>
> I believe many of us have observed many times that the situation with 
> regard to the Web services transaction specifications is less than 
> ideal, and many of us have also discussed many times the various 
> reasons for this and events that have led to the current situation. 
> However we are now faced with the opportunity once again to bring the 
> community together or somehow act in a way that continues the split.
>
> In the ideal world we would not have had to consider what to do with a 
> dual set of specifications based on the same approach, containing some 
> overlap, and some complementary bits. However, we do not live in that 
> world. Our opportunity now is to find the best way to reconcile the 
> current situation and preserve as much as possible of the good work to 
> which we have all contributed.
>
> It is clear that WS-Context represents a new specification that 
> describes a feature not proposed or considered by the WS-TX TC. So I 
> think we can all agree that this work needs to be completed, and it is 
> on track to be completed soon.
>
> I think we can also all agree that the BPM transaction model is beyond 
> the scope of anything proposed or considered by the WS-TX TC. I think 
> we also should complete this work to ensure that it is maps to the 
> WS-C specification. A concern was raided during the last WS-CAF call 
> about the instability of the WS-C specification during the coming 
> year. The current WS-C specification is very stable as specifications 
> go, and the WS-CAF TC can easily track its progress.
>
> Furthermore additional variations on the 2PC protocol and compensation 
> based protocol may be of interest to some customers, rounding out a 
> kind of “library” of pluggable protocols.
>
> Comments?
>
> Eric
>
> +1 781 902 8366
>
> fax: +1 781 902 8009
>
> blog: www.iona.com/blogs/newcomer <http://www.iona.com/blogs/newcomer>
>
> //Making Software Work Together (TM)//
>