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.
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.
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.
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.
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:
- Reduce the cost of doing business.
- Reduce cost of entry into eB usiness.
- Provide an easy to use tool-set.
- Improve data integrity and accessibility.
- Provide appropriate security and control.
- Provide extendable and controllable technology.
- Integrate with today's systems.
- Utilizes open standards.
- Provide a successor to X12/EDIFACT and interoperability
for XML syntaxes.
- 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.
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.
|
