XML Meets Middleware

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 that encapsulate or abstract XML and ensures that those messages are understood by any source or target applications that need the information (see Figure 11.5). 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.

Figure 11.5. Leveraging middleware and XML to move information.

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. In truth, it is not particularly difficult to XML-enable a product. Therefore, vendors were able to react quickly, for a change.

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.