Beneath the Vortals

The Lowdown on XML-Based B2B Standards

By Michael Carroll

Using Internet procurement automation tools and techniques to buy operating resources can reduce costs, often achieving 300 percent return on investment (ROI) for the buying organization. Because of this, buyers and suppliers with different procurement and catalog systems must find ways to interoperate effectively. Three standards are emerging to try to solve this problem.

Operating resources are the goods and services needed to run a business, anything from pencils and paper to computers, software, and secretarial support and legal advice. According to a report by the Aberdeen Group, operating resource expenditures can be as high as 35 percent of the total operating budget for manufacturers, and more than 60 percent for service organizations.

So it's not surprising that many vertical portals ("vortals" -- see this issue's article by Tom Spitzer, "Vertical Horizon") have sprung up not only to provide content aggregation (industry news, career opportunities, legal information, and catalogs), but also to facilitate the procurement transaction process. A typical buying scenario goes like this:

1. An employee in a buying organization selects products and services from supplier catalogs.

2. Specialized software on the employee's desktop (such as Ariba's ORMS or Commerce One's BuySite) generates a purchase requisition and routes it via email for approval.

3. Upon approval, the software generates a purchase order and submits it to the vortal through the Internet.

4. The vortal routes the purchase order to the appropriate suppliers.

5. Each supplier secures payment and updates the order status at the vortal, ships the product, then notifies the buyer that the order has shipped.

Naturally you might ask how so many different buyers and suppliers with different procurement and catalog systems can interoperate effectively. Won't there have to be myriad point-to-point solutions? The answer lies in some exciting new developments in B2B e-commerce standards, the most promising of which are based on XML. This article explores these standards.

The traditional approach to B2B e-commerce has been electronic data interchange (EDI). A couple of EDI standards in wide use are ANSI ASC X12 and the international UN/EDIFACT. However, these standards predate Internet e-commerce and reflect a flat-file-based, least-common-denominator approach to computer data interchange. With the explosive growth of Internet e-commerce, however, such interchange standards are considered by many to be inflexible and inadequate. New methods of exchanging structured data based on HTML and XML are now dominant.

Of course, there are still plenty of legacy systems that need to be fed X12 or EDIFACT documents, so developers need to integrate Internet messaging and data transfer mechanisms with translators that can talk to the back-end legacy systems.

Traditional EDI has much to offer semantically and structurally to Internet B2B -- but its syntax is definitely antiquated. Many companies are involved in the simple translation of EDI documents into XML. The so-called XML/EDI movement is an excellent first step. It helps ensure that valuable domain knowledge codified in EDI standards -- that is, the semantics and structure of business documents -- is not lost in the rush to deploy newer technologies like XML. However, XML-based approaches have the potential to go beyond the mere reproduction of EDI transactions in XML format. XML brings the potential for document processing and validation.

The Fundamental B2B Problem: Lack of Shared Semantics

The need for standards is especially acute at B2B vortals. Such vortals are marketplaces where numerous trading partners can gather and exchange business documents. Portal software builders such as Epicentric, Ariba, and Commerce One realize that their XML-based approaches to content aggregation lends itself well to expansion into B2B exchange.

Epicentric's Portal Server currently relies on Information and Content Exchange (ICE), which facilitates content aggregation via a syndication/subscriber model (see Dan Greening's article "Self-Service Syndication with ICE" in the November 1999 issue). Although ICE is not a B2B e-commerce standard per se, its approach to aggregation may well serve as a model for aggregating e-commerce business documents. Like the more specific B2B e-commerce standards reviewed below, ICE is based on XML.

The main challenge in using XML is not with document structure and syntax, but with semantics. It's much easier to share syntax than to share semantics. Each application domain needs to have both specific document structure and agreed-upon semantics to make effective use of XML-defined documents. Various vertical industry segments have to agree on the meaning of their domain-specific XML tags. Only then can the appropriate action be taken upon parsing: translating components into internal business objects for use within the enterprise.

Fortunately, several XML-based standards are emerging. They use XML to describe the types of business documents that need to be exchanged so that trading partners can exchange goods and services. The more notable of these standards are Ariba Commerce XML (cXML), Commerce One Common Business Library (CBL), and Microsoft BizTalk Framework. There are also several non-XML solutions. Open Buying on the Internet (OBI) is a fairly mature example of the non-XML sort.

