Standards dissent is overblown

It really irks me to see CNET wheeling out another of their snide articles about standards rivalry. This is kneejerk journalism of the worst kind. The headline declares, Rivalry bogs down Web services. Let's examine the evidence for this sweeping claim:

• There are two separate standards efforts in progress on web services messaging. Big deal.


• Sun is annoyed with Microsoft. This is supposed to be NEWS?


• A user is critical. Just one? Hardly a groundswell.


• The same happened with BPEL/WSCI and WS-Federation/Liberty. Yeah, CNET was stirring back then, too.


• An analyst predicts a lot more conflict. Why am I not surprised?


• Another user says he can live with it. His exact words: "I'm not losing any sleep over it"

This is not even a storm in a teacup. Standards rivalry is to be expected — even welcomed. It's a good thing that people are passionate about these technologies. They believe in what they're doing and they want to make a difference. What worthwhile advances were ever achieved without a fight?

This week's mild row was over higher-level messaging standards that don't actually affect the vast majority of web services projects being put in place currently. Most applications can cope very well sending web services messages over HTTP using SOAP (you don't even need SOAP in some cases). If you don't want to build reliability functions into the application itself, you can use an ESB infrastructure based on the JMS standard, or you can use ebMS if you're working within an ebXML infrastructure.

Companies like ABNA have already seen a tenfold reduction in their integration costs by using JMS-based infrastructure in place of proprietary EAI messaging. So lack of ROI isn't the issue here. The only people who are going to get bogged down because of the current debate are people who are looking for an excuse not to do anything.

In any case, it's really vital to have these debates. Nobody knows all the answers right now, and sometimes the only way is by trial and error — which means some people are going to have to live with making mistakes, so that the rest of us can learn from them. We may well end up finding we actually need several different messaging standards, so that users can strike the right balance between performance and cost for each of their applications.

Look at how modern desktop computer design was achieved. Back in the 1980s, there was dissent between the two leading vendors, IBM and Compaq, about how to evolve the expansion bus. Users complained bitterly about all the uncertainty, and many analysts advised their enterprise clients to adopt IBM's technology, called microchannel. But it was Compaq's EISA that won that battle, and later Intel combined the best of both architectures to create PCI. We wouldn't have got where we are today without going through that debate, messy though it was at the time.

The only architectural standards that fall ready-formed out of the sky are ones that have been designed to protect vested interests. Good, durable, independent standards take blood, sweat and tears. The progress made to date on web services has been exceptional in its harmony and our luck has held out longer than we could have wished for. Messaging is becoming a battleground because it touches more vested interests than any other aspect of web services (think about it: if you get document-centric messaging right, then why do you need a web services interoperability initiative?). If they stop arguing about it soon, then that's when you should start worrying.
posted by Phil Wainewright 11:52 AM (GMT) | comments | link

All about ESB

Here's a compendium of links to recent articles about ESB, the new buzzword that's becoming even hotter than SOA:

• ESB adopters look beyond integration describes how users deploying ESBs have simplified integration to the extent that their biggest problem now is getting to grips wth business processes. Sure, there are some drawbacks, and it's not for everyone, but this new Loosely Coupled article appears to show that the ESB phenomenon is more than just vendor and analyst hype.


• Best of Breed ESBs (PDF, 578k) is a new white paper by middleware guru Steve Craggs, vice-chairman of the EAI Industry Consortium, outlining what to look for in an ESB. Incidentally, he also succinctly sums up why ESB is all set to overtake SOA as the buzzword du jour: "ESB is a pre-packaged SOA implementation, already consisting of the necessary functional components to achieve the SOA aims."


• Enterprise Service Bus (ESB): Lasting concept or latest buzzword? is a very well-written overview of ESB by Nicolas Farges of TechMetrix Research, published on searchWebServices. It explains exactly where ESB fits in, what its role is, and where it still needs to mature. The conclusions don't bode well for EAI vendors, but also stress the importance of complementing ESB implementation with proper business process analysis.


• Driving the Enterprise Service Bus is another good overview piece, this time by InfoWorld's Paul Krill. A quote from Cape Clear's David Clarke reinforces the overlap with SOA, but this time from a web services vendor perspective: "ESB is an attempt by the industry and the analysts to try to tie down the key things you need in a web-services platform." I met with Annrai O'Toole, Cape Clear CEO, a few weeks back, and he welcomes ESB a handy term that everyone can latch onto: "We think this ESB category is a bit of a godsend. What Gartner and IDC are vocalizing is this need in the business world for integration to be made radically simpler ... We'd say that's what we've been doing all the time. It gives us a shared vocabulary — the concept is out there."


• Programmable Integration, also on InfoWorld, is a review by former Utah State CIO Phil Windley of Sonic Software's ESB platform. Phil concludes that the product falls short in its ease-of-use for policy configuration: "Some tools aim for ease of use and even boast that business people can use them to manage business processes. But none of them offers the flexibility necessary for complete system integration. Sonic ESB offers that flexibility, but only if you have developers and integration architects to take advantage of it."


• Managing the Reach and Range of Your Business Processes (printable version) is an interesting overview of the interaction of ESBs with business process management, by Harvey Reed, a technical product manager with Sonic Software and formerly product manager of eXcelon BPM (which Sonic acquired): "Using an ESB, the implementation of the business process is minimal, saving on development and QA costs. This is true whether the business process is basic, as with messaging, or sophisticated, as with a BPM tool," says Harvey, which is a different message from Phil's I think the fact is, there's a lot of work still to be done at the interface between a properly architected services infrastructure and the business process layer that sits on top of it.


• The Enterprise Service Bus: Making Web Services Safe for Application Integration is by Ronan Bradley of ESB vendor PolarLake, published at WebServices.Org. It's a useful overview of why the ESB concept is important for web services, and a refreshing change from white papers by Sonic Software, who seem to have cornered the early market in publishing white papers and articles about ESB.


• ESB architecture eases app integration is by Gordon van Huizen, VP of product management for (talk of the devil) Sonic Software. It includes a useful diagram showing how everything fits together, and a concise, clear definition: "An ESB is a standards-based, service-oriented backbone capable of connecting hundreds of application endpoints. ESBs combine messaging, Web services, XML, data transformation and management to reliably connect and coordinate application interaction. The ESB deployment model is an integrated network of collaborating service nodes, deployed in service containers."


• Define meaning of ESB is Loosely Coupled's own glossary definition. We always like to start off with an ultra-short definition, which in this case is: "Universal integration backbone".


• Predicts 2003: Enterprise Service Buses Emerge is the original December 2002 Gartner document that first defined ESB (the link is a sponsored online reprint courtesy of — you guessed it — Sonic Software).


• The Enterprise Service Bus: Disruptive Technology for Software Infrastructure Solutions is IDC's gung-ho take on ESB: "The ESB is an open standards-based technology concept that will revolutionize IT and enable flexible and scalable distributed computing for generations to come." Unfortunately you still have to pay IDC to view this report (now there's an opportunity for one of Sonic's rivals to seize a corner of the white paper battleground).

UPDATE [added July 21]: Sonic's Dave Chappel has helpfully contributed links to three more resources in a comment today. Thanks Dave!
EXTRA UPDATE [added July 26th, 2004]: We just named today's top seven ESB vendors along with detailed profiles of each in the July 2004 issue of Loosely Coupled monthly digest.
posted by Phil Wainewright 7:47 AM (GMT) | comments | link

Service economics

On-demand computing doesn't make sense economically, according to a paper just published by database guru Jim Gray. But web services do. In Distributed Computing Economics, the Microsoft Distinguised Engineer underpins his arguments with some compelling calculations:

"Computing economics are changing. Today there is rough price parity between (1) one database access, (2) ten bytes of network traffic, (3) 100,000 instructions, (4) 10 bytes of disk storage, and (5) a megabyte of disk bandwidth. This has implications for how one structures Internet-scale distributed computing: one puts computing as close to the data as possible in order to avoid expensive network traffic."

As long as falling telecoms costs continue to lag Moore's law, then there are virtually no applications where it makes sense to send large chunks of data across a wire to be processed somewhere else, he finds. Raw computing power doesn't outsource economically.

On the other hand, shared services that collect, store and process data in a single location benefit from the self-same economics, which makes Jim a fan of web services: "Put the computation near the data," he concludes. "... one should push as much of the processing to the data sources as possible in order to filter the data early ... There are many techniques for doing this, but fundamentally it dovetails with the notion that each data source is a web service with a high-level object-oriented interface."

One element that doesn't feature very much in Jim's calculations, though, is the cost of people. There may be applications where it makes sense to move the data nearer the people even when that wouldn't be economic in strict computing terms. But don't imagine for a moment that this creates an argument in favor of on-demand computing so that we can save on the costs of database administrators. Processing and disk costs are so low now that we might as well just store the data more redundantly, Jim argues in a recent interview in ACM Queue.

That interview also contains a story about exchanging large databases that's a perfect illustration of the comparative cost of telecoms. Instead of incurring a $2000 phone bill to transfer a terabyte of data over the Internet, he writes the data on a PC and sends it via UPS. "I tend to write a terabyte in about 8 to 10 hours locally. I can send it via UPS anywhere in the U.S. That turns out to be about seven megabytes per second ... UPS takes 24 hours, and 9 hours at each end to do the copy."

One more notable comment, based on observing the development of relational databases, highlights the importance of usability over performance in getting new technologies established:

"At a certain point, most people who bought the relational stuff bought it for the usability, not the price performance. They were getting new applications, and they wanted to get their applications up quickly.

"You see this today. Two groups start; one group uses an easy-to-use system, and another uses a not-so-easy-to-use system. The first group gets done first, and the competition is over. The winners move forward and the other guys go home. That situation is now happening in the web services space. People who have better tools win."

Better in the sense of easy-to-use, that is, not better in terms of sheer performance. It's the human element again, the one factor that no computer scientist should ever discount. However good the technology, if it doesn't somehow benefit a human being, it has no value. Terminator 3 notwithstanding, this isn't a matter of sentimentality, it's simple, dispassionate economics.
posted by Phil Wainewright 8:10 AM (GMT) | comments | link