The Power of Five:
XML itself provides the
foundation. The Web was born on the abilities of the
HTML language, itself a very limited subset of the
original and highly complex SGML document syntax. Now
XML has been created that sits between the two, not
as complex as SGML, but vastly more capable than
HTML. XML tokens and frameworks are the syntax that
transports the other components across the network.
XML tokens replace or supplement existing EDI segment
identifiers. XML also brings with it all the rich
capabilities and transport layers of the Web and the
Internet in general.
EDI is the grandfather of the
electronic commerce. The ability to express data in a
simple format and send it to someone else so they can
interpret the information they have just received.
XML/EDI provides 100% backward compatibility to
existing EDI transactions, while moving EDI forward
to the next generation. This means we do not have to
discard the investment in existing EDI systems and
knowledge.
Templates, these Rules provide the
glue that holds the whole process together. Without
them you cannot express in the XML alone all the
details of the work that needs to be done. Templates
are referenced or travel along inside the XML as a
special section and set of tokens, and can be easily
read and interpreted, they look rather like a
spreadsheet in layout and content and they are
supplemented by what XML calls Document Type
Definitions (DTD's). DTDs enable
transaction interoperability, rules enable processing
(which may include presentation) of transactions.
DTDs let two organizations understand each other's
data. Rules define what happens to that data.
Agents, both interpret the Templates
to perform the work needed, and also interact with
the transaction and the user to create new templates
for each new specific task, or look up and attach the
right template for existing jobs. They also can
reference DTD's to determine display characteristics
for forms. This is where Java and ActiveX fit in.
Right now they provide the best medium for creating
Agents, and of course, XML structure containing these
pieces can be referenced or transported to wherever
they are required. Initially these agents will be
simply driven by the Templates, with
additional capabilities anticipated to follow later.
Repository - Shared Internet
Dictionaries are already in use by hybrids of
traditional EDI systems such as the BSI which uses a
dictionary that allows users to manually look up the
meaning and definition of EDI elements. The Shared
Internet Dictionary concept takes this to the
next level, and provides automatic lookups rather
like the more advanced Internet search engines now
do. This component provides the semantic foundation
for business transactions and the underpinning that
the software Agents need to correctly
cross-reference entities. (This concept is also
referred to as "repositories" in this
article, and includes adding DTD's to the repository
as well).
Combining these components together provides a system
that delivers information, not just data, and the
processing logic that is required.
What will XML/EDI do?
XML/EDI provides four core models of use. These
include traditional EDI deployment methods, along with
new document-centric capabilities. Figure 2 shows
at a glance the four core models. Further in the document
we discuss some example interactions.
Figure 2 XML/EDI Transaction Models
The next section discusses frameworks that enable
these models. The "star" model shown is the
classic EDI model, where a major business partner or
organization sets the standards for its trading partners.
The "ad hoc" model is the new net-based model.
Smaller trading partners setup their own ad hoc
interactions, these in time may evolve into more formal
methods, or they may not. The "hybrid" model is
a combination of the first two. Here a "Star"
model is extended by trading partners, by creating new
versions of frameworks, and by linking in their own ad
hoc ones. The "Web" model is a document-centric
model. Where content is the most important information
being exchanged. Content can either arrive driven by
pre-set rules, or be requested, or be broadcast. The
classic example for this is an electronic catalog, and
the associated "Request For Quotations" (RFQ)
dialogs.
Why a framework?
XML/EDI provides for the infrastructure of a wide
variety of EC systems; from searchable on-line catalogs
to robust machine-to-machine transaction subsystems. The
XML/EDI initiative is to provide open solutions for
implementing E-business systems today. The operative word
here is "solutions". There isn't just one
solution for all of the E-business scenarios. Each
scenario has its own requirements and goals. This is why
we need a framework and not an application or module.
The goal of the framework is to provide formal
interfaces for commercial EC components to interoperate.
For XML/EDI to be successful these interfaces will be
open and yet standardized. The business model is either
of ad hoc interactions between small groups, or agreed
upon national or international frameworks, such as those
by trade associations or industry bodies.
Figure 3 - XML/EDI Layered
Architecture
Figure 3 depicts the technical layers that a
base XML/EDI system can be built. Not all layers are
required to achieve results with XML/EDI. The framework
builds upon and enhances the XML and EDI standards and
defines the blueprint of EC component interaction. For
example, catalog vendors may only want to implement the
XML tagging. The tags are defined in "standard"
repositories. The various layers support different
targeted EC systems. Overall each successive layer
provides increasingly more sophisticated capabilities so
as to handle more demanding needs.
The framework is not a "all-or-nothing" nothing
implementation. Each EC component is designed to be able
to be used independently -- interfacing with each other
as defined by XML/EDI standards. You can create a DTD for
formally define the strucuture of EDI messages without
having to use it to validate well-formed XML documents.
You can simply place EDIFACT/X12 messages in an XML shell
element or you can code the message, or parts of it, in
XML. You can chose to formally validate messages, or
simply check that they are well-formed XML. You can link
your messages to data stored elsewhere, or have it all
stored intermally. You can link your documents to
rule-templates, or have in-built (or no) rules for
processing the data you receive. Its up to you how you
mix and match the options.
End Users interact with these technical layers through
highly visual desktop tools. Developers use EC components
to build these tools. Users interface with their
documents as they would use any tool in their office
support products - word-processing, spreadsheets,
databases or whatever metaphor is most suited to the
application.
What makes XML/EDI different?
The main difference with XML/EDI and other mechanisms
is that a system can encode the document's information
much more precisely and in a very rich structure than was
previously possible with earlier formats. Through
the use of XML tags and DTD's, XML/EDI transaction are
self-describing--applications processing XML/EDI
documents can "understand" a transaction with
access only to the content of the transaction.
There are several reasons why we anticipate XML/EDI to
be the technology of the future. Some of the reasons are
listed below -
XML/EDI...
- is built on open standards
- provides for self-describing
transactions (XML)
- allows tool vendors to build on existing products
- tools include workflow and document management
functions as well as EDI "mappers"
- interfaces with legacy systems very well
- framework uses an evolving best of breed
philosophy - i.e. dynamic shared dictionaries
- will allow for object-based documents - data
& rules reside together
- provides the organization the path to move down
to a document-centric environment
- enabling more flexible business
models (Rules/Agents)
- cheaper and easier to implement
- access to a greater number of
trading partners (see
previous bullet)
- and most importantly: access to
"interactive" transactions enabled by
the web rather than being limited to
"system" or "batch"
transactions.
Another aspect of XML/EDI which needs to be mentioned
-- only a few times in computing history has the
attention to the collective technologies and their
potential solution to solving today's business problems
been so focused - there is excitement in the air and a
sense of the achievable.
Document-centric environment?
The world has changed from thirty years ago, and now
requires a dynamic and vibrant tool that matches the
organized yet ad hoc nature presented by both modern
business practice and its manifestations in the Internet
itself. The Internet is re-writing the rules on how
people interact, buy and sell, and exchange goods and
services.
Today we see document-based management systems
integrating with relational database management systems
(RDBMS). If we look at the various offerings with
"universal servers"; Oracle, DB2, Informix and
"message stores" such as Notes and MS-Exchange
these give us our roadmaps for predicting the possible
types of business computing systems. These systems
are/will combine fielded data with full text-based
subsystems - database systems and document-centric tools
are supplementing each other and providing to the end
users new paradigms for working with documents.
This integration of data-centric and document-centric
tools is coming together for larger audiences than that
of XML/EDI. For example, it is rumored that Microsoft is
considering using XML as Exchange's native file format to
speed access to/from the message store. This step is
needed if Exchange is to be able to handle 5 million
users on a clustered NT environment, 2 or 3 years from
now. By building upon these types of XML mechanisms,
XML/EDI can leverage these tools, such as workflow,
cataloging, routing and searching. For XML/EDI, it is
often referred to as, "all this stuff comes
free" or "all part of the evolving XML
technology".
If our assumption is true, applications will evolve to
using the built-in browser functions as their front-ends.
Developers won't be writing individual screens to view
transactions, i.e. an invoice or patient record, but
instead use the integrated browser which will
"know" how to adapt for the transaction. The
document-centric tools will be entering the workplace
more and more, XML/EDI just builds on and leverages these
tools.
XML/EDI documents will serve as a structure that
contains data, and will include instructions on how the
transaction should be processed or displayed. Based on
user defined rules the document will be routed in its own
workflow process, triggering events on its own. In the
simple case, the document will be able to find the
application (or user) by using the search, classifying,
and routing mechanisms, instead of the applications (or
user) having to find it. The document will have
transaction status self-contained for applications (or
users) to set/interrogate and will know it is one in a
set of linked set of documents used in the workflow.
Now lets us pose the question again... What if you had
the tools to process the transaction as a document? This
is the powerful concept behind the "universal
servers" of today, combining the strength of the
RDBMS with document management. With a variation on the
tools today; i.e. SGML, EDI mappers, we can leverage this
technology to store, search, and manipulate our
documents. We can use document-centric tools to
complement those tools EDI administrators have today (RDBMS).
Isn't XML used only for Web-based
documents?
No. The first acceptance of XML is already taking
place for the Internet, and for a wide range of Intranet
applications that are dependent upon the Browser. But as
these applications develop they will feed the tools
required for the use of XML/EDI . XML/EDI is not tied to
the browser, client based model. XML/EDI delivers true
server based batch processing as well. And of course via
any transport method -- an XML/EDI document can be
exchanged by floppy, LAN, WAN, dial-up modem, Internet,
etc.
Where
is the value-add of XML/EDI?
One of the XML/EDI objectives is to makes the transfer
of documents between organizations as easy as possible to
the point that it is transparent to the user. This will
allow for workflow or "pipelines" to extend
across organizations. As a subset, this includes software
agents to reach out on to the Internet to read from and
"make sense" of online catalogs. The workflow
of documents should be able to route to a trading partner
as easily as a colleague down the hall. This transparency
is achievable with XML/EDI.
What studies have shown is that only a few companies
who have implemented EDI have leveraged all of the
benefits that are provided when automating the data
interchange process. Most companies use EDI only as a
transport mechanism to send fixed structured data from
and to trading partners. Some organizations even re-key
the received EDI data into their other systems!
EDI usually is imposed upon corporations by their
partners, and EDI is seen only as a task to keep their
customer base happy. Very few corporations begin to get
involved with EDI by saying, "EDI is a good thing
and think I will save my company money, by cutting
processing costs." EDI usually happens in a company
because of a partner has dictated its use, so no wonder
EDI is left at the organization's doorstep.
The difference between the above EDI efforts of the
past and XML/EDI is primarily due to changes in the
workplace. These changes will help with integrating data
and processes between organizations. The time will come
when users of XML documents will expect their systems to
be able to transparently pass on a transaction to a
trading partner as easily as just printing it. The short
of it, with XML/EDI the transaction does not stop at the
gates of the organization, but extends into an
organization enabling all facets.
Using
XML structures for XML/EDI?
An EDI application for XML provides the structural
complexity that supports and parallels today's EDI
transaction sets. XML provides a rich document structure
that can be nested to any level of complexity. With XML,
our documents are like chameleons, capable of being
processed by different components, delivered by different
mechanisms, and displayed to the user in different ways.
By using the XML extensible tag set, EDI
"objects" can be either passed or dynamically
reference to objects stored in repositories. The XML/EDI
Group is proposing the use of XML as a
"carrier" for the document information so that
the transaction can carry not only data (like trad-edi),
but also code (at each level in the transaction tree).
With an element having data properties and code methods,
this allows the business elements to be manipulated as
"objects". [Note: object inheritance is slated
to be incorporated in a later version of XML]. In XML,
each document is an object and each element of the
document is an object.
The logical structure of the document and tag set can
be specified in a Document Type Definition or DTD. (The
best-known example of a DTD is HTML, which is defined by
a DTD describing the structure of HTML documents.) In a
DTD, sets of elements and their attributes are defined;
the names that are used as tags are assigned; and the
element relationships or transaction is defined. If a DTD
is used then programs can validate the transaction's
structure. You can validate the structure of an XML/EDI
document automatically. If this sounds complex, it is
not. Defining your own markup language (DTD) with XML is
actually surprisingly simple.
Most workflow systems today; such as Lotus Notes,
cannot even begin to store adequately an X12 or EDIFACT
transactions as a relational view. Today these systems
need to "flatten" out the database or to
explain it a different way. Typical workflow documents
can only store a single one-dimensional view of the
transaction. XML/EDI structure will allow products like
Notes the ability to store and process EDI transactions
in a relational manner.
Once defined, rules can be applied to the objects in
the transaction. We will get to this later.
Dynamically referenced objects?
An important note: the data and code do not
have to reside in the same transaction! How can this be?
The code and data can be externally referenced - via
links to dynamic reference(s), i.e. URLs. XML links can
be between two or more resources, and resources can be
either files (and not necessarily XML or HTML files) or
elements in files. Links can be between more than one
resource, they can be specified outside the actual
documents themselves and the linked-to element inside a
resource. The link can be specified in very powerful
ways. The element can be identified with an attribute, a
position in the element structure, or one can even
specify that the link goes to things like the "ship
to" address for the third item in a purchase order.
This XML-Link makes XML/EDI very flexible.
The "standards" or dictionaries are stored
in a repository(s) for dynamic reference. No more
shoe-horning data into improper codes or wild use of ZZ
(codes not found in the dictionary) -- just add the new
code and its meaning to the repository! XML/EDI framework
describes the use of the repositories; interface and
replication. XML is a language, the repositories allow
for common EC definitions among organizations in a
dynamic fashion -- the repositories provide us with a
richer language.
How
are rules applied to objects?
The answer lies in the Document Object
Model (DOM) as defined by the W3C DOM Workinggroup.
(Note: Microsoft recently has introduced DOM or Dynamic
HTML into IE 4.0). The Document Object Model makes
it possible to address all the elements of an HTML
document. In effect, each element is a programmable
object. By using the Document Object Model, XML/EDI
documents are able to combine the content, the rules that
controls the transaction, and the view in one
file/transaction. XAPI-J provides the standards for Java
components to address and navigate the objects in the DOM
tree. These objects are our business objects as defined
in the DTD. At the user level, rules are graphically
presented very much like setting up the
"assistant" templates in your E-Mail program
where you move messages from one folder to another
depending on the "Sender" or
"Subject" message.
Software Agents Explained
In this section we answer the question "isn't
software agents all research and academia with no real
products?".
First one must appreciate that there are a range of
software agents. The term encompasses from the very
simple to the very complex. In the initial XML/EDI
framework described here, the use of agents is either
simple, or using already proven agent methods and
technologies. Some examples will illustrate the points
here. One agent component is required to provide access
to users existing databases, or create databases if
directed. Java already has these capabilities in the JDBC
database component, and also the Microsoft ODBC
equivalent. So an agent merely includes these existing
capabilities. Another agent may simply provide the
ability to help the end user initially configure a
particular component when it is first used. This is the
familiar "Wizard" style prompting agent that
has a simple set of rules and user queries that it
processes and creates a set of results.
In the long term also, the more sophisticated agents
will be running not at the client Web Browser but on
servers on the Internet. Components on the Web Browser
will then query these remote agents to obtain results. An
example of this is the Global Dictionary Lookup. A local
agent receives a type of EDI data segment that it has not
encountered before, therefore it will query the agent at
the server to classify it and send it back the results.
Another objection to using agents is centered around
the security risk. "These agents are Java based and
how do I know they are safe?". Obviously in any EDI
interaction, the trading partners must predefine who they
are allowing to interface with their system. They should
also be able to define who they will accept agents from.
This will add greater security, since obviously a rogue
agent introduced into a global network would be
propagated widely. These are issues however that are not
unique to XML/EDI, and so these are being solved in a
wider arena. XML/EDI however needs to ensure provisions
are designed into the system to take advantage of such
security methods.
Of course the benefit of using agents is to make the
system fault tolerant and also much easier to use. In
many cases agents will resolve problems without the user
being aware there was a problem in the first place. The
example of the Global Dictionary lookup just given being
one such case. Once the agent receives the information
about the newly encountered data segment, it is then able
to correctly process that new element. Perhaps the new
segment relates to a changed rule for processing an
existing segment. This existing segment value can now be
correctly validated using the new segment, and so on.
How
about searching and routing transactions?
XML/EDI will be able to use the many search tools that
will/are being adapted for XML. The infrastructure will
allow for the searching of business objects in addition
to keywords. The business objects in XML documents will
allow for more intelligent searching than with full-text
search engines today. There are already SGML query
languages that are similar to SQL in power. Expect these
to be integrated with relational database fielded
searching; ConText from Oracle and the Monarch project
from Microsoft using OLEDB. With standardized DTDs for
different applications one could retrieve information
much more accurately than today. The relationships in the
structures can be used as well as the objects themselves
in the query. The DTD allows for precision relational
searches of the XML/EDI documents either in your message
store, on the Web, i.e. catalogs, E-Mail subsystems, and
so forth.
Once searched, the transactions can be classified and
routed based on application-type information. Much work
has taken place and continues to take place in this area
of product development such as Intelliserv from Verity.
Routing and status information is stored in the document
itself. Routing can be as simple as vectoring a document
to a URL. This is how the Web works today -- we push and
pull HTML pages to and from servers on a click of a mouse
on the Send button. This means, we can have distributed
applications by simply using the infrastructure present
on the Internet today. This distributed architecture aids
us when mapping to legacy applications as discussed later
in this article. In addition, agent software has exploded
in parallel with the Internet. The XML/EDI framework
utilizes these agent components to make the user's task
simpler.
What
about displaying the transaction?
Now what was that about person-to-application, Web
technology? Oh, yes, as an added benefit, the leading
browsers will be supporting XML, allowing for the
documents/transactions to be viewed exactly the way the
user wants it, anyway they want it. If users want the
transaction to look like their paper form, it will.
Because the presentation can be stored in the document,
authors have full control of the view during page makeup.
Even better we don't have to create a template or form
to view the transaction. As the document passes from
department to department or trading partner to
department, it gets viewed appropriately - and
automatically. No need for endless man years of
programming effort maintaining templates for specific
transactions. An XML API with Java (XAPI-J) to be
supported by all XML processors (browsers and other
XML/EDI tools). This API will make it possible to have
Java applets that can be used to change the display of
XML/EDI-encoded information in Web browsers. The way the
transaction is viewed can be dynamic; simply setup by its
author once using a XML/EDI editor for the transaction.
Each node on the documents workflow or pipeline
redisplays the document as specified by the author.
There are other benefits to storing the structured
presentation with the structured data.
- aided by labels, searches are simpler
- archiving of the document becomes simpler
- page makeup while the document is being retrieved
from the message store becomes much simpler
- even reading and navigating the documents is
simpler
The overall result is that XML/EDI documents are
simpler to use. Even adding a "yellow sticky
note" to a document is no problem with XML/EDI.
Interfacing
to a legacy system?
or exchanging information
between disparate systems
Today, companies use EDI only to transport fixed data
from here to there; extracting the data out of their
database fields, formatting it, sending it, and then the
trading partner receives it, takes it apart and tries to
figure where to put it in their database fields. This is
a very common example of a legacy system. Let's say we
want to extract data from an application into our
workflow or we have just routed the document to the
application's URL, and now we need to export/import the
information from/into the application. We need to
translate our XML/EDI document out of/into our RDBMS.
What tools do we have with XML/EDI to assist with this?
Actually extracting the data to be sent is a somewhat
easier problem than deciphering upon receiving an inbound
transaction due to the fact that they are self
describing. Our rules based templates do just fine, and
aren't much different than that of today's mechanisms.
Because a DTD gives a standard format for information
related to a specific subject it can be used to simplify
the exchange of information between different sources.
Many kinds of applications have or will have standard
DTDs. This means that systems can use these common base
DTDs to exchange information with each other, regardless
of their internal format. Using DTDs in this manner is
one of the most important reasons why XML/EDI will enable
all organizations large, medium or small to exchange
data.
Where XML/EDI shines is with handling the harder
inbound documents, with traditional EDI the data is all
we get from our trading partners. Remember with XML/EDI
we get not only data, but any rules; application logic,
required by the system we are interfacing. The XML/EDI
advantage comes from the fact that we aren't just passing
data elements, but passing business objects. If we apply
these objects and their EC mechanisms to our translator
problem, we untie our hands from data only inferences,
allowing us to apply agent technology to assist in the
mapping challenge.
As mentioned above, with a distributed architecture
via the use of URLs, mapping can take place at the
various applications. This is in lieu of forcing the
centralized server approach. A distributed architecture
aids us when mapping to legacy applications because we
can take advantage of the knowledge stored within the
application. Validation, cross-reference look-up tables,
and most importantly application logic can be used during
the mapping process. Each user effectively becomes a
trading partner, sending and receiving transactions,
internal and external to the organization.
Example...
To understand the set of interactions here, let us
consider the simple example of two businesses each with
the need to send information to the other. Partner A
starts the XML/EDI software, selects the databases from
his business application, reviews the list of information
presented and chooses the data to be sent. The XML/EDI
software references the Global Dictionary, it looks for
an existing template with significant matching, and also
the occurrence of the same business elements in the
dictionary. Matches are found for the obvious items, such
as postal code and invoice date, but definitions are
taken from the database field formats for the remainder.
In this case no suitable template is found, the system
creates one that describes the information being sent,
including its record structures.
The system also creates an XML document, displays this
in a Web browser, and allows Partner A to both modify
this data view and select the information required to be
sent. Now the information is ready it is sent to Partner
B.
Partner B receives the information and she repeats the
process, this is the first time she has received this
template and data format, so the receiving XML/EDI
software queries for an action. It uses the incoming
template to help match the information to the receiving
databases of Partner B's business applications. Partner B
now reviews the data and matches it to the same locations
and items in the receiving databases. Agent software
guides this process by making the obvious matches for
her. The XML/EDI software agents now create a second
template and rules that correspond to this set of data
transformations. The Agent software is also able to
automatically resolve data structure transfers and create
the necessary data records in the receiving system.
Partner B reviews the received data in her Web Browser
and adjusts the view. Partner B can now use her template
to also extract information from her system and send it
back to Partner A. Partner A now has the original
template, and the new template to enable reversing the
process to receive this new information. Now in this
example we illustrated a simple transfer. Obviously Java
applets or ActiveX components can be exchanged to
calculate complex interactions and elements. An example
would be the interest payments on past due amounts, given
five fields, the amount owed, the date the payment was
due, and the date the amount was paid, and the amount
that was paid, and the interest rate.
One further note, in this example, the interaction was
driven through a Web browser interface. However once the
templates and formats are created, these can equally
easily be used in a batch style exchange. In this case a
batch process determines the data records to be sent at
that time, creates the XML/EDI documents and sends these
directly, either to a batch process at the receiving end,
or to a Web Browser interface, or even an E-Mail system
for delivery and onward processing. This begins to
illustrate the power and flexibility of the XML/EDI
system.
We have been searching for the ultimate solution for
exchanging information between disparate systems for many
years - to date XML/EDI comes closest to our ideal
solution.
XML/EDI for existing EDI.
One of the most powerful capabilities provided by the
Rule Template component of the XML/EDI "Power of
Five" is the ability to define templates that map
data to and from traditional EDI messages (such as X12,
EDIFACT, or HL7). This means that XML/EDI can seamlessly
interface with existing EDI systems and provide 100%
backward compatibility. The template contains the
structure of either the incoming or outgoing EDI message
formats, and this allows XML/EDI to exactly re-create
them without needing an external translation process.
Added to this is the ability of XML to define a
presentation definition in the DTD's and XML structure
that instructs the Web Browser how to display and edit
the data content (if this functionality is required).
Therefore an existing EDI message can be read in and the
details displayed to the user directly. This will
actually allow traditional EDI systems to reach out to
users they have hitherto been unable to reach because of
cost factors in deploying and maintaining traditional EDI
translator systems at remote sites.
XML/EDI for the Power Hungry?
Critics scorn at an increase in size of a transaction
due to the increase in tagging characters. A common
assertion is that XML/EDI sounds expensive in terms of
processing and bandwidth. The critics are correct, there
will be additional overhead in the size of a transaction.
The number of characters could be as high as 50% more
than a traditional EDI transaction today. We believe
bandwidth of the communications infrastructure is not a constraint for electronic
commerce today. The increase in tagging characters is a
small price to pay for the many benefits gained.
Consider a current EDI system where everything has
been hand tuned to minimize message size, and it is also
processing 200,000 messages a day. Surely this Web
XML/EDI based stuff cannot handle that with all of its
token overhead?
This is where one has to realize the flexibility of
the method. Certainly the preferred approach is to simply
add all the details and structure you need, because in
low volume Web interactions this is the best way.
Ensuring the receiver can fully process the information
passed.
However, because the template and XML structure
information are separate components, one can easily take
the opposite approach. Instead of using extensive
meaningful tokens, one can instead select two byte
descriptors as tokens that are machine readable only, and
send only the data section of the XML message. Now your
semantic overhead is comparable to traditional EDI.
The templates and Java applets are sent only once as a
separate exchange. Once they are invoked the templates
contain the logic to decode the cryptic tokens into the
full length versions, either by referencing the global
dictionary, or simply having the expansions within the
templates themselves. So hexadecimal
"" corresponds to "Last
Invoice Billing Date", and so on. Similarly you
could even compress the message content itself in line,
and then use a Java applet with the expand routine to
retrieve the actual data. This is XML/EDI for the power
hungry.
What is the existing alternative?
Compare using XML/EDI as described above with that of
your current processes. Even the simpler HTML Web
interface, which thousands of corporations are developing
today seems archaic when compared to the advantages
afforded XML/EDI.
To contrast the differences, an HTML form is either
created or dynamically generated with text, drop-down
edit fields, etc. to house information to be captured
from a user. Hard coded JavaScript or Java objects reside
on the page (not attached to a business object) and
responds to these generic events to provide validation.
Upon submission to a server via hard coded CGI, NSAPI,
ISAPI, or ASP (Active Server Pages) syntax these can then
be stored to a proprietary database or mapped onto an X12
or EDIFACT transaction set. And if the Web page is going
to an external company... no this article doesn't cover
the problems on the receiving end of a legacy system.
Suffice to say we have the same "mapping"
problem between companies. Does this HTML based approach
work for some applications? Yes, but very limited
compared to the options afforded with XML/EDI.
XML/EDI provides an extendible tool that requires less
physical coding to develop and deploy.
Summary
The framework is best summarized by stating the noting
the following:
XML/EDI in short...
- Self-describing transactions
- Enables more flexible business models
- Cheaper and easier to implement
- Access to a far wider number of trading partners
- Security, reliability, and robustness
- Interactive transactions enabled by the Web, not
just "system" or "batch"
transactions.
XML/EDI in detail...
- is based on industry standards
- allows for presentation, application logic, and
data to be contained in one document
- is an evolution rather than a revolutionary
approach, it builds on current Web technologies
and yet also interfaces with legacy EDI systems
- provides for common tagging for accurate
interpretation of documents
- is a unified structure for batch, interactive,
forms-based, and real-time exchanges
- allows for the use of document-centric tools in
addition to database facilities to manipulate,
store, search transactions
|