The concept of EDI is even more relevant today than it was 20 years ago because
EDI and the InternetSo, deploying EDI makes a lot of sense, but traditional EDI technologies, such as EDIFACT and X12, have not really taken off on the Internet. A number of reasons have been proposed to explain this lack of interest:
It is expected that XML could help alleviate some of these problems because
These are all valid reasons, and I think the most important one is the integration with the Web. XML works as a natural extension of HTML for specific applications. See Figure 5.3 for an illustration. Figure 5.3. XML supports both users on a workstation and a more automated approach.
The lower portion of Figure 5.3 is the familiar Web site, although this one is built on XML. The server of the seller uses XSL to present information to a buyer. This is similar to what we built in Chapter 4, "Content Syndication." However, instead of publishing news, it publishes commercial documents such as purchase orders, invoices, and customs declarations. The upper portion skips the style sheet to demonstrate an EDI-like exchange of information. The same XML commercial documents are presented to the accounting system or the ERP of the buyer. What is interesting about this setup is that it uses Web technologies to integrate the two accounting systems. The main benefit of this setup is that it enables the buyer to start with limited investments (a browser) and upgrade to the more automatic mode as the volume of transactions grows. XML/EDIIn 1997, the XML/EDI Group ( http://www.xmledi.com ) was established as a grassroots effort to promote XML in business-to-business e-commerce. Since 1997, other groups, vendors , and organizations (such as ebXML, BizTalk, CommerceOne, RosettaNet, and more) have adopted XML as their preferred syntax for business-to-business e-commerce. Unlike EDI, no worldwide, standardized XML version of the order and other commercial document exists. In fact, it is very unlikely that there will ever be one. Listing 5.2 is one possibility for an XML version of an order. Figure 5.4 is a graphical representation of its structure. As you can see, it is a classic order with buyer and seller information followed by order lines. The XML order is very close to the EDIFACT order for a good reason: Most orders look alike. Listing 5.2 orders.xml<?xml version="1.0"?> <Order confirm="true"> <Date>2000-03-10</Date> <Reference>AGL153</Reference> <DeliverBy>2000-04-10</DeliverBy> <Buyer> <Name>Playfield Books</Name> <Address> <Street>34 Fountain Square Plaza</Street> <Locality>Cincinnati</Locality> <PostalCode>45202</PostalCode> <Region>OH</Region> <Country>US</Country> </Address> </Buyer> <Seller> <Name>QUE</Name> <Address> <Street>201 West 103RD Street</Street> <Locality>Indianapolis</Locality> <PostalCode>46290</PostalCode> <Region>IN</Region> <Country>US</Country> </Address> </Seller> <Lines> <Product> <Code type="ISBN">0789722429</Code> <Description>XML by Example</Description> <Quantity>5</Quantity> <Price>24.99</Price> </Product> <Product> <Code type="ISBN">0789724308</Code> <Description>Applied XML Solutions</Description> <Quantity>10</Quantity> <Price>42.50</Price> </Product> </Lines> </Order> Figure 5.4. The structure of the XML order is more readily apparent than its EDIFACT counterpart .
Although they convey the same information, the XML and EDIFACT orders are not strictly identical:
Our goal in the next sections is to convert one format into the other and vice versa. Warning The XML document includes product descriptions that have no equivalent in EDIFACT. This is not a technical limitation of EDIFACT; it is more of a cultural one. Specifically, including product descriptions using segment IMD is possible. However, EDIFACT users tend to be conservative with bandwidth, so if the ISBN is enough to identify the product, why waste resources?
|