The CDATA board of education

During my days on the web services team of a big bank a couple years ago, we wrote a ton of web services on the java platform. Almost every service we wrote was SOAP based, and also conformed with a huge pile of enterprise standards that were actually pretty non-standard in the outside world.

The consequence of these slightly non-standard services were that first-time clients of our services sometimes had painful integrations with us. Most notably .NET clients that wanted to auto-generate their client proxy classes. The tool would simply not work with our WSDL, so they had to manually bind to our services, which greatly increased their cost and dates. We didn't care though - the services we wrote were compliant according to our tools, and we simply didn't care that much about the clients that were having trouble connecting to our services. Suck it up, you whiners. We hand wrote all our services from the contract on down, and we're not going to bend over backwards for some whiny .NET'r that can't step outside the confines of his "Add Web Reference" tool.

Fast forward to the last few months. I've written client code for four different service providers. One SOAP, one TCP (I didn't know people still wrote raw TCP-based services!), and a couple XML over HTTP services.

The integration that made me shameful of my former attitude was one of these XML "services" that consists of a large amount of non-normalized CDATA. For example:


<[CDATA[
ColumnHeaderA ColumnHeaderB ColumnHeaderC
aaa bbb ccc
ddd eee fff
ggg hhh iii
]]>


My attitude was that any self-respecting programmer would not be serving up text data that should not be parsed by the XML parser and pass it off as a service, forcing clients to use regular expressions when they should instead be using a proper XML parsing tool. The product manager couldn't understand why I felt that this service was no friend of mine. Their opinion was that it was a perfectly good service, and any average programmer could crank it out in a week.

Why? Because they wrote everything in perl!

It caused me to think back about those clients that I've wronged by not making their lives as easy as it could be. Not to mention gave me another anti-pattern to look out for.

Words of wisdom? When writing a public XML service, do eat your own dog food using different platforms and techniques to evaluate the palatability of your service. Also, write client code for a few other public services to see what feels good, and what's painful from the client's perspective. For example, do you really need to namespace your XML? Does SOAP make it harder or easier for what you're trying to offer? You might be surprised by what you find to be elegant from different sides of the service.