|Research, training, consultancy and software to reduce IT costs|
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.
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:
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.Next: XML-based programming 2: evolving a framework
Minimal IT: research, training, consultancy and software to reduce IT costs.