Splitting and lumping protocols (was RE: [ws-caf] WS-ACID)

["Furniss, Peter" <Peter.Furniss@choreology.com>]

I agree that, in so far as there is a perceived need for a ws and xml
version of the extant
acid/atomic protocols, WS-ACID or WS-AT do have an ecological (or
marketecture) niche. So
pulling WS-ACID out from the soup of the possible is reasonable. Whether
its technically
necessary to split it is another question, but one that is clearly going
to be ignored
(One might consider that no customer ever bought a protocol - they buy
the implementation
and the bit they are interested in is the api plus the knowledge that it
sends/receives
the protocol understood by some other implementation)

What is far less clear, and from your message is still an open issue, is
what comes out
of the soup next. Although there are other interaction patterns that
would deserve a
different protocol (in a narrow sense), I don't think the range of
function raised in 
ws-caf so far needs more than one.  But, for now, the important point is
that we 
agree that this question has NOT yet been answered in the TC - and, for
example, we
won't just split out WS-LRA in a few months because it was there,
without looking
at the problem domains in sight and working out what if the partitioning
is sound.

However:
We really would be doing ourselves, and the community, a service if we
did this with
ws-acid too.  There is a fundamental difference between splitting and
lumping protocols
and splitting and lumping implementation functionality. Your useful
comment in one of the
other messages is:

<mark>
As I've said on several occasions though: we've had experience of 
selling (to customers, partners and analysts) a BTP product and a 
product based on the "micro-protocol" approach. It was nearly impossible

for the former, even with (or is that despite?) the HP publicity machine

in full swing. The latter is a different matter: people just "get it": 
you get the separation of concerns, the core competency, the dedicated 
solution without impact on others, the leveraging of existing 
infrastructural investments (IMO this is critical to the uptake of any 
solution in this area, and is why we should concentrate on WS-ACID 
firstly), ...
</mark>

the thing is the latter part of that message is irrelevant to the
question of
splitting and lumping protocols.  A protocol, with possible markers or
qualifiers, that
can choose things (as, on a small scale, the alternative registrations
of WS-ACID or WS-AT
for synch/normal or volatile/durable) is more flexible than one that
forces choice 
a priori - why aren't there separate contexts for synch and normal ?
Because it would 
be uneccessary and complicate things.  Does (to take another example) a
WS-BA registration
need to declare whether it will demand a Prepare or can volunteer ? I
don't see why - if
the coordinator has received a Prepared, it needn't prompt, and if they
cross the
participant can ignore the surprise Prepare. There is no "need to know".
Widening, and heading
for the contentious area, how will the behaviour of the
service/participant be affected by the
knowledge that other participants are using locking ?  Locking against
what - their concept of transaction (in general) may be quite different
from this systems. Does it even matter that
all of them will get the same outcome ? (yes, but only in some cases).
The behaviour of the 
service is much more likely to be affected by expected duration of the
transaction, likelihood
of it being asked to rollback etc. But those would obviously be
qualifiers of a protocol - I
doubt anyone would suggest completely different sets of messages for
those cases.

Using a single protocol as the intercommunicating underlay for a RANGE
of implementations, which
are indeed oriented on different purposes allows those implementations
to interact directly when
their purposes touch. The alternative is to divide the domain up more or
less arbitrarily.



Peter

ps - btw, the approved minutes for the New Orleans meeting say, on
transactions:
<quote>
Transactions

Mark gives presentation on transactions.

Mark motions that TXM be split into separate, independent 
specifications. Greg Pavlik seconds. Martin asks if TXM disappears.

Greg Pavlik motions we move forward with ACID model and leave the other 
two alone. Mark seconds. AI to editors to adopt the broken out ACID 
model to use the Context/CF updates.
</quote>

There is no mention of anything like "It was also 
> agreed (again by vote) that the concept of transaction 
> "micro-protocols", or more specifically protocols that would be 
> targetted at specific use cases and not the "one size fits all" 
> approach, would be taken."

there is no mention of any discussion of this long-contentious point,
let alone a vote.



> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com] 
> Sent: 27 May 2005 09:49
> To: Furniss, Peter
> Cc: Newcomer, Eric; Martin Chapman; Green, Alastair J.; ws-caf
> Subject: Re: [ws-caf] WS-ACID
> 
> 
> 
> 
> Furniss, Peter wrote:
> 
> >The documentation relationship of the things is not at 
> issue. Separate 
> >documents for separate protocols is generally the current 
> direction of 
> >things (and historically, different standards groups have gone 
> >different ways in splitting and lumping).
> >
> >The point is, why these three ?
> >
> We're not saying there are three. What we are saying is that 
> there will 
> (probably) be at least two: one for interoperability with existing TP 
> systems, and one for long duration interactions. What we 
> agreed in New 
> Orleans was that the first of these we would address would be WS-ACID.
> 
> >Are each useful separations AS PROTOCOLS
> >from
> >each other, addressing different requirements that cannot be 
> met by use 
> >of each other or by some other arrangement of functionality. 
> Given the
> >range of function of the set, is there a need for more than 
> one protocol
> >?
> >  
> >
> Yes. Without opening up the discussion again (I keep coming 
> back to this 
> point: we were quorate at New Orleans and voted to take this 
> approach), 
> it appears that the majority of the industry (including those players 
> not within this TC) agree from experience and customer input, 
> that the 
> approach of protocols-per-problem-domain is the right one. We've seen 
> the almost complete failure of adoption of any other approach 
> time and 
> time again, for many reasons (technical included).
> 
> But, we're not ruling out a binding to BTP for those vendors who 
> strongly believe that it is the right approach. I fail to see 
> how this 
> is a bad compromise, since it gives all parties what they want. Since 
> we'll probably be defining a conformance statement for 
> CAF/TXM that says 
> (and I paraphrase): "you don't have to support all protocols to be 
> conformant", it also means that a vendor who is only 
> interested in, say, 
> the BTP binding, can support that to total exclusion of the 
> other protocols.
> 
> Mark.
> 
> >(not entirely exact comparison: there is one IP, and for a long time 
> >there were only two general-purpose transport protocols on it. All 
> >sorts of higher uses could have invented their own 
> equivalents to UDP 
> >and TCP, but didn't. Eventually the range of applications expanded 
> >beyond that (e.g. VOIP). Is the range of function covered by 
> the input 
> >TXM set analogous to transport requirements of Telnet to 
> SMTP, or does 
> >it range wider (c.f. DNS and VOIP))
> >
> >Peter
> >
> >  
> >
> >>-----Original Message-----
> >>From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
> >>Sent: 26 May 2005 13:55
> >>To: Martin Chapman; Green, Alastair J.; Mark Little; ws-caf
> >>Subject: RE: [ws-caf] WS-ACID
> >>
> >>
> >>I don't consider whether the models/protocols are in one spec
> >>or three to be a technical issue.  I think we are happy to 
> >>debate the merits of the various models at the upcoming face 
> >>to face.  My understanding is the decision was made during 
> >>the previous F2F to separate the content, not change it.  
> >>Whether or not it makes the discussion easier or more 
> >>difficult is certainly a matter of opinion but I would say 
> >>the more substantive issues relate to the content rather than 
> >>the form of the specs.
> >>
> >>I believe we also said during this week's call that we'd
> >>start the discussion on WS-TXM etc. during the next concall.  
> >>Email debate on them is of course fine in advance.
> >>
> >>But I don't think that was meant to reopen the decision about
> >>splitting up the spec(s).  My understanding was the 
> >>discussion would start from where we are following the 
> >>results of previous F2F.
> >>
> >>Eric
> >>
> >>-----Original Message-----
> >>From: Martin Chapman [mailto:martin.chapman@oracle.com]
> >>Sent: Thursday, May 26, 2005 8:34 AM
> >>To: 'Green, Alastair J.'; 'Mark Little'; 'ws-caf'
> >>Subject: RE: [ws-caf] WS-ACID
> >>
> >>Alastair,
> >>
> >>TXM is just a collection of different TX models. There is no
> >>real design philosophy that binds them aside from 
> >>being built on context and CF. Hence the decision to separate 
> >>and let them have independent existence. So lets 
> >>debate/design each one based on the goals each is trying to 
> achieve. 
> >>
> >>Cheers,
> >>  Martin.
> >>
> >>    
> >>
> >>>-----Original Message-----
> >>>From: Green, Alastair J. [mailto:Alastair.Green@choreology.com]
> >>>Sent: Thursday, May 26, 2005 10:34 AM
> >>>To: Mark Little; ws-caf
> >>>Subject: RE: [ws-caf] WS-ACID
> >>>
> >>>
> >>>Hi Mark,
> >>>
> >>>I think that we should take a step back. Why are there 
> three specs in 
> >>>the WS-TXM family? Are they actually needed, or the right 
> ones? What 
> >>>are we trying to achieve/what are the underlying 
> requirements? This 
> >>>is very major phase of work, and not one to be rushed at.
> >>>
> >>>The history of this TC is that a review of fundamental 
> >>>principles/model/architecture has usefully led to simplification 
> >>>towards the genuinely general, both with Context and WS-CF.
> >>>
> >>>I would like to propose a full discussion of the model and 
> principles 
> >>>behind the current WS-TXM input documents and their separation of 
> >>>powers at the face to face. I think I am right in saying that you 
> >>>have raised, for example, the question as whether WS-TXM 
> BP is useful 
> >>>as an independent spec.
> >>>
> >>>In my view the WS-TXM specs as they stand are a very 
> complicated way 
> >>>of achieving a set of fairly-well understood goals. They 
> also raise a 
> >>>couple of interesting new ideas (or at least not so generally 
> >>>accepted ideas).
> >>>
> >>>If WS-TXM is to be a useful competitor to WS-BA/AT then it 
> should be 
> >>>helpfully different (better, simpler, more functional etc).
> >>>
> >>>If WS-TXM is heading for the fate of WS-Reliability, then 
> it might be 
> >>>more apposite to seek emulation, rather than competition 
> -- i.e. get 
> >>>the capitulation over with quickly, and provide some helpful 
> >>>additional features that the WS-TX TC will be able to take 
> note of as 
> >>>it spits and polishes the
> >>>      
> >>>
> >>BA/AT specs.
> >>    
> >>
> >>>Per se, I have no objection to a legacy-adaption spec 
> which enables 
> >>>OTS vendors to respray the wire in XML colours, but I think we are 
> >>>jumping ahead too fast.
> >>>
> >>>Parenthetically, it seems that the difference between ACID 
> and AT is 
> >>>the difference between OTS and OLE-Tx.
> >>>
> >>>Heuristics are quite traditional, and I suspect the lack of 
> >>>heuristics wouldn't survive an open standardization of
> >>>      
> >>>
> >>WS-AT, if/when.
> >>    
> >>
> >>>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)
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Mark Little [mailto:mark.little@arjuna.com]
> >>>Sent: 25 May 2005 20:29
> >>>To: ws-caf
> >>>Subject: [ws-caf] WS-ACID
> >>>
> >>>Ignoring the differences in WS-Context and WS-CAF that may impact 
> >>>WS-ACID, does anyone have any issues with the protocol or
> >>>      
> >>>
> >>model as it
> >>    
> >>
> >>>currently stands?
> >>>
> >>>I can summarise the differences between it and traditional ACID 
> >>>transactions if needed. If you're looking for major differences 
> >>>between WS-ACID and WS-AtomicTransaction then they 
> probably come down 
> >>>to: WS-ACID uses a synchronization protocol, whereas WS-AT uses
> >>>volatile 2PC
> >>>
> >>>for "volatile" pre/post commit processing, and WS-AT 
> doesn't support 
> >>>heuristic outcomes (there's an "protocol violation" error message 
> >>>which isn't quite useful enough).
> >>>
> >>>Mark.
> >>>
> >>>--
> >>>Mark Little
> >>>Chief Architect
> >>>Arjuna Technologies Ltd
> >>>(www.arjuna.com)
> >>>
> >>>
> >>>      
> >>>
> >>
> >>    
> >>
> 
> -- 
> Mark Little
> Chief Architect
> Arjuna Technologies Ltd
> (www.arjuna.com)
> 
>