The Need for Schemas

As we examine the three XML-based standards for B2B document exchange -- cXML, CBL, and BizTalk -- keep in mind that each is dependent on its own schema definitions. XML is a metalanguage providing the rules for defining tagged markup languages. A schema, however, is a formal specification of the grammar for one particular language. A schema is needed to validate document content, that is, to determine whether a document is a valid instance of the grammar expressed by the schema. A schema not only constrains the structure of XML document instances but also the meaning, usage, and relationship of a document's component parts: its data types, elements, attributes, and their values.

Because DTDs also constrain document instances, you're probably wondering what the difference is between DTDs and schemas. First, the XML 1.0 spec itself constrains the well-formedness of XML documents (for example, the syntactic rules for the use of angle brackets). A DTD further constrains the validity of a particular document instance, identifying particular tags and their attributes for any particular class of documents. Schemas, however, go beyond DTDs by further constraining the validity of the content between the tags, or the values of attributes.

For example, a DTD may constrain an element to containing only character data, yet it might not specify what type of character data. A schema may go on to specify that the contents of the element may contain only character data of a particular form, say, only integers in a specified range. Thus schemas play an important role in providing detailed data typing constraints for XML documents. So documents that need strong data typing, such as e-commerce business documents, need more than DTDs. They need schemas.

Schemas, being expressed in XML itself, also provide extensibility. This facilitates maintenance and upgrade of the document grammar, so that legacy applications can use updated documents without being affected. Further, you can extend a particular schema to suit your particular application and still have it interoperate with other applications.

It is also important to note that while cXML and CBL are comparable technologies -- each defines its own XML-based business documents -- BizTalk cannot be directly compared to cXML and CBL. BizTalk focuses more on the envelope header and protocol aspects of B2B exchange.

All the standards use XML, but they differ in how they define their schemas. They also differ significantly in the choice of business documents they define and the business object ontology they use.

A schema defines both the tags that can appear in a document and the tags' allowable attributes. It also specifies the document's structure. For example, it determines which tags can appear as child tags under others, the order in which the children may be presented, and the number of allowable children. The schema can also specify default values for attributes.

cXML

Commerce XML, or cXML, is a set of XML DTDs and schemas jointly developed by more than 40 companies. Ariba has incorporated cXML into its existing XML-based infrastructure. Other e-commerce solutions providers using cXML include Extricity Software, InterWorld Corporation, Ironside Technologies, POET Software, Sterling Commerce, Vignette, and webMethods.

A chief proponent and early adopter of cXML, Ariba began pilot implementations using cXML over the Internet in early 1999. Ariba's flagship product, Operating Resource Management System (ORMS), resides at the buying organization and provides users with a browser-based user interface. ORMS uses Ariba's Enterprise System Adapters to interoperate with human resource management system (HRMS) and enterprise resource planning (ERP) systems from vendors such as J.D. Edwards, Oracle, PeopleSoft, and SAP. For transport and messaging ORMS uses standard email and directory service systems such as SMTP, NIS, and NT Domain.

ORMS gives employees at buying organizations internal access to supplier catalogs. It facilitates the generation of purchase requisitions, approvals, and orders, and it routes the approved purchase orders to suppliers through the Ariba Network. The latter is also the conduit through which buyers receive supplier catalogs. Ariba also offers Internet Business Exchange (IBX), a hosted version of the Ariba Network.

cXML transactions come in two flavors: request/response and one-way. Request/ response transactions can be characterized as "document pull" and rely on an HTTP connection for transport. One-way transactions represent "document push" and are not restricted to any particular transport. In many ways they resemble SMTP messaging. The initiator of the transaction immediately sends the cXML document some underlying messaging transport protocol. Although an acknowledgement may be used, the one-way transaction is essentially finished as soon as the document has been sent. One-way transactions may also be initiated using HTTP's POST method.

An interesting three-party scenario involving a one-way transaction is called cXML-urlencoded. In this scenario, a buyer might visit one site and receive a Web page with a cXML message embedded in a form. When the buyer subsequently submits the form, the cXML message may actually be POSTed to a third-party server for processing. In this way, there's no need for direct integration of the first Web site with the third-party server. The user's browser actually serves as an intermediary for communications between the Web site and the third party, a fulfillment house perhaps. This means a business shopper could traverse several different online stores and place items in his or her shopping basket, and then check out through the third-party fulfillment house.

