Key Team Member Sees Unfortunate Future for ebXML

A new report by Michael C. Rawlins, a former team leader on the ebXML development project, predicts none of the ebXML infrastructure specifications for Web services will be successful in terms of adoption.

“The ultimate measure of any standard, and for that matter any product, is market acceptance,” says Rawlins in his report titled Market Impact of the ebXML Infrastructure Specifications. “Regardless of quality, features, or technical deficiencies, the final judgment of any standard is whether or not its implementation achieves that certain ‘critical mass’.”

ebXML is a series of XML architectures developed as part of a joint effort by the United Nations Center for Trade Facilitation and Electronic Business, and XML-centric consortium OASIS. The architectures cover messaging, registry, electronic configuration of trading partner information, and the electronic exchange of business documents. And while the initiative was completed in May of this year, it has struggled so far to gain acceptance.

Rawlins believes ebXML has the best chance to succeed in the messaging space, describing the bundling, routing and security features of the messaging implementation of ebXML as superior to those offered by the more popular Simple Mail Transfer Protocol. But even for messaging, Rawlins is skeptical about a long-term future for ebXML.

“Perhaps the biggest problem with the messaging service specification is that it was produced by ebXML and lacks the cachet of having come from W3C,” says Rawlins. “There’s a very good chance that SOAP by itself may become the de facto standard.”

Rawlins feels if the Simple Object Access Protocol were, ultimately, to obviate ebXML from gaining share in the messaging space, it would be rather ironic because the ebXML development team incorporated SOAP into its messaging service specification in order to get Microsoft Corp. involved in the project. Microsoft has yet to support ebXML though, and now Rawlins says ebXML may end up being rendered obsolete by SOAP, a brainchild of the Redmond-based computing giant.

Meanwhile, the registry services specification of ebXML, Rawlins says, is not equipped to support distributed, networked registry systems, which he feels will ultimately hinder its ability to gain acceptance. For electronic configuration of trading partners, Rawlins says ebXML is only valuable in limited circumstances with organizations that have a large number of trading partners. And he gives ebXML almost no chance at all to succeed as a specification for exchanging business documents, saying “there are less elegant but much easier ways to implement some of the most significant functionality that business applications might support.”

Ultimately, the main reason Rawlins expects a fate of failure for ebXML is because the specifications don’t cater to the small-to-medium sized business, which was the development team’s original intention. And furthermore, says Rawlins, the ebXML architectures lack the level of interoperability to provide long-term value.

About the Author

Matt Migliore is regular contributor to He focuses particularly on Microsoft .NET and other Web services technologies. Matt was the editor of several technology-related Web publications and electronic newsletters, including Web Services Report, ASP insights and MIDRANGE Systems.