Previous PageTable Of ContentsNext Page

1.0  INTRODUCTION


The purpose of this report is to assist Department of Defense (DoD) [in particular Defense Logistics Management Standards Office (DLMSO)] in evaluating the applicability of existing and future eXtensible Markup Language (XML)-based standards for use within DoD logistics business operations systems. A key part of the research conducted for this task was to identify and evaluate the current myriad of bodies and/or business standardization initiatives potentially applicable to DoD's emerging XML/EDI planning and migration efforts.

XML was formally recommended by the World Wide Web Consortium (W3C) in February 1998 - and since that time, XML tools, techniques, and methodologies are maturing. Software vendors are embracing this technology and they are beginning to build it into their products and services. XML is quickly becoming the standard markup language for the Web, which is a key part of why XML is touted as having the potential to revolutionize the way businesses exchange data. In addition to allowing companies to easily and cheaply conduct online business transactions with their customers and partners, XML also delivers a variety of other capabilities such as mapping data, application and database integration, styling data for screen display, and delivering a variety of other media across the Web. Although XML has great potential, the user community needs agreed upon standards in order to make XML a feasible mechanism for e-commerce applications, integration, and interoperability.

The following diagram illustrates the three key and independent areas of standardization relating to XML and Electronic Data Interchange (EDI).

 

Figure 1.0-1  The Move Towards an Integrated Framework


Figure 1.0-1 shows how the EDI and the Web XML are fueling the standardization of so called "Integration Frameworks." These frameworks include services such as Registries and Repositories, etc (see Section 1.3). Sections 1.1 and 1.2 introduce EDI and Web XML respectively. The remainder of this report addresses each of the three above-mentioned areas separately. Section 2.0 of this report provides an overview of the EDI standards bodies' (ANSI ASC X12/DISA and UN/EDIFACT) perspective with respect to XML. Section 3.0 provides addresses the World Wide Web Consortium and the relevant Web technology standards (XML family of specifications) and discusses the Internet Engineering Task Force (IETF). Section 4.0 discusses the various emerging industry consortia/frameworks and their respective mission, goals, status, and future plans. Section 5.0 of this report touches on some of the existing DoD efforts related to XML and XML/EDI standardization. Finally, Section 6.0 provides some summary recommendations regarding the future of the standardization efforts and how DoD can, best position their organization to embrace and extend these emerging standards and frameworks.


1.1  What is EDI?
Electronic Data Interchange (EDI) is the computer-to-computer exchange of business data in a standardized format. With EDI, information is organized according to a specified format set by both trading partners thus allowing a "hands-off" computer transaction requiring no human intervention or re-keying on either end. The information contained in an EDI transaction set is for the most part the same as on a conventionally printed document such as a purchase order, bill of lading, or invoice.

In the late 1960's as businesses began to computerize their internal operations, the shipping and transportation industries developed EDI in an effort to reduce the burden of paperwork and also as an attempt at implementing the fictional "paperless" office. Although EDI never eliminated paper documents, it decreased the number of times such documents were handled by people. Reduced handling resulted in fewer errors and faster transfers, but unfortunately, it also increased the complexity of moving electronic documents around. Historically a company that switched from traditional methods - usually mail or fax to EDI saw savings in time and transaction costs, at the costly expense of having to implement and develop proprietary communication protocols.

Traditional EDI users, mostly Fortune 1,000 or Global 2,000 companies used leased or dedicated telephone lines or a Value-Added Network (VAN) such as those run by IBM, GE, or AT&T to carry data exchanges. A VAN was a system whereby a third party (the VAN provider) leased lines from local telecommunications providers, often enhancing them with elements such as error detection. These lines would then be used to connect participating trading partners who in turn would need to install the VAN's proprietary software to translate and transmit their business documents in EDI formats. The result was a secure, swift, and accurate system. The drawback of a traditional VAN was the high costs involved, which effectively blocked most Small-to-Medium sized Enterprises (SMEs) from taking advantage of EDI and like many new innovations EDI was never able to reach critical mass.

As telecom infrastructure increased, the Internet became the obvious heir apparent to VANs. An already existing infrastructure and a growing market for secure transmissions showed pioneers that the market for EDI could reach well beyond those who could afford the traditional VAN approach. Soon the EDI format was adopted for transmission across the Internet, and "EDI-over-the-Internet" services were born.

There are two types of EDI on the Internet. The first is called "Web enabled EDI" and uses a common Web-browser to view messages in a graphical format. This is considered ideal if the volume of messages is not too high. Web enabled EDI uses a simple point and click interface to search and select specific messages for viewing, download and print. "Internet EDI" is a term for high volume message transactions. Available on many systems, File Transfer Protocol (FTP) protocol complements the graphical point and click convenience of Web enabled EDI allowing high volume mass downloads matching the capability of most EDI VANs.

