XML Meets Middleware

Now that we have established that XML is a simple, text-based standard and, as such, cannot provide everything needed to integrate disparate applications, it quickly becomes clear that in order to provide maximum value to the application integration solution set, XML needs middleware (and, conversely, middleware most likely needs XML).

XML's value to middleware is clear. Middleware simply "carries the load." It moves messages (XML documents) that encapsulate or abstract XML and ensures that those messages are understood by any source or target applications that need that information. Middleware may also manage the interfaces with the source or target applications and move information into and out of the applications through an unobtrusive point of integration such as a database or an API.

Because of XML's value, every middleware vendor, new and old, has declared dominance in the XML space, applying its technology to application integration problem domains. None of us should be surprised that there is a certain degree of "puffery" to these declarations. The truth is that it is not particularly difficult to XML-enable a product. Therefore, vendors were able to react quickly.

XML-enabling a product is simply a matter of embedding a parser within the middleware and teaching the product to read and write XML from and to the canonical message format. In addition, because many of these products already have native connectors to traditional enterprise systems and data stores, such as SAP, PeopleSoft, and DB2, they provide enterprises with the ability to produce and consume XML without impacting the applications.