XML: A Managers Guide (2nd Edition) (Addison-Wesley Information Technology Series)

Exposure to the many initiatives related to XML messaging often makes the topic appear complex to newcomers. However, this apparent complexity results from many layers of detailed decisions rather than the inherent difficulty of the underlying concepts. Attacking this topic at the conceptual level provides an easily comprehensible framework for examining the details of different initiatives later.

Much of the confusion surrounding XML messaging stems from the fact that it has two distinct motivations that became intertwined while the protocols were being designed. Therefore, from the individual perspective of either motivation, different initiatives appear to address superfluous issues. Separating these motivations quickly clears up much of the confusion.

The first motivation is to enable the automated exchange of XML business documents among software applications. This motivation is easy to understand. It makes little sense for a group of enterprises to agree on XML formats for catalogs, purchase orders, and invoices without a standard means to send these documents over the Internet. Certainly, they could e-mail or FTP them to each other, but processing would require human intervention. A better solution would be a standard protocol that software applications could use to exchange such documents directly. We'll refer to this motivation as business document messaging. It is the same motivation behind traditional EDI systems.

The second motivation is to have a standard means of exposing remote interfaces that other software could use to access application functions. Notice that there is nothing XML-specific about this motivation. In fact, a number of similar attempts have been made in the past, such as the OMG's CORBA and Microsoft's COM. Unfortunately, these past attempts did not result in the widespread interoperability that organizations were looking for. Because XML has achieved broad cooperation among vendors and enterprises, another attempt at achieving this desired interoperability makes sense. We'll refer to this motivation as remote interface messaging. It is the same motivation behind distributed object computing.

The protocol requirements for business document messaging and remote interface messaging have a significant amount of overlap. Both need to get XML data from one point to another over the Internet. Theoretically, you could even argue that business document messaging is actually a subset of remote interface messaging. Simply define a remote interface with one function ”"process business document" ”that takes a single parameter ”"business document." However, this argument ignores the practicalities of how developers architect business document versus remote interface messaging applications.

The desire for common infrastructure further complicates the issue. If many applications use the same infrastructure, it reduces costs and increases robustness in the long run, even though this infrastructure might not provide an optimal feature set for any particular application. XML messaging evolved based on the belief that it would be possible to create a simple protocol that satisfied the requirements of both types of messaging. Only after the practical constraints of developing these systems emerged did it become clear that a single protocol would have to be more complicated than originally envisioned . Nevertheless, the benefits of a common protocol may still outweigh the costs.