Probably the toughest lesson to learn is not the one we get when we are seeking to learn. Rather it is the one which creeps under the door, rears its ugly head and smacks us soundly on the nose. As one saying goes, "In the school of hard knocks, the lesson comes after the test!"
Last week I watched an episode of the BBC's new update to the classic series "Dr. Who", in which some of the gifts exchanged between visiting dignitaries turned out to contain little spider-like robots which get loose and create havok and death. Small packages can deliver major revolutions.
For example, many of us got our start in understanding XML in a very simple way - by editing its big brother, HTML. After all, in the days before Frontpage or its ilk, a lot of us created and edited our own web pages using a text editor like notepad or emacs and typed in the HTML tags directly. (Sorry to admit, notepad and vi are still my wed editing tools of choice on at least two of the sites I work on).
The reality is that XML has become the "little engine that could" in data interchange. Just as TCP/IP is a very simple networking protocol, the complexity of the entire internet has been heaped onto this humble packet format. In the same way, XML has become the common language (the lingua franca) for applications that want to exchange data. On top of this humble spec has been layered an awesome tower of standards, software and expectations. I think it was 1997 or 1998 or so when I finally realized that XML or something like it was the language we were going to use when we wanted to glue loosely-coupled applications together no matter what they wanted to exchange.
Now as people talk about developing web services, service oriented architectures, software as a service, XML is at the heart of all of it.
The problem is, XML wasn't designed for computers to process data efficiently. It was designed to be human readable. As a result, we will consume a lot of time in applications processing XML - parsing it, translating its Unicode into internal formats, validating it, securing it and routing it about the network efficiently.
I could simply wait until Moore's Law catches up to this problem and throw transistors at it. This isn't a bad approach actually to some of the performance problem. I'm just afraid that as an internet economy, the XML future hope will become the XML present headache a lot quicker than we think. One example for starters: Radio Frequency Identification (RFID) tags will start showing up on all kinds of packages and boxes in flight, all of which generate XML data whenever they are actively or passively scanned. As a result, the stream of XML data is going to turn into a flash flood before we know it.
Which is why you probably need to put some thinking into XML today. Several questions to think about - how do I authenticate these XML messages? How do I route them quickly to the right application to handle them? And how do I parse them as fast as possible?
If you are an experienced application developer, I'm betting that you won't want to become the world's expert in XML and all of it's many standards and implementations. It's more importantant to get your job done. That's why you should try to find some trusted partners who can help you solve your XML problems. I found some good resources for this in the Intel Software Network site, and I know there is more to come here.
Some of these problems could be solved with Intel's XML Appliances. At this year's Software Enabling Summit, I saw a great demo showing a secure healthcare implementation, between users and healthcare providers, running on the Intel XML Appliance for security, XML routing and acceleration. This is definitely something to keep your eyes on.
Part of your thinking should also be driven by what I call the "Core Software Strategy", which I will write about later.
Is XML the solution to all of our data interchange problems? Are there good solutions today to the problems of security and performance? What do you think?
Note: this piece reflects my opinions only, and not the opinions or strategy of Intel Corporation.