Why I Like ebXML

What’s the best way to create new standards for web services? There are effectively two approaches happening simultaneously today. One of them started simply, with small ambitions, while the other had much larger goals right from the start. More important, one of them is clearly succeeding, and the other, just as clearly, is not.

The one that’s succeeding is the simpler process that produced SOAP, WSDL, and other core web services standards. Here’s how it works: Microsoft and IBM somehow get together to create and agree on a new piece of web services technology. Once they’re happy, the result is made public and implementations appear. Not too surprisingly, the first implementations tend to come from Microsoft and IBM, but the technologies are usually relatively simple, and so other implementations follow quickly. Once the technology has been shown to be viable, it’s handed over to an official standards body such as the W3C.

Open systems purists aren’t especially happy with this process. There’s nothing open about it, in fact, since two dominant vendors make the key decisions behind closed doors. Yet this approach has one enormous thing in its favor: it works. A common set of web services technologies is being embraced by every vendor today, even though some of those vendors may dislike the way they were created.

The other process for creating web services standards began around the same time that the Microsoft/IBM axis was formed. Rather than revolving around two vendors, this one revolves around two standards organizations—OASIS and UN/CEFACT—and its most visible vendor support has come from Sun. The standards it creates are published under the umbrella name of ebXML.

The ebXML technologies are created using a much more traditional process, one based on multi-vendor committees, detailed specs, and a plethora of meetings. The goals of the people behind it are laudable—standards for business-to-business interaction and an updating of traditional approaches to electronic data interchange—but the practical results have not been impressive. No ebXML technology comes close to a SOAP-based technology in popularity, and to the best of my knowledge, no complete ebXML implementations are available. In fact, since there’s no reference implementation—this is a spec-based technology—it’s conceivable that a complete implementation of the ebXML standards isn’t even possible. Until someone actually tries to use them all together, it’s difficult to guarantee that they actually fit.

And yet, I really like ebXML.

My fondness isn’t because ebXML has a bright future as a widely used set of standards—it doesn’t. And it’s not because it has produced any technology breakthroughs—standards bodies just can’t do this. I like ebXML because I believe it will deliver the final deathblow to the pernicious idea that a bureaucratic, spec-oriented, committee-based process can successfully produce ambitious, broad-based standards for new technologies.

There are plenty of examples of previous failures that I might cite here, but none was more egregious or more expensive than the Open Systems Interconnection effort. The work on OSI spanned more than a dozen years and consumed many millions of dollars, yet almost nothing of value was produced. The problem was the process: committees of self-selected volunteers writing complex documents in hotel meeting rooms just can’t create good technology. Instead, effective technology standards require real experts working on them, along with a devotion to implementation rather than just specification. Those experts also need to be driven primarily by technical considerations, not by vendor or standards body politics, and they must also be willing to move ahead without perfect consensus.

We should have learned all of this from the debacle of OSI. I certainly did, as I spent the early years of my career mired in this technology tar pit. Yet the industry as a whole didn’t internalize the lesson. The truth is that successful standards for complex new technologies cannot be produced by over-ambitious committees—the process just doesn’t work. The failure of OSI wasn’t enough for everyone to learn this, but the failure of ebXML could well be. If it stops us from ever again mounting this kind of wasteful, doomed effort, ebXML will have been a very good thing.

Now Available: Eric Newcomer’s Understanding Web Services

Web services are the biggest thing happening in distributed computing today. Understanding Web Services provides a coherent and complete introduction to this important new area. Along with examinations of the key technologies— SOAP, WSDL, and others—the book also looks at ebXML and the strategies of leading web services vendors. Its author, Eric Newcomer, is deeply involved in web services as the CTO of Iona, and was also co-author of Principles of Transaction Processing, widely viewed as the best general book on this topic. To see reader reviews for Understanding Web Services or to order a copy, visit Amazon.

Understanding Web Services is the second book in Addison-Wesley’s Independent Technology Guides series, for which I am the series editor. Every book in this series gives a complete introduction to an important technology, and books on web services security, LDAP directories, and other topics are on the way. Each book has an easy-to-read layout with margin notes emphasizing the main point of most paragraphs, plenty of diagrams, and distinct analysis sections, allowing the writer to clearly mark opinions, discussions of controversial issues, and other topics that are especially interesting. Just as important, each book provides an independent perspective on the subject rather than reflecting the position of any particular vendor. The goal of the series is to provide effective, readable paths to understanding today’s most important technologies.

• Why I Like ebXML
   
• Now Available: Eric Newcomer’s Understanding Web Services

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his keynotes, seminars, writing, and consulting, David helps IT professionals around the world understand, use, market, and make better decisions about enterprise software technologies. David has been the keynote speaker for conferences in the U.S., Europe, Latin America, and the Middle East, and at many in-house events. His popular seminars have been attended by tens of thousands of developers and decision makers in more than two dozen countries, and his books have been translated into ten languages. David’s consulting clients have included Compaq, Microsoft, Stanford University and others. Contact him at david@davidchappell.com.

©Copyright2007 David Chappell and Associates
All rights Reserved.