Understanding ebXML, UDDI, XML/EDI
By David Webber and Anthony Dutton

Introduction

The past six months have seen an extensive and accelerating amount of work on providing practical implementations and technical specifications to enable the development of open interoperable eBusiness interactions. This work is focused around utilizing the W3C XML syntax and the Internet as the underpinning technologies.

In this context, the focus of the ebXML initiative is to develop a single global electronic market based on an open public XML-based infrastructure enabling the global use of electronic business information in an interoperable, secure and consistent manner by all parties. A primary objective of ebXML is to lower the barrier of entry to electronic business in order to facilitate trade, particularly with respect to small- and medium-sized enterprises (SME's) and developing nations. The ebXML initiative is sponsored by UN/CEFACT and OASIS and is an open public initiative with now over one thousand participants.

The Universal Description, Discovery and Integration (UDDI) initiative by contrast was started by IBM, Ariba and Microsoft about five months ago as a means to create an implementation of their technologies that deliver the underpinning for the interoperation of netmarket places and integrating business services using the Internet. (http://www.uddi.org/) is based around the concept of standard registry services that provide Yellow, White and Green Page business functionality. The UDDI focus is on providing large organizations the means to reach out to and manage their network of smaller business customers. The biggest issues facing UDDI are ones of acceptance and buy-in from businesses themselves, and implementation issues of scalability and physical implementation.

By contrast the XML/edi Initiative was start three years ago as a grass-roots initiative to promote the use of XML for eBusiness. The XML/edi Vision includes the concept of the Fusion-of-Five: XML, EDI, Repositories, Templates and Agents to create next generation eBusiness. The ebXML and UDDI work represent embodiments of the XML/edi vision and as such we need to understand how far this work has come, and how much further is needed to fully deliver on the promise of XML and eBusiness.

ebXML

In order to make sense of the technical architecture for ebXML is it important to first understand the conceptual thinking behind the initiative. From the outset the technical architecture team approached the project from the standpoint of business workflow, selecting the objects common to many business processes, such as address, party and location. With the advent of XML it was now easier to identify and define these objects with attributes (data) along with the functions that could be performed on those attributes. A cornerstone of the project was allowing these objects to be reused so that ebXML could provide for the means to unify cross-industry exchanges with a single consistent lexicon.

It is important to realize, however, that the role of ebXML is not to replicate the reliance on electronic versions of common paper documents such as purchase orders, invoices, tender requests and to offer up and develop such implementation examples. Instead the ebXML specifications provide a framework where SME's, software engineers, and other organizations can create consistent, robust and interoperable eBusiness services and components seamlessly within an integrated global eBusiness market.

Fig 1: ebXML approach

Figure 1: the ebXML approach; automating business-to-business interactions.

The actual architectural model of ebXML uses two views to describe the relevant aspects of all business interactions. These two views stem from early work on OpenEDI by UN/CEFACT. First is the Business Operational View (BOV), which addresses the semantics of business data transactions, and associated data interchanges. The architecture for business transactions includes operational conventions, agreements and mutual obligations and requirements. These specifically apply to the business needs of ebXML trading partners.

 

Fig 2: Business Operational View

 

Figure 2: the Business Operational View

Second is the Functional Service View (FSV), which addresses the supporting services and meeting the deployment needs of ebXML. The implementation of the FSV of ebXML has three major phases; implementation, discovery and deployment and then the runtime phase. The implementation phase deals specifically with procedures for creating an application of the ebXML infrastructure. Then the discovery and deployment phase that covers all aspects of the actual discovery of ebXML related resources and self-enabled into the ebXML infrastructure. And after that, the run time phase that addresses the execution of an ebXML scenario with the actual associated ebXML transactions.

FSV focuses on the information technology aspects of functional capabilities, service interfaces and protocols including the following:

  • Capabilities for implementation, discovery, deployment and run time scenarios;
  • User application interfaces;
  • Data transfer infrastructure interfaces;
  • Protocols for interoperation of XML vocabulary deployments from different organizations.

In order to deliver on the BOV and FSV, integral to the ebXML architecture is the Registry System. An ebXML Registry provides a set of distributed services that enable the sharing of information between interested parties for the purpose of enabling business process integration between such parties by utilizing the ebXML specifications.

Fig 3: Functional Service View

 

Figure 3: Functional Service View

The shared information is maintained as objects in an ebXML Repository that is managed by ebXML Registry Services. Access to an ebXML Repository is provided by the interfaces (APIs) exposed by Registry Services.

Therefore, architecturally the Registry and Repository are tightly coupled components. The Registry provides the access services interfacing, the information model and reference system implementation, while a Repository provides the physical backend information store. For example, an ebXML Registry may provide a Trading Partner Profile from the Repository in response to a query; or an ebXML Repository may contain reference DTD's or Schemas that are retrieved by the Registry as a result of searching a metadata classification of the DTD's or Schemas. Figure 4 provides an overview of this configuration.

Fig 4: Registry/Repository Interaction Overview

Figure 4: Registry / Repository interaction overview

UDDI

Hot on the heals of the OASIS sponsored ebXML initiative comes the Universal Description, Discovery and Integration Project co-sponsored by IBM, Microsoft and Ariba and announced only in September, 2000. In addition to the sponsors, a selection of other companies has signed on since September including particularly those focused on directory services and enterprise system integration. Interestingly, IBM, Sun and several others involved with the UDDI project are also already committed to delivering ebXML solutions, and to working with the associated groups, most notably OASIS, CEFACT and the W3C.

The fundamental difference between UDDI and ebXML is that UDDI is aiming to create a standard registry for companies that will accelerate the integration of systems around Net Marketplaces, while ebXML is working to standardize how XML is used in general business-to-business (B2B) integration. The core of the UDDI model is therefore focused particularly on middleware connectivity, and using XML itself to describe the systems that companies use to interface with one another. UDDI plans to do this by storing information about companies' integration profiles and capabilities in a shared directory that other companies can access via a set of XML standards currently being worked on.

The initial UDDI registry system contains three types of information that are being referred to as the white, yellow, and green pages. The white pages directory will allow companies to register their names and the key services they provide, and will allow other companies to search the directory by company name. The yellow pages component of the directory will categorize companies in three ways: by NAICS industry standards codes set by the U.S. government, by United Nations/SPSC codes and finally by geographical location. The final element of UDDI is the green pages, which is where companies will be able to interface with other companies in the registry using XML. Because it will be clear from their search which formats are being supported, the companies can then communicate and send documents based on a specific XML format.

Therefore it is also apparent that ebXML systems will be able to also integrate to UDDI systems at this level, since ebXML also provides all these same capabilities. So why was the UDDI initiative work launched at all? Mostly internal time-to-market pressures on the three principals, who simply decided they could not wait for ebXML to complete its work, but instead choose to rush to market with a proprietary solution, and then use this work to drive the direction of the ebXML and W3C standards work at a later point.

Over the next 18 months the UDDI project aims to expand the number of categories and add more complete features to help smooth the searching capabilities of the B2B effort. Suggestions include customizing the categorization features and accommodating the needs of large corporations with a variety of business units focused on different goals. In addition, a number of vendors expressed interest in building upon the standard as it progresses and developing registries with customized features that lie on top of UDDI. All this work will surely cause potential confusion with major work by organizations such as GCI, AIAG and RosettaNet that are already committed to work with the ebXML initiative in these areas.

XML/edi

While traditional EDI had proved the feasibility and efficiencies possible when using electronic business transactions the limitations were found to be the cost of integration and deployment to the smaller business partners. The vision for XML/edi, therefore, was to build a system that would allow organizations to deploy smarter, cheaper and more maintainable systems to a global audience. XML/edi approached the problem by developing a system that allowed each trading partner to quickly synchronize their systems by exchanging not just the old structures of EDI data, but also process control templates and business rules as well.

The central idea to XML/edi is to add enough intelligence to the electronic documents so that they (and the document-centric tools that handle them) become the framework for electronic business commerce. By combining the five components together, XML/edi provides a system that delivers not just data, but more importantly, information accompanied by the necessary processing logic. Thus not only is data exchanged but also the enabling underlying processing information.

Examining the critical business parameters, as opposed to the technology, history has shown that traditional EDI failed to create a broad based acceptance for a number of reasons. To deliver a next generation global EDI solution, the following capabilities must be addressed as the "Business Top Ten" requirements list:

  1. Reduce the cost of doing business.
  2. Reduce cost of entry into eB usiness.
  3. Provide an easy to use tool-set.
  4. Improve data integrity and accessibility.
  5. Provide appropriate security and control.
  6. Provide extendable and controllable technology.
  7. Integrate with today's systems.
  8. Utilizes open standards.
  9. Provide a successor to X12/EDIFACT and interoperability for XML syntaxes.
  10. Globally deployable and maintainable.

So far ebXML is proving that it has the components to come closest to these goals. However simply redefining the old EDI message formats in XML, to make them Web deployable is not enough. The ebXML initiative has concentrated on modelling tools to capture the business processes, not just the transactions, and storing standard definitions in globally accessible registries (repositories). Done correctly the small businesses can avoid the need to do costly and complex modelling, while still able to quickly and easily tap into existing process models and off-the-shelf application solutions. Whereas the XML/edi guidelines have added two additional key components: Process Templates and Software Agents to assist in this. The idea is to provide truly dynamic software processes based off XML representations by using the ability of XML to define not just the data but also processing scripting systems. The ebXML work sees this as a second phase need; with the first phase being based on simpler rigid well understood more static interfaces.

Within the integrated XML/edi system (figure 5), XML itself provides the foundation, whereby XML tokens and frameworks are the syntax that transports the other components across the network. XML tokens replace or supplement existing eBusiness transactions, and thereby enrich the capabilities and transport layers of the Internet in general. Process Templates built using XML are the glue that holds the whole XML/edi system together. Without them you could not use the XML syntax exclusively to express all of the needed work requirements. The templates are globally referenced, or travel along inside the XML as a special section and set of tokens where they can be easily read and interpreted. They also control and define the business context and process definitions that allow users to locate the correct components that they need. The ebXML classification work and ebXML Business Process Metamodel are also now moving to implement these same capabilities within the Registry indexing system, but as yet without the Template and business token focus. This may change as the XML/edi GUIDE work (http://www.xmlguide.org/) matures and provides synergy with the ebXML metamodel.

 

Fig 5: Components of XML/edi

Figure 5: The Power of Five - The Components of XML/edi

XML/edi Internet Repositories (referred to as Registry/Repository systems in ebXML) allow users to manually look up the meaning and definition of eBusiness elements. Additionally the concept takes this to the next level and provides automatic lookup interfaces, much like an advanced Internet search engine (for example http://www.goxml.com/). This XML/edi repository component of the system provides the semantic foundation for global business transactions and at the same time the underpinnings needed by the software agents to correctly cross-reference entities.

Thus the Software agents serve several functions. First, they interpret the Process Templates for performing the work needed. Second, they interact with the eBusiness transaction data definitions and the user business applications to integrate each specific task. Third, they look up and attach the right template for existing jobs by accessing the Global Repository. An example would be an agent that can take an eBusiness transaction and examine the underlying global repository definitions and construct and determine display characteristics for forms to display the information to users.

Conclusion

We are facing a very interesting moment in the development of eBusiness and the Internet. The Internet itself has shaped our ability to develop open public standards across diverse groups of people who are geographically located on all the major continents. The emergence of pervasive networking and small personal computing devices are challenging previously understood limits of information delivery and utilization. While the United States continues, for now, to dominate the development of business standards, this is based mostly on the fact that the US economy constitutes over 30% of the world economy. Within the software industry itself countries such as India and the Eastern European countries are already making significant in-roads into this domination as the labour pool for cost-effective development resources are stretched to the limit worldwide. Consequently over the next five years we can foresee that the industry is moving to an open global economy where new and profoundly different metrics will emerge. The measure of ebXML, UDDI and XML/edi will be how well they are able to provide and satisfy these needs.

Copyright ©, XMLGlobal, October 2000.


Bottom Gear Image