Integrating XML with other applications

Tired of yet another article on XML? I don't blame you; it's becoming increasingly difficult to separate the hype from reality when it comes to the potential benefits of XML. Needless to say, the widespread adoption of XML has particular significance for enterprise application integration. As more applications adopt XML as a means for externalizing data, the question of how XML is applied in the context of EAI becomes increasingly important. Some have even suggested that the adoption of XML will supplant the need for EAI technologies such as message/integration brokers. Nothing can be further from the truth!

To understand the potential of XML applied in this context, we must first understand the strengths AND the limitations of XML. You'll clearly see why XML complements, rather than replaces, the use of integration brokers in solving complex EAI problems. First, let's examine some of the strong points of XML.

XML's Strengths

• Powerful meta language. XML provides an easily used mechanism by which other markup languages can be developed for specialized needs or business domains. This is evidenced by the proliferation of markup languages such as Chemical Markup Language (CML), VoxML (Voice Markup Language) and VML (Vector Markup Language).


• Simplicity. XML is, generally, easy to understand because of its text-based approach. When you look at an XML document, you can usually understand the structure and data contained within the document and, because of that, can more easily manage the content.


• Separation of content and presentation format. Unlike HTML, XML cleanly delineates between the semantic content of the document and the presentation of the document.


• Common open standard. This is one of the great benefits of XML. There are no inherent ties to a specific proprietary browser, editor or interpreter. Instead, XML is a computing industry standard that has found broad acceptance and applicability across multiple industries.

As you can see, XML has particular strengths that are significant for EAI--but that's not the whole story. For the purposes of solving complex enterprise integration issues, XML has limitations that should be noted as well. Let's take a look at some of the limitations of XML with regard to application integration. What you'll discover is that these limitations are complemented and compensated by the use of integration brokers.

XML's Limitations

• Limited semantic interpretation. In the midst of the hype that surrounds XML, we may forget what XML does and what it doesn't do. While XML provides the ability to create specialized tags that describe a particular entity or behavior, the semantic interpretation of what the data represents is outside the scope of the XML document. For two parties to exchange documents, each party needs to explicitly agree on the meaning of tags and data within the document. For instance, in a procurement situation, both buyer and seller must agree on what a <CUST_ORDER_STATUS> tag might mean in an invoice document.


• No data transformation facilities. XML has spawned many business-specific exchange formats applied in the B2B space, such as Open Financial Exchange (OFX) or RosettaNet. However for EAI, the goal is still to integrate data from disparate applications. Within the enterprise, XML is simply one of many data formats that exist, and the need to transform data still remains a primary challenge.
  
  
  
  Integration brokers provide advanced data transformation capabilities, enabling the reformatting of data from multiple sources. Unlike current B2B trading activities that are primarily point-to-point interactions, EAI requires complex splitting and merging of data to and from multiple sources, and the combination of dependent data as part of integrating business processes.


• Inefficiencies of text-based documents. For EAI, the movement of text-based documents can prove extremely inefficient. Externalized documents such as SAP AG's SAP Intermediate DOCuments (IDOCS) and the Open Applications Group's Business Object Documents (BODs) are repeating data structures that can be extremely large. Putting these documents "on the wire" is simply not acceptable for efficient network bandwidth utilization, especially when the throughput for document processing increases.
  
  Even with compression, the results are still generally poor. Perhaps more importantly, when performing EAI transformations, computations often require that the transformation and rules engines deal in native data types instead of pure text. How do integration brokers handle this issue? The reality is that many of the advanced integration brokers and transformation hubs will convert XML documents into binary objects with hierarchical structures in order to gain a more efficient data package for transformation.
  
  
  
  The XML Document Type Definition (DTD) is read and converted into an integration broker definition package. The integration broker then reads the XML document as it would any other file format, parses and compiles it into binary form. The resulting object has all the content and attributes of the XML document but is generally less than a tenth its size. When processing thousands of documents, a smaller binary package means faster distribution and more efficient use of network bandwidth. On the other end, the binary object definition package enables the integration broker to produce a document in XML form. The binary object definition package is also converted into a corresponding DTD.


• Absence of content-based routing. Content-based routing and rules are central to the automation and dynamic management of integrated business processes. XML cannot inherently deliver this ability. Integration brokers can "read" document content, apply business rules and intelligently route the message to the appropriate destination. For example, Company A receives an invoice from a B2B trading partner in the form of an XML-based document. However, Company A has internal rules regarding the processing of the invoice; rules that vary depending on the value of the invoice or the profile of the partner. These rules also affect the billing and customer service for that partner. Integration brokers are key to automating these processes, applying rules and delivering transformed data to the billing and customer service systems.