Re: [ws-caf] Needless variation a waste of time

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

Green, Alastair J. wrote:

> Mark,
>
>  
>
> My customer experience is precisely the opposite of yours. Your 
> product approach has been rejected because you offer two sub-products 
> (different code bases) with three or four or five separate APIs to do 
> a job that can be handled by one, with one. It's the unifying vision 
> of an adjustable and mixable spectrum of behavours (and the common 
> code base and config and recovery etc etc) that's attractive. That's 
> my experience.
>
Which as I've said to Robert, is good: it shows that there are different 
requirements for different sectors. Seems again to point to the 
inadequacy of a "one size fits all" approach.

>  
>
> It is very easy to explain and to get agreement that a multiplicity of 
> protocols is an invisible annoyance and expense ... but it's also a 
> fact of life. We are not going to change IBM's or Microsoft's mind.
>
>  
>
> But: we in this TC can however stop banging our own heads against a 
> brick wall, and in the process make life that little bit easier for 
> the ultimate customers and users ... who do not need shadow specs for 
> the two "micro protocols" that IBM has deemed are appropriate for WAS 
> or WBI.
>
The aim of this TC is to provide an open standards approach to composite 
applications, including context, coordination and transactions. 
Irrespective of what is going on elsewhere outside of a standards 
process, that work should go on. It is not a coincidence that IBSoft and 
WS-CAF have come at similar problems and produces similar results: when 
you're talking about companies that drive the field of transactions on 
the scale of IBM, Oracle etc. then it makes complete sense that there 
would be similar experiences. As a result, the fact that both groups see 
directed protocols for specific problem domains as the way forward is 
good. We should in no way say "because our solution is similar to IBSoft 
we shouldn't go there" and "we need something entirely different to 
justify existence" as that simply compounds the problem with competing 
specifications and encourages companies to act outside of the open 
standards approach.

>  
>
> I have seen no confidence from anyone (end user, ISV) that CAF 
> transactions can possibly win against AT/BA. I endorse that view -- 
> the only way in which WS-CAF transactions are useful or potentially 
> viable is if they are *different*, usefully different.
>
I completely disagree. If that were the case the BTP would have been 
successful. If I understand your flawed argument, it seems to go 
something like: if WS-CAF (and presumably any TC) wants to do work that 
may overlap with proprietary work/specifications that IBM and Microsoft 
are working on, or have already produced, then they should make sure 
that any solutions are substantially different from the IBSoft results, 
otherwise they might as well shut up shop and go home? I don't believe 
that is the right approach and I'm disappointed that anyone in this TC 
should consider it: it's defeatist.

>  
>
> The fate of WS-Reliability awaits WS-CAF transactions, in other words. 
> That's what happens to technically near-identical specs that have less 
> powerful backers: they fuse or lose.
>
We have always encouraged interaction with IBM & MSFT. When those 
specifications eventually come to a standards body, it will be good to 
"fuse" as you put it. I'm fairly confident that if we changed our 
transaction model to a BTP-like approach, that "fusing" would be more 
complicated and may not happen.

>
> What seems to be completely unattractive to everyone in the world is 
> the proliferation of virtually identical protocols. This is the single 
> largest impediment to the adoption of the kind of technology we are 
> both producing and selling. The analysts, as you know, have been known 
> to say to end-user customers who enquire: don't touch this area -- 
> it's too unstable -- look at the standards mess.
>
You should be directing this at those companies that don't do the work 
in a standards body.

>  
>
> At least there is a technical difference of approach behind BTP.
>
But that hasn't got it anywhere. Maybe this is a discussion for the BTP 
group, but I honestly don't think that there's much point in pushing 
this argument: all of those doors are closed.

> There is no known technical distinction of any consequence between 
> LRA/Acid and BA/AT. Heuristics could be added to WS-AT within one day 
> (and I bet you implement them as an extension in your implementation 
> already).
>
>  
>
> The difference between WS-Acid and WS-AT is about as interesting to 
> customers as the difference between Newcastle and Gateshead -- a 
> passionate matter from a mile away, and a matter of total indifference 
> from anything other than a parochial perspective.
>
>  
>
> Producing a me-too spec seems like the least useful way that anyone 
> could use their time. The input specs are a bad answer to the right 
> questions, which are posed in the charter.
>
I disagree and if you look back through the history of these efforts, it 
can be argued that it's not us doing the "me to".

>  
>
> Alastair
>
>  
>
> P.S. I would still like to know what happened to Greg's motion -- I 
> may have missed the answer in the large quantity of text swirling here.
>
>  
>
> What exactly did happen at the F2F, and why are these decisions not 
> recorded in the minutes accepted by the TC? These are not minor 
> issues, as we all know. Why were these decisions taken without any 
> prior notification or written discussion?
>
>  
>
>  
>
>  
>

"[snip] at New Orleans it was agreed by the TC (by vote) that we would 
separate out the 3 models (WS-ACID, WS-LRA and WS-BP) into their own 
specifications; furthermore, that we would start work on WS-ACID first, 
though issues against the other models could still be raised in 
preparation for future discussions. 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. We mentioned BTP as a possible 
additional protocol which WS-CAF might provide a binding for that would 
address the latter style, if users really saw a need. The TC saw no 
point in reinventing BTP within WS-CAF [snip]"

The important thing is that the meeting was quorate. Votes were taken. 
If they're not recorded in the minutes then I suggest we update the 
minutes - but as I've said several times today, only if other people who 
attended the meeting agree with my recollection.


The agenda distributed by Martin (and on the TC page) for the New 
Orleans f2f said

"Thursday April 28 2005

9:00 - 10:30 Resume WS-CF Issues

10:30 - 11:00 Break

11:00 - 12:30 Resume WS-CF Issues

12:30 - 13:30 Lunch

13:30 - 15:00 Transaction models    <---------Here be Dragons!!

- start talking about post CF

15:00 - 15:30 Break

15:30 - 17:30 Logistics and future plans


- Plan for next F2F
- Discuss plans for public demo
- Review document schedules for WS-Context, WS-CF, and WS-TXM
- Review meeting schedules "

This was also distributed in advance when Eric & Martin asked for any 
further agenda items.

On the Wednesday we made such good progress on WS-Context and WS-CF that 
we agreed to make the follow day about WS-TXM. I believe Tony as present 
on the Wednesday. Neither yourself nor Peter were present at either day.

There was plenty of prior notice that we were going to start talking 
about WS-TXM and all that that entailed. Given that the meeting was 
quorate, I think we followed due process.

Mark.

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