Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
