who said you can’t teach an old dog new tricks. (or bill’s view of the wonderful world of xml)

Copyright © William G. Cafiero, 2000

GE Global eXchange Services

Who said you can’t teach an old dog new tricks.(or Bill’s view of the wonderful world of XML)

Who said you can’t teach an old dog new tricks.(or Bill’s view of the wonderful world of XML)

Bill [email protected]



Credits

My thanks to the following experts for contributing ideas, material and advice in the development of this material:

• Bob Angrisano, Microsoft Corporation, for the style sheet examples

• Joe Kellett, Legendary Systems, for much of the XML vs EDI material

• John Ousterhout, Scriptics Corporation , for the XML application integration discussion

Any errors or omissions introduced into their material are solely my responsibility

Bill Cafiero



Session Outline

This Session has five sections:

1. Introduction - Why XML?

2. Technical Section - For the “Pony Tails” - the mechanics of XML

3. Current Standards Development Section - What work is underway at the present

4. The Role of XML - For the “Grey Hairs” - Where XML might fit in B2B commerce

5. Observations for the EDI Professional

A good web site for general XML information is www.xmlinfo.com

An XML Tutorial may be found at www.ge.gxs.com

A good web site for general XML information is www.xmlinfo.com

An XML Tutorial may be found at www.ge.gxs.com



Section 1 - Why XML?

• EDI is “B2B” (Business-to-Business) electronic business process integration, fine-tuned by knowledgeable and talented people over many years, and it works now.

– Rich and sophisticated business semantics.– Mature supporting technologies.– Reliable.– Large available pool of technical talent.

• So why “reinvent the wheel” with XML? The promise is:– Faster time-to-market for TP connectivity, faster end-to-end

communications.– Cheaper to create and maintain TP relationships.– Better quality of TP relationship, since XML “extensibility”

makes it easier to design and implement new solutions.



EDI Tradeoffs

• EDI was designed when storage and network costs were more important factors, and is therefore “cryptic” and “hard to understand”.

• This “cryptic” quality also means that specialized stand-alone translation software is required.

– It is quite impractical for business applications to be programmed to “speak and understand” EDI natively.

• Therefore a specialized staff is required who understands the cryptic encoding methods used, and who can program (“map”) the specialized software.

• A “specialized staff” means development bottlenecks and training/recruitment issues.



EDI Tradeoffs

• At runtime, the required translation software is also a point of delay, and sometimes a point of failure.

• High-level business process exchanges are only loosely standardized. High-level business-process analysis and design is required for each TP relationship (at least for the non-dominating partner).

• EDI “standard” documents are highly configurable - no two need have the same structure. Therefore, lower-level data analysis and design is also required.

• The final custom design must be custom programmed (“mapped”) by the specialized staff on the specialized software.

• In other words, a one-off custom software development effort is required to bring up a TP relationship.



“EDI or Die”?

• “EDI or Die” never happened and never will.

• Some industries are so time-constrained and interaction-rich that EDI did become a survival requirement.

• Big hubs love EDI for its cost savings; they enjoy economies of scale that easily recoup EDI investment.

• Everyone else resists EDI unless forced because their cost/benefit ratio is too high.

XML to the Rescue???XML to the Rescue???



Section 2 - For the “Pony Tails”

Let’s look at the details of XML...Let’s look at the details of XML...



XML Highlights

Data that in X12 is defined by its position in a predefined structure is, in XML, given a label (tag) that describes the data in the transmission itself.

<Price>9.95</Price>

This is the essence of XML!This is the essence of XML!



Where Does XML Fit?

The Internet creates a need for platform-

independent technology.

XML

HTML

Java

Internetpresentation

dataprocessing

platform



Shipment_DetailLine_NumberQuantity

ShipmentShipment_Numb

erShipment_Date

DetailLine_NumberItemQuantityPrice

An Order in XML

<?xml version="1.0"?><!DOCTYPE Order SYSTEM "Orders.dtd"><Order>

<Order_Number>1001</Order_Number><Order_Date>04/24/00</Order_Date><Customer>Bill's Supply Company</Customer><Detail>

<Line_Number>1</Line_Number><Item>A-123</Item><Quantity>10</Quantity><Price>1.50</Price>

</Detail><Detail>

<Line_Number>2</Line_Number><Item>B-987</Item><Quantity>20</Quantity><Price>2.00</Price>

</Detail><Shipment>

<Shipment_Number>1</Shipment_Number><Ship_Date>3/15/00</Ship_Date><Shipment_Detail>

