So here’s my little war story for Cameron’s XML Abuse Contest. I’m sure Sam Ruby has quite a few as well, and people like him – who work closer to the WS-* hell – will win this contest, as clearly denoted by his brilliant and disturbing “Reality is Corrosive”.
I’ll throw in my two pennies anyway. Couple of years ago I was working at the second largest mobile telecom company in Sao Paulo, and we had a project with pretty much all the symptoms of a horrible catastrophe: large team, no crystal clear goal, no QA, shoddy source control system, poor choices of tools, and one of our missions was to integrate BEA Tuxedo with enough EJBs to invade a middle-eastern country with.
So the project leads, in all their wisdom, thought it would be a good idea to teach us a lesson by bringing XMLink to the table, thus completing our fabulous toolset with this marvel of modern software engineering and buzzword compliance.
The team went on a coding rampage for a couple of months. No deployment was ever made during that period, and no full build was attempted. I’m not blaming XMLink for all of the chaos that ensued, but this is an XML abuse story, so I should focus on it a bit.
I barely remember the details, and I’m just too weak to look at its documentation again, but basically we were using it to transfer data in and out largely bloated Tuxedo calls. You know, the typical stored-procedure-like thing. XMLink creates this huge XML message for each call, each parameter and each return, which is perfectly acceptable if your point-of-sale system can bear a 10 seconds-per-call until the transformations and byte-chewing occur. Put Websphere 4.0.1 (this was 2002) on top of it, on a subdimensioned hardware architecture, sit back and watch the fireworks.
Luckily, the project was canned before it was ever built, and I left the gig for some sanity – which took me a while to find again.