Is anyone out there?

Our industry is always revisiting past debates. The only thing that changes is the periodicity. However, in the past when arguments raged around CORBA versus DCOM, or Mac versus PC (for example), you could be forgiven for not knowing what was said in the past, because online archiving facilities were ad hoc and references to debates within hardcopy literature required access to that literature. However, with the advent of Google there are fewer excuses for not doing your homework before re-launching those arguments. These days it's REST versus SOA, or OSGi versus Sun, but the background material exists in copious amounts if you want to search for it.

However, one debate I had hoped never to see again was: WS-AT Considered Harmful to SOA. No sh*t Sherlock! But then we've been telling people that for years. It's a bit like saying: jumping out of an airplane without a parachute will kill you. Or: playing with electrics in the bath is a bad idea. These are fairly obvious truths and I'd hoped that the same was the case with the use cases for WS-AT. But maybe not!

Many of us (the group of various WS transaction specification/standards authors) have been saying that "one size does not fit all" for years: it's why all of the specifications/standards supported multiple models. Don't get hung up on two phase commit. It's a consensus protocol. Using it does not mean you are using all ACID properties of a traditional transaction. Protcols like WS-AT and WS-ACID exist for one very important reason: interoperability. As I said on Arnon's blog:

"WS-AT, WS-ACID (from WS-CAF) and Atoms (from BTP) were never intended to be used for loosely coupled interactions. They are there for short duration interactions between heterogeneous transaction system implementations. If you've ever tried to get CICS to talk to Tux, or Tux to talk to JBossTS (as examples), then you'll know that it's not easy to do out-of-the-box! We tried to do transaction interoperability in the OMG through the OTS, but that took a long time and not everyone supports OTS/JTS (when was the last time you saw Microsoft with an OTS implementation?) Web Services offer interoperability as one of their main benefits. We now have demonstrated transactional interoperability between all of the major TP vendors (excluding BEA, who haven't got a WS-AT implementation). For customers who have heterpogeneous implementations, then this is a critical component.

As authors of the specifications, we have *never* said that WS-AT et al should be used for long duration interactions. Over the past 8 years the reasons for not doing so have been well documented. If people are still arguing this question then they're not reading the literature, which basically agrees with them anyway!"

Web Services != SOA. Just because you're writing applications with Web Services doesn't mean you are (or necessarily need to) developing with SOA principles in mind. That does not mean Web Services are less important a technology. But it seems to be something that people are still having trouble understanding.

Now we can't prevent people from using WS-AT in other situations. Just like we can't prevent people from using electrical devices in the bath. But in that case, you'd better watch out and know what you're doing and why you are doing it!