The cXML infrastructure streamlines the secure exchange of catalog content and transactions. It supports various supplier content and catalog models, including buyer-managed, supplier-managed, content-management services, electronic marketplaces, and Web-based sourcing organizations. This will let suppliers give customers selective access to customized catalog content.

Additionally, cXML defines several request/response processes supporting various business documents. These processes include purchase orders, change orders, acknowledgments, status updates, ship notifications, and payment transactions.

A good place to start your search for cXML information is the cXML Web site (see " Online"), which includes a PDF version of the cXML/1.0 specification. You'll also find there a ZIP file, cxml.zip, containing all the modules and DTDs associated with cXML. The ZIP archive also contains cxml.doc, a Microsoft Word version of the spec. The spec describes both the cXML protocol interactions and business documents.

CBL

Commerce One's Common Business Library (CBL) is a collection XML-based business documents and processes built on Commerce One's Schema for Object- oriented XML (SOX).

SOX is a data description language, that is, a schema, expressed in XML. It uses the standard XML data model to produce XML documents, but is defined by stronger constraints and supports more powerful validation of document structure.

While cXML was built using the XML-standard DTD constraints, CBL was built using SOX. SOX has been submitted to the W3C for consideration. The W3C is expected to make recommendations regarding such schema proposals to enhance ease of use for XML protocols. This extends to such issues as low-level data type checking. However, the W3C does not wish to recommend any particular standard that defines particular business documents. So don't expect the W3C to favor either cXML or CBL over the other.

Some other heavy standards players have offered favorable reviews of the CBL standard. Most notably, the UNCEFACT, purveyors of the UN/EDIFACT international standard for EDI transactions, have given CBL some encouraging words of support. This is not surprising, considering that CBL was consciously designed to leverage the semantics and structure of standard EDI documents and transactions.

Commerce One's equivalent of the ORMS is the Commerce One BuySite, and its equivalent to the Ariba Network/IBX is the Commerce One MarketSite.net. The latter is a B2B portal built on Commerce One's MarketSite 3.0 software. If you want to build a vortal for your own particular vertical industry, you can license and deploy your own copy of MarketSite.

BizTalk

BizTalk is Microsoft's foray into B2B e-commerce. Unlike cXML and CBL, it does not attempt to define B2B documents. It concentrates more on the header and protocol elements. In fact, there are three different products or services that make use of the name BizTalk:

1. The BizTalk protocol is essentially the transport mechanism for B2B documents. This encompasses the sender, recipient, and timestamps associated with documents, such as the envelope header information.

2. The BizTalk.org schema repository contains schemas from many companies. Eventually the schemas from Ariba and Commerce One will reside there.

3. The BizTalk server is a next-generation server architecture for Microsoft's commerce interchange pipeline product.

This will be a front end to Microsoft's Site Server Commerce Edition.

Microsoft and Ariba are working together to accelerate the adoption of XML-based standards for e-commerce. The companies are integrating cXML with the BizTalk Framework to define schemas for communicating operating resource transactions, such as catalogs and orders.

While cXML provides tags to support supplier content and catalog models -- including transaction information for purchase orders, change orders, status updates, and payments -- BizTalk is an application and business-process integration framework. BizTalk will support any XML schema written using the BizTalk guidelines, which Microsoft says will track with industry standards.

OBI

A fourth standard that applies to Internet procurement is Open Buying on the Internet, or OBI. Although not currently based on XML, it's being reworked as an XML application.

The OBI architecture ties business process information with business process owners. Buyers are associated with requisitioner profiles, account information, and purchase approvals. Sellers, on the other hand, are associated with catalogs, price information, order entry, and inventory. The OBI protocol and formats ensure that buyers and sellers can interoperate. OBI models the process flow from beginning to end.

OBI is actually a fairly mature technology, having started its development in 1996. Wise use has been made of the ASC X12 EDI heritage. For example, the contents of OBI Order Requests and OBI Orders are based on the 850 document, an ASC X12 standard for purchase orders.

Although OBI is not currently based on XML, there are plans afoot to include XML in future OBI specifications.

Like cXML, OBI makes use of HTTP and SSL for its transport mechanisms. This does not mean that a human has to be in the loop, however. A warehouse bar code reader and a database monitoring inventory levels could just as easily launch an HTTP user agent (like a robot) and reorder inventory from the manufacturer.

