Re: [ws-caf] ACTION for optimization of registration

[Mark Little <mark.little@arjuna.com>]

Alastair, I'm fairly under the weather today, so probably won't be able 
to reply to any more of your email until tomorrow (with luck). However, 
I do feel it necessary to correct you on one important aspect:

Green, Alastair J. wrote:

>I don't understand a number of Mark's arguments here.
>
>  
>
>>>(i) a WS-Context context that flows back on the response; none of our
>>>      
>>>
>
>  
>
>>>specifications actually restrict context flows on "outbound" 
>>>messages, since we're in a one-way domain, and this is conceptually 
>>>appealing as it continues to tie together message exchanges within 
>>>the same activity because the messages are all contextualised. Put it
>>>      
>>>
>
>  
>
>>>another way: all one-way messages are contextualised and we are 
>>>simply providing another specific element within the extension 
>>>capability we already support, to address this. The precedent for 
>>>this is the OTS and various commercial implementations.
>>>      
>>>
>
>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.
>
>  
>
That is simply not true (ignoring the checking aspect, because that is 
orthogonal). Although the specification says nothing about reverse 
context flow, it does not preclude it and several implementations 
take/took advantage of the fact for precisely that reason. For example, 
in several places the OTS specification simply talks about propagating 
the context between "execution environments" and makes no indication of 
direction, whereas in others it does talk about "requests". It is fair 
to say that this is a deliberate "oversight" that dates back to the 1.0 
version of the specification - I remember being involved in some fairly 
active discussion around this topic on the TC back in the early 1990's. 
I also seem to recall that at the time, Transarc and BEA were definite 
proponents of this requirement because of their existing implementation 
requirements. They also used it for low-cost interposition: subordinate 
coordinators were created upon request inflow and not registered with 
the parent until the response was received - the information about them 
was sent within a back context. Fairly obviously because it isn't 
mandated (or even fully specified), it affects interoperability in the 
OTS, so those vendors would only do it when they were sure about the 
capabilities of both endpoints, but that's a problem for the OTS - not a 
problem for the concept.

A little bit of further historical information that acts as another 
proof point. When we built the first distributed object transaction 
system in C++ back in 1986, we did precisely the same thing. This 
predated OTS, so we obviously had the freedom to ignore interoperability 
requirements (we were interoperable with ourselves, which was good 
enough for our users).

Mark.

-- 
Mark Little
Chief Architect
Arjuna Technologies Ltd
(www.arjuna.com)