Quit it with the Web Services "bloat"

I'm getting a bit annoyed at people ranting about Web Service "bloat" or inefficiency and then gibbering on about Ruby on Rails or the like. Lets be clear

1. Server side Web Service and XML stacks are not optimised for binary executable size
2. That doesn't mean it isn't possible

Back in 2002 I was presenting at JavaOne on "Mobile Web Services" where we demonstrated a number of device to device interactions. These used a server intermediary to bridge the connections between the phones (simulated phones because the GSM network in Moscone was practically non-existent back them) something that looked a lot like comet (cheers Gavin) which was a bugger to make reliable over GSM. As an aside the old JavaPhone API allowed phone to phone comms.

Anyway so back then we talked about how to get Web Services running on mobile phones (including noting that Web Services != WS-*, it was about the Service design). Around that time I had a Nokia 6310i which was pretty much the first MIDP phone I could get my hands on. It had 30kb available for programme (compiled) space so I set myself a challenge to write something that used Web Services from the phone. If anyone saw the quick code example that Duane did at JavaOne then basically that is what I did. Using a stripped down (very stripped) version of ksoap the little client allowed you to enter a city name, it then returned a list of airport codes related to that name, you could then pick one and it would display the current weather report for that airport. It made two different WS calls and worked perfectly well in 30kb of executable on a mobile phone

Now this isn't best practice WS for many reasons, mainly however because memory and CPU are rarely the biggest issues on modern server infrastructures. The point is therefore what are you trying to save on a server? The answer is support time as that represents the biggest cost. Doing my stripped down WS stack on a server would be mental as it would be practically impossible to support and wouldn't be flexible.

The only bloat that really matters is support bloat and every technology that saves a couple of lines in developer time but adds time to support is a failed technology.

Bloat isn't a code issue on server software, its a support issue.

Technorati Tags: SOA, Service Architecture