I’m now in a 3-day SOA course in John Bryce, courtesy of my IBM scholarship. I wanted to start ranting about SOA applications, but two things got in my way:
- Those smart guys at John Bryce have a switch that turns off the students’ monitors while the instructor talks, so I can’t surf the web too much during the course (If only it worked with students’ cell phones…)
- We didn’t actually learned any real SOA material yet
The course starts off with a long introduction to XML. I guess that’s an essential introduction to a platform that puts all of its power on top of an XML-based technology stack. It looks something like this:
<crunch>balls</crunch>
In other words, if something doesn’t fit into the XML view of the world, kiss your SOA assets goodbye.
That reminds me why XML is not such a great format for “everything you’ll ever need”. It’s birth-in-sin from SGML and other early web formats left it with a wierd heritage: Awkward delimiters (what was wrong with curly braces?), uncomfortable escape sequences (why & and not just \& ?) and redundant syntax (why both elements and attributes?).
However, XML’s most serious limitation is that it is a textual format. A binary format would have been more compact, flexible and efficient for machine processing. The claim that binary formats cannot be standartized because they are too platform-dependent is a lame excuse: The Java bytecode is a binary format based on a Tag-Length-Value (TLV) recursive structure, and it is platform-independent. PDF also comes to mind.
XML prevailed because it is human-readable. The tech guys who came up with it couldn’t resist the temptation to make something that you can just hack with Emacs. Accessibility to basic tools is a noble ideal. I am not sure, however, that it can count as a technological advantage – Not when you’re using it to send a 2-MB chunk of inter-process communication.
Nevertheless, it seems that until someone re-implements the entire XML stack using some binary format, it is here to stay.
<farewell>Cheers.</farewell>