<Line_Number>1</Line_Number><Quantity>10</Quantity>

</Shipment_Detail><Shipment_Detail>

<Line_Number>2</Line_Number><Quantity>15</Quantity>

</Shipment_Detail></Shipment></Order>

OrdersOrder_NumberOrder_DateCustomer

DetailLine_NumberItemQuantityPrice

ShipmentShipment_Numb

erShipment_Date

Shipment_DetailLine_NumberQuantity



Simple XML Document Processing

<?xml version=“1.0” ?><Purchase_Order>

<Order-Type> newOrder = “True” Quoted = “Yes”/><Bill-To>

Bill-To Info</Bill-To><Ship-To>Ship-To Info<Ship-To><Line-Item>Line Item Info</Line-Item><Line-Item>Line Item Info</Line-Item><Terms>Some Payment Terms</Terms><PO-Total>PO value info</PO-Total>

</Purchase_Order>

Sender’s Application Generates

XML Purchase Order

Sends toReceiver

<?xml version=“1.0” ?><Purchase_Order>

<Order-Type> newOrder = “True” Quoted = “Yes”/><Bill-To>

Bill-To Info</Bill-To><Ship-To>Ship-To Info<Ship-To><Line-Item>Line Item Info</Line-Item><Line-Item>Line Item Info</Line-Item><Terms>Some Payment Terms</Terms><PO-Total>PO value info</PO-Total>

</Purchase_Order>

XML Parserexecutes and

checks forwell-formeddocumentand if OK,

createsPARSE TREE

ReceiverApplication processes

PO

Sender

Receiver

ReceivesPO

Passesto

XMLParser

PARSETREE

toapplication



Orders.xml Parsed

http://msdn.microsoft.com/xml/notepad/intro.asp



Viewing XML

What about displaying XML documents?

• XML itself does not describe how a document is to be displayed for human interpretation (i.e., screen, paper, audio)

• XML documents are just plan text files - you use a text editor to create and view them but there’s no formatting

• Internet Explorer 5 and Netscape Communicator 6 browsers will handle XML directly.



Style Sheets

What is a Style Sheet?

• You can combine a style sheet with an XML document to display the document

• Style Sheets contain the rules that declare how the document’s information should appear

• Style Sheets are like “templates and styles” in MS Word

• Extensible Styling Language (XSL) is the language of Style Sheets



bar.xsl

art.xsl

The Power of Style Sheets

table.xsl



nokia.xslsony.xsl

ie5.xslie4.xsl

nav3.xsl

edi_x.xslsap_y.xslflat_z.xsl

Use the Same Data Multiple Ways



XML Processing

WebBrowser

Other(e.g. Directly into

Application)

XMLData

Source

XSL Style Sheet

XS

LP

roc

ess

or

XM

LP

ars

er

DTD



Section 3Current Organizational Developments

Why use XML for E-Commerce?:

• XML bridges the gap between traditional EDI and Web-based applications.

• Most of high-tech industry has espoused XML:

– Virtually all new software from Microsoft, GE Global eXchange Services, Netscape, IBM, and others are going to be enabled to use XML.

• XML could make EC/EDI more available to the SME and other non-traditional EDI users.

Many approaches are under development:Many approaches are under development:



Sampling of Current Initiatives

• XML/EDI• Open Applications Group Integration Specification (OAGIS)• Collaborative Planning Forecasting and Replenishment• Open Trading Protocol (OTP)• Open Financial Exchange (OFX)• Commerce Interchange Pipeline (CIP)• SAP’s BAPIs• IE and Netscape browsers• MS-Office• DLA Emall• Extensible Forms Description Language (XFDL)• Common Business Language (CBL)• Web Interface Definition Language (WIDL)• Bank Internet Payment System (BIPS)• XML Metadata Interchange (XMI)• Simple Workflow Access Protocol (SWAP)• Information Content & Exchange (ICE)• Interactive Electronic Technical Manuals (IETM)• Standard Exchange for Product (STEP)• Organization for the Advancement of Structured Information• etc., etc., etc...



ebXML

The ebXML Approach

• Adopt existing specifications where appropriate

• Utilize what worked in EDI

• Understand the underlying reason for failure in EDI

• Bridge needs for application-to-application versus application-to-human

• The approach supported by ANSI ASC X12

ebXML



Section 4The Stuff for the “Grey Hairs”

XML and EDIWhere will XML fit in B2B EC?

How will XML and EDI interact?



XML-EDI Visualized

