The Value of XML

XML provides a common data-exchange format, encapsulating both data and metadata. This format allows various applications and databases to exchange information without having to understand anything about one other. In order to communicate, a source system simply reformats a message, a piece of information moving from an interface, or a data record as XML-compliant text and moves that information to any other system that understands how to read XML.

Although we can now appreciate XML's value to application integration, it was originally created as a mechanism to publish data through the Web without the originator having to understand anything about the system sending the data. As the application integration problem became more evident, application integration architects and developers recognized the value of applying XML to the problem domain in order to move information between enterprises. The success of XML has led many people to refer to it as the next EDI.

Although XML's benefits sometimes appear revolutionary in scope, as a concept it falls short of being revolutionary. It also falls short of being the panacea for the application solution. We're not suggesting that it does not bring some real value to the application integration solution set. That value simply requires stretching XML far beyond its original intent which leads to a problem. Stretched too far, XML may be applied in areas where it stands little chance of success.

The overapplication of XML in so many areas of technology diminishes its real value and results in a great deal of unnecessary confusion. Perhaps most damaging is the predictable behavior of many vendors that look to recast XML using their own set of proprietary extensions. Although some want to add value to XML, others seek only to lock in users.

XML's power resides in its simplicity. It can take large chunks of information and consolidate them into an XML document meaningful pieces that provide structure and organization to the information (see Figure 11.2).

Figure 11.2. XML is a simple text representation of complex or simple data.

The basic building block of an XML document is the element, defined by tags. An element has both a beginning and an ending tag. All elements in an XML document are contained in an outermost element known as the root element. XML can also support nested elements, or elements within elements. This ability allows XML to support hierarchical structures. Element names describe the content of the element, and the structure describes the relationship between the elements.

An XML document is considered to be "well-formed" (that is, able to be read and understood by an XML parser) if its format complies with the XML specification, if it is properly marked up, and if elements are properly nested. XML also supports the ability to define attributes for elements and describe characteristics of the elements in the beginning tag of an element.

For example, XML documents can be very simple, such as the following:

 <?xml version="1.0" standalone="yes"?> <conversation> <greeting>Hello, world!</greeting> <response>Stop the planet, I want to get off!</response> </conversation> 

The Document Type Definition (DTD) determines the structure and elements of an XML document. When a parser receives a document using a DTD, it verifies that the document is in the proper format.

Some XML documents may be DTD specified, contain an internal subset, and possess a more complex structure, such as the following:

 <?xml version="1.0" standalone="no" encoding="UTF-8"?> !DOCTYPE titlepage SYSTEM   "http://www.frisket.org/dtds/typo.dtd" [<!ENTITY % active.links "INCLUDE">]> <titlepage> <white-space type="vertical" amount="36"/> <title font="Baskerville" size="24/30"          alignment="centered">Hello, world!</title> <white-space type="vertical" amount="12"/> <!  In some copies the following decoration is        hand-colored, presumably by the author  > <image location="http://www.foo.bar/fleuron.eps"   type="URL" alignment="centered"/> <white-space type="vertical" amount="24"/> <author font="Baskerville" size="18/22"   style="italic">Munde Salutem</author> <titlepage>[1] 

^[1] www.W3C.org.

XML parsers read XML documents and extract the data for access by another program. Parsers are becoming part of the middleware layer (defined later), able to process XML documents into and out of the middleware infrastructure (see Figure 11.3).

Figure 11.3. XML parsers extract information from XML.

XML metadata can be any attribute assignable to a piece of data; anything from concrete attributes to such abstract concepts as the industry associated with a particular document. XML can also be used to encode any number of existing metadata standards. The binding of data and metadata is a fundamental feature that maximizes XML's benefit to information-sharing scenarios. In fact, it is the feature most consistent with the concept of a common enterprise metadata repository that is supported throughout an organization or a common metadata layer shared within a trading community. Currently, XML is attempting to establish common metadata standards throughout the Internet in support of B2B, and within the enterprise in support of intracompany application integration.

