Less Is More In E-Business: The XML/edi Group
The XML/edi Group's XML for E-Business Initiative
Industries and individual companies need to establish
standard mechanisms for making XML work for business data
exchange. As we have seen with EDI, standards encourage businesses
to invest in data exchange technology and help draw in vendors to
develop packaged software that supports those standards. The
XML/edi Group, among others, have been focusing on key enabling
technologies for delivering on such functional XML/EDI
standards.
An overview of the
first draft of the XML for E-Business recommendations is presented
in Table 1, reflecting a series of functions based on
business needs. In the rest of this section,
we expand on certain key elements of
these recommendations: XML repositories and Bizcodes. We then
look at the importance of maintainability and
scalability in XML/EDI applications.
Table 1: XML/edi Group's XML for E-Business Recommendations
|
1) Functionality:
|
|
Enable XML repositories and XML glossaries
with Bizcodes to create a basis for
simple automated mapping between XML vocabularies, dialects
or schemas, and DTD and EDI (code and element) re-use. |
|
Syntax:
|
|
Utilization of the XLink and XPointer
specifications for implementing Bizcodes, which link
elements to their
definitions in repositories; see the XML/edi Group's
Repository White Paper.
|
|
2) Functionality:
|
|
Ability to validate application interchange elements via DTDs and ATTLISTs, without needing complex programming
constructs and or additional parser helper components. |
|
Syntax:
|
|
Basic datatyping with five primitive types as per the 24 September XML-Schema working draft (byte, date,
integer, sequence, SQL and Java), plus a Picture Mask definition based only on the following picture codes "#$XNULBPV.,/-"
as a direct means to express e-business field format rules within a DTD or attributes.
|
|
3) Functionality:
|
|
Open ability to exchange authenticated and
secure transactions across all XML transaction servers. |
|
Syntax:
|
|
Digital signature, and authentication
certificates as detailed in the Extensible Forms Description
Language, XML For All, and BizTalk methods; looking at these
methods, a single implementation may be derived for common
use.
|
|
4) Functionality:
|
|
Ability to exchange and route transactions
between XML transaction servers. This will allow Information
and Content Exchange, Biztalk, Java Message Service,
Interactive Financial Exchange, RosettaNet and EDI messaging
servers to talk to each other with one consistent envelope
based on XML. It will also ensure a firm minimum for the
legally required tracking information associated with messages
that vendor products should handle. |
|
Syntax:
|
|
Common XML syntax for interchange envelopes,
with common persistent tracking and registration authority
recommendations for open transaction interchanges. Use of
standard business methods, such as Dun and Bradstreet and
UNSPSC codes, for company identification plus a mechanism for
ISPs to set up their own business interchange registration
companies using a consistent format.
|
|
5) Functionality:
|
|
Open the syntax for creating SQL statements
that will work against a variety of back-end XML-based
database products. This step will greatly simplify
implementation, maintenance, and training. It will also ensure
broad and rapid adoption, and allow robot and/or 4GL
software to consistently generate valid access
statements. |
|
Syntax:
|
|
XML extensions to SQL via the CONTAINS verb
as implemented by Oracle. This feature provides a robust and
immediate means for SQL-based access querying to XML content
stored in a database column or object class.
|
XML Repositories Store the E-Business Valuables
Once XML vocabularies have been developed for the data elements
exchanged in business processes, there is a need to have them
available for use. This is the function performed by a
repository. Data definitions are stored in the repository for retrieval and
use by e-business applications. In particular, a network of
relationships between data definitions is built up, with the re-use
of element definitions from other industries, and the
establishment of data elements
between which there is an effective equivalence.
We
propose that to document these relationships, repositories
rely on semantically neutral references called
"Bizcodes". Just like the familiar UPC/EAN bar codes
for products and items that provide simple semantically neutral
numbers for manufacturers, distributors, and retailers to use
for inventory control, Bizcodes provide neutral identifiers for
relating data elements among electronic transactions and across
industries.
For example, a party that engages a company to acquire
goods or services could be called a customer, client, guest,
buyer, renter, visitor, or user depending on the industry. XML
vocabularies for these industries would identify these entities
using the terms most familiar to those industries:
<CustomerNr>, or <ClientNr> or <BuyerID>, and so
on. Each industry may use its own vocabulary (with different terms
and tag names) but they all essentially reference the same
thing.
Traditional EDI has addressed this consideration with code
and element dictionaries, but has not provided the roadmap for the
cross-referencing. Instead, individual EDI tool vendors have
provided their own industry specific vocabularies mapped to the
standards.
In XML parlance, this integration of the terms, and the
data model along with the business use semantics, is known as a
schema. So a vocabulary combined with data structures and business
rules can be expressed in XML syntax using schema definition
rules. In the XML 1.0 specification the schema modeling tools are
known as the Document Type Definition (DTD) syntax. The W3C's
draft XML-Schema specification will extend the modeling capability
far beyond what is currently possible with DTDs.
In the XML repository for each of our example industries, a
glossary would equate a specific identifier to the equivalent
Bizcode. An industry could create a label for the Customer/Client/Buyer identifier example and call it
"BE000123". A company from another line of business that
needs to interact with companies using that industry's XML
vocabulary could precisely relate its customer or buyer or client
identifiers to BE000123.
As a result, trading partners in a
vertical industry can use the business terms and rules with which
they are familiar, yet still relate to allied businesses. In the
financial world, stock brokerage houses can relate to personal
banking integrators and to financial regulators, where each group
uses related information that overlaps across the business
domains. Financial industry associations through their XML syntax
working groups are already looking into these ways of
interacting.
Another important use of Bizcodes is to locate, re-use and
transform information (often called mapping) both within business
transactions and more broadly across the web itself. An example is
product catalogues. A vendor may have a catalogue displayed on the
web using its own vocabulary, such as <ProdCode>,
<Cat>, <InStockQty>, <Delivery>,
<Product>, <ListPrice>, <WebDisc> and
<TechSpecs>. From their published Bizcode references (these
can be conveniently documented in an XML DTD), software can then
automatically relate these references to a search process that
locates customers for specific products.
In a global economy, Bizcodes can also provide an effective
method of translating between languages. A customer in Japan, for
example, could see search results displayed in their own language;
replacing the original English terms. Notice in
this context that Bizcodes can work more robustly and directly
than traditional vocabulary labelling techniques, or mapping the
vocabulary itself, where any variance in the spelling or naming
will cause significant failures to occur.
Technically, Bizcodes are implemented using fixed attributes in
DTDs. More information on repositories and Bizcodes is available in the
XML/edi group's
XML
Repositories white paper. Note that Bizcodes are here
introduced as the "ATTLIST mechanism".
Data Exchanges Must Be Scalable and Maintainable
At the beginning of this article we saw how IDC are predicting
a major upsurge in business use of XML and the Internet. To
successfully expand traditional EDI style systems to a global audience
of tens of thousands of trading partners means
developing and deploying new, innovative, and very robust software
processes. Simple arithmetic is at work here. If your current EDI
department processes 50,000 transactions daily, working with 200
trading partners, will that support group be able handle ten times
that number of partners? Would you, or could you, hire more people
to accommodate that volume?
Clearly the new breed of XML/edi systems must be flexible, and
able to handle a large expansion of exchanges without excessive
human interaction. This is why there is a need to understand how
we can integrate software agent technologies into XML/edi
systems.
Up to now, the picture seems
discouraging. Despite the grim lessons of Y2K compliance that have
cost businesses billions of dollars, many software development
teams are still happily creating hard-coded systems with
ready-made limits on their ability to handle new and different
business data.
We are not talking about highly advanced
capabilities here, but simple measures like avoiding creating
an information system that will only handle 2 address lines in an
address, or no more than 10 items per order, and so on. What
happens when an order with 11 items, or 3 address lines comes in?
XML provides the means to express metadata without specifying
hard-coded constraints. This means that developers building new
XML implementations should avoid hard-coded constraints in the XML
content to prevent such problems in process models.
Creating XML software systems that are significantly
flexible, fault tolerant and scalable is a design and
engineering challenge. Software agents can help this process.
The most immediate need
is for tools that can track XML transaction content and
alert support staff to potential failure conditions in the
information, particularly relating to versioning.
Traditional EDI
implementors have long understood the need to manage versioning
between trading partners. In an XML-driven world, such changes
are exacerbated by the ease that trading partners can change and
revise the details in their transaction content and
structures.
XML for E-Business: A Growing Concern
In addition to the work being pursued by the XML/edi Group, other
groups are recognizing similar needs and requirements. Among
initiatives in this are CommerceNet's
eCo Framework and the ebXML initiative launched by the United Nations' CEFACT and OASIS.
The inaugural ebXML initiative meeting takes place this November.
The stated objectives of the ebXML initiative closely mirror those
envisioned in the XML for E-Business Initiative. What may
differentiate the two is in that the former has a higher level,
top-down approach, while in the XML/edi Group's work there is a
detail-oriented bottom-up approach. As such, both approaches are
complementary.
Further Thoughts and Review
The W3C and other bodies must recognize the needs of doing
business with XML when crafting further refinements to the XML
standard. They must ensure that the emerging complexity found in
extended portions of new working drafts on XML technologies does not
derail the process of providing simple, consistent, light weight,
easy-to-learn and broadly maintainable e-business systems.
Michael Swaine, editor-at-large for Dr. Dobb's Journal,
in his November 1999 DDJ column "Programming Paradigms",
puts all this very succinctly while discussing the Oxygen Project
at MIT (introduced on MIT's site in this transcript). Under
the heading of Attaining Invisibility, Swaine writes:
"The goal of MIT's Oxygen Project is to push computer
technology and information technology beyond what passes for
ease-of-use today, making it not only accessible to everyone, but
richly exploitable by everyone".
Swaine then identifies the key technologies that will deliver on
this promise. "The five technologies of speech (and other
perceptual capabilities), knowledge access, automation,
collaboration and customization are the only new kids on the
block. Out of the thousands of things that we can imagine doing in
the new world of information, these five are the foundations on
which any new activities that help us do more by doing
less will be built".
Doing more by doing lessthis mantra is central to the
vision for XML/edi. Realizing e-business is an early step towards
a world of
transparent computing envisioned by the MIT project.
Much work in e-business remains to be done: XML
repositories coupled with Bizcodes by themselves cannot capture
all the aspects of automating a data integration process. When an
application system transforms and re-uses information across
domains, both structural and business semantic changes occur, and
software may also re-combine data to produce new data.
What Do You Think?
Discuss the issues raised in this article in our forum on XML and e-business.
Have your say in our XML/EDI
online forum.
|
|
However, our objective here has been to introduce
the core concepts behind the XML/edi Group Initiative on XML for
E-Business, and show how these aspects are critical for
implementing broad-based global electronic commerce via the
Internet.
Prev [1] [2]