The changes in the computer technology environment and the increasingly integral role that information technology now plays in today's manufacturing, distribution and services environment, along with changes in business philosophy and practices, have changed the definition of EDI. The definition must now be more encompassing than merely the rapid transmission of electronic documents.

EDI must now be viewed as an enabling technology that provides for the exchange of critical data between computer applications supporting the process of business partners by using agreed upon, standardized, data formats. No longer is EDI merely a way to transmit documents, but it is a means to dynamically move data between trading partners whose computer systems will use the data to order raw materials, schedule production, schedule and track transportation, replenish stock, etc. Enter XML, which fulfills these requirements for real-time, IP-centric solutions, as it provides businesses a flexible, extensible and dynamic environment for integrated, interoperable data exchange.


1.2  What is XML?
Very simply defined, XML is a subset of the Standard Generalized Markup Language (SGML) designed for use on the Internet. XML has been referred to as having 80% of the functionality of SGML, with only 20% of the complexity. As defined by the W3C, XML describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them. XML is an application profile or restricted form of SGML, the Standard Generalized Markup Language [International Organization for Standardization (ISO) 8879], therefore by construction; XML documents are conforming SGML documents.

Referring to Figure 1.2-1, XML is a platform, a database, a language and media-independent. It is ideal for data-centric Web applications, easy to distribute, easy to manipulate on the client site, easy to customize data by using intelligent agents (that is the tags are machine processable).

 


Figure 1.2-1  The Move Towards an Integrated Framework


"XML provides the content to be displayed with HTML, while Java provides a mechanism by which XML content can be processed."

XML is portable, which because the web is a distributed architecture, is very important. Note that eXtensible Style Language (XSL) is really two specifications: eXtensible Style Language Transformation (XSLT) for mapping and transformation and XSL for styling and Formatting Objects (FOs). XML will enable new ways to add value to business transactions, which include: dual support for machine-to-machine and machine-to-human (user interface) processing, intelligent agent queries/processing, intelligent awareness and discovery capabilities, and enhanced mapping and integration capabilities.

There are varieties of techniques for storing XML data in traditional relational database systems, which include:

Storing XML documents as whole documents (document-centric) is a good strategy when the content is static. For example, storing XML documents as whole documents is good for such things as news articles, books, advertisements, etc. On the other hand storing documents as data (data-centric) is a good strategy when you have well defined structured data that is reused in other applications. Examples of data-centric applications include purchase orders, invoices, and several other business-to-business exchanges.

In many real-world applications however, the worlds of documents and data need to come together. For example, consider the following cases:

It is therefore not uncommon for applications to make use of both the data- and document-centric approaches to managing their business information inside their databases. The leading enterprise relational databases, like Oracle 8i, offer seamless integration of both these approaches. Combining this structured and unstructured data to function as a single document can be accomplished using database views.


1.3  What is a Framework?
The term framework is used often in this paper. For the purposes of this paper, we provide the following definition for framework:

Framework - a structured set of reference specifications used to integrate organizational modules into an integrated architecture. A Framework comprises three architectures:

When considering XML frameworks for next generation EDI it is important to understand how the syntax, semantics, and application integration aspects differ when comparing traditional EDI to XML. The following diagram compares specific points of traditional EDI vs. a Web based replacement of EDI:

 


Figure 1.3-1  The Need for Standards in Migrating from Traditional EDI to the Web


The purpose of the above diagram is to show how the syntax, semantics, and application integration areas compare for traditional EDI vs. Web XML/EC/EDI. It is important to note that XML (the language only - not the family of complementary suite of specifications) primarily provides the syntax and NOT the semantics for XML/EDI. Namespaces (see Semantics in above diagram) will allow you to define a 'scope' for a particular tagset to avoid the problem of tag name collisions. Most of the `action' going on in the standards development area currently is in the semantics and integration areas.

An additional area that is being standardized involves Transport, Routing, and Packaging. See Figure 1.3-2.

 


Figure 1.3-2  The Need for Standards in Conducting XML/EDI Business


The above diagram illustrates some of the areas currently in need of standardization. Generally speaking, the emerging frameworks are transport agnostic - meaning you can choose your own type of transport. However, the design of the message headers and packaging, compression, security, etc. are each areas that are currently being standardized. (See ebXML's Transport, Routing, and Packaging work group - Section 4.2.3.5 of this report.)

Additional components which can be included as part of a XML / EDI framework include:

Note a registry is a mechanism whereby relevant documents and meta-data about them can be registered such that a pointer to their location, and all their meta-data, can be retrieved as a result of a query, where as a repository is a location or set of distributed locations where documents pointed at by a registry reside, and from which they can be retrieved by conventional (HTTP, FTP,SMTP, etc.) means, perhaps with an additional authentication/permissions layer.

Section 3.0 of this report covers in detail some of the leading emerging framework specifications.

 

Previous PageTop Of PageNext Page