This month, an international consortium led by the united nations centre for trade facilitation and electronic Business (UN/CEFACT) and heavyweights like Hewlett-Packard, IBM and Sun Microsystems finished work on a new standard designed to give companies of all sizes, and from all industries and countries, a way to communicate and trade with one another over the Internet.
How successful the effort ultimately will be is anyone's guess. But if participation is any indication, the electronic business eXtensible Markup Language (ebXML) should begin appearing in the global marketplace soon.
In a guest essay for Interactive Week, two of the men who oversaw the unprecedented effort, Klaus-Dieter Naujok, chairman of the ebXML Initiative, and Ralph Berwanger, vice chairman at the American National Standards Institute's Accredited Standards Committee X12, discuss creation of the new infrastructure and its future.
It began in September 1999. the u.n. technology group and an international technology business consortium called Organization for the Advancement of Structured Information Standards (OASIS) announced they were joining forces to produce a global XML framework for electronic business. Immediately, more than 120 companies and standards bodies signed on to begin the "ebXML Initiative." Eighteen months later, in a May meeting in Vienna, more than 1,000 participants ratified the first generation of ebXML and began delivering the infrastructure.
With that ratification come several key questions: Can first-generation ebXML be implemented successfully? Is the infrastructure complete? And are there plans for follow-on support to ebXML? The short answers are: yes, yes, yes!
Implementing version 1 of anything can be risky. prudent consumers wait while the foolhardy dive in to find undocumented features. Why should either the vendor or user communities implement the first generation of the ebXML specifications?
The strongest argument for using the specifications is that they are built upon established technology. No new protocol was invented. The various project teams evaluated proven technology as the baseline for all specifications. Specification authors leveraged as much existing technology as possible, including the World Wide Web Consortium's XML Schema, XML Linking Language, and the XML Signature Syntax and Processing specification. Additionally, a broad series of references from the Internet Engineering Task Force's Request for Comments were considered. Even initiatives that started after the ebXML project was under way were carefully examined, including Security Services Markup Language, Simple Object Access Protocol and Universal Description, Discovery and Integration. SOAP was successfully incorporated into the Message Servicing Specification.
Another strength is that the user and vendor communities are being provided with a set of specifications that have been proven to work. The ebXML Proof of Concept Project team exercised the proposed architecture during multiple public demonstrations in which dozens of companies showed that the specifications could be implemented and interoperate. One vendor demonstrated the entire infrastructure, end-to-end; other vendors implemented components of the ebXML system and allowed the components to "talk" with other components in a network. Other demonstrations evidenced one user operating components from multiple vendors as a single, integrated solution. The presentations did not portray the intensity of a fully operational business-to-business system, but they established that small, midsize or large enterprises can quickly configure ebXML environments that support member registration, trading partner discovery and secure business data exchange.
Lastly, the ebXML infrastructure is the only open, out-of-the-box, standards-based solution available and ready for use. Several competing commercial solutions are available, most notably Microsoft's BizTalk Framework. Many of these solutions are very good. It should be no surprise that solutions qualified as "very good" provided significant contributions to the ebXML specifications. However, none support all the business verticals simultaneously. Enterprises electing to use one of these commercial solutions may not be able to participate in a truly global environment. The ebXML answer is XML-based and transport protocol-neutral. Its developers crafted a solution that allows traditional Electronic Data Interchange, XML-based or proprietary payloads to be communicated between businesses and partners using common or different vocabularies.
The ebXML initiative included five major work areas, three of which are clearly infrastructure components that facilitate registration of a business entity, discovery of business partners, configuration of business partners and exchange of business information.
The registry/repository component supports all of the above functions, making it a major piece of the infrastructure. The ebXML registry provides a set of distributed services that enable the sharing of information. This allows business process integration between business parties. The registry provides the access services interfacing, the information model and reference system implementation, while a repository provides the physical back-end information storage. For example, an ebXML registry may provide configuration information for a particular business entity from the repository in response to a query, or an ebXML repository may contain document type definitions or schemas that are retrieved by a registry query.
Collaborative Protocol Profiles are another key element of the infrastructure. The CPP specification is based on the Trading Partner Agreement Markup Language (tpaML) work begun by IBM. The IBM work was enhanced through efforts of the Trading Partner Agreement project team to produce a method for defining the transport, messaging and security environment of a specific business entity. Also, the team defined methods for dynamically exchanging the CPP data between business entities and negotiating message-exchange agreements between the parties. These profiles may be maintained by the individual business entities within the ebXML business domain or stored with an ebXML repository.
Information packaging and transport mechanisms, specified in the ebXML Message Serving Specification, are the final critical components of the ebXML infrastructure. A communications protocol-neutral method for exchanging the electronic business messages is defined in this specification. Enveloping constructs are specified that support reliable, secure delivery of business information. These flexible-enveloping techniques permit ebXML-compliant messages to contain payloads of any format type. This versatility ensures that legacy electronic business systems using traditional syntaxes (i.e., United Nations Electronic Data Interchange for Administration, Commerce and Transport; Accredited Standards Committee X12; or Health Level 7) can leverage the advantages of the ebXML infrastructure along with users of emerging technologies.
Maintenance and future development
The joint initiative is now complete. the participants have fulfilled their commitments, specifications have been published, demonstrations are going back into the box and press releases have been published. So, what happens next?
During the final plenary session on May 11, the U.N. group UN/CEFACT and OASIS signed a new memorandum of agreement for continuing the ebXML work. The agreement assigned the infrastructure component to OASIS transport, registry/repositor and collaborative profile protocol and placed the business components business process and core components within UN/CEFACT. The proposed technical committee for the transport group has scheduled its initial meeting for July; others, no doubt, also are being planned around the same time.
With the die now cast, companies can anticipate announcements from the two sponsoring organizations related to the continued improvement of this open, global, XML-based electronic business standard.