XML and EDI
Peat
peat at erols.com
Wed Jun 4 23:20:48 BST 1997
I wanted to share this with you. It is from David Weber posted early May on
the EDI-L mailing list.
- Bruce Peat
----------------------------------------------------------------------------
------------------
BOO!!! ARE WE ALL HISTORY???
This message is in two parts, in the first part I argue why DISA is about
to
become history, hit by a truck marked 'Microsoft - Internet EC', just
another piece of road kill along the path of computing history. Therefore
we should just switch tacks and pack our bags and figure out how to go and
build EC based systems.
In the second part I argue the opposite and introduce my vision of a 4 Tier
EDI that can become an active part of EC, and migrate from traditional EDI
to the new EC model and retain a role for DISA as a facilitator of future
commerce.
OK - first lets look at some recent press from the 10th DISA conference:
>>>>>> "EDI Expansion"
"The EDI industry is currently growing at over 40 percent
annually," says Harvey Seegers, president and chief operating officer
of Rockville, Md.-based GE Information Services. Seegers is a keynote
speaker at the conference.
Seegers' message is "EDI has a future -- particularly if it
embraces Internet technology -- to extend its capabilities." An
important component of a successful future for EDI is Web technologies
such as TCP/IP, which enable data to be moved across diverse computing
environments: from desktops to mainframes, from Windows to UNIX.
Browser interfaces are another innovation that can breathe new life
into EDI by giving the Internet "a much friendlier interface to EDI,"
Seegers says.
Other industry leaders are seeing examples of EDI growth as well.
For instance, Stamford, Conn.-based Frontec is growing at a rate
of 40 percent annually, says Peter Stiles, Frontec's senior vice
president of consulting, whose presentation at EC/EDI `97 is about
using EDI in transportation planning and supply chain management.
Wilton, Conn.-based APL Group reports "a tremendous" growth spurt
in the past six months, especially in its consulting business. A
software and services provider, APL specializes in personal computer-
based EDI translation software and is preparing to move into offering
Internet and Web-based EDI systems. APL is one of the exhibitors at
the DISA show, where it plans to announce a new electronic commerce
initiative with Washington-based telecommunications giant, MCI.
<<<<<<
Wake up and smell the Roses! This says to me that all the big players
couldn't give a fig about old EDI. New EC based stuff is going to use
HTML, CGI and even more importantly the upcoming XML, extendable
next generation HTML, along with perhaps some Java objects to exchange
business data, business facts, and processes.
(XML - eXtenible Markup Language :
http://www.gca.org/conf/xml/xml_what.htm)
This will make DISA style traditional EDI obsolete within a year.
Especially as the delivery mechanism between trading partners now
becomes an NT box running a Web Server and a hook to your friendly
local ISP for $20 a month. Add in Microsofts 'Normandy' MCIS product
and now you can click, drag-drop out of Access or VB into your Web
Browser and your data is delivered. Total integration of MS Office
and the backend delivery channels. (Full details at www.microsoft.com,
search on MCIS).
XML provides the glue to allow the receiving system to successfully
interpret
the received information and store it in the correct places in their
own databases.
Cross-platform is a snap, since if you need to go to a mainframe, the Web
server gives you that easily. You can pass the data to a COBOL or CICS
process over on the big iron top do final updates.
Also - you can query in real time. Your Web page can send an Account # to
a remote Web Server for validation, before continuing the data entry
process off your local Web Server with the end user. Totally seamless.
Where does traditional EDI fit into this picture? It DOES NOT! It just
gets in the way. It's faster to put a Web page and some HTML together
to capture the information that you need, and get people to interface that
way EVEN if they are using a BATCH process to generate HTML from their
database, instead of an expensive translate into EDI format.
So, OK, there is message overhead this way, but who cares? Bandwidth
is cheap these days. When EDI was first done 2400 bps was state of the
art.
Now ISDN costs less than 2400 did 10 years ago. 115200 bps can take alot of
HTML overhead.
Better still even new programmers straight out of college know HTML
inside and out and there are great GUI tools for slapping fields onto
forms and creating the programs to drive them so easily.
Plus, when you send someone your sample HTML form they can bring it up
in their FREE browser and understand it instantly. (Try that with
your proprietary format EDI Implementation Guideline and EDI message format
that
only works with the EDI tool you have purchased).
OK - so lets read some more news - smell some more Roses ->
>>>>>>>>>>" Like many companies, Mobil Corp. was tantalized by the idea
of using electronic data interchange to swap information with business
partners. But because of the pitfalls--high costs, burdensome software
maintenance and lack of real-time information--Mobil is eschewing
traditional hard-wired EDI and using an intranet for electronic commerce
in what analysts call a "leading-edge approach" to an area of EDI that's
now under intense scrutiny. After a successful pilot, Mobil this month
began rolling out the new system to its more than 300 lube distributors,
the independent businesspeople who handle Mobil's "heavy
products"--packaged or bulk industrial oils and greases. The intranet
integrates Mobil's mainframe data with an Oracle Corp. database that
holds product information.
<<<<<<<<<<<
Can I call them or what? There's more:
>>>>>>>>>>>
Previously, Mobil had implemented two different EDI systems--one
DOS-based and the other Windows-based--that transmitted business
documents over a VAN (value-added network). Mobil encountered many of
the problems that have stymied the growth of EDI. VAN charges for using
the hard-wired networks topped $100,000 a year. Maintenance was
burdensome: Every time Mobil changed a business rule, new software had
to be sent to each dealer and installed on their desktops. Inventory
information was updated only once a week.
Because of this, dealers communicated with Mobil through a hodgepodge
of EDI, phone calls and faxes: a system of redundant data input that led
to many time-consuming errors. Mobil began looking for a new system when
its lube group made improving communications with dealers a top
priority. The Internet was an obvious solution.
An intranet approach for EDI didn't require a hard-wired network, so
VAN charges disappeared. When business rules are altered, Mobil only has
to make changes once, test the new rules and put them on the
server--they become immediately available. "Our customer support people
are excited because distributors can look up the information and make
the transaction electronically, so the support people's phones won't be
ringing off the hook with questions," said Hawkins.
Mobil's business rules are embedded in the system's Java applets. The
system immediately alerts a distributor if he or she is entering an
incorrect order--say, asking for a product in an unavailable package
size or making an order that is too large for a truck shipment.
<<<<<<<<<<<<<<<
Just what I've been saying. This last piece is key. The Java is the
transport layer that links business rules and data handling into the
whole. OK, but the NAY sayers can still point to some holes "
>>>>>>>>>>>>>
"Mobil's approach is a leading-edge way to do this kind of
application," agreed Rick Drummond, a consultant in Forth Worth, Texas,
who has been helping develop security standards for EDI over the
Internet. Yet he still has reservations. Said Drummond: "The impact
outside this limited application is pretty low because it's not clear if
it's dealing with the interoperative issues" raised by EDI systems that
are not as closed as Mobil's.
<<<<<<<<<<<<<<<<<
Yep, but guess what, this is just a matter of time, NOT technology. XML
is with us, and it will provide that missing piece, along with use
of Java, to be able to link components of one system to another.
So - I can embed rules in XML or Java into my LOCAL data processing
system, and have Mobil et al send me those when they update them.
Thus allowing this thing to move to the next level in a way that
EDI was never able to.
In fact it gets even worse. The new XML provides all that missing Object
Orientated
transport layer that DISA has been haggling over, built right into your
Web Browser and Web server. (As an aside DCOM and or CORBA? Who cares?
As an end user, there is no need to worry about such MIDDLEWARE issues,
since the browser companies will always have to provide a layer that can
transport your objects at the Web server end. DCOM, CORBA? You never see
this! Your
JAVA or XML toolkit and execution environment handle all this 'bits and
bytes' stuff).
Microsoft and Netscape have had to address these issues for their new V4
browsers, not because of EC or EDI but for distributed programming
and client/server deployment reasons.
Just so happens they nailed the EC and EDI side too.
So where does DISA fit into this model? It does not! If I'm Mobil
and I'm implementing the next application, I just create my HTML,
XML, Java and do it. Then my trading partners collect those components
off my Web server and use them to exchange the information we need.
I can even generate all this stuff straight off the SQL database
definitions I already have loaded up in my CASE tools and database
dictionaries.
DISA, who him??
==========================================================================
The Second Part of this story: 4 Tier EDI to the Rescue!
>From DISA's 10th conference I see alot of haggling over who is right.
(Kind a like Nero fiddling while Rome burns around them?)
Let's roll the video tape: >>>>>>>>>>>>>
Modelling a Better EDI
Many in the EDI standards community hope the creation of a new
type of EDI standard will open up big new markets for the standardized
technology among the nation's estimated 4 million small and medium-
sized businesses. The new EDI would have to be simple to implement at
little cost. An important aspect of that future EDI standard will be
that it must also maintain backwards compatibility with the existing
versions of EDI standards, including the standards of ASC X12 and the
United Nations.
Standards discussions at the DISA show include one by Klaus-
Deiter Naujok, standards manager at Concord, Calif.-based Premenos
Corp. His subject is Object Oriented EDI, a new proposal for future
EDI developed under the auspices of the United Nations EDIFACT's
CEFACT. The proposal, made public for the first time at the
conference, makes use of object-oriented techniques to model business
scenarios into business objects.
Naujok says object-oriented modeling holds the possibility of
making EDI easier to use and less costly.
More Than One Way
Dan Codman, co-founder of the Wilton, Conn.-based APL Group and
chairman of X12C, the communications and controls subcommittee of ASC
X12, says he is not confident object-oriented techniques are relevant
to EDI standards. However, ASC X12's Strategic Implementation Task
Group, formed to represent U.S. positions on EDI to the CEFACT, will
look at modeling techniques to aid the development of a new EDI
standard. It will have to be able to be used around the world,
cheaply implemented, and understood by anyone who uses it, Codman
says.
David Files, the leader of ASC X12's Business Information
Modeling Group, says Object Oriented EDI fails to address the needs of
large companies doing high-volume EDI. Such companies, the majority
of those already EDI-enabled, will find that OOEDI is less efficient
for large volumes, he warns.
Estimates put EDI usage in the United States at only 5 percent of
the potential. Reaching the hundreds of thousands of small and mid-
sized companies not yet doing EDI is a crucial factor in future
growth, industry experts say, and a new EDI model is one of the key
linchpins in that endeavor. And, of course, different alternatives
will benefit different segments of the industry.
<<<<<<<<<<<<<<<<
So we have at least three camps! Well, what if all three can live
together under the one roof? And the fourth 'grizzly bear' called
Internet EC can also be made a player too?
Enter 4 Tier EDI. Here's a picture of this, and here's how it works.
Layer 1 - Traditional EDI |
------------------------------- |
Layer 2 - Rule Based EDI/EC |
------------------------------- |
Layer 3 - Process Based EDI |
------------------------------- |
Layer 4 - Object Based EDI |
------------------------------- V
Now, what this means is that your total EDI message can consist of
some or all of these components AS YOUR BUSINESS NEEDS require.
Layer 2 is absolutely the KEY LAYER. (Layer 3 and Layer 4 are
in fact implemented and done with the tools in Layer 2).
Layer 2 supports both XML and Java as the means to define
your complete EDI message, including the data.
You can either embed an EDI message itself using the
standard HTML comment token, i.e. :
<BODY>
<P> This is just some text </P>
<BR>
<! Here comes my EDI message /!>
<!
ST*323*712990413
V1*7039610*NEW ZEALAND QUEEN*D*104N*SCAC***L
LS*0100
R4*D*D*JAX*JACKSONVILLE FL****
V9*EAD**920819**JACKSONVILLE FL***A26
LE*0100
SE*25*712990413
/!>
</BODY>
Or, you can use the newer HTML/XML methods of identifying
data fields and their content within your business forms.
What is more, HTML already has a convenient 'Process' level mechanism -
the URL to the next, or previous linked form, and the POST/SEND
mechanism as a way of telling you where the message came from, plus
status information. XML of course allows you to roll your own more
extensive features. XML also allows you to transport binary
information, and is also fully multi-lingual compliant.
OK - so you get the picture. The ability to define your own
message sets, structure, rules, objects, whatever grabs your
fancy. And then send this to your nearest neighbour via
Web Server technology.
Also, LAYERS, so that if an Object Orientated approach is meaningless for
your business needs you DO NOT need to use it, or burden your
messaging with any overhead or complexity associated with OO needs.
By defining Layers 3 and 4 using Layer 2, you allow people to choose to
what
level they wish to use each messaging component.
So - how does DISA get into the middle of all this?
Two ways. First XML is a virgin territory, therefore DISA
can step in and define XML components and standards for
enclosing EDI fields, and mapping Traditional EDI to XML/HTML.
Then DISA can define process components in XML that facilitate EDI, that
for example an applet or object called: date_format(), or
entity_characteristics(), and so on, that reference the existing EDI
data entity rules that have been loving crafted over the last twenty
years.
This means DISA can publish a CDROM of XML/Java components that
describe and reference existing EDI entities. This will make
everyones life easier, and speed implementation of EC.
How? Because right now, programmers are using Sun's Java library as the
next best thing, plus whatever they can grab off the Java/JavaScript
language sites of 'canned' code. I.e. I need to check two dates are
valid in my Web form, and so I hook in either an Applet, or JavaScript
module that does this, pass the applets dates as parameters, and presto,
my dates are OK. Well, instead, on the CDROM is a nice set of routines
called Java_valid_EDI_date(), and XML_valid_EDI_date(), that do this for
me, but now I know my dates are also fully EDI compliant. And so on.
Tool vendors can build plug-ins to Web Browsers that automatically
associate these kinds of properties to EDI compliant fields.
Also the Web Servers provide services such as Transaction Logging (alot
of them can do that now) and of course message routing to different
backend servers based off content and addressing, security, database
interfacing. In short everything one would expect from a mature
communications server platform.
The second piece is then obvious for DISA. Having stepped into the
middle of the EC process by extending XML, and migrating EDI standards
over to this transport layer, DISA then has an on going role. Providing
both support for this, and also maintaining products such as the
Universal Entity Dictionary, and also defining new methods, processes,
and objects that are specific to EDI for use with XML/Java.
OK, I hope this is fairly clear. 4 Tier EDI, founded on merging EDI
formatting and transport methods with EC Web based methods, where DISA
provides the lead in this, and then maintains the standards and
certifies vendors products as being compliant, et al. A migration to
Web EC based messaging standards as the foundation for future EDI.
Understandably there is a section of the existing DISA membership that
has to be resistant to this, because their entrenched commercial position
is exposed to newer Web vendors and a completely different business
and trading model.
A brief consideration of the alternatives however should bring everyone
into focus. This is not really a choice! If Microsoft and Netscape
saw a role for DISA in the future of EC they would already be very
active members of this forum.
As they are NOT, I can only conclude that DISA needs to quickly make
itself part of the mainstream EC agenda, before it vanishes into the
mists of time.
Otherwise I foresee that Microsoft will shortly be hosting its on
Electronic Commerce Symposium for EC Business Partners, and signing
up vendors to support its MMSP (Microsoft Messaging Standards Protocol)
that it built-in to the Microsoft Web Server engines and Browsers.
Certainly one EDI stalwart has already made the move, two months ago
"EDI World" magazine was renamed "Electronic Commerce International".
=========================================================================
David Webber.
p.s. ---------- I shall also be cross posting this to EDI-L, as the
broader issues
fall into their bag.
p.p.s. -------
Just went up on the Microsoft Site to verify some details.
Their product is MICS, now (changed from MCIS), and they have a 570K
White Paper you can download. Microsoft Internet Commerce Server.
One paragraph in it says "but this does not mean the end of traditional
EDI".
Yeah, right, one paragraph in 570k, and no mention of why not, or how to
link the two! Excuse me for not believing that for one second, and for
believing that really
Microsoft is now setting the agenda.
The URL is : http://www.microsoft.com/commerce/whitepaper.htm
David Webber.
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)
More information about the Xml-dev
mailing list