Trading Communities
In 1996, Dr. Marty Tenenbaum proposed the vision of an Internet "eco system" in which businesses build on each others' services to create virtual enterprises, markets and trading communities. Internet-enabled businesses could be modeled as a collection of services, some internal to the organization, others provided by trading partners. Eco systems would replace closed trading partner networks with open markets, and extend enterprise applications such as inventory management and production scheduling across entire supply chains.
Because platform and application heterogeneity are facts of life, integration at such a scale would have to be at a semantic level where components connect and communicate through a shared language, vocabulary, and business concepts. Tenenbaum called this the Common Business Language (now referred to as the Common Business Library, xCBL), and it would be the foundation of the component-based Internet.
The XML Revolution and XML Standards
By making it possible to encode information and services with meaningful structure and semantics that computers can readily understand, the Extensible Markup Language (XML) has become a key technology for the Internet. XML is more capable than the format-oriented HTML encoding with which the Web began, and vastly simpler than other approaches to application integration. XML makes it easy to create specialized markup languages (sets of tags) that identify and describe buy ers and sellers, the goods or services that they want to buy or sell, and the numerous other document types needed for commerce. XML has been embraced by all major platform vendors including IBM, Microsoft, Netscape, Oracle, SAP, and Sun - and by hundreds of other companies building innovative Web products and services.
But the flexibility of XML can also be a liability. If every business invents its own XML definitions for product catalogs, requests for quotes, price lists, purchase orders, invoices, transportation schedules, shipping notices, delivery and payment receipts, the Web will become scarcely more usable as a platform for electronic commerce than if everyone used HTML. So many forward-looking individuals and companies have started to work together to develop XML-based specifications for the information they most often need to exchange in a particular industry or marketplace. Commerce One participates in the following standardization efforts:
- The RosettaNet initiative is designed to facilitate the exchange of product catalogs and transactions between manufacturers, distributors, resellers, and shippers of personal computers and other information technology products.
- The Internet Open Trading Protocol (IOTP) initiative has developed a purchasing protocol that handles the various roles of consumer, merchant, value acquirer, deliverer, and customer care provider and defines the transactions of purchase, refund, value exchange, authentication, withdrawal, and deposit in a payment-method-neutral manner.
- The Open Buying on the Internet (OBI) initiative is developing a standard buying and selling framework for non-production goods and services to ensure that buy-side and sell-side systems are able to communicate and interoperate.
XML standardization initiatives are critically important. There are substantial benefits when standard XML definitions are shared by the companies in a particular industry or market. These include reduced development and maintenance costs and the elimination of custom "mapping" between the information models embodied in a company's business systems and those of its trading partners.
The Need for a Common Business Library
While each new XML specification for a particular industry is a step forward, it also contributes to the proliferation of information models that cut across industries or marketplaces. Each new specification seems to start from scratch, reinventing concepts such as:
- Descriptions of businesses and individuals
- Measurements, date and time, location, country codes, currencies, business classification codes
- Basic business forms like catalogs, purchase orders, and invoices
A better approach is the development of XML document models from reusable semantic components that are common to many business domains. Such documents can be understood from their common message elements, while also providing a common mechanism for linking to unique elements that vendors need to differentiate themselves.
The goal of xCBL is to provide an initial set of XML building blocks that companies can assemble and extend to develop XML applications quickly. Some of these building blocks come from well-established international standards, such as ISO 8601 (date and time), ISO 31 (measures), ISO 639 (languages: EN, FR, etc.), ISO 3166 (country codes: US, JP, etc.), and ISO 4217 (currencies: USD, FFR, etc.). Other building blocks come from SIMPLE-EDI, a project to create minimal EDIFACT transaction sets. The "standard" business documents in xCBL are based on these building blocks and an analysis of similar documents emerging from the OBI, RosettaNet, and OTP initiatives, with the goal to harmonize them as much as possible.
xCBL will be made freely available in registries run by Commerce One as part of Commerce One MarketSite, as well as well as through registries operated by xml.org, CommerceNet, Biztalk.org, and other organizations. We hope that the Internet community, building on this foundation, will contribute many additional elements and document models to xCBL and to similar efforts.
(Perhaps the most important standardization effort in this area is "ebXML," a harmonization project involving most of the major players from the EDI world and the XML e-commerce world. This group is currently working to unify the component and document sets used for e-commerce, to guarantee greater interoperability moving ahead. xCBL is one of the major sources from which this "ultimate" business language will draw.)
The "Document Services" Architecture in MarketSite
The basic assumption that underlays xCBL and its use in Commerce One's MarketSite product family is that it is easier to interconnect business systems and services in terms of the documents they exchange - on which they largely agree to begin with - than in terms of their application interfaces, which inevitably differ.
Shared document definitions provide an intuitive framework for specifying the business logic and computations that take place on each end of the document exchange. For example, the following two business rules contain implied definitions for five shared documents:
- if you send me a request for a catalog, I will send you a catalog
- if you send me a purchase order and I can fulfill it, I will send you an invoice and a shipping notice.
This "document services architecture" is fundamental to achieving the goal of supplier and buyer integration in Commerce One's MarketSite products because it substantially reduces the cost of business systems integration. A MarketSite operator or "market maker" defines (or reuses from some other MarketSite) the "community standards" for business documents. Buyers, suppliers, and other service providers can participate if they can produce and consume those documents. How the documents are produced and what actions result when they are consumed are strictly up to the business. This elevates integration from the system level to the business level. It enables a business to present a clean and stable interface to its business partners despite changes in its internal technology implementation, organization, or processes.
Defining interfaces in terms of documents allows for an incremental path to business automation, whereby browser-based tasks are gradually transferred to computer processes. A supplier with a small product catalog and a few sales a day can use a web browser to send and receive orders until increased transaction volume justifies integration with ERP or database applications. Likewise, a buyer who buys only a few items "off the shelf" can rely on a browser, and only integrate with purchasing or accounting systems when scale justifies it. In each case, since the same XML documents are going in and out, the changes to the implementation are invisible to the marketplace and other trading partners.
The CommerceNet eco working group is developing a specification for interoperability of XML-based electronic commerce applications that extends and general izes this idea of defining all system interfaces in terms of document exchange. Commerce One expects that MarketSite will provide "eco-compliant" document interfaces soon after the CommerceNet specifications become public.
XML Document Exchange and EDI
Many companies are concerned that the emergence of XML is a threat to their traditional ways of doing business with Electronic Data Interchange (EDI). The X12 and EDIFACT EDI standards are generally used to automate routine transactions between established trading partners, especially where at least one of them is a very large company.
In principle, EDI embodies the "document services architecture" that makes direct coupling of business systems unnecessary, and twenty years of EDI experience has created standards for a few hundred transaction messages in many different industries and application areas. So at first glance it might seem that traditional EDI could be quickly adapted to the Internet to obtain lower cost and faster message delivery, while enabling integration of EDI-enabled functions with other Web services. One way would be as "Internet EDI," which would put a wrapper around EDI messages so that HTTP could be used for EDI transport rather than VANs. An approach that would be especially attractive to small businesses for which traditional EDI was cost-prohibitive would be "Web EDI," which would use Web forms for capture and display of EDI messages.
In practice, however, it doesn't appear that EDI will make the transition to the Internet without some fundamental changes. Neither approach for putting EDI messages on the Internet "as is" seems to be the magic solution to preserve the investments companies have made in EDI. The fundamental problem is that the flexibility that both the X12 and EDIFACT standards leaves the precise definition of the documents to be exchanged to "implementation guidelines" that are not computer-processable. Without the precision of an XML DTD or schema to specify the structure and contents of a message, EDI messages must be validated with software that has been custom tailored to each implementation guideline. For the same reason it is difficult to define EDI messages using reusable building blocks.
The best way to preserve EDI investments appears to be to encode EDI semantics into XML. After studying a variety of different philosophies for the "XMLification" of EDI, we've chosen an approach that takes advantage of the best parts of EDI without sacrificing any of the power and flexibility of XML.
