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

The Value of XSLT
It is important to remember that XML documents are like messages. And because each application has its own unique set of application semantics, documents moving from application to application need to be transformed. Both data structure and content must be semantically correct in order to load into the target application. If the data is not in the proper format, the update operation is likely to fail.

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

The state of the technology of most integration servers, supporting complex but valuable information transport, may indeed be a better fit for binary messaging, which is more efficient than text-based messaging and is easier to manage and process. However, the tradeoff is that binary messaging does require that specialized systems (such as message-oriented middleware) manage it, and it is not as easily managed by external systems as text-based messaging (e.g., XML).

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:

A common language for transforming application semantics as text or XML moves between applications.

A common standard for representing transformation behaviors

A common input and output message/document structure

Backing from most major B2B and intracompany application integration technology vendors and consultants

However, there are limitations to consider as well, including the following:

Complex transformations are difficult.

Programming is almost always a requirement.

The slow emergence of vendor support because of the limitations of existing technologies (e.g., moving from binary messaging to XML text).

The technical limitations, including performance and security, of using text, and only text.

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.