< XML >+

EDISyntax and Standards



XML and B2B

What XML does for B2B:

• Format for data interchange

• Standard protocols for trading communities

– CXML: Ariba

– RosettaNet

What XML can’t do for B2B:

• Integration with enterprise resources

• Business rules



Internet

XML-enabledApplication

XML-enabledApplication

Non-XMLApplication

Non-XMLApplication

DatabaseDatabase

XMLEAI or Enterprise

Middleware

EAI or EnterpriseMiddleware

????

XML Infrastructures

What XML Doesn’t Provide

• Integration

• Translation

• Business rules

• Management



Where XML Might fit

Enterprise ApplicationIntegration (EAI):• Apps within Enterprise

Application Server:• Browsers over Internet

XML IntegrationServer:• B2B over Internet



Section 5Observations for the EDI

Professional

What does all this mean to the EDI Professional?

Is EDI Dead?



XML Utopia

• XML proponents think they’re going to dramatically reduce the expense and time-to-market factors associated with EDI.

• Also, the “XML vision” sometimes goes far beyond “B2B” to include revolutionizing the way all electronic process interfaces are done.

• The XML “Utopia to Come”…

• Faster

• Cheaper

• Better



TANSTAAFL

• “There Ain’t No Such Thing As A Free Lunch”.

• XML document standards aren’t shaken out yet.

• And for quite awhile you’ll still have your existing non-XML-speaking back-end systems.

• Most applications won’t speak XML natively for quite awhile. Too many rapidly evolving “standards” for one thing.

• So the XML analogs of “translators and gateways” will be used (although not named that, too “EDI-ish”.)



TANSTAAFL

• So in addition to “EDI experts and specialized translation software” you’ll also need “XML experts and specialized translation software”.

• A significantly different technology with non-trivial learning curve.

• XML by itself is pretty simple, but things like “XSLT”, “XML Namespaces”, and “XML Schema” are non-trivial.

• But XML and ancillary technologies will fast become a fundamental universal data-processing skill, rather than an esoteric specialized skill like EDI.



TANSTAAFL

• And for awhile you will still have to interface between an XML “translator” and the back-end systems, just as with EDI.

• Bolting XML on the front will not change your existing back-end.

• XML helps at “lower layers” of the protocol stack, not at “higher layers”.

Back-end integration will still be the major challenge!

Back-end integration will still be the major challenge!



So Why Bother?

• However, your new XML environment will still be significantly “faster, cheaper, better” for the tasks it is given (once you’re over the learning curve!) and will increasingly make your business more competitive.

• More applications will be able to speak XML natively “out of the box”, especially as standards solidify, thus further improving XML’s cost/benefit ratio.

• “Plug-and-play” standards (e.g., RosettaNet) will have big payback if they in fact meet business needs as planned.



Whither EDI?

• EDI will stay relatively undisturbed for quite awhile.

• EDI does what it was designed to do and does it reliably.

• No need to disturb existing huge investment in technology, custom-developed software (“maps”), and staff expertise.

• B2B via XML will start penetrating areas that EDI has not touched due to EDI cost/benefit ratio.

• Large enterprises will be compelled by the need to compete in “Internet time” and to achieve new functionality.

• SME’s will be able to play cost-effectively in B2B as turn-key solutions arise (more likely/doable in XML).



Whither EDI?

• Eventually B2B via XML will start encroaching on EDI.

• But only after XML is much better established.

• XML cost factors, time-to-market factors, and functionality will gradually dictate “XML” rather than “EDI” for new/updated TP relationships in traditional EDI roles.

• An evolution, rather than a revolution.

• And much of EDI’s sophisticated business semantics may be merely transferred into the XML world.

XML - It’s just like EDI, only different.XML - It’s just like EDI, only different.



Whither EDI?

• What about EDI professionals?

• Again “it’s just like EDI, only different.” It’s “faster, cheaper, better” only at the lower techie levels.

• It’s a very natural thing to have the EDI group absorb “B2B via XML” along with existing EDI.

• “Just” ramp up on XML-specific skills and all other skills (business knowledge, analytical skills, project management, ability to interact with business folk and implement what they need) still apply as before.

Is EDI dead? To paraphrase Mark Twain:Rumors of my death have been greatly exaggerated!

Is EDI dead? To paraphrase Mark Twain:Rumors of my death have been greatly exaggerated!



Thank Thank youyou

who said you can’t teach an old dog new tricks. (or bill’s view of the wonderful world of xml)

Documents