Although a number of standards exist for information interchange and process definition, industry standards have yet to emerge for defining common integration server and B2B integration server services such as routing, rules processing, and transformation. In the absence of such standards, individual vendors have created proprietary approaches to these basic information-processing services. As a result, we are confronted with features that are not interchangeable, require specialized training, and do not provide a common framework of services.

Even as we begin to implement standards such as XML as mechanisms to manage information interchange, we are also looking to create standards that support information processing within the middleware. These standards will define services common to most integration servers and to B2B integration servers, including rules and transformation.

XSLT seeks to fill the need for a standard approach to both rules and transformation processing. Like XML, XSLT could become the preferred standard mechanism for transforming content and application semantics as information moves from application to application and business to business.

The power of XSLT resides in its simplicity, tight integration with XML, and the completeness of the standard. Although it does not provide every type of out-of-the-box transformation service currently found in most integration servers and B2B integration servers, XSLT provides the infrastructure to create such services through an extensible and declarative programming language.

XSLT has been covered in great technical detail in XML-Journal, so we won't dwell on the details here. However, I can say that XSLT is a language designed to transform one XML document into another, changing both its schema and content in the process. At its most primitive, XSLT is a text-processing system that enables the programmer to transform XML documents, or, if required, generate other standard markup languages such as HTML (or any text, for that matter). The transformation capability that XSLT offers is a fundamental service required within almost all application integration problem domains; however, it is indeed redundant to other proprietary transformation services already existing as features of modern application integration technology.

XSLT is the preferred method of converting data structured within XML. You can leverage XSLT for the following:

• Extracting data
• Validating data
• Persisting data
• Converting attributes to elements
• Converting elements to attributes
• Changing the metadata and content of an incoming XML document to create a new outgoing XML document

Although XSLT has tremendous promise, a huge disconnect remains between what XSLT provides and what middleware needs to offer in terms of transformation, the primary differences being:

• Support for complex transformations
• Efficiency during transformation processing
• The need for programming

Because that is the case, to process messages using XSLT the messages must first be transformed into XML text (or any text) for XSLT transformation and then be transformed back into a binary message. Efficient? Clearly not. Even as a few integration servers and application servers look at XSLT as their standard mechanism for transformation, it is apparent that building text processing into existing binary messaging systems will be difficult.

XSLT will fit into some middleware products and not others. XSLT almost certainly will succeed as a standard transformation mechanism in products that already process information as raw text or XML. If XSLT continues to pick up speed, other middleware vendors will inevitably follow the crowd. However, those of you moving from advanced proprietary application integration middleware to XSLT will notice the lack of features right away, and may indeed pass on XSLT due to the comparative limitations.

Those moving from the more primitive mechanisms for transformation to XSLT may have a much better opinion. XSLT provides several advantages over SAX and DOM. Its design is based on the fact that most transformation programs use the same design patterns, and therefore can be automated using a higher-level, declarative language. (Stating that the XSLT language is declarative means that it describes the transformation behavior rather than a sequence of instructions necessary to perform the transformation. In other words, XSLT describes the transformation and then leverages the XSL processors to carry out the deed.) Moreover, when XSLT is used, the requirements of transformation can be expressed as a grouping of rules that define what output should be created when a particular pattern is encountered.

XSLT does not operate directly on the XML text. Instead, it relies on a parser (DOM or SAX compliant) to convert values into an object tree for processing. It uses this tree to manipulate the structure in memory. XSLT enables the user to take advantage of the native language to navigate around the node tree, select nodes, and alter the nodes as the transformation requires.

XSLT and Application Integration
XSLT is not the solution to every application integration requirement. It is, however, an important piece in the puzzle. XSLT's great potential lies in its ability to finally provide a standard transformation mechanism that everyone can agree upon, one that does not require application integration architects to relearn technology as they move from vendor to vendor.

There are several other advantages to using XSLT for transformation, including the following:

The fact that not all standards make it, and XSLT could lose momentum and thus lose wide support, like so many other standards in the past.

Published Dec. 3, 2003— Reads 10,503
Copyright © 2008 SYS-CON Media. All Rights Reserved.

About David Linthicum
David S. Linthicum is an internationally known thought leader in the EAI, SOA, enterprise architecture, and Web 2.0 spaces. He is a sought-after consultant, speaker, and writer, and formed David S. Linthicum, LLC (www.davidlinthicum.com), a leading consulting organization focusing on enterprise architecture, SOA, and use of the next-generation Web within the enterprise. He is the former CEO of BRIDGEWERX, CTO of Grand Central Networks, as well as CTO of Mercator Software (now a part of IBM) and SAGA software (now a part of Software AG).In addition, Dave was an associate professor of computer science for eight years, and continues to lecture at major technical colleges and universities, including University of Virginia and Arizona State University. He keynotes at many leading technology conferences, and has several well-read columns and blogs, as well as a weekly Podcast. Dave has authored 10 books, including the ground-breaking "Enterprise Application Integration" and "B2B Application Integration." You can reach Dave at david@davidlinthicum.com.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...