How cXML, CBL, and BizTalk Differ

Returning to our three XML-based standards, let's consider their differences. They differ in DTDs, schemas, namespaces, and most importantly, in the structure of the "standard" business documents they implement. Just for starters, the BizTalk tag specification is concerned with header information, and requires that a BizTalk Framework document must begin and end with the <BizTalk> tag pair, the so-called root tag, as in Example 1.

These outer tags define a BizTalk Framework 0.81 document, telling the parser that the elements found therein are from the Framework namespace. This is useful because a parser could then use the BizTalk Framework specs to validate the inner structure of the message. Once you get past this mandatory root tag, however, you have free rein to build your own specific internal structure, perhaps conforming to other standards, such as CBL or cXML (see Example 2).

Keep in mind that BizTalk is not concerned with particular business documents. It's primarily concerned with lower-level standardization, headers, and protocols.

cXML and CBL, however, are comparable, and they differ in subtle ways right from the beginning in their use of XML-Data schema proposed by Microsoft. Microsoft recommends that its data type schema definitions be referenced externally by the uniform resource name (URN) in an XML namespace attribute, as in Example 3.

Commerce One's CBL and underlying SOX schema does just that. CBL's purchase order definition begins as in Example 4.

Ariba's cXML, however, takes a slightly different approach. It uses a DTD, not a schema like SOX. Further, it has defined -- internally and explicitly -- its own atomic data types, leaning on and informally referencing the Microsoft specification. In its Common.mod import module, the definition of atomic data types resembles the code in Example 5. In a sense, Ariba's approach to atomic data type definition is hard-coded in the DTD.

To further contrast cXML and CBL, consider how each models a purchase order, a standard business document. In cXML, a purchase order is defined as in Example 6. On the other hand, in CBL, a purchase order would be implemented with the tags in Example 7.

Those who know the old standards might detect here the close mapping between the CBL model and traditional ASC X12 850 document structures. IMHO, this was a wise choice on the part of Commerce One. Although cXML elements can also be mapped into legacy EDI components, Ariba chose not to maintain the fieldnames and exact hierarchy from the legacy EDI standards. Something can be said in favor of this approach: Ariba has aimed to make cXML easier to adopt for those who are not familiar with the EDI legacy systems. It takes very few ASP pages to integrate with cXML.

I don't wish to take sides here. Both cXML and CBL are robust, XML-based languages facilitating the interchange of business documents. Just as they can both be readily parsed and translated into legacy EDI documents, they can also be mapped into each other. After all, part of the power and beauty of XML is that it so readily facilitates the expression and translation of structured data. However, the fact that cXML is DTD-based and CBL is schema-based is to be noted. How important this distinction will be remains to be seen. The claim that schemas are more extensible than DTDs certainly seems worth consideration.

Conclusions

Of course, the economic motive for all this B2B e-commerce is clear: The Organization for Economic Cooperation and Development (OECD) predicts that by the year 2003, e-commerce transactions could reach $1 trillion, an increase in volume over 1998 of more than 4000 percent! The OECD also estimates that by the same year B2B will be the dominant e-commerce sector, with more than $800 billion in goods and services exchanging hands.

As B2B e-commerce continues to grow, more and more companies will want to settle on a relatively small number of standards to facilitate their B2B transactions. At this point, it looks like it will pay to keep an eye on XML-oriented standards such as cXML, CBL, and BizTalk. Given that the three main sponsors (Ariba, Commerce One, and Microsoft) are all talking, comparing notes, and deferring to some extent to the wisdom of the W3C, it's likely that these standards may be able to interoperate more easily in the future. At least it's not too far-fetched to see applications in the future that will be able to parse and translate from one set into another.

It's also evident that a successful vortal must provide both content aggregation and e-commerce transaction capabilities. A combination of software like Epicentric's Portal Server for gaining access to newsfeeds and other industry-specific content, and Commerce One's BuySite/MarketSite 3.0 package, or Ariba's ORMS/Ariba Network, looks like a fast way to get a vortal up and running and, at the same, adhere to emerging XML-based standards.

(Get the source code for this article here.)

---

Michael is president and founder of CyberStrategies, an e-commerce solutions provider in Upland, CA. He is the author of Cyberstrategies: How to Build an Internet-Based Information System. Reach him via email at [email protected].