OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Needless variation a waste of time


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.

 

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.

 

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.

 

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.


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.

 

At least there is a technical difference of approach behind BTP. 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.

 

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?

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]