XML provides individual industries with the ability to define common metadata within their domain. For example, the pharmaceutical industry defines the structure of product data quite differently from the automobile industry. As a result, its metadata definitions must be different as well. XML provides mechanisms such as namespaces (see the description in the "XML Namespaces" tidbit later in this chapter), XML-Schemas, and RDF for defining localized metadata around particular industries, or even between two or more trading partners. These metadata standards are just now emerging and have yet to find wide acceptance within trading communities.

Because XML is independent of any particular type of metadata format, there is little risk that a particular technology vendor will define its own set of metadata tags. In other words, XML cannot be made proprietary to any particular type of data. At least, that's the hope.

What XML Adds

Ironically, XML's real power is not in the technology itself but the fact that everyone seems to agree that XML provides an acceptable common format to allow applications within or between enterprises to exchange critical business information. XML is a momentum technology: Almost everyone concerned with storing or moving information such as database and middleware vendors hypes their products with claims of XML support. (Not surprisingly, they support XML in very different ways.)

XML also adds a foundation that other standards can build upon. As we'll explore later in this chapter, XML-enabled standards now exist for transforming information between applications. These standards include Extensible Stylesheet Language Transformation (XSLT, covered later in this chapter), BizTalk, XML for EDI (XEDI), and Commerce XML (cXML). They use XML as their base and expand in a specific direction to address a particular business issue.

What XML Does Not Add

The hype around XML threatens to turn us all into wide-eyed kids at a carnival, ready to eat too much cotton candy and get drawn in to every attraction. We need to step back, take a deep breath, and consider not only what XML does, but what XML does not do. XML is no exception to the pitfalls of other momentum technologies, in which end users tend to overestimate the capabilities of the technology and thus incorrectly apply them within their problem domain.

One common and dangerous misconception about XML is that it is a substitute for application integration technology such as middleware (including application servers and integration servers). Nothing could be further from the truth! In fact, the opposite is true.

As we already stated, XML is a simple, text-based document format that provides both metadata and information content. Nothing more. Nothing less. You or your vendor must provide the technology to move the XML documents from application to application. You or your vendor must make any necessary changes to your source and target applications so they can consume and produce XML. In other words, a lot has to occur before you can apply XML to application integration.

XML Namespaces

A namespace is a collection of names that may be used in an XML document as elements or attribute names. These can identify names with a particular domain and thus avoid redundancy, or allow the use of the same name with two different meanings. Namespaces in XML are identified by a Uniform Resource Indicator (URI), which allows each namespace to be unique. For example, we may have three elements known as "account." The first refers to a frequent-flyer account, the second is a bank account, and the third is a customer account at a hotel. Using namespaces, we can identify these different classes with a different and appropriate URI. Each account name is associated with a particular domain in our example, the airline URI, the bank URI, and the hotel URI, respectively. For example, we could place the following in the document to associate the element with a particular namespace:

http://www.airline.org.account

http://www.bank.org.account

http://www.hotel.org.account

The importance of XML namespaces in the context of application integration is their ability to define common application semantics between trading partners within a vertical industry. In other words, we can come up with a common notion of a customer, a product attribute, and other properties that are common within a particular vertical industry or trading community.

In order for applications using XML to be integrated, the applications must externalize the information as XML. Currently, few applications are capable of doing so. In order to be most successful, either the existing applications must change so they produce and consume XML or, better yet, they must leverage XML-enabled middleware technology.

XML-enabled middleware technology manages the extraction of information from the source system (or systems) as well as the conversion of the information into XML (if required) and the placement of the information in the target system (or systems). All this occurs automatically and is transparent to the end user.

XML does not make a good message format for information exchange, either intra- or intercompany. As we noted, XML is text based, and thus information that would normally exist in a binary message as "512 KB" could easily map to an XML document 20 times that size (see Figure 11.4).

Figure 11.4. Text-based XML is huge, which makes it a difficult format to transport from system to system.

Although XML provides a good point of integration when communicating with source or target applications within or between enterprises, moving information using native XML demands a huge overhead. As a result, most middleware vendors still use a binary message format, either proprietary or open, to move XML data and metadata from one system to another.