The New Integration Architect: You

Dec. 16, 2002 12:00 AM

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:

XSLT is a declarative language: Unnatural for programmers who have been trained in and have been doing procedural programming for years.

XSLT is heavily driven by the source document: Makes it very tricky to predict the outcome simply by visually scanning the source document and the stylesheet.

Creating transformations: A simple case is a source document that has <zip-code>, the target document needs <postalCode>. A stylesheet transformation can also include more complicated things like extracting multiple line items of a purchase order into separate XML messages. How about being able to just visually place the source and target documents side-by-side, connect the dots, and let a tool generate the XSLT for you?

Modifying transformations: What's the round-trip experience of changing an XML document and updating its associated stylesheet? Why should you manage this by hand, when you can automatically generate it with a tool?

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.

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.

Your Feedback

The New Integration Architect: You

Thomas Elmiger wrote: I like the vision of ESB very much. I strongly feel, that this is the way to go. In fact I have waited for years for such a thing to emerge. However most babys look pretty when they are young. The devil often is the detail. I hope it will be possible, to keep ESB clean and simple. An example of a good idea that was then mistreated is XSLT. We have completed a quite sophisticated XML project using XSLT as the basic mechanism to transform XML to HTML. Of all techniques we came across in the last few years (and there are many), XSLT was liked least by the team. It is cryptic to write and read, difficult to debug, lacking many things you desperately need and prone to errors. Note that we came to this conclusion, though we were using StylusStudio (the top tool) from the very beginning and had access to a guru in both XML, XSLT and the tool. Thus my advice: if you can avoid XSLT, avoid it! It...