ebXML battles Web services over which will become the e-business platform of choice.
Companies looking to conduct complex business transactions might expect Web services to enable those efforts. But along the way, they might find some business partners adamant about using another technology for the same purpose, electronic business with XML.
Under development since the late 1990s, ebXML is a multifunction e-business framework that includes a secure document-messaging component and a methodology for constructing those documents. Web services, of course, fits a similar description, although the degree to which they help businesses conduct more than the simplest of online transactions is one subject of the Web services vs. ebXML debate. Another topic is whether a debate is needed at all. A number of experts say the two technologies are complementary, because ebXML can, and does, employ Web services underpinnings such as Simple Object Access Protocol (SOAP).
"People are seeing they can use these things in combination," says David Webber, an independent consultant who chairs the Organization for the Advancement of Structured Information Standards' (OASIS) Content Assembly for ebXML technical committee and co-authored the book, ebXML: The New Global Standard for Doing Business. He argues that Web services are king for informational sorts of transactions, such as checking stock with a business partner. But the purchasing act requires systems that can communicate on a more meaningful level, with proper security. All of which ebXML provides, he says.
"People think of ebXML as a holistic framework rather than having multiple aspects that can be adopted independently," says Joseph Chiusano, senior consultant with Booz Allen Hamilton in McLean, Va., and a member of the OASIS ebXML technical committee. While Web services didn't really exist when ebXML was conceived, OASIS and UN/CEFACT, an international standards body that also plays a role in ebXML development, have since made multiple efforts to incorporate Web services components in ebXML. Those include an interface that enables ebXML messages to be carried via SOAP, and the ability to register and discover Web Services Description Language (WSDL) documents.
But John Radko, chief architect of global technology operations at e-business service provider Global eXchange Services, sees the power struggle as quite real. "The conflict is simply this: If you use one, you're not using the other." While it's true that the same company might employ ebXML and Web services for different applications, the two don't interoperate. If you want to send a trading partner a message using ebXML, the partner has to support ebXML, he says. The same is true for Web services.
Radko says he sits in on numerous meetings in which the ebXML vs. Web services debate rages on. Members of the auto industry, for example, are debating whether to use ebXML document formats or those that are more closely aligned with Web services, such as WS-Attachments. This Microsoft-developed specification is at least the third attempt at defining how to send files back and forth in a Web services environment.
He says such a specification must have four basic attributes: to, from, message type and a message ID, for tracking. "EbXML does all that great; it was designed from the ground up to do that," Radko says. Work is underway in standards bodies including the Internet Engineering Task Force and World Wide Web Consortium to define the same attributes for Web services.
So why not simply use ebXML document formats and send them over a Web services-based transport? For one, ebXML uses a component-based approach toward building documents that Radko says is technically sophisticated but difficult to work with. "If you're going to write a letter, you don't think, 'I need two address components, a salutation component, a body component and so on,' " he says. "People want to be able to find a purchase order and fill that out."
Large vendors, too, are picking sides in the debate. "Sun is a big backer of ebXML, so that tells you who is not," Chiusano says.
Radko also notes that Web services suite vendors, including IBM, Microsoft and Oracle, don't have strong ebXML offerings. This causes independent software vendors concern over dedicating resources to ebXML.
But the ebXML camp can cite at least a couple of reasons why it is the better choice, such as interoperability tests, spearheaded by Drummond Group, a consulting and testing firm. As of early November, more than a dozen products from 10 vendors were certified as interoperable, suitable for use in applications such as one defined by the Centers for Disease Control and Prevention for exchanging documents relating to public health. And ebXML enjoys widespread international adoption, notably in Asia.
Chiusano expects OASIS to promote the notion that companies don't have to choose between ebXML and Web services, and it may add more Web services components to ebXML, such as a binding to WSDL.
Still, Radko cautions companies to remain forward-thinking. "If you want to go with ebXML, make sure your vendor can support Web services, and vice versa. Something new is going to come along eventually and you'll have to upgrade."
Desmond is president of PDEdit, an IT publishing firm in Framingham, Mass. He can be reached at firstname.lastname@example.org .
Learn more about this topicOASIS expands scope of Web services management work
A standards body working on management specifications for Web services admitted on Monday that its original work did not go far enough, so it is regrouping and redefining its goals. Network World Fusion, 03/10/03.