Minimal IT - XML-based programming 1: means, not ends

1 June 2010

XML-based programming 1: means, not ends

XML is not just a data interface standard. It also solves problems in design, development and programming.

This is the start of a series of newsletters about development. If you are a management sort who does not like anything technical, look away now.

Still here? Good. I want to share with you a journey I have taken into a style of development which we could call "XML-based programming".

My journey started in the late 1990s. I was working on new integration standards for my employer. I had previously used EDI standards, and had implemented a variant of these for data transfer inside the company. Old EDI-style formats were relatively inflexible, and when we saw how flexible XML was, we adopted it enthusiastically as part of the new standards.

Having adopted XML, I got involved with many package vendor's early attempts at XML-based integration. There were many problems.

Many vendors bolted integration tools around their products. Most of these were rubbish. Integration needs to be designed into the product.
Most applications that did design integration into the product were rubbish at XML. They were translating to and from XML at the edge of the application, but internally using something else, and this caused many problems.

From these years of frustration I learnt that the best integration is based on XML, but to do this well you have to implement XML directly into the code.

When I left that company, I wanted to refresh my skills and decided to learn web-based development. In my earlier career I had worked with many old and ill-structured CICS COBOL applications, and had learnt the hard way the fundamental importance of separating user interface code from business logic.

Not wanting to experience the same problems in web development, I looked at design approaches with strong separation between user interface code and business logic. Many of these approaches use a Data Transfer Object pattern, in which a dumb object is used to pass data between different subsystems.

I started experimenting with the pattern, but I found it very tedious. I had to code Data Transfer Objects by hand, and it was hard to develop the sort of complex data structures you need to build a web interface. A number of things came together in my mind:

I need to transfer complex data between different parts of the application.
Writing data transfer objects by hand is too hard.
XML could work as a universal data transfer object.
This would also achieve the direct XML support that is the basis of effective integration with other applications.

So I adopted using XML internally within the application, primarily as a way of achieving good separation between different parts of the application, and secondarily as a good basis for integration.

That was the start of my XML-based programming. I used XML not because I had an imposed requirement to support XML, but primarily as an aid to programming. XML was a means to and end, not an end in itself.

Next week I will describe how this approach evolved into a rich development framework.