According to Gartner, Inc., vice president and research fellow Roy Schulte, "a new form of enterprise service bus (ESB) infrastructure will be running in most major enterprises by 2005." ESBs combine Web services, enterprise messaging, transformation, and routing to provide an integration network that can span global enterprises and encompass potentially thousands of application end points. Application integration is a top priority among CIOs, and as the current IT value center in the enterprise, IT organizations must shift their focus from application development to application integration. The convergence of this IT spending trend, and the availability of standards-based technology and tools for integration, means IT developers are the next integration architects.

While a thorough technical analysis of this ESB infrastructure is beyond the scope of this brief editorial, I would like to look at what many consider the defining characteristic of integration: transformation. As the focus of this month's issue is tools, tips, and tricks, It seemed appropriate to focus on the importance of tools for creating and managing XML and XSLT transformations.

The Role of XSLT Transformation
XML is a common way of representing data that is being routed between applications within an enterprise, and between business partners. However, standards for packaging XML are constantly evolving. We have competing standards in place for representing common business objects, such as billing and ship-to addresses. Business partners may have chosen to implement their own proprietary XML formats. Yes, we live in a time where we already have legacy XML formats that we have to deal with!

It is fairly common practice for an enterprise to use a single common format for packaging up XML data as it travels throughout the enterprise between applications across the ESB, then set up translation services to convert data to and from the target formats. The translation service can be part of an adapter to an application, or can serve as part of a collaboration with an external business partner. The idea is that each transformation service at each end point can be solely responsible for translating data between the common XML format and the target format of the application consuming the data.

XSLT (eXtensible Stylesheet Language for Transformation) is an ideal way of converting XML data from one form to another. Using an XSLT processor, a stylesheet can be applied to a source document to produce one or more output documents. The output document can be another XML document, HTML, or plain text. The XSLT processor can add to, copy, remove, or rearrange the contents of the source document in accordance with the instructions found in the stylesheet. Extensions may be applied to the transformation in the form of Java, JavaScript, VBScript, or any language the XSLT processor supports, to allow more detailed control of the transformation.

The Role of Tools in Creating and Managing XSLT Transformations
You might consider yourself a code-slinger who doesn't need any fancy tool stuff. You've been using vi for years and that's all you'll ever need. You may even have migrated to Notepad. Why go further? For starters - XML is extremely verbose! Well, that's old news, but that in itself makes one yearn for simple pleasures like color coding, bracket matching, and tag completion. That's all well and good, but how do tools apply to XSLT? What are the issues? Why should you care? Here are a few reasons:

Eventually this XML data that is being shipped around needs to be visualized by humans: Either for diagnostic purposes or for formal presentation in applications. XSLT is perfect for that job too. Having a tool that allows you to drag and drop elements and attributes from an XML document directly onto an HTML canvas can be very handy for creating the XML-to-HTML transformation.

The instant gratification using the IDE-style metaphor of "edit/compile/run" that most of us have grown accustomed to should apply to writing transformations as well. There's no substitute for being able to automatically apply a stylesheet to a piece of data and immediately see the output. For some folks the IDE metaphor is more often "edit/compile/debug," and that should be OK in this world too. Think of being able to set breakpoints in the XSLT document, or in an associated Java extension, and being able to step through a transformation and watch it happen. How about back-mapping from a destination document - being able to click on the piece of data in the output document and to automatically be brought to the line of XSLT code that produced that data? You just don't get that in Notepad.

As you and your IT staff gain responsibility for a greater share of integration projects, XML technology, skills, and tool sets will become increasingly important to the success of your integration projects, and indeed your success as well.

Published Dec. 16, 2002— Reads 15,421 — Feedback 3
Copyright © 2002 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

About Dave Chappell
David Chappell is vice president and chief technologist for SOA at Oracle Corporation, and is driving the vision for Oracle’s SOA on App Grid initiative.