[
Lists Home |
Date Index |
Thread Index
]
Jens
In my, limited and rather narrow experience, I would have to say that XML,
even without standard api's parsers, and the raft of supporting technologies
that are emerging, has proved to be worthwhile.
I come from and EDI background, building loosely coupled, asynchronous,
message driven b-to-b applications, often between only relucantly consenting
parties. XML really doesn't let us do anything that we couldn't do before,
and believe me it is possible to use EDIFACT and ANSII X12 quite creatively
when you have to. However, EDI only comfortably covers the b-to-b piece of
the puzzle, whilst XML can be used to loosely couple applications within a
single enterprise too. So even if the messages have a different structure
and purpose, many of the same technologies and techniques can be applied
over and over again.
A company I used to work for built a set of tools that a business analyst
could use to create a rules based application, run over EDI (or
other)messages, implementing logic like: if order x from customer y arrives
before 15:00 hrs, indicate next day delivery in order response. By having a
message store, it allowed the analyst to create report templates, or
establish a historical context for business logic (e.g. if value of orders
for product x by customer y exceeds amount a over time-period t, offer
discount d). There was no way that the software tools were going to run
directly over EDI messages from multiple trading partners, and so in about
1994, after a lot of experimentation, they came up with a hierarchical,
tagged data structure that looks remarkably like XML (sans braces and
closing tags). All incoming messages (whether EDI or CSV, or whatever) were
mapped to the XML like structure, and all outgoing messages were mapped from
their XML like equivalents. In fact, even the business rules were expressed
as documents. Messages came in and out via the file system, sockets, HTTP or
an EDI mailbox, or a GUI.
The software didn't use XML parsers, the DOM or SAX internally (they didn't
exist when we started out), but still it benefited enourmously from
consistency and simplicity in the form of data expression. Descriptive tags
and a vertical/hierarchical structure greatly assisted the development of
generic message storage and querying, and facilitated the definition of new
functional, or hybrid messages by analysts, used to drive business
processes. In fact the XML-like structure was only rarely used for data
interchange, rather it was the central, common ground that allowed analysts
to build unified applications over messages expressed in many physical
formats, from many sources, with a set of generic tools. Our analysts found
it relatively quick and simple to add new messages, amend existing ones, or
alter the business rules, and this was at least in part down to data
structure.
When XML emerged, we took a good long hard look, and realised that
internally it gave us nothing that we didn't already have, but it did,
potentially, provide a simple and consistent set of rules for expressing
inter/intra-enterprise messages, whether or not we ourselves chose to
implement the DOM or SAX, etc within our own tools.
So, what I am rather long-windedly trying to say, is that in my own
experience, a tagged, hierarchical data structure can really help when
building often changing, message driven applications, that may require the
implementation of complex and varied business rules. XML, even without the
baggage it is acquiring, fits the bill pretty much as well as anything else
anyone has come up with, and some of the baggage has already proved quite
useful, even in its infancy.
I think that many problems people are having with XML, in my own narrow area
of experience, are down to the fact they try to use XML to help build big,
tightly integrated, distributed applications; rather than smaller,
independent applications, that just happen to have rather intense
conversations from time to time. In my experience, message driven
applications are akin to ordering something over the phone. You do not tell
the operator which fields to fill in on their screen, or which keys to press
on the keyboard, you just give them the information they need, in a language
they understand and let them get on with it. Let's face it, that can be hard
enough!
All the best
Mark Seaborne
|
